Std Phobos 2 and logging library?

Leandro Lucarella llucax at gmail.com
Sun Apr 12 15:27:25 PDT 2009


Christopher Wright, el 12 de abril a las 17:54 me escribiste:
> >>Absolutely.  When writing parallel code to do large scale data mining in D, the
> >>lack of precision and multithreaded allocation are real killers.  My interests
> >>are, in order of importance:
> >>
> >>1.  Being able to allocate at least small chunks of memory without locking.
> >>2.  Precise scanning of at least the heap.
> >>3.  Collection w/o stopping the world.
> >>4.  Moving GC so that allocations can be pointer bumps.
> >3. is my main goal right now. I think 1. can be done using thread-specific
> >free lists/pools. 2. Is possible too, but bigger changes are needed,
> >specially in the compiler side (1. and 3. can be completely done in the GC
> >implementation). 4. is not 100% possible because we can never have a 100%
> >precise GC, but can be very close if 2. is fixed =)
> 
> You can create StackInfo similar to TypeInfo, I suppose, and thus get an
> entirely precise GC.

Sure. This is a big (compiler) change, and you probably have to drop
C compatibility (what would you do with C functions stacks frames without
StackInfo? How do you know it a stack frame is from an "untyped"
C function or a "typed" D one? Where do you search for that StackInfo?).
But it's definitely possible in theory.

> Or you can pin anything that's referenced from the stack, and move
> anything that is only referenced from the heap.

That's more likely to happen, but it requires a compiler change too
(provide type information on allocation). Maybe I wasn't too clear,
I didn't mean to say that a moving collector is impossible, what is
impossible is to make allocation a "pointer bump".

What I mean is you can be as precise as you want, but as long as union and
void[] is there, there always be "might be a pointer" fields, and cells
pointed by that type of fields should not be moved, ever. So, even after
a fresh collection, your heap can be still fragmented. You have to store
information about the "holes" and take care of them. This can be very
light too (in comparison with the actual allocation algorithm), but it can
never be as simple as a "pointer bump" (as requested by David =).

So technically, you'll always have to deal with memory fragmentation in
D (I don't think anyone wants to drop unions and void[] =), and it's true
that it can be minimized to almost nothing. But since it's technically
possible, you can never get away from the extra complexity for managing
those rare cases.

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
EL "PITUFO ENRIQUE" LLEGO A LA BAILANTA
	-- Crónica TV



More information about the Digitalmars-d mailing list