RFR: 8193064: JarFile::getEntry0 method reference use cause for startup regression

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

RFR: 8193064: JarFile::getEntry0 method reference use cause for startup regression

Claes Redestad
Hi,

desugaring the JarFileEntry::new in JarFile::getEntry0 avoids a hefty
startup regression on our smallest startup tests:

http://cr.openjdk.java.net/~redestad/8193064/open.00/

I think the implementation could be improved further by using static
non-capturing functions rather than Jar-/ZipFileEntry::new (which, since
they reference a non static class constructor, are implicitly capturing)
and filed: https://bugs.openjdk.java.net/browse/JDK-8193066

Thanks!

/Claes
Reply | Threaded
Open this post in threaded view
|

Re: RFR: 8193064: JarFile::getEntry0 method reference use cause for startup regression

Xueming Shen
Hi Claes,

I'm OK with this. It would be help to add a simple comment to remind why
we have to do this
here, before there is better alternative in place for the startup.

Thanks!
Sherman

On 12/5/17, 6:51 AM, Claes Redestad wrote:

> Hi,
>
> desugaring the JarFileEntry::new in JarFile::getEntry0 avoids a hefty
> startup regression on our smallest startup tests:
>
> http://cr.openjdk.java.net/~redestad/8193064/open.00/
>
> I think the implementation could be improved further by using static
> non-capturing functions rather than Jar-/ZipFileEntry::new (which,
> since they reference a non static class constructor, are implicitly
> capturing) and filed: https://bugs.openjdk.java.net/browse/JDK-8193066
>
> Thanks!
>
> /Claes

Reply | Threaded
Open this post in threaded view
|

Re: RFR: 8193064: JarFile::getEntry0 method reference use cause for startup regression

Mandy Chung
In reply to this post by Claes Redestad
+1

nit: s/jarFileEntryFunction/newJarFileEntryFn/

Mandy

On 12/5/17 6:51 AM, Claes Redestad wrote:

> Hi,
>
> desugaring the JarFileEntry::new in JarFile::getEntry0 avoids a hefty
> startup regression on our smallest startup tests:
>
> http://cr.openjdk.java.net/~redestad/8193064/open.00/
>
> I think the implementation could be improved further by using static
> non-capturing functions rather than Jar-/ZipFileEntry::new (which,
> since they reference a non static class constructor, are implicitly
> capturing) and filed: https://bugs.openjdk.java.net/browse/JDK-8193066
>
> Thanks!
>
> /Claes

Reply | Threaded
Open this post in threaded view
|

Re: RFR: 8193064: JarFile::getEntry0 method reference use cause for startup regression

Claes Redestad
In reply to this post by Xueming Shen
Hi Sherman,

sure, I'll add a small comment to this effect.

/Claes

On 2017-12-05 17:13, Xueming Shen wrote:

> Hi Claes,
>
> I'm OK with this. It would be help to add a simple comment to remind
> why we have to do this
> here, before there is better alternative in place for the startup.
>
> Thanks!
> Sherman
>
> On 12/5/17, 6:51 AM, Claes Redestad wrote:
>> Hi,
>>
>> desugaring the JarFileEntry::new in JarFile::getEntry0 avoids a hefty
>> startup regression on our smallest startup tests:
>>
>> http://cr.openjdk.java.net/~redestad/8193064/open.00/
>>
>> I think the implementation could be improved further by using static
>> non-capturing functions rather than Jar-/ZipFileEntry::new (which,
>> since they reference a non static class constructor, are implicitly
>> capturing) and filed: https://bugs.openjdk.java.net/browse/JDK-8193066
>>
>> Thanks!
>>
>> /Claes
>

Reply | Threaded
Open this post in threaded view
|

Re: RFR: 8193064: JarFile::getEntry0 method reference use cause for startup regression

Claes Redestad
In reply to this post by Mandy Chung
Thanks Mandy,

On 2017-12-05 17:14, mandy chung wrote:
> +1
>
> nit: s/jarFileEntryFunction/newJarFileEntryFn/

updated in-place along with a comment that this is deliberately not a
method ref for startup reasons, as requested by Sherman.

/Claes