GMC Update

It's been a pretty long time since I last wrote something here, and many things happened :

first, leo made many comments on GMC for dummies, which led to a much better design, and something closer to what he had in head for gmc. Main topics that were concerned were placement of objects, the structure of gmc_gc_obj (and specifically its header, which needs to be as small as possible) and inter-generational pointers (IGP) handling.

Bob Rogers later made some remarks concerning IGP and the difficulty of collecting cycles. After much thought, I came up with a modification of the first design, which I called Night of the Living Dead Collection. It was just then that I realized that it was almost exactly what leo wanted to do (though a little bit more complex). We are not really one-pass anymore but almost so (back pointers need to be followed in order to make a real marking).

Other news was that I was in Paris for a week (mostly drinking guinness and trying new restaurants with friends). And of course, as a simple application of Murphy Law, my laptop AC adapter died... So I couldn't work on design documents or begin coding anymore while I was there. Fortunately, the IBM warranty guys (may they be blessed) sent me a new adapter very quickly and everything is fine again.

As a consequence, I have begun coding some things (for now only data structures), rather than producing again design documents which would not be confronted to the tough reality of parrot source code. As I don't have yet svn access (and don't know if I am supposed to commit my changes, even though they are protected by #ifdef statements), I did not add them to the parrot source code, but the thing is here for anyone to look at and comment : smallobject.h.

GMC for dummies

I may not have said it elsewhere, but the name of the project is GMC : Generational Mark & Compact (though funnier interpretations have been proposed).

Nevertheless, I had a small discussion with leo today, on the first draft, and he gave me the key to nice and easy indirection level for objects access. But the lack of a clear and simple description of the thing and how it all worked was quite patent (full_design.pod is more an API than an explanation). So I wrote a second document, gmc_for_dummies.pod, which is (I think) a lot clearer and will help me (and leo, I hope) much.

I think it's the best introduction if you want to have a more accurate idea of what the project is all about (btw, if you don't know what pod is, it stands for Plain Old Documentation and is widely used in Perl). man perlpod will tell you much about it, but a simpler way to access it is to run "pod2html" on it, which will produce a plain looking html page.

First draft of GMC design is over !

Great news : I've finally completed the first draft of the design document. I also renamed it to something more suggestive : gmc_design.pod. I am now waiting for leo comments on it.

I have hopes to begin to seriously code quite soon. It may seem that it is quite late, but I had to understand some parts of parrot source (although I'm still very far to know the whole thing), how allocation worked and such things. And I think having written that document helped me a lot to stabilize my ideas about what I had to do and how to do it. I think it will allow me to go quite fast (as I pretty much know everything there is to do, now (or think I know, rather)).

Exuberant-tags

Slowly but with certainty (is there an idiomatic english translation ?), the project is going on.
full-description.pod has been updated, and I am beginning to really understand how things are going on in the internals of parrot.

Multi-threading, however, will may be be a problem, as the spec is not complete yet, so I have to make guesses at how things will work. Of course, that also means that I won't have to write code for it right now, but I think forgetting it entirely would be a mistake, as this would make adapting the code much more difficult when it eventually comes in...

I had a small talk with leo on IRC and he pointed me to the right places for adding the extra layer in object allocation (the trick_that_mades_compacting_possible).

More importantly, he advised me to use exuberant-ctags. I had already looked at it before and even installed the right vim (did I say somewhere that it was the greatest editor on the planet ? Well, I should have) mode, but never had the (courage|motivation|desire|need|fill_in_with_whatever_pleases_you) to use it seriously. And I must confess it's life changing ! No more random walk in files whose names look vaguely suggestive and big "grep -ri my_function src/" which gives some thousands calls of the function and hidden somewhere (if we are lucky) a declaration.

Confirmation and Monotone

I received two days ago the mail that I had been waiting for more than a week : Chris confirming me that I had been accepted.
Cheers !

Just in time for the end of my internship in Marseille. Now I have much more time and I can stop worrying, so I should be able to be productive again.

I resumed the work in full-description.pod (not mirrored yet) with some initialization functions and more data structures related to multi-threading issues.

I also managed to compile monotone (manual compilation of 0.20 and emerge of 0.19 failed, but the ~x86 0.20 ebuild worked) and set up a local version of my parrot tree, where I will store my changes before the whole thing is ready. There is no online mirror but if people want so, I think I could make one (although finding monotone-capable web servers seems not very easy...).


I have good hopes of the project eventually being on track !

Welcome on my blog

Hi and welcome to everyone who read these lines,

this is the blog where I expect to keep track of my Summer of Code project : writing a new generational, thread-aware GC for parrot. This is mentored by the Perl Foundation, and more specifically by Leopold Tötsch.

You can find a more detailed description of what I will be doing at this address : full-description.pod, although it is not as much up to date as I would like it to be...