Hi Todd;
Todd L. Miller wrote:
>
> > (2) I have made moved duplicative code from the global functions
> > into methods of the various classes (java_thread, java_class, frame).
>
> Increasing their efficiency as well, I'd imagine.
Well, I don't know that it's any more efficient (there is now subroutine
overhead), but it shrinks the size of the executable (a good thing), and, since
we'll probably be revisiting the initialization phase (when we get native
threads), it'll mean we've only got to muck about in one place. (Also,
hopefully, it's easier to understand for new code-readers/contributors.)
> > (3) I propagated the active thread throughout the class loading, linking,
> > preparing, and resolving steps because I thought I could, at this stage, and
> > prior to having native threads, handle this entirely WITHOUT keeping context in
> > native stacks. This would enable the scheduler to know which thread was
> > running, and it would enable a debugger to know, and it would enable pre-emption
> > of static initializers. I was wrong, wrong, wrong. I do not know whether I
> > should back these changes out, or leave them in (they don't seem to break
> > anything).
>
> They might be useful later on (viz: exceptions). But why doesn't
> propogating the thread throughout allow for pre-emptive static
> initializers?
It's a necessary (but not sufficient) condition for pre-emptive initializers.
There were some complications. You know how the PC value is
incremented/decremented at several places in the runOpcode/runInvoke methods?
Well, in order to pre-empt, I'd have to absolutely back out of the instruction
completely so as to enable a clean restart, and the PC is mucked about with in
literally dozens of places (and I would have had to chase them all down and
verify that I hadn't broken anything). So, I wimped out.
The threads are also created pretty far down in the bowels of the resolution
machinery, and I would've had to "throw" (conceptually, anyways) all the way
back up the native stack, and catch it in an utterly clean way (e.g., don't
create garbage, although a Boehm-whatever GC would help), and back out of the
offending opcode, and then make sure all the state machinery of the various
classes (java_class, java_thread, class_loader, etc.) were all restartable.
Maybe also "wait" the current thread on the initializer thread. Seemed like too
big a job at this point. So, more reasons to wimp out. Alternatively, we can
punt on this until we get native threads, and then just keep the context on the
native stack.
> > (4) In perusing this machinery, I think there are some further changes I might
> > like to make with respect to how classes are known to be
> > resolved/linked/whatever, and, in specific, when the initializer threads get
> > spawned (right now they get spawned really early, but don't get executed, so
> > there are a LOT of dormant threads lying about). I shall discuss these with
> > Todd after I commit the merged changes.
>
> Right now, threads don't cost a whole lot more than frames do, and
> they're a little more convenient. We could get away with nothing more
> than a pointer to the opcodes, but that's probably inflicting unnecessary
> pain on ourselves.
Fine -- the changes I was talking about are (more or less) to address those
resolution concerns (especially when we get user-provided class loaders).
> > (6) I have not (cannot?) build the latest Java source successfully. Todd, would
> > you please be so kind as to put your latest successful zipfile (compressed, of
> > course) somewhere I can FTP it from? Then I can test my merged changes before I
> > commit them so as not to break anything. It would also help if you put a
> > logfile (obviously, host build only) showing me what output to expect.
>
> Sure thing. Has anyone else had problems building the latest java
> sources?
I confess I haven't tried to rebuild them yet since you all have reduced
dependencies upon AWT (I just got as far as I described in my email this
morning, and haven't gotten any further).
Later!
-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
