[External] : RE: StackMap problem

[Chen Liang]

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<mailto:adam.sotona at oracle.com>>
Sent: Wednesday, January 29, 2025 1:07 AM
To: Mark Roberts <markro at cs.washington.edu<mailto:markro at cs.washington.edu>>; classfile-api-dev at openjdk.org<mailto:classfile-api-dev at openjdk.org>
Cc: Chen Liang <chen.l.liang at oracle.com<mailto: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<mailto:classfile-api-dev-retn at openjdk.org>> on behalf of Mark Roberts <markro at cs.washington.edu<mailto:markro at cs.washington.edu>>
Date: Tuesday, 28 January 2025 at 21:45
To: classfile-api-dev at openjdk.org<mailto:classfile-api-dev at openjdk.org> <classfile-api-dev at openjdk.org<mailto:classfile-api-dev at openjdk.org>>
Cc: Chen Liang <chen.l.liang at oracle.com<mailto: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/6b513d90/attachment-0001.htm>