Jim wrote:
> I want to study it a bit more before I put it in though (give me a
> day or two).
No problem.
> As for gcc - people have used MSVC with Kaffe in the past, but I don't
> know of anybody who is currently using it (although one person did
> express some interest in using it). Unfortunately, this change does
> look like it would be very hard to duplicate in another compiler without
> using the gcc feature for getting the address of a label.
You'd probably have to resort to asms to get the same effect in MSVC
(maybe?). (Unless there is a similar address-of-label extension for
MSVC?)
> I guess I'm more concerned that we've increased the size of the
> exception structure on the stack for each JNI method call.
Actually, the exception object has not changed size. That's because
of the "frame" union which uses the same eight bytes for the JNI
version as for the pre-existing interp version.
In any event, the size of those fields are completely dwarfed by the
156-byte (on Linux) JMPBUF stored in every exception handler object.
> Is there any additional benefits in doing so, other than the fact
> that it solves a build time issue (we need to figure out how to
> force the compiler/linker to keep the functions together in the text
> segment)?
The current approach also restricts the exception handling to just the
segment of code between the BEGIN/END macros. Whomever wrote jni.c
put an XXX comment in there saying that the original approach covered
exceptions in pre- and post- code in the JNI functions that shouldn't
have been covered. (Though there is hardly any such code except the
stuff that sets up the exception handler, so that's probably not a big
deal.)
> We could force the compiler/linker to keep all the functions
> together by using GCC attributes and a linker script.
Yep. (Any idea how to get libtool to use a custom linker script?)
Another (horrible) idea I just had would be to put all the JNI
entrypoint functions in the same function and use a goto or switch to
jump to the right bit of code based on an argument, and then provide
wrapper functions around this giant dispatch function that passed the
right argument.... Its portable, but that's the only upside...
A perhaps less horrible idea (though a lot of work) would be to
re-write the jni.c methods to do explicit checks and not use
exceptions.
-Pat
----- ----- ---- --- --- -- - - - - -
Pat Tullmann [EMAIL PROTECTED]
"I'd kill for a Nobel Peace Prize." -- S. Wright
_______________________________________________
kaffe mailing list
[EMAIL PROTECTED]
http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
