[External] : RE: StackMap problem

Wed Jan 29 18:26:54 UTC 2025

Oh I see – I should have changed the exception handler range to 17-33.
This relates to my problem adding new labels that Chen has addressed in
another thread.

Thanks

*From:* classfile-api-dev <classfile-api-dev-retn at openjdk.org> *On Behalf
Of *Adam Sotona
*Sent:* Wednesday, January 29, 2025 10:02 AM
*To:* Chen Liang <chen.l.liang at oracle.com>; classfile-api-dev at openjdk.org
*Subject:* Re: [External] : RE: StackMap problem

I see what happened here. The transformed method is invalid because the
istore_1 is injected into the try block and consumed outside.

As I used CodeTransform::atStart to inject the istore_1 – I injected it
before the try block and stack maps are valid.

It is not guaranteed Class-File API will always fail eagerly when
generating stack maps for invalid bytecode. ClassFile::verify is
recommended to verify the generated class file is valid.

Your instrumentation should inject code introducing new locals before any
try block (if consumed outside of the try block). Otherwise valid stack
maps are unable to compute.

Adam

*From: *Chen Liang <chen.l.liang at oracle.com>
*Date: *Wednesday, 29 January 2025 at 18:44
*To: *Adam Sotona <adam.sotona at oracle.com>, classfile-api-dev at openjdk.org <
classfile-api-dev at openjdk.org>
*Subject: *Re: [External] : RE: StackMap problem

Indeed, I noted that our StackMapGenerator eagerly checks if a newly
encountered store instruction (the istore_1 in the exception handler range)
breaks the stack maps, and our StackMapGenerator would have failed fast in
that case.

Chen
------------------------------

*From:* Adam Sotona <adam.sotona at oracle.com>
*Sent:* Wednesday, January 29, 2025 11:35 AM
*To:* Mark Roberts <markro at cs.washington.edu>; classfile-api-dev at openjdk.org
<classfile-api-dev at openjdk.org>
*Cc:* Chen Liang <chen.l.liang at oracle.com>
*Subject:* Re: [External] : RE: StackMap problem

I see, the frame is listed at the end of the line.

Key question still remains – how the instrumentation is done?

Class- File API regenerates the stack map when I create similar method and
inject the istore_1 and iload_1 instructions.

Adam

*From: *Mark Roberts <markro at cs.washington.edu>
*Date: *Wednesday, 29 January 2025 at 17:45
*To: *Adam Sotona <adam.sotona at oracle.com>, classfile-api-dev at openjdk.org <
classfile-api-dev at openjdk.org>
*Cc: *Chen Liang <chen.l.liang at oracle.com>
*Subject: *[External] : RE: StackMap problem

The ‘before’ was compiled with javac version 24-ea+22-269, but I compiled
with javac version 17.0.11 and got the exact same binary.  The stack map
frames are there:

  StackMapTable:

  StackMap((SAME_LOCALS_1_STACK, offset delta=19, stack
items={(type=Object, class=DataStructures.Overflow)}), (SAME, offset
delta=0))

The first (@19) is the target of the exception handler, the second (@20) is
the target of the branch @16.

It all looks good to me.

Mark

*From:* Adam Sotona <adam.sotona at oracle.com>
*Sent:* Wednesday, January 29, 2025 1:07 AM
*To:* Mark Roberts <markro at cs.washington.edu>; classfile-api-dev at openjdk.org
*Cc:* Chen Liang <chen.l.liang at oracle.com>
*Subject:* Re: StackMap problem

Hi Mark,

Both attached class listings are missing stack map frames at branch
targets, and they seem to be invalid.

I would like to ask what compiler generates the first class and how your
tool adds the instrumentation code.

My first impression is that I don’t see any trace of Class-File API stack
map generator involment. Transformation of a method with missing or invalid
stack map would generate new stack maps, unless explicitly disabled.

Thanks,

Adam

*From: *classfile-api-dev <classfile-api-dev-retn at openjdk.org> on behalf of
Mark Roberts <markro at cs.washington.edu>
*Date: *Tuesday, 28 January 2025 at 21:45
*To: *classfile-api-dev at openjdk.org <classfile-api-dev at openjdk.org>
*Cc: *Chen Liang <chen.l.liang at oracle.com>
*Subject: *StackMap problem

The existence of compiler generated, unnamed local temps (no LocalVariable
code element) seems to cause a problem with stack maps.

The ‘source’ attachment shows the problem method.   The ‘before’ attachment
shows the generated code before instrumentation.  Note that the compiler
generates an unnamed temp at slot 0 to store the exception code. The
stackmap for the branch target says same locals, which is correct.

The ‘after’ attachment shows the code generated after our tool has added
instrumentation code – note the addition of a new local variable at slot
1.  The stackmap for the branch target still says same locals, which is no
longer correct. This causes the iload_1 @41 to fail.

I tried to see if this issue has already been reported, but I was unable to
figure out how to search https://bugs.java.com/bugdatabase/
<https://urldefense.com/v3/__https:/bugs.java.com/bugdatabase/__;!!ACWV5N9M2RV99hQ!Oxj6SR2NV9Ad-EfEdNCFmjPL0gx3yAPgZ8jQoj8jWrlF9W-NohRiSuxWzqdOPpnNxoTuYr4zSmL9s1LDi14H1ymI$>
by keyword.

Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/classfile-api-dev/attachments/20250129/93f79728/attachment-0001.htm>