RFR: 8271461: CompileCommand support for hidden class methods [v10]

[Xin Liu]

On Fri, 6 Aug 2021 07:41:52 GMT, Jie Fu <jiefu at openjdk.org> wrote:

>> Hi all,
>> 
>> We'd like to improve the CompileCommand to support hidden class methods, which is helpful for debugging and perfmance analysis.
>> 
>> Current implementation of CompileCommand doesn't work for hidden class methods.
>> For example, if you run with `java -Xcomp -Xbatch -XX:+PrintCompilation`
>> The following hidden class methods were compiled:
>> 
>>    5317 1573    b  3       java.util.ResourceBundle$$Lambda$1/0x00000008010413c8::run (8 bytes)
>>    5318 1574    b  4       java.util.ResourceBundle$$Lambda$1/0x00000008010413c8::run (8 bytes)
>>    6735 1938    b  3       java.util.ResourceBundle$ResourceBundleProviderHelper$$Lambda$2/0x0000000801041e80::run (12 bytes)
>>    6736 1939    b  4       java.util.ResourceBundle$ResourceBundleProviderHelper$$Lambda$2/0x0000000801041e80::run (12 bytes)
>>    7060 2029    b  3       java.util.ResourceBundle$ResourceBundleProviderHelper$$Lambda$58/0x800000060::run (8 bytes)
>>    7061 2030    b  4       java.util.ResourceBundle$ResourceBundleProviderHelper$$Lambda$58/0x800000060::run (8 bytes)
>>    7688 2153    b  3       java.util.ResourceBundle$ResourceBundleProviderHelper$$Lambda$4/0x0000000801043218::run (16 bytes)
>>    7688 2154    b  4       java.util.ResourceBundle$ResourceBundleProviderHelper$$Lambda$4/0x0000000801043218::run (16 bytes)
>> 
>> 
>> Then people may want to exclude the compilation of `java.util.ResourceBundle$$Lambda$1/0x00000008010413c8::run` like this
>> 
>> -XX:CompileCommand=exclude,'java.util.ResourceBundle$$Lambda$1/0x00000008010413c8::run'
>> 
>> 
>> But unfortunately, it doesn't work.
>> 
>> CompileCommand: An error occurred during parsing
>> Error: Method pattern uses '/' together with '::'
>> Line: 'exclude,java.util.ResourceBundle$$Lambda$1/0x00000008010413c8::run'
>> 
>> Usage: '-XX:CompileCommand=<option>,<method pattern>' - to set boolean option to true
>> Usage: '-XX:CompileCommand=<option>,<method pattern>,<value>'
>> Use:   '-XX:CompileCommand=help' for more information and to list all option.
>> 
>> 
>> The failing reason is that the name of `java.util.ResourceBundle$$Lambda$1/0x00000008010413c8::run` is actually `java.util.ResourceBundle$$Lambda$1+0x00000008010413c8::run` in the VM.
>> But "+" had been replaced with "/" when it was printed by PrintCompilation [1].
>> 
>> So for a hidden class method, "/" should be replaced with "+" to make CompileCommand work.
>> 
>> Thanks.
>> Best regards,
>> Jie
>> 
>> 
>> [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/oops/klass.cpp#L685
>
> Jie Fu has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Improve error msg
>  - Revert changes

LGTM

hi, Jiefu, 

I spent some time reading JEP 371: Hidden Classes. it describes a lot of "not discoverable". eg. 

> A hidden class is not anonymous. It has a name that is available via Class::getName and may be shown in diagnostics (such as the output of java -verbose:class), in JVM TI class loading events, in JFR events, and in stack traces. However, the name has a sufficiently unusual form that it effectively makes the class invisible to all other classes.

It seems to me that the hidden class purposely uses name mangling to reduce discoverability, hide from programmers. Unless the mangling scheme is well defined, I don't think we can have a maintainable pattern to match them all the time. Yes, regex or wildcard may work, but it needs extra cognitive load to master, doesn't it?

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

Marked as reviewed by xliu (Committer).

PR: https://git.openjdk.java.net/jdk/pull/4926