Hi;
[EMAIL PROTECTED] wrote:
> [GAM] I was aware of the synchronisation problems, which I would
> have thought could be very unpleasant indeed. The benefits of interrupt
> driven scheduling hadn't occurred to me. I guess another benefit of native
> threads is the ability to make use of more than one processor in a
> multi-processor box (though I imagine support for these is a low priority /
> a long way off). I would still question whether the gains from native
> threads will outweigh the pain of implementing them (both in terms of
> reworking the kernel and putting in all the necessary synchronisation)?
> [Please note that these comments are based on zero experience of
> implementing operating systems and can therefore be safely ignored.]
I think we're on the same page. Basically, we'll get green threads running, and
if native threads is the next-hottest fire, then we'll put that one out.
> [GAM] With the heap as it currently is, there's nothing I can do
> with the information that a piece of memory is free *now* -- this info is
> gathered during the mark phase. So carry on nulling out pointers for now. If
> it seems like there would be useful gains from doing something sensible with
> explicit frees, I'll try to work that into a later version.
OK. Nulling-out-pointers it is...
> [GAM] The VM tricks also seem useful when doing generational GC --
> they can be used to implement a write barrier to track pointers to younger
> generations.
Exactly my understanding.
> > That's OK. I'm assuming we can just recompile it with the C++ compiler
> > (it's ANSI C, right?) and link it on in.
> >
> [GAM] Yes it should compile fine with g++ (I'll check this).
OK. Just let us all know!
> [GAM] Apart from the lack of support for large objects (well, not
> so large actually: >1/2 page) and no way of handling mark stack overflow,
> it's pretty much getting there. (I managed to get it to allocate and
> conservatively scan some noddy C structures at the weekend.) As mentioned
> above, I've haven't put any thought into handling explicit frees, and I'm
> loath to spend time turning it into an allocate/deallocate heap, cos that
> will inevitably detract from progress elsewhere. I would very much hope to
> have something that GCs correctly (albeit slowly) by, say, the 14th of this
> month. This would include the large object support, but maybe not deal with
That's great! Hopefully, we'll have something with which it can be integrated
(Todd and I can thus be advised to be sure to finish anything we start by
roughly the 14th).
> the mark stack overflow. If I haven't managed to get this far by then, I'll
Yeah, I think we're OK there. Any improved marking-space improvements can
certainly wait.
> happily hand over the code for completion by people with more time /
> speedier coding skills. I hope this is a usable timescale for you and Todd.
You betcha. It's a lot faster than either of us can come up with one...
> In the meantime, it would be very useful if you could go through the kernel
> and decaf and identify the roots for garbage collection. Issues I foresee
OK. We'll start that effort...
> with this: do we need to look in registers; how to find top and bottom of
> the native code stack for scanning.
I'm thinking with green threads we won't have to, but that's based upon a whole
10 seconds of thought... Todd, what sayest thou?
BTW, I'll be out of touch through Wednesday night at the earliest...
Thanks for the help!
-jm
--
==== John Morrison ==== MaK Technologies, Inc.
==== Chief Technology Officer ==== 185 Alewife Brook Pkwy, Cambridge, MA 02138
==== [EMAIL PROTECTED] ==== http://www.mak.com/welcome.html
==== vox:617-876-8085 x115 ==== fax:617-876-9208
_______________________________________________
Kernel maillist - [EMAIL PROTECTED]
http://jos.org/mailman/listinfo/kernel
