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 Sun, 14 May 2006 09:39:23 GMT
Hello, Rana,

Thanks a lot for your comments to make me clear.

On 5/14/06, Rana Dasgupta <rdasgupt@gmail.com> wrote:
>
>
> >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.Socketimplementation.
> Classlib >programmer still has to write native code to implement Socket
> function. And I also think it's
> >classlib programmer's responsibility
>
> The idea is that the VM provides some standardized functionality through
> VM
> and Platform accessors. How much that is, is part of the standard
> definition
> that we need.


Agree, and  I'm also interested in the standard API definition criterias.
:)


I am not completely  sure what you mean by the "classlib
> programmer's responsibility". It is true that the classlib programmer will
> need to implement whatever is not provided by the standardised accessor
> components.


Understood.

Thanks,
> Rana
>
> On 5/12/06, Andrew Zhang <zhanghuangzhu@gmail.com> wrote:
> >
> > 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
> >
> >
>
>


-- 
Andrew Zhang
China Software Development Lab, IBM

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