Re: OPEN Specification

[Arzhan Kinzhalin]

Hi Tim,

On 5/14/06, Tim Ellison [EMAIL PROTECTED] wrote:

First a caveat that I have only read the OPEN document through quickly
so far, so apologies if this is off-base.  I do intend to go back an
read more thoroughly.

Is it fair to generalize the Accessors proposal to say that there should
be internal APIs in the 'right place' within the class library to allow
a good range of OS/CPU/VM architectures to optimize their implementation?


Yes, this is a good abstract of the intention. The accessors are there
to provide secure access to functionality hidden by Java design, but
needed to implement some parts of the API (like NIO, graphics etc.) in
efficient manner. It is also an attempt to standardize the API
necessary to access underlying functionality for Harmony community so
that the class library could solidly rely on a VM and work together
well.

Security is one of the most important aspects of the accessors.
Neither do we not want to expose a security hole in the VM nor do we
want to sacrifice performance by having massive security checks in the
accessors implementation.

Thanks,
Arzhan


The document describes some ideas about how the optimizations will occur
(singleton classes, JIT recognized methods, etc.) but I just want to
back-up a moment to check the rationale before looking at the solution.

Regards,
Tim



--
Arzhan
Intel Middleware Products Division



Rana Dasgupta wrote:
 Hi Andrew,
   Thanks for your comments and interesting feedback. The ideas in this spec
 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
 pure
 form...some degree of pollution creeps into an implementation when one
 tries
 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
 out
 of this...

For context, this proposal sees the accessor( platform and VM
 ) mechanism as a tool to facilitate Classlibrary development in Java( as
 you
 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
 via
 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-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?


  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
 writing
 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
 definition
 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 [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:

 citeThe 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 

Re: [classlib] performance tips

[Arzhan Kinzhalin]

Mikhail,

It's great that we consider performance of the API lib. Let me give
you just a couple of things to keep in mind in addition to your
observation.

Firstly, it all depends on the VM implementation which executes the
code. For modern VMs, bytecode is far from what is actually executed,
unless you force a VM to interpret. A JIT compiler may eliminate
exessive bytecodes. For instance, it would be natural for a VM to
allocate space for an object and fill it with zeroes which yeilds
Java's default field values. JIT may rely on it and throw away
explicit initialization to default values.

Secondly, even if both allocation mechanism and JIT are not very smart
or if the VM interprets the bytecode, consider the case when test is
only created once during application lifecycle. Impact would be about
zero. On another hand, if creation of test objects takes, say, 70% of
the application execution time, optimization of the constructor would
give dramatic improvement.

So, your suggestion could give from zero to a few tens percent boost.
In order to determine how much exactly, we need a context. Context is
always required when performance is questioned.

Thanks,
Arzhan
Intel Middleware Products Division

On 3/10/06, Robin Garner [EMAIL PROTECTED] wrote:
 Mikhail Loenko wrote:

 Hello
 
 May be it is obvious and everybody knows it from babyhood, but anyway...
 
 Everybody knows that this two examples of code do the same:
 class test {
 public Object field = null;
 }
 
 and
 
 class test {
 public Object field;
 }
 
 But if you disassemble these two classes, you'll see that the first example
 has a 6 instruction constructor:
 
0: aload_0
1: invokespecial #1; //Method java/lang/Object.init:()V
4: aload_0
5: aconst_null
6: putfield #2; //Field field:Ljava/lang/Object;
9: return
 
 while the second one has only 3 of them:
0: aload_0
1: invokespecial #1; //Method java/lang/Object.init:()V
4: return
 
 So having explicit assignments of default values slows down constructor.
 
 Thanks,
 Mikhail
 
 
 Mikhail,

 Is this something a bytecode compiler should be able to optimize away,
 or is there something in the JLS that requires the additional bytecodes
 to be generated ?  Have you measured the impact (I suspect it is
 negligible).

 cheers

Re: Bug-to-bug compatibility - first issue

[Arzhan Kinzhalin]

 URLClassLoader can't load this class because searchURLs parameter in
 findClassImpl does not contain current directory and includes only
 p:/. So, IMO problem is inside VM kernel classes.

 What do you think we should do with this issue?

It actually has corresponding bug report [1] which provides some
background to the story.

Names and behaviour of command-line arguments is not a part of the
spec. It's just that everyone follows well-established conventions. In
this case it would seem natural to copy the behavior.

[1] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4515984

--
Arzhan
Intel Middleware Products Division