[M3devel] garbage collector compacting and volatile?

[mika at async.caltech.edu]

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.