My project.
This post assumes that the reader has read
my last post.
This was a week full of segfaults, failed assertions, changes in the user data and other crazy stuff. I started working on the allocation of memory on the freed lines. In the first glance, it seemed to be much harder than the small changes I ve done to free memory in lines, because of the a never-seen-before-by-me datatypes being dealed with in
alloc_for_copy(), from
rts/sm/Evac.c:
gen_workspace. But in a short time the code of
alloc_for_copy() has shown itself to be simple, and it was easy to do an initial implementation. I went in the same path I was going on before, trying the simplest solution that works. For instance, the line representation used is not ideal, because groups of lines are not considered, but it was the simplest at that time, and I plan to improve it latter.
The
gen_workspace data type contains a pointer to an area of a block that is not being used (
todo_free) and a pointer to the end of that area (
todo_lim). When a space for an object is requested, it s allocated in this area, and
todo_free is adjusted. If the area is full, a new block is requested. My intended change was to return the first free line of the generation when the object is smaller or equal to the size of a line, and use the current approach otherwise. This is the simplest way I could think, but has
the problem that the only one object is allocated per line. This was a known issue.
if(size <= BITS_IN(W_) && gen->first_line != NULL)
to = gen->first_line;
gen->first_line = (StgPtr) *gen->first_line;
return to;
ws = &gct->gens[gen->no];
After that I got the first round of segfaults. One problem I could spot so far was in the code in
rts/sm/Sweep.c, related to the liberation of the lines. The block is allocated by need, and there s a pointer to the first free byte,
free. This free space is used by
alloc_for_copy(). So, we should only think of lines in the region already allocated in the block, that is, where the address is smaller than
free.
if(bd->u.bitmap[i] == 0 && bd->u.bitmap[i - 1] == 0 &&
start + BITS_IN(W_) <= bd->free)
But the segfaults, memory corruptions, etc, kept going on. I tried some restrictions, like allocating in lines only objects with the exact size of a line, or very small objects (size == 2), or allocating just one object for generation, or only one object at all. I also tried checking for the type of the allocated object, to see a correlation with the problems I was having. Nothing helped by now.
So I thought I should work on other things, so that maybe my mind gets clearer and I can spot the problem. I followed
the suggestion of using
todo_free and
todo_lim to make it possible to allocate more than one object in a line. I liked this change, since I had the impression that it fits better with the rest of the code than the initial implementation, and it will be easier to addapt it when I improve the representation of the free lines. As I said, I wanted something to work while I think in how I ll solve the segfault problems. The bad side of this choice is that I ll not be able to test it, since it s just a reimplementation of the same idea in the allocation code, and is not expected to work. The good size is that it may work, and solve the problems I was having by accident.
if (ws->todo_free > ws->todo_lim)
if (size <= BITS_IN(W_) && gen->first_line != NULL)
ws->todo_free = gen->first_line;
gen->first_line = (StgPtr) *gen->first_line;
to = ws->todo_free;
ws->todo_lim = ws->todo_free + BITS_IN(W_);
else
to = todo_block_full(size, ws);
I got the same results as with the older implementation, and no ideas about how to solve it (yet). So I thought about another thing to work on, which I m talking about all through this post: improve the free line representation. This has the advantage of being testable, since it s unrelated to the allocation code, and may give me an idea about how I can fix the segfaults. The bad side is that it probably won t fix my problems directly. I m working on it right now.
Following
a suggestion, I ve started using
gdb to see what was happening in the GC instead of including
printfs everywhere, and it s been useful. I ve noticed that sometimes
printf is more effective, but sometimes
gdb is much better.
Father's Day in the US has always been a weird one for me. I've been
pottering through the day oblivious, when a friend who is a father will tell
me that they've been thinking of me especially today because of our loss. Then I'm
reminded that Father's Day is in June and not September. I wonder what the
deal is with that? It seems very
few countries observe it on the first Sunday in September. Weird.
Zoe hits the 7 week mark tomorrow, and I return to work. Boy is that going
to be a shock to the system for all of us.
The 7 weeks of paternity leave has been absolutely wonderful. Google's
Paternity Leave benefit is now firmly my number one favourite employee
benefit. Co-workers had complained that taking it all at birth was a bit of
a waste, because all the baby does is sleep, but it's definitely been
worthwhile taking it all now.
Because we've been predominantly bottle feeding with pumped breast milk,
I've been able to be very involved with the feeding, and I've been able to
do a lot of the running around helping Sarah, so I wouldn't have done it any
other way. It's also been great to watch Zoe grow and develop. She's
interactive enough at this age, and it's just great to cuddle with her, or
share a nap with her.
On the sleeping front, things are a bit all over the place. She definitely
gets fussy in the evenings, at around 5pm to 7pm. Often we have trouble
getting her to go back to sleep after a feeding around this time. Sometimes
the trouble can extend past the 10pm to midnight feeding. She sleeps
magnificently during the day, and travels fairly well. She sleeps quite well
in her car seat, and stays asleep in it when we're at a cafe or restaurant.
We had our first overnight trip while Sarah's Mum was visiting. We went down
to San Simeon to take her to Hearst
Castle. It was fun having Zoe in a hotel room with us. Whenever she
fussed during the night, we'd just grab her and bring her into bed with us.
She spent quite a lot of time in our bed asleep on our chests. It was very
sweet. It was like a little baby vacation.
Zoe also had her first outing to the California Academy of Sciences, and we
managed to spend about 5 hours there without any major meltdowns from
anybody.
It was absolutely fantastic having Sarah's Mum here for 4 weeks too. She's
great to have around. She was a big help in cleaning up the back yard
significantly, and generally helping out around the house. It was great
having her take care of the 7am feeding when Sarah and I were both zonked
out from overnight interruptions. It was also nice not to have to think so
much about how dinner was going to materialise.
My parents have decided they will come and visit in September, which is
excellent, as they won't have to wait until February to meet Zoe. One of the
other nice things about the Google Paternity Leave is that you keep accruing
vacation time while you're on it, so I should have enough vacation time to
take a couple of weeks off while they're here, as well as in February when
we go back to Australia for Sarah's residential school at the University.
The next big event will be Zoe's vaccinations at 8 weeks. Hopefully that
will be as uneventful as possible.
Turns out that the football is insufficiently engaging to distract me from picking up the laptop, but sufficiently noisy that I don't get time to think about more complex problems (leave those for weekday evenings), so weekends seem to offer a brief window to relax and do some QA/RC uploads.
There are lots of 
With due apologies and thanks to my dear and crazy friend 
The 
Perl & Apache?
Have you already started to try out these new storage/database things commonly referred to as NoSQL? (For you google-bot, I'm talking about CouchDB, Cassandra, HBase, Hadoop, Hypertable, MongoDB, Tokyo Cabinet, etc). Well, it's one thing to install and use them but another to understand all the computer science background about them.
I've always thought about collecting random bits of useful/interesting/cool
Unix features and the like. Before I let that rot indefinitely in a text file
in my $HOME, I'll post it in a series of blog posts. So here's bit #1:
Everyone knows /dev/null, and most will know /dev/zero. But /dev/full was
unknown to me until some time ago. This device will respond to any write
request with ENOSPC, No space left on device. Handy if you want to test if your
program catches "disk full" - just let it write there:
Recently, I started to write some web tool to track the status of ongoing transitions in unstable. I thought I could use some code from the 
(because they used to rely on the generated 
1. Kavin is of 3 today. Can t forgot that awesome day 
