harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew Zhang" <zhanghuang...@gmail.com>
Subject Re: OPEN Specification
Date Sat, 13 May 2006 02:56:16 GMT
Hello, Rana

I took a quick view on the document, and I have some questions on Chapter 6.

Let's take 6.9.1 "A.NM ACCESS TO NATIVE MEMORY" as example:

<cite>The MemoryAccessor interface includes the following function groups:
1.Memory allocation and de-allocation: malloc, realloc, free
2.Operations over primitive types: getByte, getDouble,setBoolean
3.Operations over arrays of primitive types: getChar(char[] buf,..)
4.Search operations: findFirstDiff, findFirstDiffReorder</cite>

For full description, please refer to "
http://issues.apache.org/jira/browse/HARMONY-459" or [1].

I wonder who has the responsibility to provide such native-related and
platform-independent interfaces to java classlib programmer?

No doubt "OS Portability Layer" provides platform-independent interfaces,
e.g, portable_malloc or portable_free. Then shall classlib
programmer write native code to implement high-level functions such as
"findFirstDiff" and invoke them via JNI mode? or shall VM provide such
high-level functions and classlib programmer only need call mem.findFirst?

I think Harmony classlib follows the former way currently.
As my understanding of the document, classlib programmer will avoid writing
native code directly, and invoke corresponding interfaces defined in VM. If
I'm right, I think it's very hard for VM to provide so many native-related
APIs for classlib programmer.
For example, java.net.Socket implementation. Classlib programmer still has
to write native code to implement Socket function. And I also think it's
classlib programmer's responsibility. I don't know whether OPEN spec would
plan to provide such interfaces? IMO, ByteBuffer example and Socket example
is on the same level programming, and the real implemenation native
code should exist on the same level code repository, e.g, both in VM or
classlib native-src. Am I missing something? Would anyone clarify my
confusion?

Thanks a lot!

[1]
The java.nio package defines the buffer classes, which are used throughout
the native input and output (NIO) APIs. Buffers can be *direct* or *
non-direct*. Given a direct buffer, the system performs native I/O
operations directly without copying the buffer content from the native to
the Java* <file:///F:/clear/opendoc/HLD.html#*> layer,
Java*<file:///F:/clear/opendoc/HLD.html#*>arrays. A direct byte buffer
is created by using the
allocateDirect() factory method, which is often mapped directly to the
system or the C library allocation methods, such as malloc() and
VirtualAlloc(). Direct access is provided by using native methods, which
increases the overall cost of accessing such data from the
Java*<file:///F:/clear/opendoc/HLD.html#*>layer. The memory accessor
mechanism encapsulates all required operations on
the native heap, and provides room for future optimizations by using
in-lining or other JIT techniques. The MemoryAccessor interface includes the
following function groups:

   - Memory allocation and de-allocation: malloc, realloc, free
   - Operations over primitive types: getByte, getDouble,setBoolean
   - Operations over arrays of primitive types: getChar(char[] buf,..)
   - Search operations: findFirstDiff, findFirstDiffReorder


On 5/13/06, Rana Dasgupta <rdasgupt@gmail.com> wrote:
>
> Hi,
> Alongside the DRLVM codebase, here is a contribution from Intel of an OPEN
> ( Open Pluggable Extensible Interface ) specification for JVM and
> Classlibrary-VM Interface development.
>
> URL: http://issues.apache.org/jira/browse/HARMONY-459
>
>
> We hope that this spec will promote modular component oriented development
> of core pieces eg., the garbage collector, core VM, Just In Time compiler,
> ClassLibrary-VM Interface etc. That it will provide a framework for
> developing and interconnecting alternate component implementations through
> standardized interfaces.
> The DRLVM codebase does not quite confirm to the OPEN spec at this point,
> though that is the final intent. The OPEN specification is also an idea,
> and
> by no means complete. We need the community's help in giving the final
> form
> to this specification, defining the header files that map to the
> specification, and then in taking the Harmony implementation forward to be
> OPEN compatible.
>
> Thanks,
> Rana Dasgupta
> Intel Middleware Development
>
>


-- 
Andrew Zhang
China Software Development Lab, IBM

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message