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
