Review Request: Add ClassOption.STRONG and default is unspecified

[Mandy Chung]

On 3/13/20 3:17 PM, John Rose wrote:
> 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.

AFAIK, no speak of live-ness as I think it's not mentioned in JVMS neither.

JVM TI has ClassLoad event and ClassPrepare event and GetClassStatus API 
follow the status defined in JVMS 5: loaded, verified, prepared, 
initialized.
> (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.)

Yes.  A "loaded" class can be of any of the above status.
>>  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.
>

+1.   JVM TI detects if a given class has been unloaded and returns 
JVMTI_ERROR_INVALID_CLASS that tools can check and handle in the case of 
class unloading.

Mandy