[M3devel] garbage collector compacting and volatile?

[Jay K]

In summary, shortest:

  We must be able to read registers (or save them to the stack or elsewhere (known thread locals)).    We must be able to read the stack.    We need not write registers or stack (from garbage collector).  

Slight elaboration: Copying/compaction only occurs when references are only from globals and heap.  Therefore updates/writes only occur to globals and heap. 

 Is there any desire to do better/different?  To require the ability to update stack/registers?  What does Java typically to? 


I guess there is the problem that we don't know for certain if values in registers and stack are pointers, or just coincident integers, and so updating them can be wrong.Whereas in the globals and "reachable thereof" we have precise type information for, so we can update those values safely.To do better/different would require more backend cooperation.We conservatively treat registers/stack as pointers if they look like them, and therefore keep values alive, but not trust them so much as to update them.

Thanks, - Jay

From: hosking at cs.purdue.edu
Date: Fri, 24 Jan 2014 13:12:33 -0500
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] garbage collector compacting and volatile?

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/20140127/9dd883b4/attachment-0002.html>