Re: RFR: 8256477: Specialize heap memory segment implementations [v2]
On Wed, 18 Nov 2020 10:08:20 GMT, Maurizio Cimadamore 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. > > Maurizio Cimadamore has updated the pull request incrementally with one > additional commit since the last revision: > > Fix typo Marked as reviewed by sundar (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/1259
Re: RFR: 8256477: Specialize heap memory segment implementations [v2]
> 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. Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Fix typo - Changes: - all: https://git.openjdk.java.net/jdk/pull/1259/files - new: https://git.openjdk.java.net/jdk/pull/1259/files/2366b69e..e892bc75 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=1259=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk=1259=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 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
