After internal discussion, the fix we arrived at is now here:
http://cr.openjdk.java.net/~mhaupt/8143211/webrev.03/
Looks good.
Best regards,
Vladimir Ivanov
Hi Vladimir,
> Am 01.07.2016 um 14:00 schrieb Vladimir Ivanov :
> Stale LF shape in the comment.
Fixed.
> -if (assertStaticType(cls, n))
> -return; // this cast was already performed
> +assertStaticType(cls, n);
>
> This change completely defeats localCl
src/java.base/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java:
+ * Emit bytecode for the loop idiom.
...
+ * loop=Lambda(a0:L,a1:L,a2:L,a3:L,a4:L,a5:L,a6:L,a7:L)=>{
+ * t8:L=MethodHandles.constant(String.class, "");
+ * t9:L=MethodHandle.invokeBasic(a5:L,a7:L);
Hi Vladimir,
thank you once more - your comments led to more improvements. The results are
at http://cr.openjdk.java.net/~mhaupt/8143211/webrev.02/, and some details are
inlined below.
> Am 29.06.2016 um 17:57 schrieb Vladimir Ivanov :
> I'd prefer to see loopStateTypes attached to the intrinsi
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;
Invo
... small correction: the FC extension for this RFE has been *requested*.
Best,
Michael
> Am 29.06.2016 um 11:49 schrieb Michael Haupt :
>
> 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
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.ne
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 LambdaFor
> On 16 Jun 2016, at 15:17, Michael Haupt wrote:
>
> 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/
>
InvokerBytecodeGenerator
—
I agree with Vladimir on the loop state held by I
InvokerBytecodeGenerator/IntrinsicMethodHandle: stringly typed
localStateDesc seems like a wart to me. Since this is all package
private, couldn't IntrinsicMethodHandle contain a @Stable Class[]
localStateTypes, then convert directly from List init to
the class array in MethodHandleImpl::makeLoop
Nice work, Michael!
Some comments follow:
===
src/java.base/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java:
+private final List> loopClauseTypes;
+/** This list contains the actual local state types added by loop
clauses, without {@code void} entries. */
+private fi
Hi Michael,
this looks quite good to me.
Forgettable ramblings:
MethodTypeForm: could it be beneficial to have a cleaner to remove
mappings from loopLambdaForms various LambdaForms are GCd?
InvokerBytecodeGenerator/IntrinsicMethodHandle: stringly typed
localStateDesc seems like a wart to me
... gentle reminder ... :-)
> Am 16.06.2016 um 15:17 schrieb Michael Haupt :
>
> 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 ha
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
La
14 matches
Mail list logo
