Tim Ellison wrote:
By the design, those kind of functions/methods will not be able
to either allocate or throw java objects.
Inlining doesn't impose any such restriction upon object creation.
I know, but the point is that the overhead for calling that kind
of native method should not require making a 'make a rocket launch
procedure' :).
Since those kind of 'light-weight' calls will lack the JNIEnv
call argument, neither exceptions nor objects creation will be
possible.
Their sole purpose would be to extend the existing methods with
native calls, leaving to the java part to deal with any kind of
object creation. In general you may think of those calls simply
as extension to the CPU machine code extensions,
So are you proposing a light-weight call that has a restricted set of
operations on heap memory, say to avoid allocations?
Right.
OTOH some calls can even be threated the same way as atomic calls
to any CPU CISC like instruction (like array copy), thus blocking
the GC. In that case the call to the native would be something
like calling the 'synchronized method'.
I'm puzzled again, calling a synchronized method won't block GC.
Right, my bad. Any non atomic object passed to the call should be
auto referenced, because the system call may block forcing a thread
yield.
All that would give the overall OS integration speedup for most of
the standard classpath things, because instead throwing the exceptions
from native, the java part of classpath would be responsible for that,
leaving the native to behave like OS abstraction layer.
While I don't think you'll see an overall classlibrary speedup by
throwing exceptions in Java code rather than native code, I do think it
is a good design point to write more of the classlibrary logic in Java
rather than in native code. Today the JNI crossing overhead can impose
a runtime cost that requires library logic to be written in natives that
would have been better written in Java if the overhead were smaller.
The problem is that when calling exiting native calls you have to
'prepare' the JVM for such a call. Since any JNI call can do almost
any kind of either object usage or creation, that process makes most
of the JNI calls that don't need such a option much slower.
Writing as much classpath code inside Java and using light weight
calls that don't require such a lengthy procedures before and after
each call to the native would give much higher overall performance
thought.
Regards,
Mladen.
