You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@harmony.apache.org by "Cheng, BuQi (JIRA)" <ji...@apache.org> on 2008/10/10 08:01:44 UTC
[jira] Commented: (HARMONY-5584) [drlvm][jit][opt][performance]
Inliner heuristics improvements: hotness and instance initializer bonuses
[ https://issues.apache.org/jira/browse/HARMONY-5584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12638492#action_12638492 ]
Cheng, BuQi commented on HARMONY-5584:
--------------------------------------
Aleksey:
There is no reason that MAX_INLINE_GROWTH_FACTOR_PROF will be defined as 2000. The bytecode size change before and after inline nextDouble are methodByteSize=52, newByteSize = 120, factor=1.76471. After changing MAX_INLINE_GROWTH_FACTOR_PROF to 500. The nextDouble is inlined also.
However, if MAX_INLINE_GROWTH_FACTOR_PROF is defined as 2000. We can see more perfomance improvement. Original, 300 ops/min, Patched with MAX_INLINE_GROWTH_FACTOR_PROF=500: 346.98 ops/min, Patched MAX_INLINE_GROWTH_FACTOR_PROF=2000: 409 ops/min. Obviously, more methods are inlined. However, I don't think we can get so much performance by inlining a method with more than 2000 instruction. So I guess the benifit must comes from the nested inlined region. I will do more study on it to find out the problem of inline policy.
Thanks!
Buqi
> [drlvm][jit][opt][performance] Inliner heuristics improvements: hotness and instance initializer bonuses
> --------------------------------------------------------------------------------------------------------
>
> Key: HARMONY-5584
> URL: https://issues.apache.org/jira/browse/HARMONY-5584
> Project: Harmony
> Issue Type: Improvement
> Components: DRLVM
> Environment: all
> Reporter: Aleksey Shipilev
> Assignee: Mikhail Fursov
> Attachments: H5584-inliner-heuristics.patch, H5584-inliner-heuristics.patch
>
>
> During the profiling of Scimark2 [1] it was found that inliner misses the inline opportunities for monte_carlo.
> This is the code for hottest method:
> public static final double integrate(int Num_samples)
> {
> Random R = new Random(SEED);
> int under_curve = 0;
> for (int count=0; count<Num_samples; count++)
> {
> double x= R.nextDouble();
> double y= R.nextDouble();
> if ( x*x + y*y <= 1.0)
> under_curve ++;
>
> }
> return ((double) under_curve / Num_samples) * 4.0;
> }
> Problems are:
> 1. nextDouble is not inlined
> 2. nextDouble is internally synchronized
> Attached patch solves these two problems:
> 1. fixing hotness bonus calculation. This is the issue Random.nextDouble() hit on: this method called in hot cycle and missing inline opportunity due to glitch in scaling function, which should be more additive rather than multiplicative.
> 2. introducing instance initializer bonus. This helps to inline constructor with all corresponding methods to help scalar replacement with scalarizing of R (and eliminating synchronization too).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.