RFR: JDK-8242451 : ensure semantics of non-capturing lambdas are preserved independent of execution mode

Mandy Chung 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 
> `false`.
> 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 
not exist.

> I have updated the webrev: 
> https://cr.openjdk.java.net/~gdub/8242451/webrev.1/

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 mailing list