RFR: 8000780 back ported Fix zero fail to build in JDK7u-dev [updated] (original) (raw)

Volker Simonis volker.simonis at gmail.com
Mon Mar 25 12:46:12 PDT 2013

Hi,

I've just realized that something must have gone wrong during the downport of 8000780 to hsx24 (probably because of the change of the content of the f1 and f2 fields in the ConstantPoolCacheEntry between hsx24 and hsx25). Unfortunately now both, '_invokedynamic' as well as '_invokehandle' don't work in the CC-interpreter anymore. The attached patch (against hsx24) fixes the problem and lets the Zero-VM pass the java/lang/invoke JTreg tests again.

These changes are needed for making JSR292 work in the Zero-port in jdk7u with hsx24.

Can somebody please open a bug for this issue and review the changes. (I can also submit a full RFR with webrev once there's a bug ID).

Thank you and best regards, Volker

On Mon, Jan 21, 2013 at 11:15 AM, Alejandro E Murillo < alejandro.murillo at oracle.com> wrote:

Thanks Vladimir, I pushed this on Friday, will be in 7u/7u/hotspot next time we take a snapshot of hs24 cheers Alejandro

On 1/18/2013 3:00 PM, Vladimir Kozlov wrote: Looks good.

Vladimir On 1/18/13 8:37 AM, Chris Phillips @ T O wrote:

Hi Alejandro,

Have updated the webrev (just off by one line in 1 file) and built both normal hotspot and zero on x8664 based on the hsx24 repo head: http://integral-portal.lgonqn.org/temp/ChrisPhi/hsx24b31- 8000780-zero20130118webrev/<http://integral-portal.lgonqn.org/temp/ChrisPhi/hsx24b31-8000780-zero20130118webrev/> [Also now contains updated copyrights] Cheers! Chris On 18/01/13 05:56 AM, Alejandro E Murillo wrote:

Hi Chris (Phillips) I just got a snapshot of hs24 and bumped the build number to b31, so we can resume pushing bug fixes to it. Unfortunately the patch in the webrev at [1] does not apply cleanly anymore, Can you guys reapply the changes to clean clone of [2] and send the new webrev? Then if the previous reviewers approve it, I will push that soon after so it makes it into next week snapshot. Apologies for the extra work [1]http://integral-portal.lgonqn.org/temp/ChrisPhi/ jdk7u-dev-zero-hs24b29**20121222/<http://integral-portal.lgonqn.org/temp/ChrisPhi/jdk7u-dev-zero-hs24b2920121222/> [2] http://hg.openjdk.java.net/**hsx/hsx24/hotspot<http://hg.openjdk.java.net/hsx/hsx24/hotspot>

Thanks Alejandro On 1/2/2013 1:02 PM, Christian Thalinger wrote: On Dec 22, 2012, at 10:15 AM, Chris Phillips @ T O<ChrisPhi at lgonqn.org> wrote: Hi Alejandro, Oops emails crossed in the net ... See my latest email , I had to regenerate the webrev and patch - This webrev s/b ok: Webrev: http://integral-portal.lgonqn.org/temp/ChrisPhi/jdk7u-dev- zero-hs24b2920121222/<http://integral-portal.lgonqn.org/temp/ChrisPhi/jdk7u-dev-zero-hs24b2920121222/> That looks good. -- Chris Chris On 22/12/12 01:03 PM, Alejandro E Murillo wrote: Hi Chris, In that case is not necessary. I initially thought the webrev was against jdk7u/jdk7u-dev/hotspot but looks like it is against hsx/hsx24/hotspot. BTW, I went to check the webrev link and is unreachable, can you check that? Thanks Alejandro On 12/21/2012 9:53 PM, Chris Phillips @ T O wrote: Hi Alejandro, The only change since I tested this afternoon is the change for the hotspotversion. I will re-run tests if you wish but it seems unnecessary. Cheers! Chris On 21/12/12 07:40 PM, Alejandro E Murillo wrote:

On 12/21/2012 4:34 PM, Chris Phillips @ T O wrote:

Hi

{Not sure if this needs a new bug or not, it definitely needs a sponsor - Twisti ? } Attached is a backport (essentially resurrection of the Permgen code) of 8000780 now updated with Roman Kennke's comments. Checked and built against hsx24b28. (Current jdk7u-dev hs) Please review. Cheers! Chris PS Webrev is here: http://integral-portal.lgonqn.org/temp/ChrisPhi/jdk7u-dev- zero/hs24b28/<http://integral-portal.lgonqn.org/temp/ChrisPhi/jdk7u-dev-zero/hs24b28/>

Hi jdk7u-dev/hotspot corresponds to hs24-b27. I just got the hs24 snapshot for b28 and bumped the number to b29, Can you rework the patch/webrev against this repo: http://hg.openjdk.java.net/**hsx/hsx24/hotspot<http://hg.openjdk.java.net/hsx/hsx24/hotspot> once it's reviewed I can push it Thanks

-------------- next part -------------- diff --git a/src/share/vm/interpreter/bytecodeInterpreter.cpp b/src/share/vm/interpreter/bytecodeInterpreter.cpp --- a/src/share/vm/interpreter/bytecodeInterpreter.cpp +++ b/src/share/vm/interpreter/bytecodeInterpreter.cpp @@ -2173,12 +2173,13 @@ // This kind of CP cache entry does not need to match the flags byte, because // there is a 1-1 relation between bytecode type and CP entry type. ConstantPoolCacheEntry* cache = cp->entry_at(index);

@@ -2197,23 +2198,19 @@ u4 index = Bytes::get_native_u4(pc+1); ConstantPoolCacheEntry* cache = cp->secondary_entry_at(index); - oop result = cache->f1_as_instance(); // We are resolved if the f1 field contains a non-null object (CallSite, etc.) // This kind of CP cache entry does not need to match the flags byte, because // there is a 1-1 relation between bytecode type and CP entry type. assert(constantPoolCacheOopDesc::is_secondary_index(index), "incorrect format"); - if (! cache->is_resolved((Bytecodes::Code) opcode)) { + if (cache->is_f1_null()) { CALL_VM(InterpreterRuntime::resolve_invokedynamic(THREAD), handle_exception); - result = cache->f1_as_instance(); + // GC might move cache while returning from VM call. + cache = cp->secondary_entry_at(index); // reload } - VERIFY_OOP(result); - oop method_handle = java_lang_invoke_CallSite::target(result); - CHECK_NULL(method_handle);

@@ -2241,10 +2238,11 @@ if (! cache->is_resolved((Bytecodes::Code) opcode)) { CALL_VM(InterpreterRuntime::resolve_invokehandle(THREAD), handle_exception); - cache = cp->entry_at(index); + // GC might move cache while returning from VM call. + cache = cp->entry_at(index); // reload } - methodOop method = cache->f1_as_method(); + methodOop method = cache->f2_as_vfinal_method(); VERIFY_OOP(method);

More information about the hotspot-dev mailing list