[M3devel] garbage collector compacting and volatile?

Tony Hosking hosking at cs.purdue.edu
Wed Jan 29 01:07:15 CET 2014


;-)

I should send him a copy!

On Jan 28, 2014, at 6:49 PM, mika at async.caltech.edu wrote:

> 
> Sounds like Jay doesn't need to buy a copy of your book :-)
> 
> Tony Hosking writes:
>> 
>> --Apple-Mail=_12C5DBD9-678E-4559-B4C2-E4CFDA144CD4
>> Content-Transfer-Encoding: quoted-printable
>> Content-Type: text/plain;
>> 	charset=iso-8859-1
>> 
>> 
>> 
>> On Jan 27, 2014, at 2:45 AM, Jay K <jay.krell at cornell.edu> wrote:
>> 
>>> In summary, shortest:
>>> =20
>>> =20
>>>  We must be able to read registers (or save them to the stack or =
>> elsewhere (known thread locals)). =20
>>>  We must be able to read the stack. =20
>>>  We need not write registers or stack (from garbage collector). =20
>> 
>> Correct.
>> 
>>> Slight elaboration:
>>> Copying/compaction only occurs when references are only from globals =
>> and heap.=20
>>> Therefore updates/writes only occur to globals and heap.=20
>> 
>> Correct.
>> 
>>> Is there any desire to do better/different?=20
>>> To require the ability to update stack/registers?=20
>> 
>> Without control of the register allocator, optimisations, and stack =
>> layout performed by the compiler (especially back-end) getting fully =
>> accurate stack maps is very difficult.
>> 
>>> What does Java typically to?=20
>> 
>> Java VMs usually control their own destiny, having full control of JIT =
>> and stack layout.  viz. HotSpot, IBM J9, Jikes RVM.
>> 
>>> 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.
>> 
>> Correct.
>> 
>>> Whereas in the globals and "reachable thereof" we have precise type =
>> information for, so we can update those values safely.
>> 
>> Correct.
>> 
>>> 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.
>> 
>> Correct.




More information about the M3devel mailing list