RFR(S): 8199557 Assert in fromTonga/vm/runtime/defmeth/scenarios/Stress_noredefine/TestDescription.java

[David Holmes]

On 15/03/2018 4:30 AM, Lindenmaier, Goetz wrote:
> Hi Coleen,
> 
> Thanks for the testing, I pushed the change to jdk-submit-hs,
> and will push it to hs if that passes.

At some point we need to understand how we end up on the given code path 
with a null receiver.

David

> Best regards,
>    Goetz.
> 
>> -----Original Message-----
>> From: hotspot-runtime-dev [mailto:hotspot-runtime-dev-
>> bounces at openjdk.java.net] On Behalf Of coleen.phillimore at oracle.com
>> Sent: Wednesday, March 14, 2018 5:49 PM
>> To: hotspot-runtime-dev at openjdk.java.net
>> Subject: Re: RFR(S): 8199557 Assert in
>> fromTonga/vm/runtime/defmeth/scenarios/Stress_noredefine/TestDescrip
>> tion.java
>>
>>
>> Hi Goetz,
>> I reviewed and tested your change against the test case that failed.
>> The test case will be moved to the open real soon now. People are
>> actively working on this.  These tests are generated so take a while to
>> isolate into something runnable without all the machinery.
>>
>> I think your change can be counted as trivial and pushed.  I assume you
>> ran through the submit repo.
>>
>> Thanks,
>> Coleen
>>
>> On 3/14/18 9:29 AM, Lindenmaier, Goetz wrote:
>>> Hi,
>>>
>>> I think this should fix the issue.
>>> Unfortunately, the assertion does not tell which of the two
>>> conditions don't hold, and without the test I can not verify this.
>>>
>>> I would assume that invoke.has_receiver() did not hold.
>>> We get the receiver from the frame here. The exception message
>>> routine can deal with receiver_klass == NULL.
>>>
>>> In case callee is NULL, I re-added the old case.
>>> If this really is the case, It would be great if I could get the failing
>>> test or a repro-case to implement a useful message for this.
>>>
>>> Please review
>>> http://cr.openjdk.java.net/~goetz/wr18/8199557-
>> fixAmeAssertion/webrev.01/
>>>
>>> Best regards,
>>>     Goetz.
>>>
>>>
>