RFR: 8293774: Improve TraceOptoParse to dump the bytecode name

Christian Hagedorn chagedorn at openjdk.org
Wed Sep 14 05:37:52 UTC 2022


On Wed, 14 Sep 2022 04:06:58 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> Please review this one-line patch which prints the bytecode name for `TraceOptoParse`.
> 
> While I was debugging with `TraceOptoParse`, I found it only prints the bci without the bytecode name.
> I had to map the bci to the bytecode manually again and again.
> It would be better to also dump the bytecode name.
> 
> Before:
> 
>     568  503       4       jdk.internal.org.objectweb.asm.ByteVector::putUTF8 (144 bytes)
> Merging state at block #0 bci:0 with empty state on path 1
> Parsing block #0 at bci [0,11), successors:  1 2
>  @ bci:0
>  @ bci:1
> Uncommon trap reason='null_check' action='maybe_recompile' debug_id='0' at bci:1
> Merging state at block #0 bci:0 with empty state on path 1
> Parsing block #0 at bci [0,11), successors:
>  @ bci:0
>  @ bci:1
>  @ bci:4
> Uncommon trap reason='null_check' action='maybe_recompile' debug_id='0' at bci:4
>  @ bci:5
>  @ bci:6
> Merging state at block #0 bci:0 with empty state on path 1
> 
> 
> After:
> 
>     571  507       4       jdk.internal.org.objectweb.asm.ByteVector::putUTF8 (144 bytes)
> Merging state at block #0 bci:0 with empty state on path 1
> Parsing block #0 at bci [0,11), successors:  1 2
>  @ bci:0 aload_1
>  @ bci:1 invokevirtual
> Uncommon trap reason='null_check' action='maybe_recompile' debug_id='0' at bci:1
> Merging state at block #0 bci:0 with empty state on path 1
> Parsing block #0 at bci [0,11), successors:
>  @ bci:0 aload_0
>  @ bci:1 getfield
>  @ bci:4 arraylength
> Uncommon trap reason='null_check' action='maybe_recompile' debug_id='0' at bci:4
>  @ bci:5 aload_0
>  @ bci:6 invokevirtual
> Merging state at block #0 bci:0 with empty state on path 1
> 
> 
> Testing:
>  - tier1~3 on Linux/x64 in progress, seems fine until now
> 
> Thanks.
> Best regards,
> Jie

Looks good!

Do we have any "hello world" kind of test that uses this flag? If not, it might be worth adding such a sanity test to cover it. But that could also be done separately.

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

Marked as reviewed by chagedorn (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10262


More information about the hotspot-compiler-dev mailing list