RFR: 8247536: Support for pre-generated java.lang.invoke classes in CDS static archive

[Mandy Chung]

src/java.base/share/classes/java/lang/invoke/GenerateJLIClassesHelper.java 
367 /** 368 * called from vm to generate MethodHandle holder classes 369 
* @return @code { Object[] } if holder classes can be generated. 370 * 
@param lines the output lines from @code { VM.cdsTraceResolve } 371 */ 
@code {....} is wrong syntax. It should be {@code ....} 372 static 
Object[] cdsGenerateHolderClasses(String[] lines) { this can be made 
private as it's invoked by VM only. Can you move it to the end of the 
file. 373 try { 374 Map<String, byte[]> result = 
generateHolderClasses(Arrays.stream(lines)); 375 if (result == null) { 
376 return null; 377 }


generateHolderClasses should never return null and so line 371-377 can 
be dropped.   I also suggest to add in the generateHolderClasses method 
to add Objects.requireNonNull(traces).

379             Object[] ret_array = new Object[size * 2];


Rename `ret_array` to retArray to follow the naming convention using camel case.


src/java.base/share/classes/jdk/internal/misc/VM.java
457         isDumpLoadedClassListSetAndOpen = isDumpLoadedClassListSetAndOpen0();


This should be cached in the caller who checks if -XX:+DumpLoadedClassList
instead of every VM initialization.

Since there are many CDS-related methods, I think it's time to introduce
a new CDS class for these methods to reside (maybe jdk.internal.vm.CDS?).

I suggest to add CDS:logTraceResolve(String line) method that
will check if isDumpLoadedClassListSetAndOpen is true, then call the
native cdsTraceResolve (or whatever name).  This way,
GenerateJLIClassesHelper can simply call CDS::logTraceResolve.


493      * Output to DumpLoadedClassList, format is simimar to LF_RESOLVE


s/simimar/similar


494      * @see InvokerBytecodeGenerator
495      * @param line the line to output.


@see is typically placed after @param.


Should it say @see java.lang.invoke.GenerateJLIClassesHelper::traceLambdaForm
instead of InvokerBytecodeGenerator?


Mandy



On 9/15/20 12:15 PM, Yumin Qi wrote:
> This patch is reorganized after 8252725, which is separated from this patch to refactor jlink glugin code. The previous
> webrev with hg can be found at: http://cr.openjdk.java.net/~minqi/2020/8247536/webrev-05. With 8252725 integrated, the
> regeneration of holder classes is simply to call the new added GenerateJLIClassesHelper.cdsGenerateHolderClasses
> function.
>
> Tests: tier1-4
>
> -------------
>
> Commit messages:
>   - 8247536: Support for pre-generated java.lang.invoke classes in CDS static archive
>   - Merge remote-tracking branch 'upstream/master' into jdk-8247536
>   - Merge remote-tracking branch 'upstream/master' into jdk-8247536
>   - Merge remote-tracking branch 'origin/jdk-8252689'
>   - 8252689: Classes are loaded from jrt:/java.base even when CDS is used
>   - 8252689: Classes are loaded from jrt:/java.base even when CDS is used
>   - 8252689: Classes are loaded from jrt:/java.base even when CDS is used
>
> Changes: https://git.openjdk.java.net/jdk/pull/193/files
>   Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=193&range=00
>    Issue: https://bugs.openjdk.java.net/browse/JDK-8247536
>    Stats: 368 lines in 18 files changed: 344 ins; 13 del; 11 mod
>    Patch: https://git.openjdk.java.net/jdk/pull/193.diff
>    Fetch: git fetch https://git.openjdk.java.net/jdk pull/193/head:pull/193
>
> PR: https://git.openjdk.java.net/jdk/pull/193