RFR 8170870: https://bugs.openjdk.java.net/browse/JDK-8170870

[harold seigel]

Hi David,

I didn't realize that both the ClassUnload event processing and the 
cleanup of the PackageEntryTables and ModuleEntryTables are done 
sequentially by the same thread.  So, I'm withdrawing this change.

Thanks, Harold


On 12/7/2016 4:51 PM, David Holmes wrote:
> Hi Harold,
>
> On 8/12/2016 4:43 AM, harold seigel wrote:
>> Hi,
>>
>> Please review this fix for bug JDK-8170870.  The fix synchronizes access
>> to the class loaders' PackageEntryTable and ModuleEntryTable structures
>> by requiring callers of ClassLoaderData::modules_do() and
>> ClassLoaderData::packages_do() to lock the Module_lock.
>>
>> The lock is needed because even during a safepoint one thread could be
>> removing items from the tables while another thread is reading the
>> tables.  For example, unloading a class could cause an event collection
>> framework's JVM support to read the tables during a ClassUnload event
>> while the VM is removing entries from these structures for modules and
>> packages whose class loader got unloaded.
>
> Sorry I don't follow this - what threads are executing code in the VM 
> _during_ a safepoint ??
>
> Also it is unclear to me whether it is safe to acquire the Module_lock 
> during a safepoint - that requires no code holding the Modules_lock 
> can ever block at a safepoint.
>
> Thanks,
> David
> -----
>
>> The fix also cleans up management of package qualified export lists.
>>
>> Open Webrev:
>> http://cr.openjdk.java.net/~hseigel/bug_8170870/webrev/index.html
>>
>> JBS Bug:  https://bugs.openjdk.java.net/browse/JDK-8170870
>>
>> The fix was tested with the JCK Lang and vm tests, the JTreg hotspot,
>> java/io, java/lang, and java/util tests and the nsk cololocated and the
>> non-colocated tests.
>>
>> Thanks, Harold
>>