How much of a problem is this likely to be? In other words, what sort of cache
line sizes are being used?
In my experience on the Windows platform the *minimum* object size in Java is
already close to 32 bytes, so rounding up to a 32 or 64 byte boundary is not
going to add much overhead. If we're talking about 1024 byte boundaries, on the
other hand, I think this is a valid concern.
- Dennis
Ole Agesen - SunLabs wrote:
>
> > If we assume that this reordering might happen due to stale cache
> > lines, rather than value prediction, here is a solution. In the
> > nursery, always allocate objects starting at the beginning of a new
> > cache line.
> > ...
> > Now, of course this wastes some space, but only in the nursery. When
> > the garbage collector moves objects out of the nursery, it can store
> > them compactly.
>
> I'd like to throw in a caution here. The nursery or youngest
> generation (or whatever you call it) is the high pressure end
> of the memory system. Any overhead introduced there, will make
> itself visible! In the above case, the overhead is on every allocated
> object, not just on every object that survives a collection.
>
> Ole
>
> -------------------------------
> This is the JavaMemoryModel mailing list, managed by Majordomo 1.94.4.
>
> To send a message to the list, email JavaMemoryModel@cs.umd.edu
> To send a request to the list, email majordomo@cs.umd.edu and put
> your request in the body of the message (use the request "help" for help).
> For more information, visit http://www.cs.umd.edu/~pugh/java/memoryModel
-------------------------------
This is the JavaMemoryModel mailing list, managed by Majordomo 1.94.4.
To send a message to the list, email JavaMemoryModel@cs.umd.edu
To send a request to the list, email majordomo@cs.umd.edu and put
your request in the body of the message (use the request "help" for help).
For more information, visit http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:14 EDT