RFR: 8322996: BoxLockNode creation fails with assert(reg < CHUNK_SIZE) failed: sanity [v3]

Vladimir Kozlov kvn at openjdk.org
Wed Jan 17 00:12:49 UTC 2024


On Mon, 15 Jan 2024 09:32:15 GMT, Daniel Lundén <dlunden at openjdk.org> wrote:

>> I think your current code is correct.
>> 
>> On x64 `sync_stack_slots` defined as 2 (takes 2 bits in regmask) in  `x86_64.ad` and as 1 in `x86_32.ad`. On most 64 bit platforms it is also 2 slots, from what I see. But we can't guarantee that some platforms will not have bigger value. We can't use last odd bit on 64 bit platform in regmask - it is taking anyway already by "infinite stack flag".
>
> Yes, that is my intuition as well. Therefore, I'm left wondering if the [construction of `_inmask`](https://github.com/dlunde/jdk/blob/9ab6e561780aee0f2cc2f06cd40ec487d60fe39c/src/hotspot/share/opto/locknode.cpp#L51) in the `BoxLockNode` constructor is incorrect, as it always just sets a single bit in the mask (no matter the value of `sync_stack_slots()`). Should we perhaps change it to instead set the range [ reg, reg + sync_stack_slots() ) in `_inmask`?

It is fine. Monitors use fixed stack slots which are not available to Register allocator: [compile.hpp#L315](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/opto/compile.hpp#L315). Fixed stack slots reserved based on number monitors and etc. We don't do regmask operations on them.

`BoxLockNode::reg(box)` is only accessed in format output in `JVMState::format()` and when we generate debug info in `PhaseOutput::Process_OopMap_Node()`.

In general, in 64-bit VM long, double, oop/pointers values take 2 slots but their value is stored only in first slot (since slot's size is 64 bit). Don't ask why. It is convention in VM.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17370#discussion_r1454236214


More information about the hotspot-compiler-dev mailing list