Re: RFR(L): 8161211: better inlining support for loop bytecode intrinsics

2016-09-23 Thread Vladimir Ivanov 

Looks even better :-) Reviewed.

Best regards,
Vladimir Ivanov

On 9/22/16 10:23 AM, Michael Haupt wrote:

Hi John,

thanks for your review, and thanks Vladimir! I've had another go at the 
implementation to use a dedicated loop clause holder class with a stable array; 
performance is roughly on par with that of the BMHs-as-arrays approach (see 
below).

The new webrev is at http://cr.openjdk.java.net/~mhaupt/8161211/webrev.01/; 
please review.

Thanks,

Michael




Benchmark(iterations) unpatchedpatched
CntL.Cr.cr3  N/A  16039.10815821.583
CntL.Cr.cr4  N/A  15621.95915869.730
CntL.Inv.bl3 02.8582.835
CntL.Inv.bl3 15.1255.179
CntL.Inv.bl3 10   11.887   12.005
CntL.Inv.bl3 100  67.441   67.279
CntL.Inv.bl4 02.8552.858
CntL.Inv.bl4 15.1205.210
CntL.Inv.bl4 10   11.875   12.012
CntL.Inv.bl4 100  67.607   67.296
CntL.Inv.blMH3   09.7349.722
CntL.Inv.blMH3   115.689   15.865
CntL.Inv.blMH3   10   68.912   69.098
CntL.Inv.blMH3   100  605.666  605.526
CntL.Inv.blMH4   014.561   13.274
CntL.Inv.blMH4   119.543   19.709
CntL.Inv.blMH4   10   71.977   72.446
CntL.Inv.blMH4   100  596.842  598.271
CntL.Inv.cntL3   049.339   6.311
CntL.Inv.cntL3   195.444   7.333
CntL.Inv.cntL3   10   508.746  20.930
CntL.Inv.cntL3   100  4701.808 147.383
CntL.Inv.cntL4   049.443   5.780
CntL.Inv.cntL4   198.721   7.465
CntL.Inv.cntL4   10   503.825  20.932
CntL.Inv.cntL4   100  4681.803 147.278
DoWhL.Cr.cr  N/A  7628.312 7803.187
DoWhL.Inv.bl 13.8683.869
DoWhL.Inv.bl 10   16.480   16.528
DoWhL.Inv.bl 100  144.260  144.290
DoWhL.Inv.blMH   114.434   14.430
DoWhL.Inv.blMH   10   92.542   92.733
DoWhL.Inv.blMH   100  877.480  876.735
DoWhL.Inv.doWhL  126.791   7.134
DoWhL.Inv.doWhL  10   158.985  17.004
DoWhL.Inv.doWhL  100  1391.746 133.253
ItrL.Cr.cr   N/A  13547.49913248.913
ItrL.Inv.bl  02.9732.983
ItrL.Inv.bl  16.7716.705
ItrL.Inv.bl  10   14.955   14.952
ItrL.Inv.bl  100  81.842   82.152
ItrL.Inv.blMH014.893   15.014
ItrL.Inv.blMH120.998   21.459
ItrL.Inv.blMH10   73.677   73.888
ItrL.Inv.blMH100  613.913  615.208
ItrL.Inv.itrL033.583   10.842
ItrL.Inv.itrL182.239   13.573
ItrL.Inv.itrL10   448.356  38.773
ItrL.Inv.itrL100  4189.034 279.918
L.Cr.cr  N/A  15505.97015640.994
L.Inv0.bl13.1793.186
L.Inv0.bl10   5.9525.912
L.Inv0.bl100  50.942   50.964
L.Inv0.lo146.454   5.290
L.Inv0.lo10   514.230  8.492
L.Inv0.lo100  5166.251 52.187
L.Inv1.lo134.321   5.291
L.Inv1.lo10   430.839  8.474
L.Inv1.lo100  4095.302 52.173
TF.blEx  N/A  3.0052.986
TF.blMHExN/A  166.316  165.856
TF.blMHNor   N/A  9.3379.290
TF.blNor N/A  2.6962.682
TF.crN/A  406.255  415.090
TF.invTFEx   N/A  154.121  154.826
TF.invTFNor  N/A  5.3505.328
WhL.Cr.crN/A  12214.38312112.535
WhL.Inv.bl   03.8863.931
WhL.Inv.bl   15.3795.411
WhL.Inv.bl   10   16.000   16.203
WhL.Inv.bl   100  142.066  142.127
WhL.Inv.blMH 011.028   10.915
WhL.Inv.blMH 121.269   21.419
WhL.Inv.blMH 10   97.493   98.373
WhL.Inv.blMH 100  887.579  892.955
WhL.Inv.whL  024.829   7.082
WhL.Inv.whL  146.039

Re: RFR(L): 8161211: better inlining support for loop bytecode intrinsics

2016-09-23 Thread Michael Haupt 
Hi John,

thank you for your review. Comments on your suggestions are inlined.

> Am 22.09.2016 um 20:04 schrieb John Rose :
> On Sep 22, 2016, at 12:23 AM, Michael Haupt  > wrote:
>> The new webrev is at http://cr.openjdk.java.net/~mhaupt/8161211/webrev.01/ 
>> ; please review.
> 
> 
> Suggestion:  Filter all loop clause functions with ".asFixedArity" when you 
> wrap up the constant array.
> This will do two things:  1. double-check for nulls (which @Stable doesn't 
> like) and 2. allow you to
> omit all asFixedArity calls from the driver function (MHI.loop).  The 
> asFixedArity normalization could
> move into MethodHandles.java, in fact, since that's part of the advertised 
> semantics (hmm, right?).

The double-checking for nulls is not strictly required, as none of the handles 
in any of the loop clauses will be null at the point the call to 
MethodHandleImpl.makeLoop() is made. I still like the idea of moving these 
calls out of the driver and will apply it. I'm applying the same transformation 
to the tryFinally combinator.

> Also (this is a nit) consider commoning (binding a temp for) the three 
> expressions 'init[i]' in the driver.
> I noticed that while peeking at the asFixedArity calls.  The JIT will DTRT 
> here, but we might as well
> make its job a bit easier.  JITs enjoy little favors like that; they are less 
> likely to drop optimizations.

Agreed.

With the performance measurements showing no difference, I'm going to push with 
these modifications.

Best,

Michael

-- 

 
Dr. Michael Haupt | Principal Member of Technical Staff
Phone: +49 331 200 7277 | Fax: +49 331 200 7561
Oracle Java Platform Group | LangTools Team | Nashorn
Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany

ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstraße 25, D-80992 
München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 
3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher
  Oracle is committed to developing 
practices and products that help protect the environment

Re: RFR(L): 8161211: better inlining support for loop bytecode intrinsics

2016-09-22 Thread John Rose 
On Sep 22, 2016, at 12:23 AM, Michael Haupt  wrote:

> thanks for your review, and thanks Vladimir! I've had another go at the 
> implementation to use a dedicated loop clause holder class with a stable 
> array; performance is roughly on par with that of the BMHs-as-arrays approach 
> (see below).
> 
> The new webrev is at http://cr.openjdk.java.net/~mhaupt/8161211/webrev.01/ 
> ; please review.

Yes, that's cleaner.

Suggestion:  Filter all loop clause functions with ".asFixedArity" when you 
wrap up the constant array.
This will do two things:  1. double-check for nulls (which @Stable doesn't 
like) and 2. allow you to
omit all asFixedArity calls from the driver function (MHI.loop).  The 
asFixedArity normalization could
move into MethodHandles.java, in fact, since that's part of the advertised 
semantics (hmm, right?).

Also (this is a nit) consider commoning (binding a temp for) the three 
expressions 'init[i]' in the driver.
I noticed that while peeking at the asFixedArity calls.  The JIT will DTRT 
here, but we might as well
make its job a bit easier.  JITs enjoy little favors like that; they are less 
likely to drop optimizations.

Reviewed!

— John

Re: RFR(L): 8161211: better inlining support for loop bytecode intrinsics

2016-09-22 Thread Michael Haupt 
Hi John,

thanks for your review, and thanks Vladimir! I've had another go at the 
implementation to use a dedicated loop clause holder class with a stable array; 
performance is roughly on par with that of the BMHs-as-arrays approach (see 
below).

The new webrev is at http://cr.openjdk.java.net/~mhaupt/8161211/webrev.01/; 
please review.

Thanks,

Michael




Benchmark(iterations) unpatchedpatched
CntL.Cr.cr3  N/A  16039.10815821.583
CntL.Cr.cr4  N/A  15621.95915869.730
CntL.Inv.bl3 02.8582.835
CntL.Inv.bl3 15.1255.179
CntL.Inv.bl3 10   11.887   12.005
CntL.Inv.bl3 100  67.441   67.279
CntL.Inv.bl4 02.8552.858
CntL.Inv.bl4 15.1205.210
CntL.Inv.bl4 10   11.875   12.012
CntL.Inv.bl4 100  67.607   67.296
CntL.Inv.blMH3   09.7349.722
CntL.Inv.blMH3   115.689   15.865
CntL.Inv.blMH3   10   68.912   69.098
CntL.Inv.blMH3   100  605.666  605.526
CntL.Inv.blMH4   014.561   13.274
CntL.Inv.blMH4   119.543   19.709
CntL.Inv.blMH4   10   71.977   72.446
CntL.Inv.blMH4   100  596.842  598.271
CntL.Inv.cntL3   049.339   6.311
CntL.Inv.cntL3   195.444   7.333
CntL.Inv.cntL3   10   508.746  20.930
CntL.Inv.cntL3   100  4701.808 147.383
CntL.Inv.cntL4   049.443   5.780
CntL.Inv.cntL4   198.721   7.465
CntL.Inv.cntL4   10   503.825  20.932
CntL.Inv.cntL4   100  4681.803 147.278
DoWhL.Cr.cr  N/A  7628.312 7803.187
DoWhL.Inv.bl 13.8683.869
DoWhL.Inv.bl 10   16.480   16.528
DoWhL.Inv.bl 100  144.260  144.290
DoWhL.Inv.blMH   114.434   14.430
DoWhL.Inv.blMH   10   92.542   92.733
DoWhL.Inv.blMH   100  877.480  876.735
DoWhL.Inv.doWhL  126.791   7.134
DoWhL.Inv.doWhL  10   158.985  17.004
DoWhL.Inv.doWhL  100  1391.746 133.253
ItrL.Cr.cr   N/A  13547.49913248.913
ItrL.Inv.bl  02.9732.983
ItrL.Inv.bl  16.7716.705
ItrL.Inv.bl  10   14.955   14.952
ItrL.Inv.bl  100  81.842   82.152
ItrL.Inv.blMH014.893   15.014
ItrL.Inv.blMH120.998   21.459
ItrL.Inv.blMH10   73.677   73.888
ItrL.Inv.blMH100  613.913  615.208
ItrL.Inv.itrL033.583   10.842
ItrL.Inv.itrL182.239   13.573
ItrL.Inv.itrL10   448.356  38.773
ItrL.Inv.itrL100  4189.034 279.918
L.Cr.cr  N/A  15505.97015640.994
L.Inv0.bl13.1793.186
L.Inv0.bl10   5.9525.912
L.Inv0.bl100  50.942   50.964
L.Inv0.lo146.454   5.290
L.Inv0.lo10   514.230  8.492
L.Inv0.lo100  5166.251 52.187
L.Inv1.lo134.321   5.291
L.Inv1.lo10   430.839  8.474
L.Inv1.lo100  4095.302 52.173
TF.blEx  N/A  3.0052.986
TF.blMHExN/A  166.316  165.856
TF.blMHNor   N/A  9.3379.290
TF.blNor N/A  2.6962.682
TF.crN/A  406.255  415.090
TF.invTFEx   N/A  154.121  154.826
TF.invTFNor  N/A  5.3505.328
WhL.Cr.crN/A  12214.38312112.535
WhL.Inv.bl   03.8863.931
WhL.Inv.bl   15.3795.411
WhL.Inv.bl   10   16.000   16.203
WhL.Inv.bl   100  142.066  142.127
WhL.Inv.blMH 011.028   10.915
WhL.Inv.blMH 121.269   21.419
WhL.Inv.blMH 10   97.493   98.373
WhL.Inv.blMH 100  887.579  892.955
WhL.Inv.whL  024.829   7.082
WhL.Inv.whL  146.039   8.598
WhL.Inv.whL  10   240.963  21.108
WhL.Inv.whL  100  2092.671

Re: RFR(L): 8161211: better inlining support for loop bytecode intrinsics

2016-09-20 Thread John Rose 
There should also be an assert in the new LF constructor, which ensures that 
the two
arguments are congruent.  Better yet, just supply one argument (the 
speciesData),
and derive the MT.  These new LFs are pretty confusing, and it's best to nail 
down
unused degrees of freedom.

— John

P.S.  I would have expected this problem to be solved by having the MHI.toArray 
function
return a box object with a single @Stable array field.  Did that approach fail?

I.e., this wrapper emulates a frozen array (until that happy day when we have 
real
frozen arrays):

class ArrayConstant {
  private final @Stable T[] values;
  public ArrayConstant(T[] values) {
for (T v : values)  Objects.requireNonNull(v);
this.values = values.clone();
  }
  public T get(int i) { return values[i]; }
  //public int length() { return values.length; }
}

The JIT should be able to constant fold through ac.get(i) whenever ac and i are 
constants.

On Sep 20, 2016, at 8:17 AM, Vladimir Ivanov  
wrote:
> 
> Looks good.
> 
> src/java.base/share/classes/java/lang/invoke/LambdaFormEditor.java:
> +LambdaForm bmhArrayForm(MethodType type, BoundMethodHandle.SpeciesData 
> speciesData) {
> +int size = type.parameterCount();
> +Transform key = Transform.of(Transform.BMH_AS_ARRAY, size);
> +LambdaForm form = getInCache(key);
> +if (form != null) {
> +return form;
> +}
> 
> Please, add an assert to ensure the cached LF has the same constraint as 
> requested (speciesData).
> 
> Best regards,
> Vladimir Ivanov
> 
> On 9/20/16 3:53 PM, Michael Haupt wrote:
>> Dear all,
>> 
>> please review this change.
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8161211
>> Webrev: http://cr.openjdk.java.net/~mhaupt/8161211/webrev.00/
>> 
>> The method handle loop combinators introduced with JEP 274 were originally 
>> not intrinsified, leading to poor performance as compared to a pure-Java 
>> baseline, but also to handwired method handle combinations. The intrinsics 
>> introduced with 8143211 [1] improved on the situation somewhat, but still 
>> did not provide good inlining opportunities for the JIT compiler. This 
>> change introduces a usage of BoundMethodHandles as arrays to carry the 
>> various handles involved in loop execution.
>> 
>> Extra credits to Vladimir Ivanov, who suggested the BMH-as-arrays approach 
>> in the first place, and Claes Redestad, who suggested to use LambdaForm 
>> editing to neatly enable caching. Thanks!
>> 
>> Performance improves considerably. The table below reports scores in ns/op. 
>> The "unpatched" column contains results from before applying the patch for 
>> 8161211; the "patched" column, from thereafter.
>> 
>> The create benchmarks measure the cost of loop handle creation. The baseline 
>> and baselineMH benchmarks measure the cost of running a pure Java and 
>> handwired method handle construct.
>> 
>> Relevant comparisons include loop combinator results versus baselines, and 
>> versus unpatched loop combinator results. For the latter, there are 
>> significant improvements, except for the creation benchmarks (creation has a 
>> more complex workflow now). For the former, it can be seen that the 
>> BMH-array intrinsics generally perform better than handwired handle 
>> constructs, and have moved much closer to.
>> 
>> Thanks,
>> 
>> Michael
>> 
>> 
>> 
>> [1] https://bugs.openjdk.java.net/browse/JDK-8143211
>> 
>> 
>> 
>> Benchmark   (iterations) 
>> unpatchedpatched
>> MethodHandlesCountedLoop.Create.create3 N/A  
>> 16039.10818400.405
>> MethodHandlesCountedLoop.Create.create4 N/A  
>> 15621.95917924.696
>> MethodHandlesCountedLoop.Invoke.baseline3   02.858   
>>  2.839
>> MethodHandlesCountedLoop.Invoke.baseline3   15.125   
>>  5.164
>> MethodHandlesCountedLoop.Invoke.baseline3   10   11.887  
>>  11.924
>> MethodHandlesCountedLoop.Invoke.baseline3   100  67.441  
>>  67.281
>> MethodHandlesCountedLoop.Invoke.baseline4   02.855   
>>  2.838
>> MethodHandlesCountedLoop.Invoke.baseline4   15.120   
>>  5.179
>> MethodHandlesCountedLoop.Invoke.baseline4   10   11.875  
>>  11.906
>> MethodHandlesCountedLoop.Invoke.baseline4   100  67.607  
>>  67.374
>> MethodHandlesCountedLoop.Invoke.baselineMH3 09.734   
>>  9.606
>> MethodHandlesCountedLoop.Invoke.baselineMH3 115.689  
>>  15.674
>> MethodHandlesCountedLoop.Invoke.baselineMH3 10   68.912  
>>  69.303
>> MethodHandlesCountedLoop.Invoke.baselineMH3 100  605.666 
>>  606.432
>>

Re: RFR(L): 8161211: better inlining support for loop bytecode intrinsics

2016-09-20 Thread Vladimir Ivanov 

Looks good.

src/java.base/share/classes/java/lang/invoke/LambdaFormEditor.java:
+LambdaForm bmhArrayForm(MethodType type, 
BoundMethodHandle.SpeciesData speciesData) {

+int size = type.parameterCount();
+Transform key = Transform.of(Transform.BMH_AS_ARRAY, size);
+LambdaForm form = getInCache(key);
+if (form != null) {
+return form;
+}

Please, add an assert to ensure the cached LF has the same constraint as 
requested (speciesData).


Best regards,
Vladimir Ivanov

On 9/20/16 3:53 PM, Michael Haupt wrote:

Dear all,

please review this change.
Bug: https://bugs.openjdk.java.net/browse/JDK-8161211
Webrev: http://cr.openjdk.java.net/~mhaupt/8161211/webrev.00/

The method handle loop combinators introduced with JEP 274 were originally not 
intrinsified, leading to poor performance as compared to a pure-Java baseline, 
but also to handwired method handle combinations. The intrinsics introduced 
with 8143211 [1] improved on the situation somewhat, but still did not provide 
good inlining opportunities for the JIT compiler. This change introduces a 
usage of BoundMethodHandles as arrays to carry the various handles involved in 
loop execution.

Extra credits to Vladimir Ivanov, who suggested the BMH-as-arrays approach in 
the first place, and Claes Redestad, who suggested to use LambdaForm editing to 
neatly enable caching. Thanks!

Performance improves considerably. The table below reports scores in ns/op. The 
"unpatched" column contains results from before applying the patch for 8161211; the 
"patched" column, from thereafter.

The create benchmarks measure the cost of loop handle creation. The baseline 
and baselineMH benchmarks measure the cost of running a pure Java and handwired 
method handle construct.

Relevant comparisons include loop combinator results versus baselines, and 
versus unpatched loop combinator results. For the latter, there are significant 
improvements, except for the creation benchmarks (creation has a more complex 
workflow now). For the former, it can be seen that the BMH-array intrinsics 
generally perform better than handwired handle constructs, and have moved much 
closer to.

Thanks,

Michael



[1] https://bugs.openjdk.java.net/browse/JDK-8143211



Benchmark   (iterations) unpatched  
  patched
MethodHandlesCountedLoop.Create.create3 N/A  16039.108  
  18400.405
MethodHandlesCountedLoop.Create.create4 N/A  15621.959  
  17924.696
MethodHandlesCountedLoop.Invoke.baseline3   02.858  
  2.839
MethodHandlesCountedLoop.Invoke.baseline3   15.125  
  5.164
MethodHandlesCountedLoop.Invoke.baseline3   10   11.887 
  11.924
MethodHandlesCountedLoop.Invoke.baseline3   100  67.441 
  67.281
MethodHandlesCountedLoop.Invoke.baseline4   02.855  
  2.838
MethodHandlesCountedLoop.Invoke.baseline4   15.120  
  5.179
MethodHandlesCountedLoop.Invoke.baseline4   10   11.875 
  11.906
MethodHandlesCountedLoop.Invoke.baseline4   100  67.607 
  67.374
MethodHandlesCountedLoop.Invoke.baselineMH3 09.734  
  9.606
MethodHandlesCountedLoop.Invoke.baselineMH3 115.689 
  15.674
MethodHandlesCountedLoop.Invoke.baselineMH3 10   68.912 
  69.303
MethodHandlesCountedLoop.Invoke.baselineMH3 100  605.666
  606.432
MethodHandlesCountedLoop.Invoke.baselineMH4 014.561 
  13.234
MethodHandlesCountedLoop.Invoke.baselineMH4 119.543 
  19.773
MethodHandlesCountedLoop.Invoke.baselineMH4 10   71.977 
  72.466
MethodHandlesCountedLoop.Invoke.baselineMH4 100  596.842
  602.469
MethodHandlesCountedLoop.Invoke.countedLoop3049.339 
  5.810
MethodHandlesCountedLoop.Invoke.countedLoop3195.444 
  7.441
MethodHandlesCountedLoop.Invoke.countedLoop310   508.746
  21.002
MethodHandlesCountedLoop.Invoke.countedLoop3100  4701.808   
  145.996
MethodHandlesCountedLoop.Invoke.countedLoop4049.443 
  5.798
MethodHandlesCountedLoop.Invoke.countedLoop4198.721 
  7.438
MethodHandlesCountedLoop.Invoke.countedLoop410   503.825
  21.049
MethodHandlesCountedLoop.Invoke.countedLoop4100  4681.803   
  147.020
MethodHandlesDoWhileLoop.Create.create  N/A  7628.312   
  9100.332
MethodHandlesDoWhileLoop.Invoke.baseline13.868

RFR(L): 8161211: better inlining support for loop bytecode intrinsics

2016-09-20 Thread Michael Haupt 
Dear all,

please review this change.
Bug: https://bugs.openjdk.java.net/browse/JDK-8161211
Webrev: http://cr.openjdk.java.net/~mhaupt/8161211/webrev.00/

The method handle loop combinators introduced with JEP 274 were originally not 
intrinsified, leading to poor performance as compared to a pure-Java baseline, 
but also to handwired method handle combinations. The intrinsics introduced 
with 8143211 [1] improved on the situation somewhat, but still did not provide 
good inlining opportunities for the JIT compiler. This change introduces a 
usage of BoundMethodHandles as arrays to carry the various handles involved in 
loop execution.

Extra credits to Vladimir Ivanov, who suggested the BMH-as-arrays approach in 
the first place, and Claes Redestad, who suggested to use LambdaForm editing to 
neatly enable caching. Thanks!

Performance improves considerably. The table below reports scores in ns/op. The 
"unpatched" column contains results from before applying the patch for 8161211; 
the "patched" column, from thereafter.

The create benchmarks measure the cost of loop handle creation. The baseline 
and baselineMH benchmarks measure the cost of running a pure Java and handwired 
method handle construct.

Relevant comparisons include loop combinator results versus baselines, and 
versus unpatched loop combinator results. For the latter, there are significant 
improvements, except for the creation benchmarks (creation has a more complex 
workflow now). For the former, it can be seen that the BMH-array intrinsics 
generally perform better than handwired handle constructs, and have moved much 
closer to.

Thanks,

Michael



[1] https://bugs.openjdk.java.net/browse/JDK-8143211



Benchmark   (iterations) unpatched  
  patched
MethodHandlesCountedLoop.Create.create3 N/A  16039.108  
  18400.405
MethodHandlesCountedLoop.Create.create4 N/A  15621.959  
  17924.696
MethodHandlesCountedLoop.Invoke.baseline3   02.858  
  2.839
MethodHandlesCountedLoop.Invoke.baseline3   15.125  
  5.164
MethodHandlesCountedLoop.Invoke.baseline3   10   11.887 
  11.924
MethodHandlesCountedLoop.Invoke.baseline3   100  67.441 
  67.281
MethodHandlesCountedLoop.Invoke.baseline4   02.855  
  2.838
MethodHandlesCountedLoop.Invoke.baseline4   15.120  
  5.179
MethodHandlesCountedLoop.Invoke.baseline4   10   11.875 
  11.906
MethodHandlesCountedLoop.Invoke.baseline4   100  67.607 
  67.374
MethodHandlesCountedLoop.Invoke.baselineMH3 09.734  
  9.606
MethodHandlesCountedLoop.Invoke.baselineMH3 115.689 
  15.674
MethodHandlesCountedLoop.Invoke.baselineMH3 10   68.912 
  69.303
MethodHandlesCountedLoop.Invoke.baselineMH3 100  605.666
  606.432
MethodHandlesCountedLoop.Invoke.baselineMH4 014.561 
  13.234
MethodHandlesCountedLoop.Invoke.baselineMH4 119.543 
  19.773
MethodHandlesCountedLoop.Invoke.baselineMH4 10   71.977 
  72.466
MethodHandlesCountedLoop.Invoke.baselineMH4 100  596.842
  602.469
MethodHandlesCountedLoop.Invoke.countedLoop3049.339 
  5.810
MethodHandlesCountedLoop.Invoke.countedLoop3195.444 
  7.441
MethodHandlesCountedLoop.Invoke.countedLoop310   508.746
  21.002
MethodHandlesCountedLoop.Invoke.countedLoop3100  4701.808   
  145.996
MethodHandlesCountedLoop.Invoke.countedLoop4049.443 
  5.798
MethodHandlesCountedLoop.Invoke.countedLoop4198.721 
  7.438
MethodHandlesCountedLoop.Invoke.countedLoop410   503.825
  21.049
MethodHandlesCountedLoop.Invoke.countedLoop4100  4681.803   
  147.020
MethodHandlesDoWhileLoop.Create.create  N/A  7628.312   
  9100.332
MethodHandlesDoWhileLoop.Invoke.baseline13.868  
  3.909
MethodHandlesDoWhileLoop.Invoke.baseline10   16.480 
  16.461
MethodHandlesDoWhileLoop.Invoke.baseline100  144.260
  144.232
MethodHandlesDoWhileLoop.Invoke.baselineMH  114.434 
  14.494
MethodHandlesDoWhileLoop.Invoke.baselineMH  10   92.542 
  93.454
MethodHandlesDoWhileLoop.Invoke.baselineMH  100  877.480
  880.496
MethodHandlesDoWhileLoop.Invoke.doWhileLoop 126.791 
  7.153