speed of simple loops: comparison to other language

[Osvaldo Doederlein]

Hi Rémi,

 The simpler Client VM is a well-known tradeoff. It has substantial
> advantages in both memory usage and startup time. The Server VM is the only
> one that really competes with C/C++, but it's much more heavy-weight. And
> even with the Client VM being the default in the JRE installed in hundreds
> of millions of consumer PCs, Java already has a bad rep for its loading time
> and resource usage (although Sun/Oracle has been sweating to reduce these
> issues since JDK 6u10). This makes easy to understand the reason that Server
> is not the default, and it won't be any time soon. In fact, the only reason
> that a 64-bit port of the Client VM is not available, is that 64-bit
> consumer/desktop stuff is generally not very widespread yet (most browsers
> are 32-bit; there's no 64-bit port of other plugins like Adobe flash, etc.).
> But I hope this will change soon, I'd kill for a 64-bit JRE that includes
> the Client VM so I can make my Windows7-64 setup more "pure".
>
>
> no need to kill someone :)
> jdk7 has a 64bit client VM.
> http://bugs.sun.com/view_bug.do?bug_id=6459804
>
>
This looks great, I didn't notice it because I'm on Windows and the 64-bit
Client VM is not yet available for that platform. I guess it is for Linux
(which 64-bit JDK download is just as big as the 32-bit one, differently
from Windows which 64-bit build is 9Mb smaller because it doesn't include
Client).

Well, I guess just need to wait a few more builds until C1 comes to Win64?
Hopefully that will also have UseCompressedOops on by default when heap size
is sufficiently "small", otherwise 64-bit applets or JAWS apps will remain
overweight...

While we're at this, any idea if Oracle plans to solve the problem of double
isolation of plugin2 in new browsers? (Latest versions of most browsers
already isolate native plugins in separate processes, so the extra isolation
created by plugin2 has become redundant and just adds overhead.)

A+
Osvaldo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20100701/f600c468/attachment.html