RFR: 8228604: StackMapFrames are missing from redefined class bytes of retransformed classes

David Holmes dholmes at openjdk.org
Sun Jan 29 23:14:16 UTC 2023


On Fri, 27 Jan 2023 04:16:05 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>>>I'd expect that at least java.util.Date and java.lang.ProcessBuilder have the same verification requirement.
>> 
>> Generally speaking yes - they are both loaded by bootstrap loader and so would both have verification disabled by default. Bt as you note the behaviour can change when CDS is involved and only one class gets dumped.
>> 
>>> But in Date has StackMapTable (starting from JDK12-b15), and ProcessBuilder doesn't has StackMapTable.
>> 
>> This seems odd, but not, IMO, in itself a bug. Perhaps @iklam  can comment on why we treat things differently during dumping.
>
>> > I'd expect that at least java.util.Date and java.lang.ProcessBuilder have the same verification requirement.
>> 
>> Generally speaking yes - they are both loaded by bootstrap loader and so would both have verification disabled by default. Bt as you note the behaviour can change when CDS is involved and only one class gets dumped.
>> 
>> > But in Date has StackMapTable (starting from JDK12-b15), and ProcessBuilder doesn't has StackMapTable.
>> 
>> This seems odd, but not, IMO, in itself a bug. Perhaps @iklam can comment on why we treat things differently during dumping.
> 
> We always enable verification for all classes during -Xshare:dump. That avoid problems where the classes were dumped without verification but at run time you enable verification.

I'm not sure of all the implications of always having the stackmap. IIU what @iklam was saying then anyone running with cds enabled will not encounter the reported problem as the stackmap will be present. So these days only when you run without CDS can you encounter the issue. Is that right?

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

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


More information about the hotspot-runtime-dev mailing list