[External] : RE: StackMap problem
Chen Liang
chen.l.liang at oracle.com
Wed Jan 29 17:44:36 UTC 2025
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>
More information about the classfile-api-dev
mailing list