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, Tim > Regards, > Mladen. > -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK.
