Weldon Washburn wrote:
Hi Mladen,
I am curious about 'light-weight' native calls for primitive array
type you mentioned below. In the general case, a GC might move the
primitive array while the native method is operating on the array.
Can you tell us how the light-weight interface would deal with this
situation? Does the array need to be pinned before calling the
light-weight native?
Well, those kind of things are exactly the one that need to be resolved.
With light-weight (or what ever we name them) calls, the call to the
native should not differ from calling any other inlined method, and thus
by that bare fact the GC itself would be treated the same way when the
any Java method is called.
By the design, those kind of functions/methods will not be able
to either allocate or throw java objects.
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, but since they
may be a long run, for primitive array access
(by that I mean accessing the raw storage locations inside JVM),
the reference count should take place if required.
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'.
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.
Regards,
Mladen.
