GC Precision

[Leandro Lucarella]

dsimcha, el 26 de octubre a las 13:08 me escribiste:
> I just realized last night that D's templates are probably powerful enough now
> to generate bit masks that can be used for precise GC heap scanning.  I'm
> halfway (emphasis on halfway) thinking of using this to try to hack the GC and
> make heap scanning fully precise except for the corner case of unions.
> However, this ties into several things that others in the D community are
> doing, so I want to gauge people's responses and make sure I'm not wasting
> effort on something that will be useless in 6 months.
> 
> 1.  Sean, Leonardo, whoever else may be working on GC implementations, have
> you by any chance broken ground on precise heap scanning already?

Maybe you're talking about me. I didn't have the chance to play with this
yet. My main goal is to make the collect run concurrently with the
mutator, but I have been a little busy lately so I didn't make many
advances yet. I will like to play with adding preciseness to the GC too if
I have the time.

> 2.  Andrei, Walter, how close are we to actually eliminating new from the
> language?  If all allocations were done by either calling GC.malloc() or using
> templates that call GC.malloc(), then things would get a lot simpler than if I
> were to have to hack the compiler to make new pass type info to the GC.

The runtime is already receiving the type information on the allocated
object when new is used AFAIK, but this information is not propagated to
gc_malloc(). So it shouldn't be too hard to add type information to the
GC. There was some interesting discussion about this some time ago.
http://www.digitalmars.com/d/archives/digitalmars/D/Std_Phobos_2_and_logging_library_87794.html#N87831

> 3.  I'm thinking bit masks could be stored as follows:
> 
> When getBitMask!(T) is instantiated, it generates an immutable size_t[N].
> Element 0 is the size of the array (to allow for storing only the ptr in the
> GC), element 1 is the size of one instance of the object, in bytes.  The size
> of the memory block must be a multiple of this.  Elements 2..$ are all of the
> offsets that should be scanned for pointers.  For example:
> 
> struct Foo {
>     uint bar;
>     void* baz;
> }
> 
> getBitMask!(Foo);  // [3, 8, 4].
> 
> That leaves the problem of where/how to store the pointers to this information
> in the GC efficiently.  I haven't gotten that far yet, but I remember some
> concerns have been raised in the past about storing 4 bytes per GC object for
> a pointer to the bitmask.  For my use cases, where I tend to allocate a
> relatively small number of relatively large objects, this isn't a problem.
> However, in a heavily OO environment, where people allocate tons of tiny
> objects, it might be.

In the discussion I mentioned Frits van Bommel proposed a reasonable way
to encode the information efficiently:
http://www.digitalmars.com/d/archives/digitalmars/D/Std_Phobos_2_and_logging_library_87794.html#N87968

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
"The Guinness Book of Records" holds the record for being the most
stolen book in public libraries