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.
Attila.
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
