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

[Karen Kinnear]

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