|

JSR166 Concurrency

Object allocations in different threads & Thread local allocation buffers

View: New views

4 Messages — Rating Filter: Alert me

	Object allocations in different threads & Thread local allocation buffers by Ashwin Jayaprakash-2 :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message Hi, I know this forum is probably not the right place to ask these questions, but since most of the Concurrency experts read this forum I'm going to post my question anyway. We all know that the newer versions of JVMs (Java 5+) have Thread local allocation buffers. What I'm curious to know is what happens to the objects when the following happens: - Thread 1 allocates a bunch of objects - These object references are handed over to Thread 2, let's say via a BlockingQueue - Thread 2 then starts modifying those objects 1) So, when Object mutations cross such Thread boundaries, does the TLAB get fragmented because it cannot be reclaimed completely? 2) Does this affect performance a lot? Doesn't the new Fork-Join or any such thread-pooling logic make heavy use of such allocations? 3) If it does affect performance, is there a better way to do things? Now, this might be a pointless question - you might say "don't use threads then".. but I'm just thinking aloud Thanks! Ashwin (http://www.ashwinjayaprakash.com) _______________________________________________ Concurrency-interest mailing list Concurrency-interest@... http://cs.oswego.edu/mailman/listinfo/concurrency-interest
	Re: Object allocations in different threads & Thread local allocation buffers by AndrewTrick :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message JVMs typically implement precise garbage collection. This allows the GC thread to move objects while mutator threads hold reference (in registers or thread stack). TLABs are small, so in that case a JVM would probably stop the mutator threads, move ALL objects in the TLAB, update each thread's root set (registers/stack values), then restart mutators. TLAB objects are locally allocated... they are often not thread-local objects. -Andy On Thu, Sep 3, 2009 at 11:12 PM, Ashwin Jayaprakash <ashwin.jayaprakash@...> wrote: Hi, I know this forum is probably not the right place to ask these questions, but since most of the Concurrency experts read this forum I'm going to post my question anyway. We all know that the newer versions of JVMs (Java 5+) have Thread local allocation buffers. What I'm curious to know is what happens to the objects when the following happens: - Thread 1 allocates a bunch of objects - These object references are handed over to Thread 2, let's say via a BlockingQueue - Thread 2 then starts modifying those objects 1) So, when Object mutations cross such Thread boundaries, does the TLAB get fragmented because it cannot be reclaimed completely? 2) Does this affect performance a lot? Doesn't the new Fork-Join or any such thread-pooling logic make heavy use of such allocations? 3) If it does affect performance, is there a better way to do things? Now, this might be a pointless question - you might say "don't use threads then".. but I'm just thinking aloud Thanks! Ashwin (http://www.ashwinjayaprakash.com) _______________________________________________ Concurrency-interest mailing list Concurrency-interest@... http://cs.oswego.edu/mailman/listinfo/concurrency-interest _______________________________________________ Concurrency-interest mailing list Concurrency-interest@... http://cs.oswego.edu/mailman/listinfo/concurrency-interest
	Re: Object allocations in different threads & Thread local allocation buffers by Boehm, Hans :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message Andy's last observation here is the crucial one; these objects are typically allocated essentially by allocating a large block and then dividing it. This avoids locking on the allocation path. The resulting objects are usually not in any sense thread-local. I'm not sure how the details are handled in Hotspot. We in fact do something bery similar in our conservative non-moving collector, though the "TLAB" there is not even a contiguous piece of memory. A thread can grab a bunch of objects of a given size (linked together in a free-list) at once with a single lock acquisition, and then parcel them out as needed without further locking. Though this isn't quite as fast as the contiguous case, it still seems to get most of the benefit. Hans From: concurrency-interest-bounces@... [mailto:concurrency-interest-bounces@...] On Behalf Of Andrew Trick Sent: Wednesday, September 09, 2009 10:03 AM To: Ashwin Jayaprakash Cc: concurrency-interest@... Subject: Re: [concurrency-interest] Object allocations in different threads & Thread local allocation buffers JVMs typically implement precise garbage collection. This allows the GC thread to move objects while mutator threads hold reference (in registers or thread stack). TLABs are small, so in that case a JVM would probably stop the mutator threads, move ALL objects in the TLAB, update each thread's root set (registers/stack values), then restart mutators. TLAB objects are locally allocated... they are often not thread-local objects. -Andy On Thu, Sep 3, 2009 at 11:12 PM, Ashwin Jayaprakash <ashwin.jayaprakash@...> wrote: Hi, I know this forum is probably not the right place to ask these questions, but since most of the Concurrency experts read this forum I'm going to post my question anyway. We all know that the newer versions of JVMs (Java 5+) have Thread local allocation buffers. What I'm curious to know is what happens to the objects when the following happens: - Thread 1 allocates a bunch of objects - These object references are handed over to Thread 2, let's say via a BlockingQueue - Thread 2 then starts modifying those objects 1) So, when Object mutations cross such Thread boundaries, does the TLAB get fragmented because it cannot be reclaimed completely? 2) Does this affect performance a lot? Doesn't the new Fork-Join or any such thread-pooling logic make heavy use of such allocations? 3) If it does affect performance, is there a better way to do things? Now, this might be a pointless question - you might say "don't use threads then".. but I'm just thinking aloud Thanks! Ashwin (http://www.ashwinjayaprakash.com) _______________________________________________ Concurrency-interest mailing list Concurrency-interest@... http://cs.oswego.edu/mailman/listinfo/concurrency-interest _______________________________________________ Concurrency-interest mailing list Concurrency-interest@... http://cs.oswego.edu/mailman/listinfo/concurrency-interest
	Re: Object allocations in different threads & Thread local allocation buffers by Ashwin Jayaprakash-2 :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message Thanks for explaining. Ashwin. On Wed, Sep 9, 2009 at 10:43 AM, Boehm, Hans <hans.boehm@...> wrote: Andy's last observation here is the crucial one; these objects are typically allocated essentially by allocating a large block and then dividing it. This avoids locking on the allocation path. The resulting objects are usually not in any sense thread-local. I'm not sure how the details are handled in Hotspot. We in fact do something bery similar in our conservative non-moving collector, though the "TLAB" there is not even a contiguous piece of memory. A thread can grab a bunch of objects of a given size (linked together in a free-list) at once with a single lock acquisition, and then parcel them out as needed without further locking. Though this isn't quite as fast as the contiguous case, it still seems to get most of the benefit. Hans From: concurrency-interest-bounces@... [mailto:concurrency-interest-bounces@...] On Behalf Of Andrew Trick Sent: Wednesday, September 09, 2009 10:03 AM To: Ashwin Jayaprakash Cc: concurrency-interest@... Subject: Re: [concurrency-interest] Object allocations in different threads & Thread local allocation buffers JVMs typically implement precise garbage collection. This allows the GC thread to move objects while mutator threads hold reference (in registers or thread stack). TLABs are small, so in that case a JVM would probably stop the mutator threads, move ALL objects in the TLAB, update each thread's root set (registers/stack values), then restart mutators. TLAB objects are locally allocated... they are often not thread-local objects. -Andy On Thu, Sep 3, 2009 at 11:12 PM, Ashwin Jayaprakash <ashwin.jayaprakash@...> wrote: Hi, I know this forum is probably not the right place to ask these questions, but since most of the Concurrency experts read this forum I'm going to post my question anyway. We all know that the newer versions of JVMs (Java 5+) have Thread local allocation buffers. What I'm curious to know is what happens to the objects when the following happens: - Thread 1 allocates a bunch of objects - These object references are handed over to Thread 2, let's say via a BlockingQueue - Thread 2 then starts modifying those objects 1) So, when Object mutations cross such Thread boundaries, does the TLAB get fragmented because it cannot be reclaimed completely? 2) Does this affect performance a lot? Doesn't the new Fork-Join or any such thread-pooling logic make heavy use of such allocations? 3) If it does affect performance, is there a better way to do things? Now, this might be a pointless question - you might say "don't use threads then".. but I'm just thinking aloud Thanks! Ashwin (http://www.ashwinjayaprakash.com) _______________________________________________ Concurrency-interest mailing list Concurrency-interest@... http://cs.oswego.edu/mailman/listinfo/concurrency-interest _______________________________________________ Concurrency-interest mailing list Concurrency-interest@... http://cs.oswego.edu/mailman/listinfo/concurrency-interest