On Wed, 31 Aug 2022 12:39:08 GMT, Coleen Phillimore <[email protected]> wrote:
>> Please review this simple conversion for the ProtectionDomainCacheTable from
>> Old Hashtable to ResourceHashtable. There are specific tests for this table
>> in test/hotspot/jtreg/runtime/Dictionary and
>> serviceability/dcmd/vm/DictionaryStatsTest.java.
>> Also tested with tier1-7.
>
> Coleen Phillimore has updated the pull request incrementally with one
> additional commit since the last revision:
>
> Fix comments, add assert.
The reason we have the table is that you can have the same instance of
java.security.ProtectionDomain used on multiple DictionaryEntry._pd_set lists.
That is, multiple classes in the class loader data have had their loading
initiated with the same protection domain, which is common. Creating
WeakHandles for each is redundant and wasteful, so we want to have one
WeakHandle for multiple entries to point to. The table is a place to store it.
I had another version that stored the WeakHandle entries in the
ClassLoaderData of the Dictionary of loaded classes that had them in their
pd_set, but they had a linear lookup to determine if they were unique. We even
performance tested that. In the end, I just translated the table to
ResourceHashtable to make it easier to review and understand what this does.
As an example, if you run hello world with the security manager allowed, you
see this:
java -Xlog:protectiondomain=trace -Djava.security.manager=allow -cp ~/work Hello
[0.188s][trace][protectiondomain] adding protection domain for class
java/lang/Object class loader: a
'jdk/internal/loader/ClassLoaders$AppClassLoader'{0x00000007fef58f90}
protection domain: a 'java/security/ProtectionDomain'{0x000000011f01d820} pd
set count = #1
[0.189s][trace][protectiondomain] adding protection domain for class
java/lang/String class loader: a
'jdk/internal/loader/ClassLoaders$AppClassLoader'{0x00000007fef58f90}
protection domain: a 'java/security/ProtectionDomain'{0x000000011f01d820} pd
set count = #1
[0.189s][trace][protectiondomain] adding protection domain for class
java/lang/Exception class loader: a
'jdk/internal/loader/ClassLoaders$AppClassLoader'{0x00000007fef58f90}
protection domain: a 'java/security/ProtectionDomain'{0x000000011f01d820} pd
set count = #1
[0.189s][trace][protectiondomain] adding protection domain for class
java/lang/System class loader: a
'jdk/internal/loader/ClassLoaders$AppClassLoader'{0x00000007fef58f90}
protection domain: a 'java/security/ProtectionDomain'{0x000000011f01d820} pd
set count = #1
[0.189s][trace][protectiondomain] adding protection domain for class
java/io/PrintStream class loader: a
'jdk/internal/loader/ClassLoaders$AppClassLoader'{0x00000007fef58f90}
protection domain: a 'java/security/ProtectionDomain'{0x000000011f01d820} pd
set count = #1
Hello5
Whenever we initiate loading (for example) java.lang.Object in a non bootstrap
class loader with the SecureClassLoader, we pass this protection domain.
Notice how the same protection domain is added to each class.
In JDK8 we pointed to the oop itself which required the GC to walk the global
SystemDictionary. We definitely never want that, so moved it to a table, and
made several other changes to enable concurrent class unloading after that -
moved the Dictionaries of loaded classes to each class loader data.
-------------
PR: https://git.openjdk.org/jdk/pull/10043
