RE: Misplaced memset?

["Boehm, Hans" <hans_boehm at hp dot com>]

> > I may be misunderstanding (and hopefully Hans will correct 
> me if so),
> > but I think in this case _Jv_AllocPtrFreeObj is not 
> required to return
> > zeroed memory for performance reasons.  There are other places where
> > we call this function, places where zeroing the memory would be
> > redundant work (since we immediately and fully initialize 
> the returned
> > object -- e.g. see the String case).
That is correct.  The comment in jvm.h even states that, though it could be more specific for some of the other functions.

In general, there is an argument for this sort of interface convention:  If the object contains pointers, it is very hard to return it from the allocator completely uninitialized.  An immediately following GC may see the bad pointers, usually with unfortunate correctness or performance implications.  For a pointerfree object, this is not an issue.

I suspect that there is often a significant performance advantage to not initializing objects in the allocator if you can avoid it.  If you look at an instruction-level profile of almost anything using our collector, a significant number of cycles are spent clearing memory.  That's in part because memory is cleared in large blocks.  Whenever you do that, you quickly fill up processor write buffers, and you end up waiting for memory.  If you could do the clearing an object a time, you could often interleave the draining of the write buffers with useful execution.  If you're going to do it an object at a time, you might as well clear only those fields that won't be immediately overwritten by initialization code.  (The trick is to trade all of this off against the added instruction overhead of doing things in small chunks, and against potential code size issues.  For our collector, there are other issues related to accidental scanning of free lists.)

If you change any of this, it's important not to increase the number function calls in the allocation code.  It's performance critical, at least in my experience.

Hans