John --
> > >(2) The decaf JVM and the jjos nano/pico/femto/whatever kernel uses C++
> and
> > >dynamic memory allocation as well. Currently, both the jjos C++ objects
> and
> > >the
> > >Java objects (which are, after all, C++ objects as far as the JVM is
> > >concerned)
> > >are allocated out of the same heap.
> >
> > I must admit I hadn't considered the heap requirements of the JVM and
> > kernel. I'll get to thinking about what this might mean for JJOS's gc.
>
> Again, I'm thinking we can treat everything exactly the same. There's a
> certain appeal to the economy of effort (especially when it's YOUR
> effort, not mine! <== this is an attempt at humor).
>
[GAM] Humour received and understood :-)
> To the best of my knowledge, yes, there is a whole lot of difference.
> Using "green threads," or "simulated threads," it is (relatively)
> straightforward to ensure that Java bytecodes are "atomic" with respect
> to each other and with respect to hardware operations. This simplifies
> the writing of the JVM, especially with respect to the thread
> synchronization primitives. One never has to worry about pre-emption of
> the C++ code which implements, well, just about everything in the JVM.
>
> On the other hand, by using native threads, we can avail ourselves of
> the CPU's (well, the x86 CPUs, anyway) ability to schedule threads via
> interrupts (etc.), which will likely be faster and entail less overhead
> than anything we can do via a polled, "is it time to switch threads
> yet?" kind of top-level loop. Based upon a whole 10 seconds of thought,
> I'm thinking that this will have to happen prior to getting JIT
> capability (assuming that we need JIT eventually). I mean, once we
> vector off to native code, that whole polling scheduler thing we're
> using now pretty much doesn't work anymore.
>
[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 hadn't considered calls to the heap to explicitly free memory, since
> you
> > can't do it from Java, and that's what I was concentrating on. I think
> it
> > would be helpful to null out pointers when they are known to be rubbish,
> > even if I didn't provide a mechanism for explicit freeing.
>
> That much, I think we do already. Well, OK, we *try* to do it. Well,
> maybe, we try to *remember* to try to do it. Seriously, it's your
> call. If you give it to us, we'll use it. I'm sure there's more to it
> than this (e.g., there's a school of thought that says don't free it
> when you know it becomes garbage, because then you're paying the
> overhead of GC/memory management in the user's time, instead of in the
> GC's time). Let me know what you think.
>
[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.
> > >> My guiding light in all this has been "Garbage Collection :
> Algorithms
> > for
> > >> Automatic Dynamic Memory Management" by Richard Jones and Rafael
> Lins.
> > >>
> > >
> > >An absolutely fabulous book -- read it cover-to-cover. Please pay
>
> Uh, that should've read "*I* read it cover-to-cover." Whoops. Didn't
> mean to appear to be handing out reading assignments by Imperial Fiat.
> Sorry.
>
[GAM] The Imperial Fiat interpretation didn't occur to me at all.
The Emperor gives good advice though!
> > Yes. Because the gc is part of the kernel, I hope that eventually that
> we
> > can work very closely with the the virtual memory system and take
> advantage
> > of various gubbins in the memory mgt unit that are inaccessible to user
> > processes.
>
> There are also some weird things we can do by availing ourselves of the
> x86's ability to trap accesses to pages that we've already scanned,
> etc. These seem to be useful for incremental GC, although I seem to
> recall reading papers that said that it might not be such a Big Win.
> However, I have no problem with a stop-and-GC scheme at this point in
> time.
>
[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.
> 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).
> With respect to schedule, when is the first likely time we can have a
> simple allocate/deallocate-capable heap implementation, without the
> conservative GC? I'm not trying to lean on you, but we'll need
> something Real Soon Now that will enable us to keep jjos+decaf up long
> enough to do something interesting (right now we leak like a sieve
> because we don't have a heap implementation at all). I can always
> kludge together, er, cons together, er, write a simple heap, but I'd
> prefer not to if you've got something that'll be the right solution...
>
[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
the mark stack overflow. If I haven't managed to get this far by then, I'll
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.
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
with this: do we need to look in registers; how to find top and bottom of
the native code stack for scanning.
-- George
_______________________________________________
Kernel maillist - [EMAIL PROTECTED]
http://jos.org/mailman/listinfo/kernel
