StackMap problem

[Mark Roberts]

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/ by keyword.



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