Immix on GHC Summer of Code weekly report #9

My project.

This post assumes that the reader has read my last post.

I’m posting this weekly report earlier this week because there are too many things to tell already. I’ve found the reason behind the segfault I’m looking for so much time. The last problem, which is the only I know exactly when was fixed, because the programs started working, was related to allocating two times in the same region of memory. This happened because in each major GC the list of free line groups is generated again, but my old code was still allocating in the same line group of the last generation. So the last part of the line group, which was not yet used, would be a part of a line group in generated in the new collection, and it will be used for allocation two times: one in the allocation of the current line group, and another when this new line group starts being allocated.

The implementation of the allocation of memory in lines is not very complicated, but it has some details that should be paid attention, and that were the cause of most trouble last weeks, and still need improvement. Initially I was allocating one object per line, just to see if it would work. As it didn’t, I kept on improving the approach until I could find the problem. The next attempt was by setting ws->todo_free and ws->todo_lim in alloc_for_copy() in rts/sm/Evac.c. I think this is not ideal, because I didn’t want the code to become too inconsistent with the way memory was allocated using these pointers before my changes. So I created new variables, line_free and line_lim, at first in the gen_workspace ws, the same place that todo_free and todo_lim are, but because of the last problem I described in the previous paragraph I changed it to generation. I’m still not sure about where to place these pointers, this is something that can be improved.

Another problem that I took a long time to understand is that the object need to be scavenged after being allocated. When it was allocated in todo_free, it was being scavenged by scavenge_block() in rts/sm/Scav.c, because the block in which it’s in, todo_bd, is scavenged by this function. As I didn’t wanted to the whole block where the free line group is to get scavenged again, I didn’t want to send it to this function. So I thought about creating a way to scavenge only part of a block, that is, the space in the free line group that was allocated. This is still a valid idea, but I noticed that it was easier to use the mark stack. So I mark the object that is allocated in the line and push it in the mark stack. The main problem with this approach it’s only possible to allocate in lines during major GCs, since only in this kind of GCs the mark stack is active. This is certainly the place where I can make more improvement.

The patch of these changes and another one for the sanity checking explained in the last post.

I’m now benchmarking these changes with nofib, to see how much it affects the performance.


3 Respostas to “Immix on GHC Summer of Code weekly report #9”

  1. foo Says:

    for the fucking love of god, change that hackergotchi on planet debian!!!!

  2. marcotmarcot Says:


  3. Immix on GHC Summer of Code weekly report #10 « Blog do Marcot Says:

    […] Blog do Marcot « Immix on GHC Summer of Code weekly report #9 […]

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do

Você está comentando utilizando sua conta Sair /  Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair /  Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair /  Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair /  Alterar )


Conectando a %s

%d blogueiros gostam disto: