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