... small correction: the FC extension for this RFE has been *requested*. Best,
Michael > Am 29.06.2016 um 11:49 schrieb Michael Haupt <michael.ha...@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.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
