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. ------------- Commit messages: - Tweak code so that specialized classes define their own factories - make base() method abstract in HeapMemorySegmentImpl - Create specialized subclasses for all the heap segment cases Changes: https://git.openjdk.java.net/jdk/pull/1259/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1259&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8256477 Stats: 187 lines in 4 files changed: 140 ins; 4 del; 43 mod Patch: https://git.openjdk.java.net/jdk/pull/1259.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1259/head:pull/1259 PR: https://git.openjdk.java.net/jdk/pull/1259
