RFR (L) : 8014013 : CallInfo structure no longer accurately reports the result of a LinkResolver operation

[David Chase]

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/20130912/a686c297/signature-0001.asc