RFR: 8000780 back ported Fix zero fail to build in JDK7u-dev [updated]
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 x86_64 based on the hsx24 repo head:
>>> http://integral-portal.lgonqn.**org/temp/ChrisPhi/hsx24b31-**
>>> 8000780-zero_20130118_webrev/<http://integral-portal.lgonqn.org/temp/ChrisPhi/hsx24b31-8000780-zero_20130118_webrev/>
>>> [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-hs24b29_20121222/>
>>>>
>>>> [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-hs24b29_20121222/<http://integral-portal.lgonqn.org/temp/ChrisPhi/jdk7u-dev-zero-hs24b29_20121222/>
>>>>>>
>>>>>> 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 hotspot_version. 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);
- oop result = cache->f1_as_instance();
- if (result == NULL) {
+ if (cache->f1_as_instance() == NULL) {
CALL_VM(InterpreterRuntime::resolve_ldc(THREAD, (Bytecodes::Code) opcode),
handle_exception);
- result = cache->f1_as_instance();
+ // GC might move cache while returning from VM call.
+ cache = cp->entry_at(index); // reload
}
+ oop result = cache->f1_as_instance();
VERIFY_OOP(result);
SET_STACK_OBJECT(result, 0);
@@ -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);
-
- methodOop method = cache->f1_as_method();
+ methodOop method = cache->f2_as_vfinal_method();
VERIFY_OOP(method);
if (cache->has_appendix()) {
@@ -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