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

Vladimir Kozlov kvn at openjdk.org
Fri Jan 26 17:44:37 UTC 2024


On Fri, 26 Jan 2024 09:56:05 GMT, Daniel Lundén <dlunden at openjdk.org> wrote:

>> I am not worry about exit in`load_interpreter_state()` there is check after call.
>> 
>> There is call to `record_profiled_parameters_for_speculation()` after `shared_lock()` call in `do_method_entry()`. It does not check `failing()`. May be add check `if (!failing())` when calling it (or inside it).
>> 
>> For `do_one_bytecode()` case the only question is if IGVN code can handle such bailout. It is called at the end of method. If not, we need to add the check.
>
>> There is call to record_profiled_parameters_for_speculation() after shared_lock() call in do_method_entry(). It does not check failing(). May be add check if (!failing()) when calling it (or inside it).
> 
> I've now added a check just after `_synch_lock = shared_lock(lock_obj);`, thanks.
> 
>> For do_one_bytecode() case the only question is if IGVN code can handle such bailout. **It is called at the end of method**. If not, we need to add the check.
> 
> I cannot see any call to IGVN after `do_monitor_enter()` in `do_one_bytecode()`. Can you elaborate? Maybe related, I also changed to
> 
> Node *box = new BoxLockNode(next_monitor());
> // Check for bailout after new BoxLockNode
> if (failing()) { return; }
> box = _gvn.transform(box);
> 
> from the previous
> 
> Node *box = _gvn.transform(new BoxLockNode(next_monitor()));
> // Check for bailout after new BoxLockNode
> if (failing()) { return; }
> 
> to avoid potential issues with `_gvn.transform` due to the new bailout.

Does `_gvn.transform` handle bailout?

> I cannot see any call to IGVN after `do_monitor_enter()` in `do_one_bytecode()`. Can you elaborate?

Sorry, I mean IGV (IdealGraphVisualizer) [parse2.cpp#L2782]
(https://github.com/openjdk/jdk/blob/master/src/hotspot/share/opto/parse2.cpp#L2782)

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

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


More information about the hotspot-compiler-dev mailing list