Hi George (and others);
[EMAIL PROTECTED] wrote:
> [GAM] Hmm.. plenty of warnings about doing arithmetic with void*.
> I'll sort them out.
Yeah, this particular embarrassment is my fault, not Todd's. It worked, so I
focussed upon new functionality, not cleaning it up. If you have already done
so, please let me know. If not, this would be a good time to also put in Robert
Fitzsimons' (Hi, Robert!) code to enable booting via GRUB (I seem to recall
that, amongst the worst offenders in generating warnings, was the code which
looked for the Etherboot-specific data structures located in various bits of
memory...)
> [GAM] I propose to put the gc code in a separate directory:
> common/nativecode/gc. How does that sound? It's currently in
> common/nativecode, but it bloats that directory somewhat. Now I've just got
> to sort out the accursed makefile :-(
OK. Works for me. Sorry about the makefile trouble. If there's a better way
to do this, I'd sure be interested... I think we have similar problems in the
bytecode directory, in that we have no platform-specific bytecode files (e.g.,
VGA driver) yet.
Hmm... this also brings up the issue of debugging this stuff under UNIX. Should
we try and build the host version with libVGA (or whatever it's called)?
libGGI? I don't know either of them. Anybody out there with any ideas ("Hi"
and "help," [EMAIL PROTECTED] guys -- check out recent kernel postings about a VGA
driver working)...
> [GAM] I'll see if I can work out a modified interface for jbheap
> earlier than the 14th. It needs to allow the rest of JJOS pass back
> information about roots and kick off an on-demand garbage collect, in
> addition to jbheap's current allocate functionality.
Fabulous! I look forward to this with great anticipation. It'll enable us to
keep jjos+decaf running long enough to be interesting!
> > > 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?
> >
> [GAM] But if I'm also doing gc for the C++ code, and the only ref
> to some C++ heap object is in a local variable somewhere on the native code
> stack, I'll need to find that ref. Otherwise that object is gone (or rather,
> the memory for it doesn't get marked as in use and could end up being reused
> for something else, which in turn could lead to some very nasty bugs).
The location of the sole native-code stack (sole because we're not doing
multithreading yet in the kernel) is easily-computable at the point where you
need to scan for the GC roots. Right now (I don't have the sources in front of
me, so this is from memory), I think there's a magic value that gets crammed
into the stack pointer register (2MB?), but I don't think this is saved into any
easily-accessible-from-C++ variable, although the heap-initialization code
*does* avoid stepping on the stack. Sorry... I can fix this... Really!
-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
_______________________________________________
UI maillist - [EMAIL PROTECTED]
http://jos.org/mailman/listinfo/ui
