Re: A GC question

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--===============0891099497==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature";
	boundary="------------enigC7E57C6EDA825F37A5B8E388"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigC7E57C6EDA825F37A5B8E388
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Hi Ceyhun,

> I have downloaded the sources and I was looking sources.
>... 
> In the source above it allocates an object and pushes it to the stack.

Actually, you probably meant that it pushes a "reference" to the object
on the stack.

> My question is, what if the thread that allocated the object is preempted
> right after the allocation and before pushing it to the stack.
> And scheduler switches to an another thread and that thread needs
> garbage collection.
> The garbage collector searches the roots (stack and frames etc) for
> references and it can not find any references because obj reference it
> is not pushed on the stack yet.

No, this wouldn't happen.  SableVM has a stop-the-world (S-T-W) protocol
that ensures that every thread has reached a GC-safe state.

So, in your example, after the allocating thread (let's call it A) has
been pre-empted, another thread B comes along and requests GC.  When B
requests GC, the S-T-W protocol  puts B to sleep, and waits for all
other threads to reach a "GC Check point".  So, at some point, thread A
will resume execution and reach a GC checkpoint, where all references
are properly stored in the method frame (stack and locals).  It will
then go to sleep.  The S-T-W will wake up B as soon as all other threads
are sleeping, B will perform GC, then S-T-W will restart all other threads.

> I have looked at Sun JDK sources (1.3, 1.4) and I did not see any
> workaround for this.

Hmmm...  Be careful here.  Are you allowed to reveal such thing to us?
To gain access to this code, you have agreed to a non-disclosure license
with Sun.

SableVM is a "clean room" effort.  None of our developers have agreed to
any Sun "non-disclosure" agreement or license, and we ave no wish to
enter into any non-disclosure agreement.  We are an independent, open,
and partly academic development project.  So, do not reveal to us any
"secret" Sun intellectual property.  Thanks.  :-)

Have fun!

Etienne

-- 
Etienne M. Gagnon, Ph.D.            http://www.info2.uqam.ca/~egagnon/
SableVM:                                       http://www.sablevm.org/
SableCC:                                       http://www.sablecc.org/

--------------enigC7E57C6EDA825F37A5B8E388
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFEHDMxjyrJi4rH84gRAm6FAJ962ccyv971nT6ELXiwHbGtq0/RVgCfbB+z
m5FQjHQXl4anN4T+xTk2Vkw=
=N6PB
-----END PGP SIGNATURE-----

--------------enigC7E57C6EDA825F37A5B8E388--


--===============0891099497==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
SableVM-devel mailing list
[email protected]
http://sablevm.org/lists/control/listinfo/sablevm-devel

--===============0891099497==--