Nick Hill 2791f0fefa Avoid use of global AtomicLong for ScheduledFutureTask ids (#9599) ... Motivation Currently a static AtomicLong is used to allocate a unique id whenever a task is scheduled to any event loop. This could be a source of contention if delayed tasks are scheduled at a high frequency and can be easily avoided by having a non-volatile id counter per queue. Modifications - Replace static AtomicLong ScheduledFutureTask#nextTaskId with a long field in AbstractScheduledExecutorService - Set ScheduledFutureTask#id based on this when adding the task to the queue (in event loop) instead of at construction time - Add simple benchmark Result Less contention / cache-miss possibility when scheduling future tasks Before: Benchmark (num) Mode Cnt Score Error Units scheduleLots 100000 thrpt 20 346.008 ± 21.931 ops/s Benchmark (num) Mode Cnt Score Error Units scheduleLots 100000 thrpt 20 654.824 ± 22.064 ops/s		2019-09-25 07:34:25 +02:00
..
java/io/netty	Avoid use of global AtomicLong for ScheduledFutureTask ids (#9599)	2019-09-25 07:34:25 +02:00
resources	Add benchmarks for SSLEngine implementations	2017-02-24 08:02:10 +01:00