[M3devel] garbage collector compacting and volatile?

[Jay K]

Good point.  I have it around somewhere... (I need that automatic resource management in real life..)
 
 - Jay

 
> To: hosking at cs.purdue.edu
> Date: Tue, 28 Jan 2014 15:49:19 -0800
> From: mika at async.caltech.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] garbage collector compacting and volatile?
> 
> 
> 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.
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20140129/895ab0a2/attachment-0002.html>