Re: PATCH: new GC implementation

[Andi Kleen <ak at muc dot de>]

rth@cygnus.com (Richard Henderson) writes:
> 
> There's probably all sorts of interesting things we can do on
> 64-bit systems if we can identify on a by-system basis a large
> bit of vma that won't be used by anything else. 
> 
> For instance, on Alpha (Linux and DU), we know that the 36-bit
> area between 0x280_0000_0000 and 0x290_0000_0000 is not going 
> to be otherwise used.  Which means several things: (1) the test
> for "is this gc-allocated memory" is trivial, and (2) by tightly
> controling placement of the memory that we allocate, there is
> no need for the `lookup' array.

I could imagine that it would be a maintenance nightmare though:

If it was hardcoded there might be the problem that the compiler will
stop working on a future OS version with changed memory map. 

Dynamic parsing (e.g. of /proc/self/maps on Linux and the equivalents 
on other systems) would require lots of porting work for the compiler.

> 
> > + #define PAGE_L2_BITS (HOST_BITS_PER_WIDE_INT \
> > + 		      - PAGE_L1_BITS - HOST_PAGE_SIZE_BITS)
> 
> HOST_BITS_PER_WIDE_INT is not the size of the host's pointer.
> We'll often use `long long' for HOST_WIDE_INT on 32-bit hosts
> for targets with 128-bit types -- ia32 will soon be one of
> those, in fact.

For long double ? 

> Others have already commented on this.  I will tell you that
> Linux does zero the memory -- not zeroing the first time 
> would be a security hole, and there is nothing to track that
> a page was previously allocated to this process, so the zeroing
> happens every time.

Sorry I was wrong. I would keep the MAP_ANONYMOUS bit for now,
until /dev/zero is fixed to not use zeromap_page_range anymore.



-Andi
-- 
This is like TV. I don't like TV.