GMC released!

GMC has just been released! This basically means that I posted a notice to perl6-internals that I thought it was ready to be tested by parrot devs (or anyone willing to, of course).

The last few days have been very awkward. I spent a lot of time trying to catch bugs, most often by dumping everything that could be dumped (which, in a software as big as parrot, means a lot) and using vim to browse the 100,000 lines files that resulted, trying to find errors. I also rewrote a lot of code, including all the compaction and most of the marking...
However, after all this, I managed to reduce the make test errors to only 10 on 2758 (yes, that's 99.64%), and at least 4 of them are due to the timely destruction code not working (but I couldn't yet find why).

Now that it's released, I feel very relieved about getting it (almost) done in time (that was pretty close, I couldn't have gone any faster) and I really hope there won't be too many bugs and that leo will be able to merge it soon to trunk (but make test will need to be at 100% first).
It's only then that we will be able to see if it is a real benefit !

GMC is here (but still buggy)

I just finished debugging the obvious flaws of compaction function a few minutes ago. Which, with yesterday's marking function, means that GMC is here ! It can run and do so flawlessly enough not to segfault (well, I saw it perform runs without segfaulting...).

However, there are stills a lot of bugs, as make test dropped from 96.5% to a mere 90.5% (check at the usual place), with segfaults, corruption and even sometimes glibc complaining or parrot freezing for some time... Some old bugs even seem to come back !

But I've still got a whole week to work things out, and I believe (err, hope) that I will be able to seek and destroy them all !

Bugs everywhere

I have been hunting bugs for the last few days, and it is beginning to pay!

With much help from leo, as usual (I wouldn't even have been aware that we needed to call VTABLE_destroy for every object out there because it forces io objects to flush their contents if he hadn't told me), make tests now reports 96% of passed tests (instead of 85%). And the remaining evil 3.5% seem to be only one memory corruption that makes them segfault (I cross fingers that I'll be able to find it soon and that it is the only one remaining). The url I gave for make test output has been updated, and I'll try to keep updating it when it changes (happily very soon !).

There also has been a discussion with people from TPF and leo went through my code. He seemed to see no serious flaw (other than not having enough comments, which is one of my bad coding habits...) and confirmed that, as me, he thought I would be able to make it in time.

Compiles and run !

Great news : the parrot code with modified object allocation targetted for GMC is not only compiling correctly (it has been for some days now) but running without segfaulting, which is a great improvement !
make test reports 85% of tests ok (more details here : make test output), so this means that there are still some important bugs around (but in heavy modification of such complicated source, the contrary would have been quite surprising !).

Update : GMC on tracks

More than two weeks since last post, and a little more than two weeks before deadline... But things have changed a lot !

The coding phase is quite advanced, and you can retrieve it in a svn branch : svn co https://svn.perl.org/parrot/branches/gmc

I'm almost done with the extra-layer of indirection for PMC. It was much slower than what I expected, mostly because I had to understand many parts of parrot internals in great details before being able to modify it in the way I intended to. Leo was of course a great help in the process, and I hope my repetitive questions have not annoyed him too much...

As soon as the new PMC design works (without GC, of course), which I expect to be in a day or two, I will be able to begin coding the GC itself. It should be faster because it's mostly linked list manipulation, which I'm a lot more familiar with, and the algorithms are ready...

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.