[9] [8u40] RFR (M): 8059877: GWT branch frequencies pollution due to LF sharing

[Remi Forax]

Hi Vladimir,

Why do you need getHistoricInt ?
Is it because Unsafe.getInt() doesn't do any constant folding ?

BTW, why getHistoricInt is named getHistoricInt ?

cheers,
Rémi

On 10/10/2014 09:08 PM, Vladimir Ivanov wrote:
> http://cr.openjdk.java.net/~vlivanov/8059877/webrev.00/
> https://bugs.openjdk.java.net/browse/JDK-8059877
>
> LambdaForm sharing introduces profile pollution in compiled 
> LambdaForms. The most serious consequence is inlining distortion, 
> which severely degrade peak performance. The main victim is 
> guardWithTest (GWT) combinator.
>
> Before LambdaForm sharing, inlining in GWT was affected by 2 aspects:
>   - branch frequencies: never-taken branch is skipped;
>   - target & fallback method handles (corresponding LFs: compiled vs 
> interpreted): if method handle has been invoked < COMPILE_THRESHOLD 
> times, LambdaForm.vmentry points to LF interpreter which is marked w/ 
> @DontInline.
>
> LambdaForm sharing breaks both aspects:
>   - sharing of GWT LambdaForm pollutes branch profile;
>   - sharing of LambdaForms used in target & fallback pollutes 
> invocation counters.
>
> I experimented w/ VM API to guide JIT-compiler using profiling 
> information gathered on LambdaForm level [1], but decided to take 
> safer route for now (8u40). JIT-compiler control approach looks 
> promising, but I need more time to get rid of some performance 
> artifacts it suffers from.
>
> The proposed fix is to mimic behavior of fully customized LambdaForms.
> When GWT is created, both target & fallback method handles are wrapped 
> in a special reinoker, which blocks inlining (@DontInline on 
> reinvoker's compiled LambdaForm). Once a wrapper is invoked more that 
> DONT_INLINE_THRESHOLD times, it's LambdaForm is replaced with a 
> regular reinvoker, which is fully transparent for the JIT and it 
> inlines smoothly.
>
> The downside of the chosen approach is that LambdaForm.updateForm() 
> doesn't guarantee that all places where stale LambaForm is used see 
> the update. If it is already part of some nmethod, it won't be 
> invalidated and recompiled, but will be kept as is. It shouldn't be a 
> problem, since DONT_INLINE_THRESHOLD is expected to be pretty low 
> (~30), so only very rarely executed branches are affected.
>
> The fix significantly improves peak performance w/ full LF sharing 
> (USE_LF_EDITOR=true).
>
> Octane/nashorn results [2] for:
>   (1) USE_LF_EDITOR=false DONT_INLINE_THRESHOLD=0 (default for 8u40&9)
>   (2) USE_LF_EDITOR=true  DONT_INLINE_THRESHOLD=0 (default for 8u40&9)
>   (3) USE_LF_EDITOR=true  DONT_INLINE_THRESHOLD=30 (fixed version)
>
> (1) & (2) correspond to default configurations (partial & full LF 
> sharing respectively). (3) is the fixed version.
>
> The fix recovers peak performance for:
>  * Crypto:       ~255ms -> ~12ms;
>  * DeltaBlue:     ~40ms ->  ~2ms;
>  * Raytracer:     ~62ms ->  ~7ms;
>  * EarleyBoyer:  ~160ms ->  ~22ms;
>  * NavierStokes:  ~17ms ->  ~13ms;
>
> 2 subbenchmarks (Box2D & Gbemu) still has some regressions, but it's 
> much better now:
>    Box2D: ~48ms -> ~61ms  (w/o the fix: ~155ms)
>    Gbemu: ~88ms -> ~116ms (w/o the fix: ~160ms)
>
> Testing:
>   tests: jck (api/java_lang/invoke), jdk/java/lang/invoke, 
> jdk/java/util/streams, octane
>  configurations: -ea -esa -Xverify:all
>  + COMPILE_THRESHOLD={0,30} + USE_LF_EDITOR={false,true} + 
> DONT_INLINE_THRESHOLD={0,30}
>
> Thanks!
>
> Best regards,
> Vladimir Ivanov
>
> [1] http://cr.openjdk.java.net/~vlivanov/profiling/
> [2] http://cr.openjdk.java.net/~vlivanov/8059877/octane.txt
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev