Re: thanks for the memory work

[Steven Bosscher <s dot bosscher at student dot tudelft dot nl>]

On Monday 24 November 2003 17:05, Jeff Law wrote:
> I'm also not 100% convinced that we're actually GC-ing everthing we ought
> to -- the lack of information from the GC system is probably going to be
> a significant hindrance in getting to the root of some of these issues.

Yup. We have already had that problem since the introduction of GC ;-)

> For example, I'd like to ask the GC system "do you have any PHI nodes which
> are marked?  If so, what was the path by which they were marked?".

It's doable to tell _if_ any PHI nodes are marked, but it's very hard if at 
all possible to tell _when_ and along which path.

What should be possible is to create a new zone for PHIs and SSA names with 
the zone collector, and then see if anything in the zone is marked.  I'll see 
if I can figure out how to do that.

But actually I'm quite sure we collect at least all SSA names, just not the 
pages they are in because there are other objects of the same size in those 
pages. I'd expect we collect a lot more now compared to last week because we 
have far more 32 byte objects than 24 byte objects.

PHIs are a bit more complicated because they don't have a fixed size and 
therefore are even harder to keep track of.

> Anyway, there's more stuff on the way, and I'm sure if you can get more
> statistics that we can find additional easy wins.

Here's one statistic that disappointed me somewhat.  I expected that we were 
creating millions of varrays for statement operands, but at least for 8361.ii 
it's not so bad at all (numbers for -O2 -fno-tree-pre):

             number of varrays
 use_ops        326058
 def_ops        327317
vuse_ops        204200
vdef_ops         88002
TOTAL           945577

Assuming that only the "name" and "type" fields of the varray_head_tag struct 
are redundant our purpose, there's less than 8 MB overhead from this.

Gr.
Steven