On Wed, 18 Nov 2020 10:08:20 GMT, Maurizio Cimadamore <mcimadam...@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.
>
> 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

Reply via email to