Re: Classpath build process and VM-specific issues

[Stuart Ballard]

Archie Cobbs wrote:
> > Okay, perhaps we need to agree what platforms we care about.
>
> Here are my votes... 
>
> - We don't care about platforms that don't have 8 bit bytes or where
>   typeof(jchar) != signed char.
>
> - We don't care about platforms where 'jlong' is insufficient to hold
>   VM private data. E.g., on a platform with 128 bit pointers, then
>   the VM must use a hash table or something to derive the actual
>   pointer (or whatever it needs). I.e., we deem 64 bits enough to
>   uniquely describe all unique VM-private data structures.

I'd like to see some qualification of "don't care". Seems to me that 
there are multiple levels of caring:

1) "Normal" VMs on "Normal" platforms. Use JNI, don't have any 
weirdnesses about the sizes or types of JNI data types.

2) "Unusual" VMs: Things where JNI-centric assumptions don't hold true. 
For example, IKVM and Jaos(?) don't use JNI at all within Classpath, and 
their natural "pointer" type is just a normal object reference. gcj with 
CNI also falls into this category.

3) "Unusual" platforms: Any real and existing platforms to which a 
Classpath port is a real possibility, but violate one of the two 
criteria above, or other normally reasonable assumptions about the 
behavior of the CPU, OS or C compiler.

4) Non-free VMs: generally JDK derivatives that we have no control over 
and are unlikely to change to adopt our practices, or even optimize for 
them.

5) Nonexistent VMs or nonexistent platforms: VMs or platforms that are 
theoretically possible or theoretically permitted by the standards, but 
which never actually occur in any real platform now or in the forseeable 
future, or will never be able to run even a minimal JVM (Z80 or 6502 
chips probably fall into the latter category?)

Seems to me that whatever is adopted needs to take into account the 
existence of types 2 and 3, but it's okay to optimize for performance on 
type 1. I'm not sure that we should invest *any* time worrying about 
types 4 or 5 (although I can conceive of situations where portability to 
type 4 is desirable, it's certainly not the general case *within Classpath*)

The byte array solution has negative implications for, at least, type 2: 
it's generally impossible to round-trip between an object reference and 
a byte[] without a hashtable and serious inefficiency.

The opaque RawData class may have negative performance implications for 
type 1 (does everyone agree on this? hard to tell), which makes it 
undesirable, but it is at least usable on all types (including the ones 
we don't care about).

Nobody yet in this thread has talked about the possibility of just using 
Object references, unless I've missed it. The advantage would be that 
you can store whatever type you like - byte[] or an opaque RawData class 
or a native pointer or anything - the disadvantage would be that the 
native code couldn't be shared when different things were stored there. 
This solution would help type 2 systems (which generally don't share the 
JNI native code anyway) while still allowing the JNI default code to use 
byte[] (or for the flamewar to continue over what it should use ;) )


I think that it's important to draw a distinction between these various 
types of VM, because they have different needs, different performance 
characteristics, and in some cases (like the byte[] solution on type 2) 
can't use one particular approach *at all* - or at least, not without 
severe, orders-of-magnitude-worse performance problems.

Stuart.
--
Stuart Ballard, Senior Web Developer
NetReach, Inc.
(215) 283-2300, ext. 126
http://www.netreach.com/