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

[David Chase]

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/20130911/6e2babed/signature.asc