On Wednesday 09 August 2006 20:52 Geir Magnusson Jr wrote:
> So - lets start with this -
>
> what are the aspects of the DRLVM codebase that make it not work on
> Win2k, what are the alternatives, and what are the costs to those
> alternatives?
Ok going technical from here. The vectored exception handling API (as opposed
to older structured exception handling mechanism which exists on w2k) was
used when we tried to implement some simple an invocation API implementation
to have a separate launcher. The typical launcher scenario looks like this:
JavaVM *vm = JNI_CreateJavaVM(...);
JNIEnv *jenv = vm->GetEnv(...);
jclass clss = jenv->FindClass(...LAUNCHER_CLASS_NAME...);
jmethodID mid = jenv->GetStaticMethodID(...LAUNCHER_METHOD_NAME...);
jenv->CallVoidMethod(clss, mid);
or something similar. When trying to establish hardware exceptions handling
for hardware NPEs, AEs, SOEs, etc it is necessary to set up a handler for
them right in the call to JNI_CreateJavaVM or GetEnv because all subsequent
calls may execute Java code which may cause the exception.
It is similar to establishing a signal handler for the process, on Linux there
are no problems with signals, but windows implements signals POSIX API in an
ugly unusable way.
The SEH syntax allows to guard a block of code by __try{} __catch{} (MS C++
syntax exgension) syntax and catch hardware exceptions inside of __catch. But
this has a limitation that handling works only on the guarded block. In the
above code example using SEH would require to guard every JNI call by SEH
block to catch hardware exception in any function which may potentially
execute Java code. And if we want a crash handler it is better to guard
blocks which execute *any* code. SEH syntax doesn't allow to do this since
launcher is generally a user code which uses invocation API.
So VEH was really a solution when we found it. I don't really know about
alternatives for w2k. Not that I know much about windows API but we did some
research to find VEH and I don't remember finding any alternatives except for
signals (see above).
There may be of course undocumented API functions (Microsoft is known for this
kind of stuff) which other Java implementations use. There may be also a
possible way of hacking TLS directly since SEH handlers reside on fs:[0]
address, but this may also interfere with C++ handlers from the launcher
because they are implemented through this address as well and if the calling
process uses C++ exceptions (e.g. a web browser) we may crash it.
Do any windows gurus know a solution for w2k?
--
Gregory Shimansky, Intel Middleware Products Division
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
