Integrated: 8256477: Specialize heap memory segment implementations

[Maurizio Cimadamore]

On Tue, 17 Nov 2020 14:55:07 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> 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.

This pull request has now been integrated.

Changeset: d2ddf074
Author:    Maurizio Cimadamore <mcimadamore at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/d2ddf074
Stats:     187 lines in 4 files changed: 140 ins; 4 del; 43 mod

8256477: Specialize heap memory segment implementations

Reviewed-by: jvernee, chegar

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

PR: https://git.openjdk.java.net/jdk/pull/1259