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

[Jie Fu]

On Thu, 5 Aug 2021 02:44:50 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 one additional commit since the last revision:
> 
>   Fix code style

> @dean-long: With [abf4df5](https://github.com/openjdk/jdk/commit/abf4df5d71671217ab80331bd08eb19fbc9b8963), we'll see some bizarre behavior. I think it will confuse users who are trying to use `-XX:CompileCommand`, as it's hard to explain why some of these work and others don't.
> 
> Given the method `java.lang.Class::isArray()`:
> 
> * `java/*::isArray`: no warning, does not match (it gets transformed to `java+*.isArray`)
> * `java.*::isArray`: matches
> * `java/*.isArray`: matches
> * `java/l*::isArray`: gives warning `Error: Method pattern uses '/' together with '::'`, does not match
> * `java/l*.isArray`: matches
> 
> The latest version, [6bdcff2](https://github.com/openjdk/jdk/commit/6bdcff262d27665fd9e07d500819beec58a6bf91), seems just too complicated for what it tries to achieve. Also, we can have regular classes to have `$` in their class names (e.g., Java inner classes), so the above problem still exists.
> 
> I think it's better to stick with the current JDK code and have a simple rule -- if you want to match hidden classes, use `+` in the class name.

Hi @iklam , 

There is no simple way to fix the problems you mentioned above.
And I don't want to improve the complexity either.

Not all people know the fact that '/' should be replaced by '+' for hidden classes.
And the java docs say there is a '/' in hidden class name.
So it's worthy supporting it directly.

To lower the complexity, there are still false positive cases.
And there seems no way to fix them perfectly.
But I don't think it really matters in practice since all of them are harmless.

There are also known bizarre false positive cases for CompileCommand, e.g,

java -XX:CompileCommand=exclude,'java.util.*:::method' -version
CompileCommand: exclude java/util/*.method bool exclude = true
openjdk version "18-internal" 2022-03-15
OpenJDK Runtime Environment (fastdebug build 18-internal+0-adhoc.fool.jdk)
OpenJDK 64-Bit Server VM (fastdebug build 18-internal+0-adhoc.fool.jdk, mixed mode)

But I don't think it's a problem in daily usage.

Let's see what @neliasso think of it.
If @neliasso , author of CompileCommand, also doesn't want to support it directly, I'll close this PR since too much time has been spent on this small enhancement.

Thanks.

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

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