GC/grey pages question

Dear Paolo,

I was trying to understand the garbage collection better (e.g. to
determine if adding a write-barrier is a pain, if direct pointers
will be feasible at some point).

I thought the concept was:

* We mprotect READ_ONLY the old space
* When an object from old space starts to point to the new space
  it will be modified and the modification will trigger a SIGSEGV
* The SIGSEGV handling will add the page to the greylist.

* At some point the GC will scan the grey list, mark the objects
  and move them to the old space too.
* The entry from the greylist will be removed and the page will
  be marked as read-only again.

The reality seems to be a bit different.

* We don't seem to mprotect the oldspace but the OOP table? Is
this correct or am I misguided?

* We slowly/never remove entries from the greylist? E.g. even
after doing ObjectMemory compact the greylist is not empty? Is
this a bug?



kind regards
        holger

_______________________________________________
help-smalltalk mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-smalltalk

Il 27/09/2014 18:01, Holger Hans Peter Freyther ha scritto:
> * We don't seem to mprotect the oldspace but the OOP table? Is
> this correct or am I misguided?

We mprotect the oldspace, not the OOP table, in scan_grey_pages:

  _gst_mem_protect ((PTR) node->base, node->n * sizeof(OOP), PROT_READ);


> * We slowly/never remove entries from the greylist? E.g. even
> after doing ObjectMemory compact the greylist is not empty? Is
> this a bug?

After ObjectMemory compact all newly-allocated pages will be grey
because "grey-ness" is removed lazily on the next GC.  I think
"ObjectMemory compact; globalGc" should remove all grey pages or almost
all of them.

Paolo


_______________________________________________
help-smalltalk mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-smalltalk