Review Request: Add ClassOption.STRONG and default is unspecified

[John Rose]

On Mar 13, 2020, at 3:07 PM, Alex Buckley <alex.buckley at oracle.com> wrote:
> 
> On 3/13/2020 2:49 PM, Mandy Chung wrote:
>> 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 always "loaded".
> 
> Can you point to the JVM TI and JDI specs which speak of "loaded" classes? We may get lucky like we did with the JVM Specification, which has always spoken of "creating" a class (not just "loading" it) and thus offered a hook to introduce classes which are created without being loaded.

If we have “deemed loaders” we can have “deemed loaded”, perhaps?
That would cut this particular knot.  From the JVM’s POV, a “live”
class is live regardless of how it got there.  Is there any language
in the specs. that speaks of “live”-ness without appealing to a
prior loading event (by saying “loaded”)?  If not, “deemed loaded”
would seem to be a reasonable patch on the terminology.

(BTW, when I say “live” here, I mean that the JVM has either
prepared, linked, and initialized the class already, or is prepared
to on demand, the first time somebody starts to use the class.
Normally the step just before all these states is loading.)

> 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?
> 
> I agree we shouldn't double up a bunch of JVM TI methods by introducing return-just-the-hidden-classes variants. Since there was a performance/overhead concern with WEAK, let me ask a similar question here: is there an overhead from making a hidden class debuggable? Might a user of Lookup::defineHiddenClass say "No! I don't want this hidden class to be debuggable if it costs any bytes at all.”

I don’t anticipate that happening.  By the time JVMTI sees a
computation involving a HC, all the queries it might do on it
will be pretty straightforward.  Some TI/DI operations are likely
to fail on a HC, such as anything that involves reconstructing
and reloading classfile bytes.  It’s not clear to me that we are
compelled to document all those limitations scrupulously.
They will either fail or not in use, and we can retroactively
improve the spec if that’s an issue to tool vendors.  A similar
issue exists today when you reconstruct and reload a class
too many times, if it runs out of CP slots.  I.e., reconstruction
is a “best effort” operation, and tools can fail on those.

— John