RFR: 8168640: (fc) Avoiding AtomicBoolean in FileInput/-OutputStream improves startup

Claes Redestad claes.redestad at oracle.com
Wed Oct 26 12:11:52 UTC 2016


Hi,

does this commentary suffice?

http://cr.openjdk.java.net/~redestad/8168640/webrev.02/

To answer Paul's question about the exact startup gain:

20 named classes observable with -Xlog:class+load (11
additional anonymous show up in heap dumps), for example:

   java.lang.invoke.MethodType$ConcurrentWeakInternSet
   java.lang.invoke.MethodType$ConcurrentWeakInternSet$WeakEntry
   java.lang.invoke.MethodTypeForm
   java.lang.invoke.VarHandle$1
   java.lang.invoke.VarHandle$AccessDescriptor
   java.lang.invoke.VarHandle$AccessMode
   java.lang.invoke.VarHandle$AccessType
   java.lang.invoke.VarHandleGuards
   java.lang.invoke.VarHandleInts$FieldInstanceReadOnly
   java.lang.invoke.VarHandleInts$FieldInstanceReadWrite
   java.lang.invoke.VarHandles
   java.lang.invoke.VarHandle$TypesAndInvokers

Not initializing this eagerly drops retained heap on a minimal
Hello World by ~17Kb, and a 3-10ms startup improvement
on similar programs (naturally varies a lot between systems
due to timing of when/if JIT compilations happen during early
execution).

Thanks!

/Claes

On 2016-10-25 15:21, Peter Levart wrote:
>
>
>
> On 10/25/2016 02:57 PM, Claes Redestad wrote:
>>> FileChannelImpl.close() may be idempotent, but why not making sure 
>>> it is called just once?
>>
>> Hmm, it would seem like a pre-existing issue that was not dealt with 
>> neither before nor after JDK-8025619, no?
>>
>> And FileChannel inherits AbstractInterruptibleChannel::close() 
>> (public final), which specifies behavior: "If the channel has already 
>> been closed then this method returns immediately." Thus I don't think 
>> the extra ceremony is warranted, won't you agree?
>>
>> Thanks!
>>
>> /Claes 
>
> Ok, then what about a hint in the form of a brief comment that there 
> is a race that might invoke FileChannelImpl.close() twice, but it is 
> harmless as FileChannelImpl.close() is idempotent? It might be helpful 
> to a future bug-hunter...
>
> Regards, Peter
>



More information about the core-libs-dev mailing list