I like the idea and something along these lines would be a great addition
to the standard library, which I will come back to as a PS.
In com.sun.misc.Unsafe there are already getLong(Object, int) and
setLong(Object, int, long) methods and the same for Object. No doubt if we
used getLong and setLong as they stand they would fail due to type checking
if used to access references to Objects in an Object[]. However if similar
methods were added that circumvented the type checking,
getLongOrReference(Object, int) and setLongOrReference(Object, int, long),
then you could write:
private Object[] vsAndRs;
...
@Override public long getValue(final int index) {
checkIndex(pos);
final long value = Unsafe.getLongOrReference(vsAndRs, index);
if ( (value & TaggedArrays.TAG) != 0 ) {
return value;
}
throw new TaggedArrayException("value at index =" + index + " is not
tagged");
}
@Override public Object getReference(final int index) {
if ( isReference(index) ) {
return vsAndRs[index];
}
throw new TaggedArrayException("reference at index =" + index +" is
tagged");
}
..
Which would save half the space and still be understandable Java (i.e. not
a collection of native calls).
Great work,
-- Howard.
PS A few random thoughts for the interface, assuming that something like
this makes it into the JDK then the following additions might be nice:
1. Fills that accept a lambda that receives the index as its argument
(filling function as opposed to filling constant).
2. A second interface and second factory that define tagged arrays for long
and double in addition to Objects, like the example code given.
3. TaggedArray32, primarily for phones etc., with the extended interface,
point 2 above, for TaggedArray32 accepting Objects, ints, and floats. On a
64 bit system TaggedArray32 would be the same as TaggedArray, but for 32
bit systems it would save space.
On 2 July 2012 23:05, Jim Laskey <jlas...@me.com> wrote:
> During a week in the rarefied air of Stockholm back in May, a sleepless
> night got me thinking. The day after that, the thinking became a reality.
> I've been sitting on the code since, not sure what to do next. So..., why
> not start the month leading up to the JVMLS with a discussion about dynamic
> values.
>
> Every jLanguage developer knows that primitive boxing is the enemy. Even
> more so for untyped languages. We need a way to interleave primitive types
> with references.
>
> Tagged values (value types) for dynamic languages have been approached
> from a dozen different angles over the history of Java. However, no one
> seems to be satisfied with any of the proposals so far. Either the
> implementation is too limiting for the language developer or too complex to
> implement.
>
> Most recently, John (Rose) proposed hiding value tagging in the JVM via
> the Integer/Long/Float/Double.valueof methods. I saw a few issues with
> this proposal. First, the implementation works differently on 32 bit and
> 64 bit platforms (only half a solution on each). Secondly, control of the
> tag bits is hidden such that it doesn't give a language implementor any
> leeway on bit usage. Finally, it will take a long time for it to get
> introduced into the JVM. The implementation is complex, scattered all over
> the VM and will lead to a significant multiplier for testing coverage.
>
> It occurred to me on that sleepless Monday night, that the solution for
> most dynamic languages could be so much simpler. First, we have to look at
> what it is we really need. Ultimately it's about boxing. We want to avoid
> allocating memory whenever we need to store a primitive value in an object.
> Concerning ourselves with passing around tagged values in registers and
> storing in stack frames is all red herring. All that is needed is a
> mechanism for storing tagged values (or compressed values) in a no-type
> slot of a generic object. Thinking about it in these terms isolates all
> issues to a single array-like class, and thus simplifies implementation and
> simplifies testing. Instances of this class can be used as objects, as
> stack frames and even full stacks. A good percentage of a dynamic language
> needs are covered.
>
> So, Rickard Bäckman (also of Oracle) and I defined an API and implemented
> (in HotSpot) an interface called TaggedArray. Conceptional, TaggedArray is
> a fixed array of no-type slots (64-bit), where each slot can contain either
> a reference or a tagged long value (least significant bit set.)
> Internally, TaggedArray class's doOop method knows that it should skip
> any 64-bit value with the least significant bit set. How the language
> developer uses the other 63 bits is up to them. References are just
> addresses. On 32 bit machines, the address (or packed address) is stored
> in the high 32-bits (user has no access) So there is no interference with
> the tag bit.
>
> We supply four implementations of the API. 1) is a naive two parallel
> arrays (one Object[], one long[]) implementation for platforms not
> supporting TaggedArrays (and JDK 1.7), 2) an optimized version of 1) that
> allocates each array on demand, 3) a JNI implementation (minimally needed
> for the interpreter) that uses the native implementation and 4) the native
> implementation that is recognized by both the C1/C2 compilers (effort only
> partially completed.) In general, the implementation choice is transparent
> to the user (optimal choice.)
>
> I've enclosed a JavaDoc and the roughed out source. For discussion. Fire
> away.
>
> Cheers,
>
> -- Jim
>
>
>
>
>
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev@openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>
>
--
-- Howard.
_______________________________________________
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
