John, Todd and all --
I hereby promise to make my mails clearer in future! To elaborate:
> > [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] The source of the void* warnings is _my_ code (unfortunately). gcc
didn't complain about what I was doing, but g++ does (vociferously). I'll
sort them out before handing the code over -- there's so much noise from
spurious warnings, it's all too easy to miss the important stuff. I only got
2 or 3 warnings from the jjos code from CVS.
BTW, I'd be very interested in booting via GRUB -- I only have the one PC,
so Etherboot is not an option.
> > [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.
>
[GAM] The "accursed" was meant to apply to make files in general, not the
jjos ones. I'm not in any way an expert on makefiles, so I don't have any
suggestions for improvements. (My lack of expertise is probably why I end up
cursing makefiles - though I doubt anyone actually loves them, do they? ;-)
> 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!
>
[GAM] That sounds good, thanks.
I've just been rereading bigsurv.ps and come across a couple of potential
unpleasantnesses:
1. Do the kernel or decaf ever only have a handle on an object by the middle
(as it were) while maintaining the necessary info to find the head of the
object again. eg it might have pointer into element 100 of a 150 element
array, but keep the offset from the start (100) in some other variable so
that the start of the object can be rediscovered. The GC at the moment will
only mark objects for which there is a pointer to the head somewhere, so
will fail to mark the example array as in use. If necessary, I think I can
change it so that pointers to the middle of an object lead to that object
being marked. I'd prefer not to though, cos it will make the mark phase more
inaccurate and slower.
2. A similar problem, but at the C++ compiler level. bigsurv.ps claims that
some compilers, particularly when doing heavy optimisation, perform
algebraic transforms / bit ops on pointers which can disguise them or make
them temporarily not point at the head of the object (or even, I suppose,
into the heap). I have no idea if g++ does this, but it is something to be
aware of as it will break a conservative garbage collector.
-- George
_______________________________________________
Kernel maillist - [EMAIL PROTECTED]
http://jos.org/mailman/listinfo/kernel
