<!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:4a5f5f320905061709n2d8cc076r9b45ad25818484c4@mail.gmail.com"
type="cite">
<pre wrap="">2009/5/7 Joshua Gargus <a class="moz-txt-link-rfc2396E" href="mailto:schwa@fastmail.us"><schwa@fastmail.us></a>:
</pre>
<blockquote type="cite">
<pre wrap="">Igor Stasenko wrote:
2009/5/7 Eliot Miranda <a class="moz-txt-link-rfc2396E" href="mailto:eliot.miranda@gmail.com"><eliot.miranda@gmail.com></a>:
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:
On 4/29/09, Andreas Raab <a class="moz-txt-link-rfc2396E" href="mailto:andreas.raab@gmx.de"><andreas.raab@gmx.de></a> wrote:
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.
...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.
See Expert to Expert - Erik Meijer and Lars Bak: Inside V8. Lars Bak thinks
this is a bad idea, and I agree with him :)
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.
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 ;-)
</pre>
</blockquote>
<pre wrap=""><!---->Heh, no this couldn't help. Who will sweep the garbage in object
memory which used to collect garbage in another object memory? 3rd
one? :)
</pre>
</blockquote>
<br>
Sure, why not? "It's turtles all the way down", and to hell with the
finite hardware! <br>
<br>
Of course you don't need an infinite chain of images. An image could
publish a list of services that it provides, one of them being
garbage-collection. When an image requires garbage collection, it can
send a request to one of the images that publish that service. Or more
simply, just have 2 GC images that take care of each other's needs (in
a massively multicore scenario, you'd want more than one image
performing GCs anyway).<br>
<blockquote
cite="mid:4a5f5f320905061709n2d8cc076r9b45ad25818484c4@mail.gmail.com"
type="cite">
<pre wrap="">
I think that to make an 'in-language' GC possible, it should use an
object/classes mirrors, which providing methods required by GC in
functional style i.e.:
to visit all refs of a single oop, GC would call following method:
oop mirror iterateReferencesFor: oop iterationCallback: closure.
instead of:
oop allReferences do: [:each| GC mark: each ].
</pre>
</blockquote>
<br>
Pretty! The point, I gather, is that you would avoid generating
garbage during the iteration?<br>
<br>
<blockquote
cite="mid:4a5f5f320905061709n2d8cc076r9b45ad25818484c4@mail.gmail.com"
type="cite">
<pre wrap="">
i started prototyping these things in Moebius. Currently i'm using
them to bootstrap an object memory. I could instantiate such mirrors
in Squeak and then using them to fill the oops in newly created object
memory. It is possible because a functional/declarative code behavior
is invariant in any environment.
</pre>
<blockquote type="cite">
<pre wrap="">(BTW, are you still working on Hydra much? Waiting for Cog?)
</pre>
</blockquote>
<pre wrap=""><!---->
I'd prefer help finishing Cog first, then we could get back to Hydra sooner :)
</pre>
</blockquote>
<br>
:-) Hopefully Eliot's "Stack VM" will be released soon; it should be a
good point to merge the Hydra changes before "Cog" makes it out.<br>
<br>
<blockquote
cite="mid:4a5f5f320905061709n2d8cc076r9b45ad25818484c4@mail.gmail.com"
type="cite">
<pre wrap="">Mainly, what i don't like in Squeak VM building process is the
involvement of C compiler.
I keep advocating the idea that by having a native code generator, we
don't need the C compiler anymore.
</pre>
</blockquote>
<br>
That would be swell. Eliot met Slava Pestov at PyCon, and was quite
impressed by the code-generator in Factor
(<a class="moz-txt-link-freetext" href="http://www.mirandabanda.org/cogblog/2008/06/06/cog/#comment-4027">http://www.mirandabanda.org/cogblog/2008/06/06/cog/#comment-4027</a>).<br>
<br>
Cheers,<br>
Josh<br>
<br>
<br>
<br>
<blockquote
cite="mid:4a5f5f320905061709n2d8cc076r9b45ad25818484c4@mail.gmail.com"
type="cite">
<blockquote type="cite">
<pre wrap="">Cheers,
Josh
Gulik.
--
<a class="moz-txt-link-freetext" href="http://gulik.pbwiki.com/">http://gulik.pbwiki.com/</a>
</pre>
</blockquote>
<pre wrap=""><!---->
</pre>
</blockquote>
<br>
</body>
</html>