Review Request: Add ClassOption.STRONG and default is unspecified

Mandy Chung mandy.chung at
Fri Mar 13 22:26:19 UTC 2020

On 3/13/20 3:07 PM, Alex Buckley 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.

Above are the main ones but not a complete list.

>> 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? 

No, as far as the current JDI implementation goes.  Very small change is 
made in JDI to get jdb to debug on a hidden class, namely handle the 
hidden class' name properly (not a binary name).

Serguei did the initial work in JDI to get jdb to debug a hidden class 
(both bytecode level and even source-level when SourceFile attribute is 


> 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."
> Alex

More information about the valhalla-dev mailing list