RFR: 8369238: Allow virtual thread preemption on some common class initialization paths [v6]
David Holmes
dholmes at openjdk.org
Wed Oct 29 05:56:07 UTC 2025
On Fri, 24 Oct 2025 14:06:03 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:
>> Yes, but don’t really see the benefit. It’s replacing a null string for `precond` in a crash.
>
> These null strings make me wish we had an assert with no strings if one isn't provided. I suppose the "precond" string isn't much better. I don't like null strings - it seems like you want to say why you're asserting this condition or what it means, ie take the opportunity to provide a bit more documentation. Like here you could say that monitorenter is only preempted when the top frame is interpreted or runtime (which is coming from the compiler right?), which I suppose is redundant with the condition. I suppose nothing is better than "sanity" or "should be". I retract my suggestion to use precond though. Others might believe it's better but I'm agnostic.
So is it a compiled frame otherwise? Reporting the unexpected frame type might be useful.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/27802#discussion_r2471812478
More information about the hotspot-dev
mailing list