On the allocation overhead of ExecutorCompletionService

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

On the allocation overhead of ExecutorCompletionService

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.

Concurrency-interest mailing list
[hidden email]