http://www.theinquirer.net/?article=7078
64MB of RAM? Bugger. Going to be tricky to get a AAA Java games crammed in there. Well, not the games, per se, but the data. When was the last time you saw a Java3D demo that didn’t gobble up 64 big ones straight up?
So get writing to Sony now! 128MB or I’ll hold my breath!
(And GL drivers per-lease!)
Cas 
Now we just have to wait and find out how big the game jvm is, assuming there will ever be one. I did think that they would jump to atleast 96 or 128 megs to top xbox.
“It’s still not clear how many of these “cells” will be used in the Playstation3, but Sony reckoned some time ago it could be as many as one teraflops, probably making it a four cell architecture.”
Each cell is said to have 128M, so the total memory is 512M plus the central 64M.
The high speed bus can make it “seem” like a usable total of 512 but looks like it will be quite a song and dance to work it that way.
Read more closely - that’s 128K in each cell. The cell memory is effectively its L2 cache.
It doesn’t really matter how small they make the VM; the problem is Java’s object overhead. Generally Java takes up a lot more RAM to store the same structures as C does.
It will also need to have the Realtime spec implemented properly for it to be viable in PS territory.
Cas
The cldc hotspot has only 4 bytes overhead for the object header. I am sure Sun could make a jvm with similarly small object headers.
That 4 byte header requires that there are rather few objects in the first place…
Cas
That probably makes sense given the limited resources of a console. Obviously you wouldn’t make a direct transfer of a vm designed for 2megs of ram, buta game vm wouldn’t require the full 8-12 bytes of a j2se vm. I don’t think I am as worried about this as you are.
I’m more worried about the rather large structures required to store 3D worlds in. They’ll end up just resorting to stuffing things in buffers and then they’ll think - well, why did we bother when it’s so much easier to do in C?
Cas
Long story short, not enough memory. I will be interested to see if the four cells do operate as generic processors, all available to the jvm. Considering the multithreaded nature of java it might be a very good fit.
I’m not sure those are really the final specs. 64Mb will probably be seen on Mobile Phones by 2005. RAM just isn’t your biggest system cost any more.
[quote]The cldc hotspot has only 4 bytes overhead for the object header. I am sure Sun could make a jvm with similarly small object headers.
[/quote]
Object headers on hotspot aren’t that much bigger.
The big issue generally isnt obejct headers but reflection information. In order to give you debugger like functionality at run time (readable stack traces, dynamic resolution of methods by symbolicname, etc) we basically have to carry what would be debugging info in other systems into the runtime.
This is why obfuscators that minimize the lengths of those strings can be a win, though you give up most of the usefulness of reflection and run-time stack traces as a result.
[quote]I’m not sure those are really the final specs. 64Mb will probably be seen on Mobile Phones by 2005. RAM just isn’t your biggest system cost any more.
[/quote]
Im sure they arent final specs because I’m pretty darn sure the hardware isn’t final yet.