RFR: 8201516: DebugNonSafepoints generates incorrect information [v4]

[Xin Liu]

On Wed, 8 Mar 2023 10:51:50 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Why don't we just use `C->_log2_node_notes_block_size` directly in (_useful.size() >> 8)? 
>> 
>> I don't understand why we have to add MAX2(8, new_size) either. It looks like c2 doesn't want to have node-level accuracy. It drops the lowest 8bits of node_idx as block_id. I think the minimal number of "block" is 1, or arr is NULL.
>
>> Why don't we just use C->_log2_node_notes_block_size directly in (_useful.size() >> 8)?
> 
> Because it's private in `Compile`. We could make it public but I thought it's not worth it.
> 
>> I don't understand why we have to add MAX2(8, new_size) either. It looks like c2 doesn't want to have node-level accuracy. It drops the lowest 8bits of node_idx as block_id. I think the minimal number of "block" is 1, or arr is NULL.
> 
> I think you are misinterpreting the code in `Compile::locate_node_notes`. It first determines the `block_idx` by `idx >> _log2_node_notes_block_size` and then the position in that block by `idx & (_node_notes_block_size-1)`.

Thanks for the clarification. yes, I understanding was wrong. 

A block is an array of 256 Node_Note.  Is it a particular reason that Compile needs at least 8 blocks?  It can grow automatically anyway.

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

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