<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Igor Stasenko wrote:
<blockquote
cite="mid:4a5f5f320905061517u16d9dabetb6128f8b17a26115@mail.gmail.com"
type="cite">
<pre wrap="">2009/5/7 Eliot Miranda <a class="moz-txt-link-rfc2396E" href="mailto:eliot.miranda@gmail.com"><eliot.miranda@gmail.com></a>:
</pre>
<blockquote type="cite">
<pre wrap="">
On Tue, Apr 28, 2009 at 9:26 PM, Michael van der Gulik <a class="moz-txt-link-rfc2396E" href="mailto:mikevdg@gmail.com"><mikevdg@gmail.com></a>
wrote:
</pre>
<blockquote type="cite">
<pre wrap="">On 4/29/09, Andreas Raab <a class="moz-txt-link-rfc2396E" href="mailto:andreas.raab@gmx.de"><andreas.raab@gmx.de></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Eliot Miranda wrote:
Note that
you could even run GC only from the scheduler (i.e., treat GC as an
external signal that requests a GC from the scheduler) which solves the
concurrent GC problem even with the current VM design.
</pre>
</blockquote>
<pre wrap="">...or even implement the GC in bytecodes. You could provide primitives
which gives lower level access to the image - raw memory maybe, or
perhaps objects indexed by oop.
It would be a bit tricky managing the garbage the GC itself would
generate. Maybe you could just leave it lying around, or maybe
deallocate it manually? And it would be a bit slow.
</pre>
</blockquote>
<pre wrap="">See Expert to Expert - Erik Meijer and Lars Bak: Inside V8. Lars Bak thinks
this is a bad idea, and I agree with him :)
</pre>
</blockquote>
<pre wrap=""><!---->
Then make GC which can't generate the garbage. Or, in other words, it
should consume a predictable preallocated limited amount of memory to
do garbage collection. Since most of GC working in that way, i don't
see how a bytecode (or better to say - the 'in-language') GC
implementation could be different. Of course you need to allow a
direct memory access, and need to be careful with code/objects
relocations which is used by GC itself during running GC, and of
course it would be better to run it in native code - for speed reasons
:)
This is not something , which is impossible to do.
</pre>
</blockquote>
<br>
It would be easier to use Hydra instead of jumping though hoops to run
the GC code from the same object-memory that you're GCing. And, the
effort put into making Hydra support this would actually be useful,
instead of doing something extra-complicated just to show that you can
;-)<br>
<br>
(BTW, are you still working on Hydra much? Waiting for Cog?)<br>
<br>
Cheers,<br>
Josh<br>
<br>
<br>
<br>
<blockquote
cite="mid:4a5f5f320905061517u16d9dabetb6128f8b17a26115@mail.gmail.com"
type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">Gulik.
--
<a class="moz-txt-link-freetext" href="http://gulik.pbwiki.com/">http://gulik.pbwiki.com/</a>
</pre>
</blockquote>
</blockquote>
<pre wrap=""><!---->
</pre>
</blockquote>
<br>
</body>
</html>