RFR: JDK-8242451 : ensure semantics of non-capturing lambdas are preserved independent of execution mode
mandy.chung at oracle.com
Tue Aug 25 17:23:56 UTC 2020
On 8/25/20 3:16 AM, Gilles Duboscq wrote:
>> Since this patch caches a singleton instance in the generated class,
>> it could apply to the eager initialization case as well and replace
>> the current use of core reflection to new an instance except that the
>> target of the returning callsite would always be the singleton object
>> (the result of invoking the static getter method handle). I wonder
>> if there is any performance difference. This is just a thought that
>> we can file a JBS issue to follow up.
>> Can you add a test case for this fix?
> I could write a test that generates different output depending on
> whether a singleton or a fresh instance is returned.
> Then i can compare the output when running with
> `jdk.internal.lambda.disableEagerInitialization` set to `true` and
> What is the recommended way of comparing 2 runs like that in jtreg?
It can simply verify if the static field is only present when
disableEagerInitialization is true; otherwise such static field should
> I have updated the webrev:
Looks okay to me.
Nit: `Class::descriptorString` can be used instead of
418 String lambdaTypeDescriptor =
> From your other mail:
>> Should this patch be a workaround to existing releases rather than
>> the main line? As Brian mentions, lambda proxy class may become
>> inline class in valhalla repo (Roger has a patch already). The
>> earlier fixing those programs the better.
> Indeed if we know this is landing in this cycle in the main repo
> there's no point with my fix. Could you point me at the issue number
> or mail thread where this patch is being discussed?
As Brian replied, integration of valhalla is not imminent. JDK-8205668
tracks the work to make lambda proxies as inline classes for the
valhalla repo (*not* main line).
More information about the core-libs-dev