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