[lworld] RFR: 8267791: [lworld][lw3] Support compiler blackholes for inline types
Tobias Hartmann
thartmann at openjdk.java.net
Thu May 27 07:36:27 UTC 2021
On Wed, 26 May 2021 12:26:06 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:
> JDK-8259316 added the support for compiler blackholes. We need to check and implement the support for inline type arguments for them. I am sure we would find more wrinkles with nano-benchmarks, but insofar sample benchmark work as they should:
>
>
> public class PrimitiveClasses {
> static primitive class Value {
> long x;
> long y;
> public Value(long x, long y) {
> this.x = x;
> this.y = y;
> }
> }
>
> [volatile] Value v = Value.default;
>
> @Benchmark
> public Value test() {
> return v;
> }
> }
>
>
> Before: crash on assert, `assert(vt->fast_out(i)->is_InlineTypeBase(), "Unexpected inline type user");`
>
> After, generated code in non-`volatile` case shows blackhole of individual components:
>
>
> $ java -Djmh.blackhole.mode=COMPILER -jar target/benchmarks.jar PrimitiveClasses -prof perfasm
> ...
> ....[Hottest Region 1]..............................................................................
> c2, level 4, org.openjdk.jmh_generated.PrimitiveClasses_test_jmhTest::test_avgt_jmhStub, version 641 (39 bytes)
> ...
> ↗ 0x00007f67bcc8eee0: mov 0x18(%r8),%r10 ; read and blackhole MyValue.x
> 0.02% │ 0x00007f67bcc8eee4: mov 0x10(%r8),%r11 ; read and blackhole MyValue.y
> 0.10% │ 0x00007f67bcc8eee8: movzbl 0x94(%r14),%r11d ; read isDone
> 0.10% │ 0x00007f67bcc8eef0: mov 0x3b0(%r15),%r10 ; TL handshake
> 2.79% │ 0x00007f67bcc8eef7: add $0x1,%rbp ; ops++
> │ 0x00007f67bcc8eefb: test %eax,(%r10) ; TL handshake
> 86.74% │ 0x00007f67bcc8eefe: test %r11d,%r11d ; isDone?
> 2.31% ╰ 0x00007f67bcc8ef01: je 0x00007f67bcc8eee0
>
>
> And generated code in `volatile` case shows blackhole of the box (with the null-check):
>
>
> ↗ 0x00007f3948c8db70: shl $0x3,%r10 ; unpack and blackhole MyValue
> 0.02% │↗ 0x00007f3948c8db74: movzbl 0x94(%r14),%r8d ; read isDone
> 0.68% ││ 0x00007f3948c8db7c: mov 0x3b0(%r15),%r9 ; TL handshake
> 0.72% ││ 0x00007f3948c8db83: add $0x1,%rbp ; ops++
> ││ 0x00007f3948c8db87: test %eax,(%r9) ; TL handshake
> 92.30% ││ 0x00007f3948c8db8a: test %r8d,%r8d ; isDone?
> ╭││ 0x00007f3948c8db8d: jne 0x00007f3948c8dba4
> │││ 0x00007f3948c8db8f: mov 0xc(%r11),%r10d ; load "v" (MyValue box)
> 0.35% │││ 0x00007f3948c8db93: test %r10d,%r10d ; null check it
> │╰│ 0x00007f3948c8db96: jne 0x00007f3948c8db70
src/hotspot/share/opto/compile.cpp line 1931:
> 1929: } else {
> 1930: // Check if any users are blackholes. If so, rewrite them to use either the
> 1931: // allocated box, or individual components, instead of the inline type node
Better replace `box` by `buffer`.
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?
test/hotspot/jtreg/runtime/valhalla/inlinetypes/BlackholeTest.java line 24:
> 22: */
> 23:
> 24: package runtime.valhalla.inlinetypes;
I think this test should go to compiler.
-------------
PR: https://git.openjdk.java.net/valhalla/pull/429
More information about the valhalla-dev
mailing list