You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@harmony.apache.org by "Aleksey Shipilev (JIRA)" <ji...@apache.org> on 2008/03/07 16:29:46 UTC
[jira] Created: (HARMONY-5584) [drlvm][jit][opt][performance]
Inliner heuristics improvements: hottness and instance initializer bonuses
[drlvm][jit][opt][performance] Inliner heuristics improvements: hottness and instance initializer bonuses
---------------------------------------------------------------------------------------------------------
Key: HARMONY-5584
URL: https://issues.apache.org/jira/browse/HARMONY-5584
Project: Harmony
Issue Type: Improvement
Environment: all
Reporter: Aleksey Shipilev
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (HARMONY-5584) [drlvm][jit][opt][performance]
Inliner heuristics improvements: hotness and instance initializer bonuses
Posted by "Aleksey Shipilev (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-5584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Aleksey Shipilev updated HARMONY-5584:
--------------------------------------
Description:
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).
was:
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 escape analysis with eliminating the synchronization in Random.nextDouble().
> [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
> Environment: all
> Reporter: Aleksey Shipilev
> Attachments: 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.
[jira] Updated: (HARMONY-5584) [drlvm][jit][opt][performance]
Inliner heuristics improvements: hotness and instance initializer bonuses
Posted by "Dmitry Pronichkin (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-5584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Dmitry Pronichkin updated HARMONY-5584:
---------------------------------------
Attachment: H5584-inliner-heuristics.patch
Patch updated for current revision.
> [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
> 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.
[jira] Updated: (HARMONY-5584) [drlvm][jit][opt][performance]
Inliner heuristics improvements: hottness and instance initializer bonuses
Posted by "Aleksey Shipilev (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-5584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Aleksey Shipilev updated HARMONY-5584:
--------------------------------------
Description:
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 escape analysis with eliminating the synchronization in Random.nextDouble().
> [drlvm][jit][opt][performance] Inliner heuristics improvements: hottness and instance initializer bonuses
> ---------------------------------------------------------------------------------------------------------
>
> Key: HARMONY-5584
> URL: https://issues.apache.org/jira/browse/HARMONY-5584
> Project: Harmony
> Issue Type: Improvement
> Environment: all
> Reporter: Aleksey Shipilev
>
> 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 escape analysis with eliminating the synchronization in Random.nextDouble().
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (HARMONY-5584) [drlvm][jit][opt][performance]
Inliner heuristics improvements: hotness and instance initializer bonuses
Posted by "Cheng, BuQi (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-5584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12638760#action_12638760 ]
Cheng, BuQi commented on HARMONY-5584:
--------------------------------------
Hi Aleksey:
For the performance data. We get following data. The version we used is the version I checked out in Augest, 4. We did not run startup.*. However, there is still many benchmarks failed to run(Not because of the patch). From these data we can find 800 is suitable for the MAX_INLINE_GROWTH_FACTOR_PROF. I am not sure what kind of data can be got in other benchmarks except SPECjvm2008. Can you give more information on why MAX_INLINE_GROWTH_FACTOR_PROF = 2000?
CLEAN
MAX_INLINE_GROWTH_FACTOR_PROF =800
MAX_INLINE_GROWTH_FACTOR_PROF = 2000
Clean 800 2000 800 2000
crypto.aes 39.59 38.22 37.08 -3.46% -6.34%
crypto.rsa 193.24 172.08 178.08 -10.95% -7.85%
crypto.signverify 118.6 109.71 107.61 -7.50% -9.27%
compiler.compiler 93.86 91.25 87.61 -2.78% -6.66%
compiler.sunflow 139.63 123.64 136.65 -11.45% -2.13%
scimark.fft.large 14.8 14.93 15.92 0.88% 7.57%
scimark.sor.large 21.69 21.71 21.65 0.09% -0.18%
scimark.sparse.large 12.86 12.88 12.85 0.16% -0.08%
scimark.monte_carlo 298.17 977.29 1024.55 227.76% 243.61%
derby 42.73 40.13 41.8 -6.08% -2.18%
compress 117.23 111.12 110.12 -5.21% -6.07%
xml.validation 81.17 82.15 80.75 1.21% -0.52%
scimark.fft.small 931.98 931.98 903.96 0.00% -3.01%
scimark.lu.small 842.59 831.09 841.83 -1.36% -0.09%
scimark.sparse.small 70.95 65.5 70.7 -7.68% -0.35%
serial 8.32 8 8.23 -3.85% -1.08%
Another problem is that, as you mentioned that escape analysis directive inline is more suitable for the case. So I am wondering if it's suitable to commit the whole patch. Maybe, it's better that we only commit the adjustment of MAX_INLINE_GROWTH_FACTOR_PROF which will introduce about 30% performance improvement in monte_carlo. However, it will be a hard work if we re-desgin the optimizations of Harmony. One general consideration is trying to promote the basic analysises(such as the live range scope of objects-escape analysis, ..) in the front of the pipeline. What do you think of it?
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.
[jira] Updated: (HARMONY-5584) [drlvm][jit][opt][performance]
Inliner heuristics improvements: hotness and instance initializer bonuses
Posted by "Aleksey Shipilev (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-5584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Aleksey Shipilev updated HARMONY-5584:
--------------------------------------
Summary: [drlvm][jit][opt][performance] Inliner heuristics improvements: hotness and instance initializer bonuses (was: [drlvm][jit][opt][performance] Inliner heuristics improvements: hottness and instance initializer bonuses)
> [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
> Environment: all
> Reporter: Aleksey Shipilev
> Attachments: 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 escape analysis with eliminating the synchronization in Random.nextDouble().
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (HARMONY-5584) [drlvm][jit][opt][performance]
Inliner heuristics improvements: hotness and instance initializer bonuses
Posted by "Egor Pasko (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-5584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12580280#action_12580280 ]
Egor Pasko commented on HARMONY-5584:
-------------------------------------
sorry for my annoyance,
...but did you measure the footprint change? If Eclipse startup footprint grows by 20%, we need to invent something more intelligent
> [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
> Environment: all
> Reporter: Aleksey Shipilev
> Assignee: Mikhail Fursov
> Attachments: 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.
[jira] Commented: (HARMONY-5584) [drlvm][jit][opt][performance]
Inliner heuristics improvements: hotness and instance initializer bonuses
Posted by "Mikhail Fursov (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-5584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12579855#action_12579855 ]
Mikhail Fursov commented on HARMONY-5584:
-----------------------------------------
There is a problem with the increased value of
-#define MAX_INLINE_GROWTH_FACTOR_PROF 500
+#define MAX_INLINE_GROWTH_FACTOR_PROF 2000
regression tests in debug mode fail by timeout.
Is it necessarily change? Can we put 1000 here or leave the old value?
> [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
> Environment: all
> Reporter: Aleksey Shipilev
> Assignee: Mikhail Fursov
> Attachments: 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.
[jira] Commented: (HARMONY-5584) [drlvm][jit][opt][performance]
Inliner heuristics improvements: hotness and instance initializer bonuses
Posted by "Aleksey Shipilev (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-5584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12580788#action_12580788 ]
Aleksey Shipilev commented on HARMONY-5584:
-------------------------------------------
Egor,
Entire JET/OPT code calculated. It was just a quick test to show the magnitude of values we have here. The code is about 1 Mb, that value is negligible comparing to Java heap of 512 Mb. So I'm not thinking its growing is the issue.
> [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
> Environment: all
> Reporter: Aleksey Shipilev
> Assignee: Mikhail Fursov
> Attachments: 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.
[jira] Commented: (HARMONY-5584) [drlvm][jit][opt][performance]
Inliner heuristics improvements: hotness and instance initializer bonuses
Posted by "Cheng, BuQi (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Commented: (HARMONY-5584) [drlvm][jit][opt][performance]
Inliner heuristics improvements: hottness and instance initializer bonuses
Posted by "Aleksey Shipilev (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-5584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12576267#action_12576267 ]
Aleksey Shipilev commented on HARMONY-5584:
-------------------------------------------
H5584-inliner-heuristics.patch performance measurements (ThinkPad T61p / Windows XP SP2).
Baseline configuration: shade.r631623.P.pC.clean/bin/java -Xms512M -Xmx512M -Xem:server jnt.scimark2.commandline -large
==== Clean: ====
Composite Score: 253.32
FFT (1048576): 47.19
SOR (1000x1000): 511.14
Monte Carlo : 51.45
Sparse matmult (N=100000, nz=1000000): 399.68
LU (1000x1000): 257.10
==== hotnessBonus implementation ====
Composite Score: 249.87
FFT (1048576): 48.90
SOR (1000x1000): 498.18
Monte Carlo : 65.091
Sparse matmult (N=100000, nz=1000000): 383.23
LU (1000x1000): 253.96
==== hotnessBonus + instanceInitializer ====
Composite Score: 260.43
FFT (1048576): 48.57
SOR (1000x1000): 493.06
Monte Carlo : 102.26
Sparse matmult (N=100000, nz=1000000): 399.68
LU (1000x1000): 258.598
------------------------------
That is, 2x improvement for MonteCarlo sub-benchmark and +4% to composite score.
> [drlvm][jit][opt][performance] Inliner heuristics improvements: hottness and instance initializer bonuses
> ---------------------------------------------------------------------------------------------------------
>
> Key: HARMONY-5584
> URL: https://issues.apache.org/jira/browse/HARMONY-5584
> Project: Harmony
> Issue Type: Improvement
> Environment: all
> Reporter: Aleksey Shipilev
> Attachments: 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 escape analysis with eliminating the synchronization in Random.nextDouble().
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (HARMONY-5584) [drlvm][jit][opt][performance]
Inliner heuristics improvements: hotness and instance initializer bonuses
Posted by "Mikhail Fursov (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-5584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12579882#action_12579882 ]
Mikhail Fursov commented on HARMONY-5584:
-----------------------------------------
A test execution time becomes too long in debug version and test fails (H5094, debug, em64t)
The best solution here could be an analysis of the problem method with -XX:jit.arg.time=on and tuning compilation time performance to make it run faster.
> [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
> Environment: all
> Reporter: Aleksey Shipilev
> Assignee: Mikhail Fursov
> Attachments: 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.
[jira] Updated: (HARMONY-5584) [drlvm][jit][opt][performance]
Inliner heuristics improvements: hotness and instance initializer bonuses
Posted by "Cheng, BuQi (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-5584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Cheng, BuQi updated HARMONY-5584:
---------------------------------
Attachment: inliner_cpp.patch
Inliner and escanalyzer huristics are selected to tune scimark.monte_carlo
> [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, inliner_cpp.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.
[jira] Commented: (HARMONY-5584) [drlvm][jit][opt][performance]
Inliner heuristics improvements: hottness and instance initializer bonuses
Posted by "Aleksey Shipilev (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-5584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12576268#action_12576268 ]
Aleksey Shipilev commented on HARMONY-5584:
-------------------------------------------
SPECjbb2005 and other performance-heavy benchmarks were checked and no disturbance in performance was notified.
Patch is ready for committing.
> [drlvm][jit][opt][performance] Inliner heuristics improvements: hottness and instance initializer bonuses
> ---------------------------------------------------------------------------------------------------------
>
> Key: HARMONY-5584
> URL: https://issues.apache.org/jira/browse/HARMONY-5584
> Project: Harmony
> Issue Type: Improvement
> Environment: all
> Reporter: Aleksey Shipilev
> Attachments: 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 escape analysis with eliminating the synchronization in Random.nextDouble().
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (HARMONY-5584) [drlvm][jit][opt][performance]
Inliner heuristics improvements: hotness and instance initializer bonuses
Posted by "Aleksey Shipilev (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-5584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12638802#action_12638802 ]
Aleksey Shipilev commented on HARMONY-5584:
-------------------------------------------
Please move this discussion to dev-list.
> [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.
[jira] Commented: (HARMONY-5584) [drlvm][jit][opt][performance]
Inliner heuristics improvements: hotness and instance initializer bonuses
Posted by "Cheng, BuQi (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-5584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12638505#action_12638505 ]
Cheng, BuQi commented on HARMONY-5584:
--------------------------------------
Sorry, I made a mistake. MAX_INLINE_GROWTH_FACTOR_PROF /100 will be real factor. So 500 will be 5 in factor.
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.
[jira] Commented: (HARMONY-5584) [drlvm][jit][opt][performance]
Inliner heuristics improvements: hotness and instance initializer bonuses
Posted by "Cheng, BuQi (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-5584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12639348#action_12639348 ]
Cheng, BuQi commented on HARMONY-5584:
--------------------------------------
Hi Aleksey:
This is the data which will not count on InstanceInitilization bonus. However, we fixed the escape analysis and extend the analysis method level: max_level=2. With this fix, the sync elimiation is done also. However, the scalar replacement still don't work. The data is like following:
cleanmax_level=2InstanceInitilize inlinemax_level=2InstanceInitilize inline
crypto.aes39.5937.7938.22-0.045466027-0.0346
crypto.rsa193.24178.11172.08-0.078296419-0.1095
crypto.signverify118.6111.5109.71-0.059865093-0.07496
compiler.compiler93.8695.291.250.014276582-0.02781
compiler.sunflow139.63133.45123.64-0.04425983-0.11452
scimark.fft.large14.815.0114.930.0141891890.008784
scimark.sor.large21.6921.6721.71-0.0009220840.000922
scimark.sparse.large12.8612.7712.88-0.0069984450.001555
scimark.monte_carlo298.17707.2977.291.3718013212.277627
xml.validation81.1779.182.15-0.0255020330.012073
scimark.fft.small931.98919.09931.98-0.0138307690
scimark.lu.small842.59811.66831.09-0.036708245-0.01365
scimark.sparse.small70.9570.9465.5-0.000140944-0.07681
serial 8.3288-0.038461538-0.03846
>From the data we can find the benefit distribution is: inline: 100, sync elimiation: 300, scalar replacement:300.
So, I think we add patch for inliner and escape analysis. For scalar replacement, it can be solved by escape analysis associated work.
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.
[jira] Commented: (HARMONY-5584) [drlvm][jit][opt][performance]
Inliner heuristics improvements: hotness and instance initializer bonuses
Posted by "Aleksey Shipilev (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-5584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12580311#action_12580311 ]
Aleksey Shipilev commented on HARMONY-5584:
-------------------------------------------
Egor, are you talking about code footprint? Inliner will only increase this one. But there is another large contributor - data (Java heap, internal VM structures) that aren't affected by this change. I wonder now much code there is on Eclipse startup relating to its data heap.
Mikhail, can you please provide me with exact line to run the test?
> [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
> Environment: all
> Reporter: Aleksey Shipilev
> Assignee: Mikhail Fursov
> Attachments: 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.
[jira] Commented: (HARMONY-5584) [drlvm][jit][opt][performance]
Inliner heuristics improvements: hotness and instance initializer bonuses
Posted by "Egor Pasko (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-5584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12580775#action_12580775 ]
Egor Pasko commented on HARMONY-5584:
-------------------------------------
Alexey,
estimation sounds great!
that's probably because most is compiled by JET, or is it including JET code? BTW, we also should count bytecode mapping and inline mapping... this is what you probably meant by data of VM structures. But they are affected by inliner.
> [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
> Environment: all
> Reporter: Aleksey Shipilev
> Assignee: Mikhail Fursov
> Attachments: 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.
[jira] Commented: (HARMONY-5584) [drlvm][jit][opt][performance]
Inliner heuristics improvements: hotness and instance initializer bonuses
Posted by "Mikhail Fursov (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-5584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12580289#action_12580289 ]
Mikhail Fursov commented on HARMONY-5584:
-----------------------------------------
>Can we just increase the timeout then?
It's possible to create an option for the test system: customizable timeout for every test. But this is not the easiest way.
Did you check -XX:jit.arg.time=on output? It's possible that some optimizations do too much checking in debug mode and this is the reason. We can easily move such checking under some special option and solve the problem.
I just want to mention that the condition of the patch to be integrated: there are tests failed.
BTW #define MAX_INLINE_GROWTH_FACTOR_PROF 1000 passes regression testing in debug mode in my environment. Is this value enough?
> [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
> Environment: all
> Reporter: Aleksey Shipilev
> Assignee: Mikhail Fursov
> Attachments: 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.
[jira] Assigned: (HARMONY-5584) [drlvm][jit][opt][performance]
Inliner heuristics improvements: hotness and instance initializer bonuses
Posted by "Mikhail Fursov (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-5584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mikhail Fursov reassigned HARMONY-5584:
---------------------------------------
Assignee: Mikhail Fursov
> [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
> Environment: all
> Reporter: Aleksey Shipilev
> Assignee: Mikhail Fursov
> Attachments: 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.
[jira] Updated: (HARMONY-5584) [drlvm][jit][opt][performance]
Inliner heuristics improvements: hotness and instance initializer bonuses
Posted by "Cheng, BuQi (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-5584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Cheng, BuQi updated HARMONY-5584:
---------------------------------
Attachment: escanalyzer_h.patch
> [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: escanalyzer_h.patch, H5584-inliner-heuristics.patch, H5584-inliner-heuristics.patch, inliner_cpp.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.
[jira] Commented: (HARMONY-5584) [drlvm][jit][opt][performance]
Inliner heuristics improvements: hotness and instance initializer bonuses
Posted by "Aleksey Shipilev (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-5584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12580770#action_12580770 ]
Aleksey Shipilev commented on HARMONY-5584:
-------------------------------------------
Egor, I have a rough estimation of code size on Eclipse startup (via -XX:jit.arg.log=info): 300 Kb of native code, no changes due to inline.
> [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
> Environment: all
> Reporter: Aleksey Shipilev
> Assignee: Mikhail Fursov
> Attachments: 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.
[jira] Commented: (HARMONY-5584) [drlvm][jit][opt][performance]
Inliner heuristics improvements: hotness and instance initializer bonuses
Posted by "Egor Pasko (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-5584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12581395#action_12581395 ]
Egor Pasko commented on HARMONY-5584:
-------------------------------------
Alexey,
thanks for the work!
do you have a patch to ease the code size calculation? if so, let's commit it
> [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
> Environment: all
> Reporter: Aleksey Shipilev
> Assignee: Mikhail Fursov
> Attachments: 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.
[jira] Commented: (HARMONY-5584) [drlvm][jit][opt][performance]
Inliner heuristics improvements: hotness and instance initializer bonuses
Posted by "Egor Pasko (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-5584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12580723#action_12580723 ]
Egor Pasko commented on HARMONY-5584:
-------------------------------------
Aleksey,
yes, I mean code. Although we cannot count it easily now, I suggest to measure the whole footprint with data. This is what users care about and we tend to forget when targeting at server-side benchmarks.
If you know a better user application to worry about in terms of footprint, I would be happy to discuss it.
P.S.: forgot to say: great work!!!
> [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
> Environment: all
> Reporter: Aleksey Shipilev
> Assignee: Mikhail Fursov
> Attachments: 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.
[jira] Updated: (HARMONY-5584) [drlvm][jit][opt][performance]
Inliner heuristics improvements: hottness and instance initializer bonuses
Posted by "Aleksey Shipilev (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-5584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Aleksey Shipilev updated HARMONY-5584:
--------------------------------------
Attachment: H5584-inliner-heuristics.patch
H5584-inliner-heuristics.patch
Proposed patch.
> [drlvm][jit][opt][performance] Inliner heuristics improvements: hottness and instance initializer bonuses
> ---------------------------------------------------------------------------------------------------------
>
> Key: HARMONY-5584
> URL: https://issues.apache.org/jira/browse/HARMONY-5584
> Project: Harmony
> Issue Type: Improvement
> Environment: all
> Reporter: Aleksey Shipilev
> Attachments: 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 escape analysis with eliminating the synchronization in Random.nextDouble().
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (HARMONY-5584) [drlvm][jit][opt][performance]
Inliner heuristics improvements: hotness and instance initializer bonuses
Posted by "Mikhail Fursov (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-5584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12581895#action_12581895 ]
Mikhail Fursov commented on HARMONY-5584:
-----------------------------------------
>line to run the test
ant reg.test -Dtest.case=H5094
> [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
> Environment: all
> Reporter: Aleksey Shipilev
> Assignee: Mikhail Fursov
> Attachments: 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.
[jira] Commented: (HARMONY-5584) [drlvm][jit][opt][performance]
Inliner heuristics improvements: hotness and instance initializer bonuses
Posted by "Aleksey Shipilev (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-5584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12579896#action_12579896 ]
Aleksey Shipilev commented on HARMONY-5584:
-------------------------------------------
So, am I thinking right?
1. There is no functional regression with increased growth factor.
2. There is an timeout during the test.
Can we just increase the timeout then?
> [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
> Environment: all
> Reporter: Aleksey Shipilev
> Assignee: Mikhail Fursov
> Attachments: 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.
[jira] Commented: (HARMONY-5584) [drlvm][jit][opt][performance]
Inliner heuristics improvements: hotness and instance initializer bonuses
Posted by "Aleksey Shipilev (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-5584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12579864#action_12579864 ]
Aleksey Shipilev commented on HARMONY-5584:
-------------------------------------------
Well, according to my measurements, this change is necessary to inline nextDouble() and also it's not degrading the performance of other workloads.
Can we fix the failure in regression tests instead? Is this issue directly caused by increasing of growth factor? It's strange how inline might break them.
> [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
> Environment: all
> Reporter: Aleksey Shipilev
> Assignee: Mikhail Fursov
> Attachments: 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.