RFR: 8304846: Provide a shared utility to dump generated classes defined via Lookup API [v2]

Mandy Chung mchung at openjdk.org
Mon Mar 27 18:23:24 UTC 2023


On Fri, 24 Mar 2023 23:00:12 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> This implements a shared utility to dump generated classes defined as normal/hidden classes via `Lookup` API.   This replaces the implementation in `LambdaMetaFactory` and method handle implementation that dumps the hidden class bytes on disk for debugging.   
>> 
>> For classes defined via `Lookup::defineClass`, `Lookup::defineHiddenClass` and `Lookup::defineHiddenClassWithClassData`, by default they will be dumped to the path specified in `-Djava.lang.invoke.Lookup.dumpClasses=<dumpDir>` 
>> 
>> The hidden classes generated for lambdas, `LambdaForms` and method handle implementation use non-default dumper so that they can be controlled via a separate system property and path as in the current implementation.
>> 
>> To dump lambda proxy classes, set this system property:
>>    -Djdk.internal.lambda.dumpProxyClasses=<dumpDir>
>> 
>> To dump LambdaForms and method handle implementation, set this system property:
>>    -Djava.lang.invoke.MethodHandle.DUMP_CLASS_FILES=true
>>    
>> P.S. `ProxyClassesDumper` is renamed to `ClassFileDumper` but for some reason, it's not shown as rename.
>
> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   avoid another map lookup

My thought on the property names:

`Lookup::defineClass` and `Lookup::defineHiddenClass` default to enable dumping of the class files via:
`-Djdk.invoke.MethodHandle.dumpClassFiles=true`

LMF and LambdaForms (and other method handle internal classes) are special cases to dump via a different system property respectively:
`-Djdk.invoke.LambdaMetafactory.dumpProxyClassFiles=true`
`-Djdk.invoke.MethodHandle.dumpLambdaForms=true`  or `-Djdk.invoke.MethodHandle.dumpInternalClassFiles=true`

Thoughts/comments?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13182#issuecomment-1485640639


More information about the core-libs-dev mailing list