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

[David Chase]

After further study, we think the different-wrong-answers are a symptom of a different bug
(to be filed) where Methodhandle processing does the wrong thing (fails to null-check or
do appropriate handshakes) when presented with empty (null) method from a virtual or
interface invocation.

So, if I may have another Reviewer (I think one more is needed for something this large)?

On 2013-08-19, at 6:46 PM, David Chase <david.r.chase at oracle.com> wrote:

> Karen Kinnear would like me to study, carefully, the wrong answer that occur in one of the default methods tests.
> Apparently this is an instance of a test where the wrong answers are still interesting -- this patch fails less, but
> in a few cases it fails differently.
> 
> David
> 
> On 2013-08-19, at 6:15 PM, Christian Thalinger <christian.thalinger at oracle.com> wrote:
> 
>> Looks good.  -- Chris
>> 
>> On Aug 19, 2013, at 11:13 AM, David Chase <david.r.chase at oracle.com> wrote:
>> 
>>> New version, with Christian's and John's fixes (and limited use of err_msg_res):
>>> 
>>> http://cr.openjdk.java.net/~drchase/8014013/webrev.03/
>>> 
>>> retested (jtreg) on Mac against hotspot/test/compiler, jdk/test/{jdk,java/util}
>>> 
>>> David
>>> 
>>> 
>>> On 2013-08-19, at 12:04 AM, David Holmes <david.holmes at oracle.com> wrote:
>>> 
>>>> On 19/08/2013 8:24 AM, David Chase wrote:
>>>>> A question about err_msg_res -- should that generally be used in place of err_msg,
>>>>> or only in certain source directories, and if so, which ones?
>>>> 
>>>> I can't answer that but be aware that there is an issue with using err_msg_res as it is unclear as to whom has responsibility for ensuring there is a ResourceMark on the stack. There's an open bug on that - 8022187.
>>>> 
>>>> David
>>>> 
>>>>> On 2013-08-17, at 1:41 AM, John Rose <john.r.rose at oracle.com> wrote:
>>>>> 
>>>>>> On Aug 16, 2013, at 1:05 PM, David Chase <david.r.chase at oracle.com> wrote:
>>>>>> 
>>>>>>> How does this look?
>>>>>>> 
>>>>>>> void fieldDescriptor::reinitialize(InstanceKlass* ik, int index) {
>>>>>>> if (_cp.is_null() || field_holder() != ik) {
>>>>>>> _cp = constantPoolHandle(Thread::current(), ik->constants());
>>>>>>> // _cp should now reference ik's constant pool; i.e., ik is now field_holder.
>>>>>>> assert(field_holder() == ik, "must be already initialized to this class");
>>>>>> 
>>>>>> Good.
>>>>>> 
>>>>>> As a side note, this bit of code (and many others) assume that there is a 1-1 correspondence between constant pools and instance klasses.
>>>>>> 
>>>>>> I hope we can change this some day; the tracking bug is http://bugs.sun.com/view_bug.do?bug_id=6711913
>>>>>> 
>>>>>> — John
>>>>> 
>>> 
>> 
> 

-------------- 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-compiler-dev/attachments/20130822/b69d9b51/signature.asc