harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mladen Turk <mt...@apache.org>
Subject Re: [arch] VM/Classlibrary Interface (take 2)
Date Mon, 05 Sep 2005 14:15:57 GMT
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

>>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?


>>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

>>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


View raw message