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