RFR (L) : 8014013 : CallInfo structure no longer accurately reports the result of a LinkResolver operation
David Chase
david.r.chase at oracle.com
Fri Sep 13 11:23:04 PDT 2013
This time, for sure:
http://cr.openjdk.java.net/~drchase/8014013/webrev.07/
Developer flags seem not to cause crashes now (added ResourceMark rm(THREAD); )
Comment on surprisingly important "placeholder" updated.
Otherwise, same as before, and thoroughly tested (since it was already tested with the placeholder untouched).
David
On 2013-09-13, at 11:26 AM, Karen Kinnear <KAREN.KINNEAR at oracle.com> wrote:
> I'm good with checking this in as is (with an added comment).
>
> I get it that the developer flags may need their own fixes - ok to investigate as a follow-on bug.
> Same with the remaining non-null placeholder. A comment works for leaving it now, since it passes
> your tests - and a follow-on bug.
>
> Thank you for doing so much testing, very much appreciated.
>
> thanks,
> Karen
>
> On Sep 12, 2013, at 11:23 PM, John Rose wrote:
>
>> Yikes; those developer flags are very likely to have their own bugs if run through big test suites.
>>
>> — John
>>
>> On Sep 12, 2013, at 8:17 PM, David Chase <david.r.chase at oracle.com> wrote:
>>
>>> I see failures, but they are not null pointer exceptions, they are instead something to do with memory leaks
>>> and resource marks. I would examine the hs_err files, except that our glorious test harness didn't seem to think
>>> they were worth preserving, so they're gone now. I'm going to go looking for options.
>>>
>>> David
>>>
>>> On 2013-09-12, at 5:49 PM, Karen Kinnear <KAREN.KINNEAR at oracle.com> wrote:
>>>
>>>> David,
>>>>
>>>> I will do a full review tomorrow.
>>>> A couple of quick questions:
>>>>
>>>> 1) In linkResolver.cpp, in resolve_field, I would have expected the if !check_access to just skip
>>>> the check_field_accessibility. I was surprised to see it also skipping other error checks. Is there
>>>> a reason for that? (I get the loader constraint tests being skipped), but what about for example
>>>> initializing the class?
>>>>
>>>> 2) I still see // use a non-null placeholder on line 1059
>>>>
>>>> 3) If the non-null was for debug printing - you want to run a quick test with maybe one of mlvm tests? with your favorite flags:
>>>> vm set would include:
>>>> -XX:+TraceMethodHandles -XX:+Verbose
>>>> -XX:+ShowHiddenFrames
>>>> -XX:+TraceInvokeDynamic
>>>> -XX:+PrintMethodHandleStubs
>>>>
>>>> and the favorite jdk 292 flags -
>>>> -Djava.lang.invoke.MethodHandle.DUMP_CLASS_FILES
>>>> -Djava.lang.invoke.MethodHandle.DEBUG_NAMES
>>>> -Djava.lang.invoke.MethodHandle.TRACE_INTERPRETER
>>>> -Djava.lang.invoke.MethodHandle.TRACE_METHOD_LINKAGE
>>>>
>>>> thanks,
>>>> Karen
>>>>
>>>> On Sep 11, 2013, at 10:33 PM, David Chase wrote:
>>>>
>>>>>
>>>>> New webrev: http://cr.openjdk.java.net/~drchase/8014013/webrev.05/
>>>>>
>>>>> Retested post changes:
>>>>> vm.quick.testlist
>>>>> defmeth
>>>>> jdk/test/java/util
>>>>> jdk/test/jdk/lambda
>>>>>
>>>>> jprt to confirm compilable across all platforms (this has been an issue)
>>>>>
>>>>> On 2013-09-10, at 10:17 AM, Karen Kinnear <KAREN.KINNEAR at oracle.com> wrote:
>>>>>>>>
>>>>>>>> Good. At this level, "static" linkage is the kind of linkage used always for both invokestatic and invokespecial, and sometimes for invokevirtual and invokeinterface (in some corner cases).
>>>>>> Overuse of the term static - a bit confusing. Thanks for the explanation, perhaps the comment could clarify.
>>>>>
>>>>> Comment now clarifies.
>>>>>
>>>>>>>>
>>>>>>>>> 6. linkResolver.cpp
>>>>>>>>> CallInfo::CallInfo:
>>>>>>>>> Why are _selected_klass and _selected_method set to resolved_klass and resolve_method?
>>>>>>>>
>>>>>>>> Mainly (I think) to prevent print statements from SEGV-ing.
>>>>>> Please change this back - and don't set the information if it is not accurate. Please fix the print statements
>>>>>> to handle null. Null provides meaningful information. If you are using the information as the selected
>>>>>> klass and selected method, I would like to understand cases in which you do that, that are handled outside
>>>>>> of the LinkResolver please, since this would imply perhaps different behavior for invokedynamic options
>>>>>> and I would really like to understand those.
>>>>>
>>>>> Changed back.
>>>>>
>>>>
>>>
>>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 163 bytes
Desc: Message signed with OpenPGP using GPGMail
Url : http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130913/cf5781bd/signature.asc
More information about the hotspot-runtime-dev
mailing list