Hi;
Todd L. Miller wrote:
> Maybe an example is necessary: I'm three frames deep in a JVM
> call, say I'm doing getClass(), which throws a NoSuchClassDefinition
> exception. I /can/ call thread::throwException( NoSuchClassDefinition ),
> and all the java-specific things would happen, but, here's the kicker:
>
> case bc::some_bytecode:
> ...
> jc = getClass();
> ...
> op_stack.push( jc->fields[x] );
> break;
>
> ...
> return true;
Um, I think you *have* to check the results, because you cannot afford to
dereference something bad. We're in OS-land (a.k.a., systems programming land),
not application-land. There are no guard-rails (a.k.a., memory protection
mechanisms). We do not want to become (in)famous for our version of the BSOD
(even though I am sure we could pick a more, well, tasteful color, and, perhaps,
put a more interesting text up on the screen like "Hey, at least you didn't PAY
for this!").
However, if one adopts a Lisp-ish functional programming style, in which
routines almost always are structured:
foo *bar::baz(quux *)
{
if (!quux)
{
return(NULL); /* Or perror, etc. */
}
else ...
}
it's not so bad. It will also almost always compile to a single conditional
jump (OK, well, maybe a load followed by a conditional jump), and if the
compiler is smart enough to make it a jump-if-zero (condition codes are usually
set upon a load to a register), then it'll often only take a single machine
cycle because there will be no pipeline flushes because the jump will not often
be taken. (On the other hand, if the compiler is stupid but predictable, you
can change the polarity of the check, and achieve the same goal.)
> How does the code AFTER the getClass() call know NOT to push
> something on the op_stack after getClass() throws an exception? I do NOT
> want to rewrite every single function call in the JVM to (a) check all of
> /its/ calls for exceptions and abort back to runOpcode() (which will in
> turn, have to abort) and (b) return true or false depending on if an
Throwing native exceptions is tricky, and interacts with the memory reclamation
stuff (although, like I said before, a conservative GC can help).
> exception was thrown or not. It's doable now, but it won't be in the
> future: native methods that throw exceptions need to be handled (unravel
> the native stack same as I mentioned in the last email for intra-JVM
> throws); the native portion of the class library (classpath?) is where you
> can't get around exception-handling in native methods. (Rewriting the
> classlibrary is a heroic effort and Not The Right Thing To Do, either, I
> think.)
Now, I'm a little out of my depth here, but here goes (somebody correct me if
I'm wrong) -- it is my understanding that native methods are inherently
non-portable, so we have some freedom to define how they should be
compiled/written (if, in fact, we support them in the medium to long term -- we
certainly won't support them in the short term). Furthermore, given that we
currently envision no memory protection (e.g., separate address spaces for
native methods), allowing native methods is an huge invitation to Bad Things
like BSODs, and viruses, etc.
> It is difficult but doable to arrange for the native exception to
> be converted into a java exception and have the necessary things happen to
> the thread's data structures -- the tremendous difficulty is in aborting
> the rest of the call(s), all the way back to where the scheduler can move
> on to the next timeslice. It seems to me that we'd be re-writing C++'s
> exception codes by hand; further, it seems evident to me that the Right
> Way to handle exceptions in native code is with native exceptions, which
> would all be trapped and converted in runOpcode().
>
> Am I being clear about the problem here?
When you say "native exception," do you mean C++ "throw," or vanilla-C reference
to memory that ain't there (a.k.a., bus error, address error, memory error)?
-jm
p.s., you want me to stop putting your specific email address on the "To" list
so you get the mail slower, but get only one copy?
--
==== 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
