RFR: JDK-8005263: Logging APIs takes Supplier<String> for message
Remi Forax
forax at univ-mlv.fr
Mon Dec 24 16:15:34 UTC 2012
On 12/23/2012 07:45 PM, Brian Goetz wrote:
>>> Henry - just a quick comment on the class description. I think it would
>>> be better not to include the sentence "Since 1.8 ..." as it that will
>>> quickly become a historical note. It would be much better (in my view)
>>> to just highlight the methods with something like "Several of the
>>> methods take a Supplier function ..." and make the potential
>>> performance
>>> benefit of using these methods clear.
>>
>> You should also add a note saying that the supplier can be specified as
>> a lambda and in that case, the lambda *must* not capture value of local
>> variable, otherwise a supplier object will be created each time you log
>> something.
>
> No, don't do this.
>
> First of all, just because the performance characteristics of
> capturing lambdas are one way today on HotSpot compared to
> non-capturing, does not mean we should burn this into spec.
It's not related to Hotspot. javac translation uses invokedynamic (by
the specification) and the metafactory provided by the JDK uses for
non-capturing lambda a ConstantCallSite which is guaranteed by the JSR
292 to be considered as a constant. Hotspot just implements the JSR 292.
So this is true for all metafactory implementation that uses a
ConstantCallSite as the one provided by the JDK.
> Also, there's no way to enforce it.
not a lambda problem, but a JSR 292 problem, and it should be enforced
by tests, it's JEP 165.
> More importantly, a capturing lambda might still be way better than a
> String, as in this example:
>
> log(DEBUG, () -> "Children of " + name + ": " + getChildrenOf(name));
>
> Collecting getChildren (and turning it into a String) commonly
> involves something thousands of times as expensive as an object creation.
Yes, true it depends on the cost of getChildrenOf,
my point was to add a sentence saying that using a lambda that capture
local variables may impact performance.
Rémi
More information about the core-libs-dev
mailing list