[concurrency-interest] On the allocation overhead of ExecutorCompletionService

Shevek shevek at anarres.org
Wed Aug 30 21:40:22 EDT 2017

I'm a little bothered by the number of objects which need to be 
allocated by ExecutorCompletionService.submit(). Without being 
overprecise, a Runnable gets:
* FutureTask.<init> -> Executors.callable(r) -> new RunnableAdapter()
* ExecutorCompletionService.newTaskFor() -> new FutureTask()
* ExecutorCompletionService.submit() -> new QueueingFuture()

Could not the first two of these be omitted by having 
ExecutorCompletionService.submit(Runnable, V) construct a new 
QueueingFuture() in the first place, and then have QueueingFuture append 
itself, rather than an embedded task field to the completionQueue?

Aside from omitting the call to aes.newTaskFor(), which I'm sure has 
semantics somewhere, does this actually break anything, or does it just 
reduce the number of allocations per-task?

I've fairly easily written something executor-like which just creates a 
self-enqueueing QueueingFuture directly over a given Runnable, and 
returns it to the user, and it seems fine to me.

Thank you.


More information about the Concurrency-interest mailing list