On 4/30/08, Attila Szegedi <[EMAIL PROTECTED]> wrote: > > On 2008.04.30., at 11:49, Jochen Theodorou wrote: > > > > > Rich Hickey schrieb: > >> > >> On Apr 29, 5:36 pm, Jochen Theodorou <[EMAIL PROTECTED]> wrote: > > [...] > >> I think the answer is tags, as John Rose discussed here: > >> > >> http://blogs.sun.com/jrose/entry/fixnums_in_the_vm > >> > >> That, standard fast multiprecision arithmetic, and tail call > >> optimization are the wish list for me. > > > > I don't see how this will help me in Groovy. We use the Java types, so > > there is no need to represent a 20 bit integer. > > > It doesn't help you now. It'd help you in a new VM that has this > trick :-) > > John says that instead of having an arbitrary object pointer to > represent java.lang.Integer instances allocated on the heap, you could > have a specially tagged object pointer that'd be treated by the code > as a pointer to a java.lang.Integer. > > Most CPUs align data on a 4 or 8 byte boundary, so it is easy to > recognize an object pointer with some of its lower 2 or 3 bits set > ("tagged") as not being a valid heap object address; which you can > then use for other purposes. Like, simulate a lightweight Integer > object. So, you use the lower 2 bits as tags, and use some more bits > for type information, and you're left with, say, 20 bits of useful > payload. That way, you could have integers that fit in 20 bits > automatically behave as objects (with some quirks w/regard to > synchronization), and the VM could do "boxing" and "unboxing" (and > subsequently arithmetic) quickly by doing shifts and masks, without > touching the heap. But on high level, such a pointer would still > satisfy instanceof java.lang.Integer. > > So, it'd allow very low-cost representation of all java.lang.Integer > objects whose value fits in 20 bits or so. But it'd be a VM level > optimization, not something you could observe on a higher level. You'd > keep using Integer.valueOf() and Integer.intValue() etc.
I'm rather unsure about the value of making changes like this to the JVM. The timescale from now to when they become useable is rather long (2-3 years to get into a released JVM then another 2-3 years before I can rely on most of my target audience having the JVM in production). What I'm seeing, via this list and others, is that people are making great strides in understanding how to utilise features in the current JVM to make dynamic languages faster. The JRuby and Groovy teams seem to be making progress which may well make this work unnecessary for them. I'm concerned that a proposal like this will make use of some redundant information which could be used by some other JVM feature and by the time it's in the field and usable the problem will have been solved another way. (I'm also slightly terrified of building something based on address alignment and assuming that the behaviour of the hardware will be the same in 5-10 years time). Whist Method Handles are quite interesting I'd rather see effort being expended in making java.lang.reflect.Method faster and more useful (we discussed allowing downcasting to types which avoided the meed to box the parameters, and unbox the result at one point on this list). If only on the basis that this could be in the next version of the JVM as an incremental improvement to refection rather than as a change to support "dynamic languages". John Wilson --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "JVM Languages" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/jvm-languages?hl=en -~----------~----~----~----~------~----~------~--~---
