RE: [Gc] PRINT_STATS kind, and free_space_divisor

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

That's somewhat encouraging.  At least that seems to be an
improvement.

Re: new regions.
Unfortunately, it's hard to figure out what those are.  They have
type MEM_PRIVATE.  It would be wonderful if we could discard those
as well, and trace only from MEM_IMAGE sections.  I'm pretty sure
that dll initialized data is mapped as MEM_IMAGE.  Does anyone
know how win32 handles uninitialized data?

My guess is that these regions result from memory allocation outside
the GC.  One other question would be whether there is a leak outside the
GC, which would cause the root set to grow, which would cause the
GC heap to grow.

The GC tries to discard sections used by malloc.  But it only
knows how to do this by periodically calling malloc, discarding
the region containing the resulting pointer, and the
deallocating the memory it got.  This is a rather primitive
heuristic, and we know how to do much better under Linux.

Re: total heap size
Did you multiply the size by the number of marks?  Objects of
size smaller than 4K are allocated on 4K pages.  The printed
block list contains one entry for each such page.

Hans

> -----Original Message-----
> From: java-owner@gcc.gnu.org 
> [mailto:java-owner@gcc.gnu.org]On Behalf Of
> Rutger Ovidius
> Sent: Monday, November 22, 2004 7:55 PM
> To: Boehm, Hans
> Cc: gc@napali.hpl.hp.com; java@gcc.gnu.org
> Subject: Re: [Gc] PRINT_STATS kind, and free_space_divisor
> 
> 
> Monday, November 22, 2004, 3:52:37 PM, you wrote:
> 
> BH> Here's a completely untested patch against CVS gcc/boehm-gc,
> BH> though it would probably apply anywhere:
> 
> I applied this patch and the app hasn't crashed yet. (win32(xp) --
> I haven't tried it on linux yet.)
> 
> The static root size is now 6 megs where it used to be 15.
> 
> But, after a while of doing basically nothing, it grows to 12 megs.
> What could cause such a dramatic increase (all at once it seems). Is
> it normal that the root set will constantly grow if only temp
> objects are being used (strings) and no new major objects are being
> permanently referenced by the app? From the gc.log, the collection
> with the total size jump to:
> 
> Total size: 12283904
> 
> Has these two noticably large additions:
> 
> BaseAddress = 4d00000, AllocationBase = 4d00000, RegionSize = 
> 1d2000(1908736)
>   AllocationProtect = 4, State = 1000, Protect = 4, Type = 20000
> ..
> BaseAddress = 5500000, AllocationBase = 5500000, RegionSize = 
> 3de000(4055040)
>   AllocationProtect = 4, State = 1000, Protect = 4, Type = 20000
> 
> I don't understand what activity could cause such a large addition to
> the static roots. The app was fully loaded, and doing nothing special.
> 
> 
> On the heap side, I'm still not sure how to understand these printed
> stats. In gc.log I see sections like the following:
> 
> Total heap size: 21938176
> ...
> Total of 6873088 bytes on free list
> 
> ***Blocks in use:
> (kind(0=ptrfree,1=normal,2=unc.,3=stubborn):size_in_bytes, 
> #_marks_set)
> (0:40,79)(1:152,4)(1:40,58)(0:2048,2)(0:1024,4)(4:256,8) .....
> blocks = 3077, bytes = 15065088
> 
> Which I assume tells me exactly the size of stuff on the heap.
> (15065088 + 6873088 = 21938176)
> 
> But, when I manually count (using awk) the size_in_bytes of
> these 3077 blocks that were printed, I total 2869356 bytes. So, I have
> a heap that large storing ~3 megs of data? I don't understand this
> disparity. I guess it has something to do with HBLKSIZE since the
> reclaim.c:GC_print_block_descr() function recalculates size_in_bytes
> based upon it, but I don't fully understand this yet. Any insight? Is
> this normal?
> 
> Thanks.
> 
> 
> Full gc.log (gc2.zip, 377k)
> http://tinyurl.com/676kv
> 
> Regards,
> Rutger Ovidius
> 
> 
>