[lworld] RFR: 8267791: [lworld][lw3] Support compiler blackholes for inline types [v2]

[Tobias Hartmann]

On Mon, 31 May 2021 09:38:37 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> src/hotspot/share/opto/compile.cpp line 1945:
>> 
>>> 1943:             if (vt->is_allocated(&igvn)) {
>>> 1944:               // Already has the allocated instance, blackhole that
>>> 1945:               bh->add_req(vt->get_oop());
>> 
>> This might keep an otherwise unused buffer allocation alive. Is that the expected behavior of using backholes on inline types? Why not always blackhole the components?
>
> The expected behavior is debatable. Current behavior in the corner cases does make sense to me: for non-flattened cases, we blackhole the reference to wrapper (as that is what application code would be exposed to), in flattened cases, we blackhole the components (as that is what application code would be exposed to). 
> 
> I probably misunderstand the compiler code here. Can there be an allocated box that goes away later, and only the component accesses survive? If so, how should this code ask for "if the allocated instance is alive, then blackhole it"?

On second thought, I think this is fine.

> Can there be an allocated box that goes away later, and only the component accesses survive?

Yes, in general that can happen and is not unlikely. For example, due to late inlining or other optimizations removing a non-scalarizable use of the buffer allocation. However, in this case all such optimizations are already over and unused allocations would have been removed. I.e., if `vt->is_allocated` is true, there is a user of the buffer allocation that won't go away and therefore linking the allocation to the blackhole should be fine.

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

PR: https://git.openjdk.java.net/valhalla/pull/429