Why does GC need zap unused heap area?

[David Holmes - Sun Microsystems]

Colin,

Looks like the filling in is always done in a debug build - regardless 
of "Zap" flag:

./share/vm/memory/threadLocalAllocBuffer.inline.hpp

inline HeapWord* ThreadLocalAllocBuffer::allocate(size_t size) {
   invariants();
   HeapWord* obj = top();
   if (pointer_delta(end(), obj) >= size) {
     // successful thread-local allocation
     DEBUG_ONLY(Copy::fill_to_words(obj, size, badHeapWordVal));

A grep for badHeapWordVal showed this.

HTH

David Holmes

Colin(Du Li) said the following on 06/29/09 17:17:
> Thanks for your reply!
> I modified the allocator, and copy some objects to new locations(similar to
> "clone"). I found some of the objects in new locations are filled with
> "0xbaadbabe" even if I set the zapping option as "false". 
> I'm wondering who may take the action of filling the heap area with
> "0xbaadbabe". Could you give me any clue?
> Thanks again!
> 
> Colin
> 
> Y. Srinivas Ramakrishna wrote:
>> It's just a debugging aid, an indicator that a specific portion of the 
>> heap has
>> not yet been allocated to a Java object. It happens when space is
>> first initialized into the heap (at initialization and space expansion)
>> and then when newly freed space is identified by GC at the end of
>> a collection (cycle). As you would have found, in product mode such
>> "zapping" is not done.
>>
>> -- ramki
>>
>> Colin(Du Li) wrote:
>>> Hi, guys,
>>>
>>> I have a question about GC.
>>> Why does GC need fill the unused heap area with "badHeapWordVal"
>>> ("0xbaadbabe")?
>>> And when does this happen?
>>>
>>> Thanks
>>>
>>> Du Li
>>>   
>>
>>
>