RFR(L): 8143211: provide bytecode intrinsics for loop and try/finally executors

[Michael Haupt]

... small correction: the FC extension for this RFE has been *requested*.

Best,

Michael

> Am 29.06.2016 um 11:49 schrieb Michael Haupt <michael.haupt at oracle.com>:
> 
> Hi again,
> 
> as there have been no comments on the .01 version, I have updated it in place with a new revision. This was necessary because there was a bug in InvokerBytecodeGenerator that led to the benchmarks crashing. The current revision, which is still available from http://cr.openjdk.java.net/~mhaupt/8143211/webrev.01 <http://cr.openjdk.java.net/~mhaupt/8143211/webrev.01>, fixes this.
> 
> The bug consisted in a lack of CHECKCAST generation that would only occur if the verifier was turned on (which it is not by default for Unsafe.defineAnonymousClass), or if, voilà, C2 kicked in for compilation.
> 
> The benchmark results are attached. Explanation:
> * "unpatched" scores are without; "patched", with bytecode intrinsics (scores are given in ns/op, i.e., smaller is better)
> * "bl" are baseline measurements; simple "bl" is plain Java, "blMH" is invoking the constituent handles
> * "Cr" are handle creation measurements
> * "Inv" are handle invocation measurements
> * "Itr" are for iteratedLoop
> * "Cnt" are for countedLoop (with 3 and 4 handle arguments)
> * "Wh" and "DoWh" are for whileLoop and doWhileLoop
> * "L" are for plain loop
> * "TF" are for tryFinally
> 
> Observations:
> * considerable performance improvements for all creation and handle constructs
> * exception: iteratedLoop is slowed down
> 
> Proposal:
> * accept the change as is (RFE with FC extension)
> * deal with necessary further improvements as performance bugs
> 
> Reviews please! :-)
> 
> Thanks,
> 
> Michael
> 
>> Am 23.06.2016 um 16:43 schrieb Michael Haupt <michael.haupt at oracle.com>:
>> 
>> Dear all,
>> 
>> thank you, Claes, Vladimir, and Paul, for your reviews. See http://cr.openjdk.java.net/~mhaupt/8143211/webrev.01/ for the next round.
>> 
>> The difference to the previous version is, roughly, as follows. Rev 01 ...
>> 
>> ... honours the possibility of there being more than one loop in a LambdaForm; InvokerBytecodeGenerator now has extra state summarising characteristics of the loops, while the concrete types are extracted from the LambdaForm during the actual compilation step.
>> 
>> ... does away with the extra intrinsic data for loops. Instead, the LambdaFormEditor is used to create (and cache) an appropriate LambdaForm as a specialisation of a template. This was a very good suggestion from Vladimir (thanks!), and it makes the code much more tidy in my opinion.
>> 
>> ... contains various small fixes that were suggested.
>> 
>> Things I think should be expressed in other issues rather than being piggybacked on this one:
>> * Removing IntrinsicMethodHandle.
>> * Taking care of Transform cache cleanup.
>> 
>> Best,
>> 
>> Michael
>> 
>>> Am 16.06.2016 um 15:17 schrieb Michael Haupt <michael.haupt at oracle.com>:
>>> 
>>> Dear all,
>>> 
>>> please review this change.
>>> RFE: https://bugs.openjdk.java.net/browse/JDK-8143211
>>> Webrev: http://cr.openjdk.java.net/~mhaupt/8143211/webrev.00/
>>> 
>>> The change puts the tryFinally and loop method handle combinator implementations, which were introduced as part of the JEP 274 effort, on a LambdaForm basis, which executes in bytecode generating (default) and LambdaForm interpretation (-Djava.lang.invoke.MethodHandle.COMPILE_THRESHOLD=-1) modes. It also changes the output formatting of LambdaForms, introducing a (hopefully) more readable format.
>>> 
>>> Thanks,
>>> 
>>> Michael

-- 

 <http://www.oracle.com/>
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
 <http://www.oracle.com/commitment>	Oracle is committed to developing practices and products that help protect the environment