Review Request: Add ClassOption.STRONG and default is unspecified
mandy.chung at oracle.com
Fri Mar 13 21:49:44 UTC 2020
On 3/13/20 9:09 AM, Alex Buckley wrote:
> On 3/12/2020 5:43 PM, John Rose wrote:
>> After “doing the math” (in the previous note) I’m with David being
>> skeptical of “unspecified”. If a JVM implementation maps
>> “unspecified” to STRONG that’s a bug, not a feature ... Only WEAK
>> mode is safe. So the best we could do is say that “if neither option
>> is specified, then the mode defaults to WEAK”. But at that point,
>> why have WEAK at all? You only need the token for the non-default
> Got it: (i) the default is specified to be WEAK; (ii) the API offers a
> single enum constant, STRONG, to override the default; (iii) both of
> the previous clauses apply to hidden classes that are nestmates AND to
> hidden classes that are not nestmates. Thanks for the enjoyable writeup.
> Zooming out, I recommend that the phrase "weak class" be exorcised
> from JEP 371. It always bothered me that the JEP introduced a concept
> which sounds first-class, as if it applies widely (inviting "Excuse
> me, will Lookup::defineClass be extended to take the WEAK option?
> Where are weak classes in the JVM Specification?" etc), but then
> pulled the rug by saying it's limited to hidden classes. I think we
> should frame a hidden class's loose relationship with its
> deemed-defining loader as just another superpower that
> Lookup::defineHiddenClass can arrange, along with (say) a hidden class
> being able to join a nest without holding an entry ticket (i.e. no
> NestHost attribute). Similarly, if STRONG is specified, then there's
> no "strong class" to put on a pedestal -- the hidden class's
> relationship with its deemed-defining loader is exactly the same as an
> ordinary class's relationship with its defining loader.
This sounds all good to me.
When a hidden class whose relationship with its deemed-defining loader
is different than that of an ordinary class, Class::getClassLoader
returns its deemed-defining loader and so does JVM TI GetClassLoader.
No issue with that.
From JVM TI perspective, each "loaded" class has one defining loader
and N initiating loaders. N is >= 1 in JDK 14 and with hidden classes,
N becomes >= 0.
For a hidden class whose has either a loose relationship with its
deemed-defining loader, this is arranged by
`Lookup::defineHiddenClass`. From JVM's perspective, a hidden class is
a "normal" class and I think same applies to JVM TI. We want hidden
classes to be debuggable. JVM TI and JDI etc assume classes are
Now, a class can be:
1. a loaded (ordinary) class
2. a hidden class whose has a loose relationship with its
3. a hidden class whose has a strong relationship with its
deemed-defining loader - exactly the same as an ordinary class's
relationship with its defining loader
From tool's perspective, it wants to find all loaded classes or loaded
classes initiated & defined by a given loader. Tools can determine if
a class is a hidden class or ordinary class using Class::isHiddenClass
or by its name. While hidden classes are not "loaded", having JVM TI
to define new API for this new "API-created-class" and making the tools
to handle hidden classes using new JVM TI events and new JVM TI APIs
seem too high cost with little benefit. Do you see this wrong?
More information about the valhalla-dev