[concurrency-interest] Advice on reuse of ForkJoinTask instances
viktor.klang at gmail.com
Tue Mar 20 19:46:44 EDT 2012
On Wed, Mar 21, 2012 at 12:16 AM, Doug Lea <dl at cs.oswego.edu> wrote:
> On 03/20/12 08:09, √iktor Ҡlang wrote:
>> We're talking about _alot_ of submissions here :-)
> We have toy test examples (like Fib) that execute over
> 400million tasks per second on some machines without big
> GC pauses, so it is not a sure thing that GC is hurting you
> enough to be worth a lot of effort. But...
Yeah, I guess it's one of those scenarios where you won't know how much
difference it makes unless you actually try it ;-)
> To get 0 allocations in my hot path I'd want to be able to resubmit the
>> current FJT,
>> I can probably implement it myself, but I believe that it could be useful
>> others as well.
> As it states in the javadocs, you have to be sure a task is done and
> that no other thread/task is depending on its completion before you
> can reinitialize/refork. In general, you can't automate this rule.
> But ff you are using FJ for async tasks that are never joined (which I
> recall holds in your case), you probably don't need to worry about
> the task completion dependencies. Which means that it might be
> possible to do better than a GC mechanism that would handle
> these dependencies (this is the main thing that GCs do better
> than you can).
Yup, essentially I just want to be able to, within the FJT, to signal that
it should be resubmitted after execution.
> One possibility is to create a ThreadLocal cache of them,
> but you'd still need to check isDone to when selecting them
> from the cache.
Yeah, would like to avoid object pooling, it always gives me the
> Concurrency-interest mailing list
> Concurrency-interest at cs.**oswego.edu <Concurrency-interest at cs.oswego.edu>
Akka Tech Lead
Typesafe <http://www.typesafe.com/> - The software stack for applications
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Concurrency-interest