2009/3/16 Eliot Miranda <eliot.miranda at gmail.com>:
>
>
> On Mon, Mar 16, 2009 at 2:15 PM, Philippe Marschall
> <philippe.marschall at gmail.com> wrote:
>>
>> 2009/3/16 Eliot Miranda <eliot.miranda at gmail.com>:
>> >
>> >
>> > On Sun, Mar 15, 2009 at 1:57 PM, Nicolas Cellier
>> > <nicolas.cellier.aka.nice at gmail.com> wrote:
>> >>
>> >> 2009/3/15 Hans-Martin Mosner <hmm at heeg.de>
>> >>>
>> >>> nicolas cellier schrieb:
>> >>> > Hans,
>> >>> > Tagging/untagging could be very fast! See my other post
>> >>> >
>> >>> > 1) UnTagging a double= No op
>> >>> > 2) Tagging a double= a isnan test (so as to have a representable nan
>> >>> > in Smalltalk)
>> >>> > 3) This trick does not had any extra cost to tagging/untagging of
>> >>> > other oops
>> >>> That's true for a 64-bit processor, and on such hardware I see the
>> >>> advantages of this scheme.
>> >>> For 32-bit hardware, it won't work.
>> >>> Hopefully we'll all have suitable hardware in the near future...
>> >>> But for example, I'm running 32-bit linux here on my 64-bit AMD
>> >>> processor just because the WLAN card I'm using only has a 32-bit
>> >>> Windows
>> >>> driver, and ndiswrapper on 64-bit linux would require a 64-bit driver
>> >>> to
>> >>> work correctly (which is somewhat stupid IMHO but I'm not going to
>> >>> hack
>> >>> ndiswrapper).
>> >>> In the real world, there are tons of silly constraints like this which
>> >>> still prevent people from fully using 64-bit hardware.
>> >>>
>> >>> Cheers,
>> >>> Hans-Martin
>> >>
>> >> Of course, most of the nice properties come from the 64 bits
>> >> adressing...
>> >> Hey, wait, I don't even have a 64 processor in my house!
>> >> For the fun I imagine we could emulate by spanning each oop over two
>> >> int32
>> >> typedef struct {int32 high,low;} oop;
>> >> I would expect a slower VM by roughly a factor 2 - except for double
>> >> arithmetic...
>> >
>> > In theory, but only for memory-limited symbolic applications.  If you
>> > have
>> > an application that fits entirely in cache then I would expect parity.
>> >  The
>> > argument for symbolic applications is that a 64-bit symbolic app has to
>> > move
>> > twice the data as a 32-bit symbolic app because each symbolic object is
>> > twice the size.
>>
>> Couldn't you compress the oops? AFAIK HotSpot was the last remaining
>> JVM that got this.
>
> I don't see the point.  Memory is cheap, getting cheaper.

But memory access isn't.

> 64-bits means
> extremely cheap address space.  Why slow down the critical path to save
> space?

Because it's faster (because you have to move around fewer data) an
gets you closer to 32bit speed.

http://wikis.sun.com/display/HotSpotInternals/CompressedOops
http://blog.juma.me.uk/2008/10/14/32-bit-or-64-bit-jvm-how-about-a-hybrid/#comments
http://www.lowtek.ca/roo/2008/java-performance-in-64bit-land/
http://www.devwebsphere.com/devwebsphere/2008/10/websphere-nd-70.html
http://webspherecommunity.blogspot.com/2008/10/64-bit-performance-thoughputmemory.html

Cheers
Philippe