RFR 8174954: Parameter target type is allowed access after a module read edge or a package export has occurred after failed resolution

harold seigel harold.seigel at oracle.com
Wed Oct 18 14:20:58 UTC 2017


Hi David,

Thanks for looking at this.

Please see inline comments.

Thanks, Harold


On 10/17/2017 10:22 PM, David Holmes wrote:
> Hi Harold,
>
> On 17/10/2017 12:20 AM, harold seigel wrote:
>> Hi,
>>
>> Please review this new JDK-10 fix for bug JDK-8174954.  If the 
>> initial resolution attempt fails with a LinkageError exception then 
>> the fix saves the exception in the resolution_errors table and sets a 
>> flag in the constant pool Cache, indicating the failure.  Subsequent 
>> attempts to do the same resolution will see that the flag is set, 
>> retrieve the exception from the resolution_errors table, and throw 
>> it, instead of re-trying the resolution.
>
> I'm a little confused. The fix seems all about indy, which seems to be 
> the topic of:
>
>  JDK-8174942 Bootstrap Method Called Multiple Times Despite Initial 
> Resolution Failure
>
> whereas this bug seems to be about a more general problem. Is this fix 
> addressing both issues??
Thanks for noticing this.  This fix addresses both bugs.  The sample 
program for 8174942 is one of the test cases for this fix.  I'll close 
8174942 as a duplicate.
>
> BTW there's no reason for JDK-8174954 to remain confidential.
Agreed.  I opened the bug.
>
> Thanks,
> David
>
>> The fix also prevents a race condition if two or more threads try to 
>> do the same resolution concurrently. When a thread tries to record 
>> the result of its resolution attempt, it will check to see if another 
>> thread recorded its result first.  If so, then it will use the result 
>> recorded by the other thread.  Otherwise, it will record and use its 
>> result. Access to the resolution result is protected by the 
>> 'resolved_references' lock.
>>
>> Open webrev: http://cr.openjdk.java.net/~hseigel/bug_8174954.1/webrev/
>>
>> JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8174954
>>
>> The fix was tested with the JCK Lang and VM tests, the JTreg hotspot, 
>> java/io, java/lang, java/util, and other tests, the co-located NSK 
>> tests, JPRT, with Mach5 tier2 - tier5 tests, and by hand to check 
>> race condition handling.
>>
>> Thanks, Harold
>>



More information about the hotspot-runtime-dev mailing list