Re: OPEN Specification
Etienne, Some words about your example. OPEN doesn't rely on any particular object layout, but tries to define functional interface for object access purposes. Open_Managed_Object_Handle is used to access this functionality from the components other than VM Core. In order to eliminate performance degradation in such overhead, OPEN defines: - Functions that JIT-compiled code calls during its execution (So called Helpers in OPEN) for quick access to objects from the managed code, - Java methods that interact with the managed code of Java class libraries (ObjectAccessors) for quick access from Java API They could be even inlined in managed code thus eliminating any modularization influence. So, any reasonable object layout could be used in OPEN compatible VM implementation, including bidirectional one. Thanks, Andrey On 5/29/06, Etienne Gagnon <[EMAIL PROTECTED]> wrote: Hi Anton, Are you proposing that all Harmony JVMs must abide by the OPEN proposal? If yes, I think that some process has to be put in place to present and discuss each of this proposal's part, and dedicate time to do so. IMO, I don't think that everyone (in the JVM sub-communityof Harmony) can simply read through this proposal and be able to make an enlightened decision about it. I think that each point would gain much from being presented along the motivation behind it. For example, would your OPEN proposal work with a bidirectional object layout, without incurring prohivitive performance costs? [Just asking, I didn't have time to read through all of it...] Of course, this is only an opinion. :-) Etienne - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: OPEN Specification
Etienne, I didn't mean that every Harmony JVM should follow OPEN interface. It is not necessary to implement but maybe JVMs can benefit from following it (or any kind of standard interface accepted by the community). It is just a proposal with some simple ideas behind it: First, JVM should be modular. Second, those modules should have standard interfaces (and therefore, be reusable in other VMs). If you don't agree with this approach or have any other thoughts about the proposal - please share it with the community - your opinion and your experience is valuable. I believe this document was made so large not with the intention that nobody would read it but just because of the complexity of problem and an attempt to clarify all issues :) -- Regards, Anton Luht, Intel Middleware Products Division On 5/29/06, Etienne Gagnon <[EMAIL PROTECTED]> wrote: Hi Anton, Are you proposing that all Harmony JVMs must abide by the OPEN proposal? If yes, I think that some process has to be put in place to present and discuss each of this proposal's part, and dedicate time to do so. IMO, I don't think that everyone (in the JVM sub-communityof Harmony) can simply read through this proposal and be able to make an enlightened decision about it. I think that each point would gain much from being presented along the motivation behind it. For example, would your OPEN proposal work with a bidirectional object layout, without incurring prohivitive performance costs? [Just asking, I didn't have time to read through all of it...] Of course, this is only an opinion. :-) Etienne Anton Luht wrote: > Hello, > > I would like to try to draw attention to the OPEN proposal again. It > was published about two weeks ago and produced a very small response > in the community. This interface is very important, because if it is > accepted, it will become a base of (many?) Harmony VMs. > > For example, one of the current limitations of OPEN interfaces is that > Component Manager loads all components at startup and there's no > possibility to change a component (for example, Garbage Collector) > later. Is it OK for everyone? Maybe someone foresees problems with > such approach? > -- Etienne M. Gagnon, Ph.D.http://www.info2.uqam.ca/~egagnon/ SableVM: http://www.sablevm.org/ SableCC: http://www.sablecc.org/ - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[OPEN] what to start with? (was Re: OPEN Specification)
On 5/30/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote: Etienne Gagnon wrote: > Hi Anton, > > Are you proposing that all Harmony JVMs must abide by the OPEN proposal? I won't attempt to speak for Anton, but IMO, "no". Right now, any JVM that works w/ Harmony classlib must simply support the class library's virtual machine interface. Let's think of the proposed OPEN spec as a starting point for the discussions about the modular JVM concept, I guess nobody assumed every JVM must abide by it. However, those VM's which are OPEN compliant would probably benefit at some point from the ability to share the components between each other. > If yes, I think that some process has to be put in place to present and > discuss each of this proposal's part, and dedicate time to do so. IMO, > I don't think that everyone (in the JVM sub-communityof Harmony) can > simply read through this proposal and be able to make an enlightened > decision about it. I think that each point would gain much from being > presented along the motivation behind it. Yes, I think that we'll need lots of discussion around this proposal. One possible approach to the discussion process could be to pick up some simple part of VM (how about class loader?), and then try to compare the existing interface for that part in DRLVM and SableVM. From this comparison we could build up a first OPEN interface for this part, and then extend it to some bigger component, then go to other parts, consider other VM's e.t.c. until we get the whole picture. How does that approach sound? BTW, does SableVM assume some component/pluggability model around it? It would be interesting to see how far is it from the proposed OPEN concepts, what works in the OPEN specifically for SableVM and what doesn't, e.t.c. Thank you, Andrey Chernyshev Intel Middleware Products Division In the future, can we prefix subject lines related to this with [OPEN] or such so poeple interested in the subject can easily identify threads related to it? geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: OPEN Specification
Etienne Gagnon wrote: Hi Anton, Are you proposing that all Harmony JVMs must abide by the OPEN proposal? I won't attempt to speak for Anton, but IMO, "no". Right now, any JVM that works w/ Harmony classlib must simply support the class library's virtual machine interface. If yes, I think that some process has to be put in place to present and discuss each of this proposal's part, and dedicate time to do so. IMO, I don't think that everyone (in the JVM sub-communityof Harmony) can simply read through this proposal and be able to make an enlightened decision about it. I think that each point would gain much from being presented along the motivation behind it. Yes, I think that we'll need lots of discussion around this proposal. In the future, can we prefix subject lines related to this with [OPEN] or such so poeple interested in the subject can easily identify threads related to it? geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: OPEN Specification
Hi Anton, Are you proposing that all Harmony JVMs must abide by the OPEN proposal? If yes, I think that some process has to be put in place to present and discuss each of this proposal's part, and dedicate time to do so. IMO, I don't think that everyone (in the JVM sub-communityof Harmony) can simply read through this proposal and be able to make an enlightened decision about it. I think that each point would gain much from being presented along the motivation behind it. For example, would your OPEN proposal work with a bidirectional object layout, without incurring prohivitive performance costs? [Just asking, I didn't have time to read through all of it...] Of course, this is only an opinion. :-) Etienne Anton Luht wrote: > Hello, > > I would like to try to draw attention to the OPEN proposal again. It > was published about two weeks ago and produced a very small response > in the community. This interface is very important, because if it is > accepted, it will become a base of (many?) Harmony VMs. > > For example, one of the current limitations of OPEN interfaces is that > Component Manager loads all components at startup and there's no > possibility to change a component (for example, Garbage Collector) > later. Is it OK for everyone? Maybe someone foresees problems with > such approach? > -- Etienne M. Gagnon, Ph.D.http://www.info2.uqam.ca/~egagnon/ SableVM: http://www.sablevm.org/ SableCC: http://www.sablecc.org/ signature.asc Description: OpenPGP digital signature
Re: OPEN Specification
Hello, I would like to try to draw attention to the OPEN proposal again. It was published about two weeks ago and produced a very small response in the community. This interface is very important, because if it is accepted, it will become a base of (many?) Harmony VMs. For example, one of the current limitations of OPEN interfaces is that Component Manager loads all components at startup and there's no possibility to change a component (for example, Garbage Collector) later. Is it OK for everyone? Maybe someone foresees problems with such approach? -- Regards, Anton Luht, Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: OPEN Specification
primitive types: getByte, getDouble,setBoolean >> 3.Operations over arrays of primitive types: getChar(char[] buf,..) >> 4.Search operations: findFirstDiff, findFirstDiffReorder >> >> 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* layer, >> Java*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 <[EMAIL PROTECTED]> 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 >> >> > -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: OPEN Specification
Hello, Rana, Thanks a lot for your comments to make me clear. On 5/14/06, Rana Dasgupta <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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: > > 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 > > 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* layer, > Java*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 <[EMAIL PROTECTED]> 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 m
Re: OPEN Specification
t; 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* layer, >> Java*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 <[EMAIL PROTECTED]> 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 >> >> > -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: OPEN Specification
ctly without copying the buffer content from the native to the Java* layer, Java*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 <[EMAIL PROTECTED]> 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
Re: OPEN Specification
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: 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 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* layer, Java*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*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 <[EMAIL PROTECTED]> 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
OPEN Specification
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
