Name: pa48320 Date: 12/20/2001


[This problem should be assigned to John Rose ###@###.###,
 it knows about it]
There is currently no way to implement a JDK 1.4 IA-64 compatible VM
because with some issues (described below) with the Unsafe Implementation.

The following is a copy of the email thread describing the problem and
the solution (the email thread was an exchange between John Rose from
Sun & Herbert Czymontek from Oracle):

>
> John,
>
> Good point. Well, having 'long' offsets instead of 'int' offsets and a null
> base address for static fields would indeed solve the problem. Of all the
> solutions mentioned so far this is definitely my favourite.
>
> Sorry, I didn't reply to your earlier e-mails, but I returned from vacation
> just today.
>
> > Moreover, with static fields, it usually is the case that there is some
> > internal VM data structure within 2**31 bytes of the static field.
> > In the case your engineer suggests ("array of the particular field
> > types"), the array itself could serve as a base address to the unsafe
> > reference. Show me a present application with 2**20 static variables,
> > and then I will begin to worry that the 2**31 limit is an issue.
>
> Consider the following case running on a 64-bit architecture:
> Static fields are divided into two groups, references and non-references.
> The references are kept in a Java array allocated on the Java object heap,
> the non-reference fields are kept in a dynamically allocated (malloc'ed)
> array. Let us also assume that we are dealing with a very big continous Java
> heap (giga range) which is mapped into high address space (0x100000000 and
> higer). Now if the malloc heap manager happens to allocate the non-reference
> field array at a low address (0x7FFFFFF or lower) then a 32-bit offset to
> access static fields becomes insufficient.
>
> > Yes, the GC may need help with these base addresses, if they are not
> > already in the GC's heap. (Many newer VMs tend to allocate internal
> > data structures on the same heap as Java objects, reducing
> > fragmentation and providing other advantages.) If the GC does not
> > recognize the base address of the static-holding structures, perhaps
> > it can be made to do so. I understand this is not always desirable.
>
> Well, you've already said it...not desirable.
>
> > (By the way, the documentation states that a value produced by
> > staticFieldBase should not be used in any way other than as an argument
> > to get and put routines. This could be clearer, but since the value is
> > a reference which may go on the JVM stack, it can also be stored in Java
> > variable. We will clarify this in a future rev. of the documentation.)
>
> Excellent point (about the JVM stack) which is yet another argument together
> with the previous one against the current implementation because it will
> require some support from the GC to be tolerant when it encounters these
> 'cookie' objects.
>
> > There are at least two intermediate options between the fall-back
> > position stated above and having the GC be totally aware of base
> > addresses of static-holding structures. One is to reserve a range
> > of 32-bit int values not in use as object offsets, and use them
> > to encode static fields. Suppose the VM never uses negative offsets.
> > Then fieldOffset of a static field would return a negative cookie,
> > and Unsafe.getInt could compile to the equivalent of:
> >
> > if (offset >= 0)
> > return *(int*)( (char*)o + offset );
> > else
> > return ((Class*)o)->getStaticInt(offset);
> >
> > ...where the getStaticInt function is an appropriate VM internal thing.
> > That is, getInt expands internally to a variant getStaticInt which only
> > works for static fields.
> >
> > A second option would be to make the VM's implementation of fieldOffset
> > return INVALID_FIELD_OFFSET for static fields, and require the Java code
> > using Unsafe to watch for such occurrences. This is probably the
> > simplest fix, in conjunction with Ken's suggested change to the
> > reflection code.
>
> You cannot assume that a VM never uses negative field offsets. As a matter
> of fact it is very desirable to use them because this allows for the
> co-location of reference fields in objects. The rule is, e.g. all reference
> fields have negative offsets, all non-reference objects have positive
> objects. Example:
>
> class foo
> {
> int a;
> Object b;
> };
>
> class bar extends foo
> {
> int c;
> Object d;
> };
>
> would result in the following object layout (offsets are just examples):
>
> foo: a offset 8
> b offset -8
>
> bar: a offset 8
> c offset 12
> b offset -8
> d offset -16
>
> This results in good locality for references as well as easy handling of
> references in the GC, etc.
>
> Thanks,
> Herbert.
>
> ----- Original Message -----
> From: "John Rose" <###@###.###>
> To: "Herbert Czymontek" <###@###.###>
> Cc: "Peter J. Allenbach (SUN)" <###@###.###>; "Kenneth
> Russell (SUN)" <###@###.###>; "John Rose (SUN)"
> <###@###.###>; "Michel Trudeau"
> <###@###.###>
> Sent: Tuesday, December 11, 2001 6:29 PM
> Subject: Re: Unsafe Implementation
>
> > This would be 100% portable and use already existing functions, e.g.
> something like
> >
> > jlong JNICALL Unsafe_StaticFieldAddr(JNIEnv *env, jclass clazz,
> jobject field);
> >
> > No, it would not port to VMs in which static variables change their
> > addresses from time to time (e.g., due to GC or object swapping).
> > Anything that moves must be accessed via a base pointer which moves
> > the same way.
> >
> > I'm curious what your responses are to the several options and
> > workarounds I send in my previous message. Just to keep things
> > interesting, let's consider changing most "int" values in the API to
> > "long". This would directly remove the 64-bit problems you mentioned.
> > (We are already performing the necessary long-arithmetic optimizations,
> > because of the existing "long" address parameters.) Allowing offsets
> > to be long would open the door to non-varying addresses of statics.
> >
> > In VMs with "malloced" statics, staticFieldBase would return null,
> > and fieldOffset would return a pointer value. The addressing mode
> > [register + offset] would have the effect of [0 + address], so that
> > any fixed virtual address can be probed by supplying a null heap offset.
> >
> > In fact, this could make half of the get/set functions be redundant;
> > everything could be expressed as [base + offset] / [null + address].
> >
> > Comments?
> >
> > -- John
> >
(Review ID: 137588)
======================================================================