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

[Karen Kinnear]

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.
>