On Tue, 17 Nov 2020 14:55:07 GMT, Maurizio Cimadamore <[email protected]>
wrote:
> The current memory segment implementation defines a hierarchy with 3 concrete
> classes: one for heap segments, one for native segments and one for mapped
> segments.
>
> Since there can be many kinds of heap segments (e.g. created from a byte[] or
> from a float[]) the current implementation is prone to type profile pollution
> problems: if enough heap segments are created (of different kinds), the JIT
> compiler will give up on speculating on the heap segment kind, which will
> then result in poor performances.
>
> This issue can be reproduced in one of the existing benchmark, by adding some
> initialization code which is enough to pollute the types profiles. When that
> happens, performance numbers look like the following:
>
> Benchmark (polluteProfile) Mode Cnt Score
> Error Units
> LoopOverNonConstantHeap.segment_loop false avgt 10 0.285 ±
> 0.003 ms/op
> LoopOverNonConstantHeap.segment_loop true avgt 10 5.540 ±
> 0.143 ms/op
>
> (Thanks to Vlad for coming up for the exact incantation which leads to
> profile pollution :-) )
>
> The solution is to create a sharp subclass for each heap segment case. With
> this, C2 has always a sharp Unsafe *base* to work with, and performances are
> stable regardless of profile pollution attempts.
>
> This patch also tweaks the benchmark for heap segments so that it checks it
> with and without profile pollution.
Marked as reviewed by chegar (Reviewer).
src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/HeapMemorySegmentImpl.java
line 44:
> 42: * sharp type information, as well as sharp null-check information. For
> this reason, many concrete subclasses
> 43: * of {@link HeapMemorySegmentImpl} are defined (e.g. {@link OfFloat}, so
> that each subclass can override the
> 44: * {@link HeapMemorySegmentImpl#base()} method so that it returns an
> array ogf the correct (sharp) type.
minor typo "ogf" -> "of"
-------------
PR: https://git.openjdk.java.net/jdk/pull/1259
