RFR 8171971: Fix timing bug in JVM management of package export lists

serguei.spitsyn at oracle.com serguei.spitsyn at oracle.com
Thu Jan 19 21:04:14 UTC 2017


Hi Harold,


On 1/19/17 10:07, harold seigel wrote:
> Hi Serguei,
>
> Thanks for the review.
>
> I think that Modules::add_module_exports_to_all_unnamed() and similar 
> functions are okay because the functions that they call to set the new 
> export states take out the module lock.

You are right.
I've misread some fragment, sorry.

>
> If you are concerned about them then maybe enter a new bug for them?

Never mind.

Thanks,
Serguei

>
> Thanks, Harold
>
>
> On 1/19/2017 5:05 AM, serguei.spitsyn at oracle.com wrote:
>> Hi Harold,
>>
>> It looks pretty good to me.
>>
>> One question though.
>>
>> || src/share/vm/classfile/modules.cpp
>>
>>   I wonder if a synchronization is needed for the functions like
>>   Modules::add_module_exports_to_all_unnamed.
>>   But this is unrelated to your particular fix.
>> ||
>>
>> Thanks,
>> Serguei
>>
>>
>>
>> On 1/18/17 07:05, harold seigel wrote:
>>> Hi,
>>>
>>> Please review this fix for the package export timing holes discussed 
>>> in JDK-8171971.  The fix reduces the number of PackageEntry fields 
>>> that are used to maintain a package's export state and uses the 
>>> Module_lock to protect all access to these fields.
>>>
>>> Also, in cases where a package transitions from having qualified 
>>> exports to being unqualifiedly exported, it fixes the cleanup of its 
>>> qualified export list by removing the _exported_pending_delete field 
>>> and using just is_unqual_exported() to determine when the qualified 
>>> exports list can be purged (at a safepoint).
>>>
>>> Open Webrev: http://cr.openjdk.java.net/~hseigel/bug_8171971/webrev/
>>>
>>> JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8171971
>>>
>>> The fix was tested with the hotspot, java/lang, java/util, java/io, 
>>> JFR, and other JTReg tests, the JCK lang and VM tests, RBT tier2 - 
>>> tier5 tests on LinuxX64, and the colocated and non-colocated NSK tests.
>>>
>>> Thanks, Harold
>>>
>>
>



More information about the hotspot-runtime-dev mailing list