RFR: 8168640: (fc) Avoiding AtomicBoolean in FileInput/-OutputStream improves startup
claes.redestad at oracle.com
Wed Oct 26 12:11:52 UTC 2016
does this commentary suffice?
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:
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
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?
> 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