RFR: 8237508: Simplify JarFile.isInitializing

Lance @ Oracle lance.andersen at oracle.com
Mon Jan 20 12:34:44 UTC 2020


Looks good Claes

Best,
Lance



Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
Lance.Andersen at oracle.com
Sent from my iPad

> On Jan 20, 2020, at 7:12 AM, Claes Redestad <claes.redestad at oracle.com> wrote:
> 
> Makes sense to keep even trivial logic out of the access bridge. Let's
> also clean up the placement of the static variable and the pre-existing
> use of the unconventional "final static" combo:
> 
> http://cr.openjdk.java.net/~redestad/8237508/open.01/
> 
> /Claes
> 
>> On 2020-01-20 12:35, Daniel Fuchs wrote:
>> Hi Claes,
>> Looks OK to me but I'd have a slight preference to a solution
>> that confines the hack to the JarFile class.
>> Would making the isIntializing field private and introducing
>> a static boolean isInitializing() method in JarFile bring the
>> same benefits WRT startup?
>> best regards,
>> -- daniel
>>> On 20/01/2020 11:16, Claes Redestad wrote:
>>> Hi,
>>> 
>>> JDK-8234466[1] introduced isInitializing to JarFile, which cause a small
>>> startup regression in various tests due increasing the number of classes
>>> loaded and earlier lambda bootstrapping. The regression can be resolved
>>> by not explicitly initializing the thread local variable to a non-null
>>> value.
>>> 
>>> Webrev: http://cr.openjdk.java.net/~redestad/8237508/open.00/
>>> Bug:    https://bugs.openjdk.java.net/browse/JDK-8237508
>>> 
>>> Testing: tier1-3
>>> 
>>> Thanks!
>>> 
>>> /Claes
>>> 
>>> [1] https://bugs.openjdk.java.net/browse/JDK-8234466


More information about the core-libs-dev mailing list