RFR: 8023681: Fix raw type warning caused by Sink
Brian Goetz
brian.goetz at oracle.com
Fri Aug 23 15:15:30 PDT 2013
Yes, this has been a beneficial side effect of lambda translation for 2+
years now. The count of captured arguments is known statically to the
metafactory and this (common) path can be special-cased:
return new ConstantCallSite(MethodHandles.constant(samBase,
inst));
The VM responds rewriting the call to the lambda factory as a constant
load (and then further inlining and other optimizations can happen from
there.)
On 8/23/2013 6:03 PM, Ali Ebrahimi wrote:
> nice. So we have currently this optimization?
>
>
> On Sat, Aug 24, 2013 at 2:14 AM, Brian Goetz <brian.goetz at oracle.com
> <mailto:brian.goetz at oracle.com>> wrote:
>
> Because non-capturing lambdas are *already* constants! The commonly
> used trick, that was needed with inner classes to avoid
> instantiating multiple instances of essentially identical objects:
>
> static final Comparator<String> c = new Comparator() { ... }
>
> is effectively implemented automatically (and lazily, instantiated
> only on first use) by the language runtime for non-capturing
> lambdas. So the "extract into a static" trick can be relegated to
> the scrap heap of "optimizations that don't optimize but still crap
> up your code".
>
> And, since the method castingIdentity() returns a constant, it will
> be routinely inlined into a constant load.
>
>
> On 8/23/2013 5:18 PM, Ali Ebrahimi wrote:
>
> Why not to make castingIdentity method a constant?
>
>
> On Fri, Aug 23, 2013 at 11:47 PM, Henry Jen
> <henry.jen at oracle.com <mailto:henry.jen at oracle.com>> wrote:
>
> Hi,
>
> Please kindly review the fix for eliminate some warnings in
> java.util.stream package.
>
> Chained Sink is an internal implementation detail, add the
> type for
> downstream is more precise but verbose.
>
> Included is also a couple other warnings cleanup.
>
> http://cr.openjdk.java.net/~__henryjen/tl/8023681.0/webrev/
> <http://cr.openjdk.java.net/~henryjen/tl/8023681.0/webrev/>
>
> Cheers,
> Henry
>
>
>
More information about the lambda-dev
mailing list