TaggedArrays (Proposal)

Mon Jul 2 07:34:16 PDT 2012

So 32-bit is a pain-point for NaN encoding. I was only playing on x64 and didn't notice that. Thanks for the info!

 (Sorry for the messed formatting in the previous mail)

 - Raven

 ------------------ Original ------------------
  From:  "Jim Laskey"<jlaskey at me.com>;
 Date:  Mon, Jul 2, 2012 10:21 PM
 To:  "Da Vinci Machine Project"<mlvm-dev at openjdk.java.net>; 

 Subject:  Re: TaggedArrays (Proposal)

We had been using NaN encodings in Nashorn but moving away from it because of 32-bit FP emulation issues.  If you use a sNaN, 32-bit FP emulation converts sNaN to qNaN on load and creates a mess of things.

On 2012-07-02, at 11:11 AM, ravenex wrote:

> Very cool stuff, Jim and Rickard! I guess people are going to start missing NaN encoded tagged value/pointers now that there's something real to play with ;-) @Remi The subclass suggestion sounds a lot like Maxine's Hybrid objects, where named fields and an untyped array is bundled into a single object. Which pretty much emulates what people like to do in C/C++, something nice to have. > I think that getValue()/setValue() should return the long with the bit set because > If i want to execute x + 1, I can convert it to x + 2 at compile time thus avoid the shifts at runtime. Even without changing the API, this kind of transformation could easily be intrinsified in the JITs, not a big worry. Cheers, Raven ------------------ Original ------------------ From: "Rémi Fora"; Date: Mon, Jul 2, 2012 09:57 PM To: "mlvm-dev";  Subject: Re: TaggedArrays (Proposal) On 07/02/2012 03:05 PM, Jim Laskey 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. but it will also help Java perf. > > 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. using it as a stack frames will require a pretty good escape analysis if you want same perf as the native stack or is there a trick somewhere ? But given that there is a trick to avoid boxing for local variables (see my talk at next JVM Summit), having an array like this just for storing fields is enough to pull its weight. > > 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.) Being able to subclass it in order to add fixed field like a metaclass field, i.e a field that is always a reference, would be cool too. About the API, the two method set should be setValue()/setReference(). I think that getValue()/setValue() should return the long with the bit set because If i want to execute x + 1, I can convert it to x + 2 at compile time thus avoid the shifts at runtime. > > I've enclosed a JavaDoc and the roughed out source. For discussion. > Fire away. > > Cheers, > > -- Jim cheers, Rémi _______________________________________________ mlvm-dev mailing list mlvm-dev at openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

_______________________________________________
mlvm-dev mailing list
mlvm-dev at openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-de
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20120702/3cc72c86/attachment.html 