Hi George (et al);
George Marrows wrote:
>
> >(1) The decaf JVM we're using uses pointers, not handles, to represent Java
> >objects (although all Java objects are subclassed from a single C++ base
> >class
> >in the JVM so we could probably change this if it became necessary). This
> >rules
> >out a whole bunch of "moving" or "copying" GC approaches.
>
> That's certainly true if you want conservative gc, but if you know what is a
> pointer and what is not, then you can update the pointers directly. This is
> what HotSpot does -- Sun seem vey proud of this fact, so I guess it's not so
> easy (either that or their marketing dept have been working hard..) See
> http://developer.java.sun.com/developer/technicalArticles/Networking/HotSpot
Yeah, we probably could, but it would involve extensive changes. The
conservative GC seems so much simpler for the moment in that we can
treat (pretty much) everything the same.
> A moving (compacting like HotSpot?) gc is something I'd maybe like to take a
> look at later.
Same here.
> >(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).
> >(3) The JVM uses "green threads" right now (i.e., simulated, not "real"
> >threads). However, when the underlying kernel implements native threads,
> >we're
> >really going to have both a Java and a native code stack for each Java
> >thread.
> >Wouldn't it be nice if we just used a conservative GC to scan both data
> >structures the same way?
>
> This has confused me whenever it's been mentioned on the JOS mailing lists -
> at the low level of the JOS kernel, is there that much to distinguish native
> threads and green threads? What benefit is there to the kernel implementing
> the threads rather than the VM? Explanations welcome ..
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.
> >With respect to design considerations, a couple of not-quite-typical
> >requirements:
> >
> >(1) Currently, decaf does not call destructors (and thence heap
> >deallocators)
> >everywhere it is possible to know that the memory object has
> instantaneously
> >become garbage. Either Todd or I can track those down so you don't have
> to.
> >We
> >have, of late, become more conscientious about calling destructors. Please
> >advise us if there is a suitable entry point in your conservative heap
> >implementation for us to mark a memory block as unused...
>
> 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.
> >(5) Java requires that we call any "finalize" Java methods upon Java
> objects
> >prior to their being GC-ed/reclaimed. Todd can perhaps shed more light
> upon
> >which context the methods must be executed in ...
>
> Again, I've not considered this yet -- I'll have to come back to it after
> the thing actually manages to gc at all!
OK. However, it might affect your design (e.g., some blocks can be
instantly reclaimed -- some others might have to go somewhere else (with
respect to Java code execution) to have their finalizers run).
> >> - Look at other types of gc: is generational gc useful for Java?
> >
> >Without having either a copying/compacting collector, I don't know right
> >now...
>
> I hadn't read about HotSpot when I asked my question -- Sun certainly seem
> to think generational is good.
LispMs used to do this to great effect.
> >> 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.
> >particular
> >attention to the brief bits about how Lisp Machines availed themselves of
> >the
> >special virtual memory hardware to increase performance (I do not have the
> >book
> >with me at work, but I recall finding some of these bits via the index).
> In
> >particular, I hope that we can scan pages BEFORE they have to get paged
> out,
> >as
> >part of the "regular" paging process, and reclaim instantly those pages
> >which
> >only contain garbage, and thus avoid the overhead of "throwing the page
> over
> >the
> >wall" and sleeping any threads at all. This is supposed to be a Really Big
> >Win.
>
> 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.
> >I have other GC-related URLs, too, if you are interested...
>
> One of the best sources I've discovered (only in the last day or two) is
> ftp://ftp.cs.utexas.edu/pub/garbage. bigsurv.ps is a survey of gc
> techniques - it covers a lot of the same ground as the Jones' book - and
> allocsrv.ps covers heap management.
Yeah, I've read those, too. Lots of useful stuff in there. Too bad not
many of the GC/DMA experts seem to agree with one another!
> Finally, a word of warning: what I've currently written is in C. This is for
> two reasons:
>
> 1) I've never written any C++
> 2) I intended to try integrating it with Kaffe for testing purposes. (I'm
> not sure this is relevant now.)
>
> I'll carry on in C until it's up and working. Then I'll try rewriting it in
> C++ -- should be a good way to learn ..
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.
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...
> Again, thanks for the warm welcome.
Looking forward to working with you...
-jm
--
==== John Morrison
==== MaK Technologies Inc.
==== 185 Alewife Brook Parkway, Cambridge, MA 02138
==== http://www.mak.com/welcome.html
==== vox:617-876-8085 x115
==== fax:617-876-9208
==== [EMAIL PROTECTED]
_______________________________________________
Kernel maillist - [EMAIL PROTECTED]
http://jos.org/mailman/listinfo/kernel
