RFR 8170870: https://bugs.openjdk.java.net/browse/JDK-8170870
harold.seigel at oracle.com
Thu Dec 8 19:13:24 UTC 2016
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.
On 12/7/2016 4:51 PM, David Holmes wrote:
> Hi Harold,
> On 8/12/2016 4:43 AM, harold seigel wrote:
>> 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.
>> The fix also cleans up management of package qualified export lists.
>> Open Webrev:
>> 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
More information about the hotspot-runtime-dev