harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Ellison <t.p.elli...@gmail.com>
Subject Re: [arch] VM/Classlibrary Interface (take 2)
Date Mon, 05 Sep 2005 09:59:28 GMT
Mladen Turk wrote:
> 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.

I'm trying to reconcile the similarities you draw between a light-weight
native call and any inlined method?

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

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

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

Of course, a reader and writer of heap memory has to be aware of GC too.
 It would have to prevent or account for memory movement.

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

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


> Regards,
> Mladen.


Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.

View raw message