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.ha...@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.ha...@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
