[M3devel] garbage collector compacting and volatile?

[Tony Hosking]

On Jan 24, 2014, at 5:38 AM, Jay K <jay.krell at cornell.edu> wrote:

> Is our garbage collector compacting?

Yes, it is mostly-copying.
Only pages that are not referred to from the stack (i.e., only from other objects) have their objects relocated (compacted).

> In particular, what model do we need for "volatile" in codegen?
> Does the compactor read the registers or just the stack?

It reads both registers and stack.

> Update references anywhere? Just the stack? Also context?

The collector first pins all pages referenced from the stacks, including registers.
Any page not pinned has its reachable objects evacuated and all references to those objects (i.e., from other objects) are updated to refer to the the new location.

> There are tradeoffs either way.

Indeed. Too many to enumerate here.

> If it is not compacting and only reads the stack, then it can be more
> portable, but every write of a collected type/pointer would have to be volatile.
> Or is that what the barriers are for?

The write barrier allows the collector to run concurrently with the mutator (once all stack roots have been sampled).

> If we update values on the stack, then there is some portability,
> but reads and writes would have to be volatile.

No updates to values on the stacks.

> If we read and write registers in the collector, then nothing has to be volatile.

Read only.  No writes to registers.

> Should this all be parameters passed to the backend?

Nope.

> And/or preserved via #ifdef in the C backend?
> That last part is easy enough, for generated C to take #ifdefs
> indicating if reads and/or writes should be volatile.

Nope.

> If the collector is not compacting, then it need not update
> stack or register values, just possibly read them.
> 
> I recall reading that it is compacting.


It is mostly-copying.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20140124/12b01775/attachment-0002.html>