Review Request: Add ClassOption.STRONG and default is unspecified

Alex Buckley alex.buckley at
Fri Mar 13 23:28:39 UTC 2020

On 3/13/2020 3:37 PM, Mandy Chung wrote:
> Please take a look the `Lookup::defineHiddenClass` spec and `ClassOption`:

We're really writing the JEP here. The API spec should just follow that, 
with sentences taken out so it boils down to one paragraph.

Speak about the "relationship" concept only at the top and bottom of the 
paragraph, not in the middle where technical statements about 
reachability and reclaiming exist. Plus, don't start with the behavior 
embodied by STRONG -- we believe that weak is the natural state of 
hidden classes. Plus, I want to hold off from saying "loose" if possible 
-- usually I'm the person demanding that terminology completely covers 
the design space, but right now I want to leave room for us to spin up 
text about "weak relationship that may or may not imply weak references".

Start by saying "Every class created by a class loader has a strong 
relationship with that class loader. That is, every `Class` object 
contains a `reference` to the `ClassLoader` that [defined it](LINK TO 
CLASS::GETCLASSLOADER). This means that a class created by a class 
loader may be unloaded if and only if its defining loader is not 
reachable and thus may be reclaimed by a garbage collector (JLS 12.7)."

Continuing: "By default, however, a hidden class may be unloaded even if 
the class loader that is marked as its defining loader is reachable. 
This allows <<text heavily paraphrased from John's mail about "go dead 
as soon as the last client drops a reference to them" -- this text will 
not be easy to write, but it belongs here -- also there used to be text 
about libraries who use WEAK needing to take care of their Class objects>>.

Continuing: "In cases where <<durable references / permanently installed 
is important>>, the `STRONG` option may be passed in `options`. This 
arranges for a hidden class or interface to have the same relationship 
with the class loader marked as its defining loader, as a normal class 
or interface has with its own defining loader."

Finally: "[A rule about independence of HCs from each other:] The 
unloading characteristics are set for each hidden class when it is 
defined, and cannot be changed later. [A note about independence of HCs 
from CLs] An advantage of allowing hidden classes to be unloaded 
independently of the loader deemed as their defining loader is that a 
very large number of hidden classes may be created by an application. In 
contrast, if STRONG is used, then the JVM may run out of memory, just as 
if normal classes were created by class loaders."


More information about the valhalla-dev mailing list