Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: harmony-dev@incubator.apache.org
Received-SPF: pass (asf.osuosl.org: domain of rdasgupt@gmail.com designates
 64.233.182.187 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references;
        b=DVnEn5m8Q+MusgzifqHji2O42vH0suKaZ6v+SXH/G1dG/cx3EVPLbvnlTyZ3hvUMka+o2qkDqUBIBM/FUOl75yPeeP0lbkCR5cT3D2uI7hs2uy8gN3UmgtqkrZ2cGTvWlctA/hvEwTfabBJ1fay1pFpQgxkurCSvsp1g0KbnaSU=
Message-ID: <51d555c70605131343t27d43d0fgd8d93edc674a8db8@mail.gmail.com>
Date: Sat, 13 May 2006 13:43:57 -0700
From: "Rana Dasgupta" <rdasgupt@gmail.com>
To: harmony-dev@incubator.apache.org
Subject: Re: OPEN Specification
In-Reply-To: <4d0b24970605121956x73118840w568baccbeeccaac4@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_7909_16570997.1147553037710"
References: <51d555c70605121031kfb36ee2q3bc60500447ccbc2@mail.gmail.com>
	 <4d0b24970605121956x73118840w568baccbeeccaac4@mail.gmail.com>

------=_Part_7909_16570997.1147553037710
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Hi Andrew,
   Thanks for your comments and interesting feedback. The ideas in this spe=
c
are certainly open to debate and input from everyone. As we well know,
modularity is a great goal which has many merits...testability, ease of
development, plug and play etc. However it is less easy to achieve in a pur=
e
form...some degree of pollution creeps into an implementation when one trie=
s
to optimize on other goals like performance, footprint etc. I was hoping
that we could see this submission as a strawman for how one could
potentially modularize VM development. With input from knowledgeable people
in the community, maybe a standard for modular VM development can evolve ou=
t
of this...

    For context, this proposal sees the accessor( platform and VM
) mechanism as a tool to facilitate Classlibrary development in Java( as yo=
u
obeserved below ). They are a set of singleton classes that class libraries
instantiate securely through a factory mechanism. Their implementation is
provided by the VM. Their default fully portable implementation could be vi=
a
JNI, however there is potential for performance optimization...eg., once
instantiated, the per invocation security could be relaxed, the JIT could
recognize and aggressively inline them, etc.
  I have tried to answer some more of your questions inline....

>I wonder who has the responsibility to provide such native-related and
>platform-independent interfaces to java classlib programmer?
>...Then shall classlib programmer write native code to implement high-leve=
l
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?


  These are VM components. The idea is that the VM provides them and the
Classlib programmer writes less native code.

>As my understanding of the document, classlib programmer will avoid writin=
g
>native code directly, and invoke corresponding interfaces defined in VM.

That is correct

>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

The idea is that the VM provides some standardized functionality through VM
and Platform accessors. How much that is, is part of the standard definitio=
n
that we need. 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.

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-relate=
d
>
> APIs for classlib programmer.
> For example, java.net.Socket implementation. Classlib programmer still ha=
s
> 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 woul=
d
>
> 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 throughou=
t
> 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
>
>

------=_Part_7909_16570997.1147553037710--