Questions on protection domains in the system dictionary

[Thomas Schatzl]

Hi all,

  I've recently taken over JDK-8003420 from Ioi to clean up/document the
change (original change
http://cr.openjdk.java.net/~tschatzl/8003420/webrev.orig/ ; cleanup at
http://cr.openjdk.java.net/~tschatzl/8003420/webrev.cleanup/).

It improves scanning the system dictionary for oops into the heap
greatly by keeping the protection domain oops in a seperate set (called
ProtectionDomainCacheTable) which entries are referenced by the system
dictionary entries.

If you do not do class unloading, during scanning of the oops in the SD
you only need to scan this set as it contains all the protection domain
oops, decreasing the effort from maybe scanning 100k SD entries to 1k
PDcachetable (or so) entries.

While looking at this code, I saw that it still traverses all system
dictionary entries when class unloading is enabled (e.g. serial/parallel
full gcs) to first mark the PD entries that are reachable by the NULL
class loader, and then only applies the given closure (to evacuate the
objects) to the marked PD entries.

One idea that came to my mind is why not keeping two of these
ProtectionDomainCacheTables around, one containing the ones referenced
by the system class loader, one by the others: when not doing class
unloading, only go through the "system" PD cache table, otherwise use
both. This saves iterating over the potentially large system dictionary
completely.

As my knowledge about PDs and their use is a bit sketchy (for me they're
just oops :), I have some questions:

My first question is about the PD entries/oops themselves: what is the
relation to the klass'es PD entry (which some time ago were moved into
the java.lang.Class instance)?
DictionaryEntry::contains_protection_domain() has an assert which states
that "A klass's protection domain should not show up in its sys. dict.
PD set". Does that mean that the actual PDs for a particular class is
both the one from the mirror *and* the ones in the PD-set?

One related question is if the PDs from the PD-set in the SD are
reachable from anywhere else, ie. is it possible that the only reference
to a particular PD is from the PD-set? If not (they are also reachable
from somewhere else), when doing a non-moving collection, wouldn't it be
possible to skip iterating over the SD completely?
If they are not reachable by anyone else, what's the use of such PD
entries?

Another question here is about the life cycle of the PD cache entries:
it seems that PD entries are only ever removed during class unloading
(e.g. only Dictionary::do_unloading calls Dictionary::free_entry() that
eventually also removes all PD entries). Is this correct?
Does that also mean, that a PD entry for a class loaded by the NULL
class loader is never cleared (as the NULL class loader and its classes
are never unloaded).

Then, with this two PD cache tables idea as suggested above (one for PDs
referenced by the NULL class loader, another one for the others), are
there any pitfalls I should be aware of?
There is some complication here, when a pd oop is in the "other" PD
cache table, but afterwards referenced by the "system" PD cache table,
there is need to move it over there.

I actually have a prototype of that idea working and so far it seems
good (http://cr.openjdk.java.net/~tschatzl/8003420/webrev.twopdcaches/).
What tests do you recommend for testing changes here?

Thomas