I think the increased memory requirement of Java has more to do with efficient garbage collection.
Sorry, Jeff but you got me wrong. I don’t talk about the program size, but the total memory consumed but the porgram and the VM at runtime. Probably swpalmer is right and it mainly has to do with GC.
For example take a look at the following benchmark comparing C++, Java and C#. I don’t matter if the overall results are meaningfull (microbenchmarking or whatever), but the mentioned maximum memory usage (Java - 163 MB , C# - 111 MB, Cpp - 98 MB) fits into my experience.
(http://www.tommti-systems.de/go.html?http://www.tommti-systems.de/main-Dateien/reviews/languages/benchmarks.html)
Bah! N00bs! Always looking at the wrong bits! JVM and JIT profiling information == tiny. Graphics & sounds == large. Just one single texture in Ultratron takes up as much room as all the jars combined. Etc. You’re going to lose a little bit of space and have to lose a texture or downgrade a sound effect or some music but it’s not really significant enough to prevent development of a proper classy game.
Cas 
I know i know
That is why the idea of a VM is so good to me, and if there was faster hardware to make startup time (the areas where VMs still show disadvantages vs Native).
In theory there would be no need to tweak java code, in practice we spend all the time tweaking especially in J2ME, because in practice almost no one respects the standards or implement them correctly and sometimes the standard is not the best solution, also competitive advantage, etc… all make the VMs break the so called java mantra: “write once run anywhere” (yeah right!) code once tweak many is more like it (still it is better than having to write X completely different versions because of hardware) so java did not solve completely the hardware (architecture compatibility) problem with it’s VM, it helped but there are still many tweaks that one has to do :-[ the advantage you mention is unfortunately not real in many cases (but we all know this).
No you got me wrong. Thats EXACTLY what I meant. As a datapoint when Sean compield his game using JET the total in memory footprint (including VM) literally doubled
We got the answer as to why from one of the guys who worked ON Jet. and its exactly what I described to you.
Clearly you need more detail. I’ve explained this before but I will do it once more.
Java, unlike C, is late bound. This means that most dispatach points cannot be inlined because you cannot gaurantee one and only one destination. Hostspot does what we call “agressive inlining.” If, at run time, there is one and only one class loaded that can meet the target rquirements we go ahead and inline it. We then watch what is loaded and, should another be loaded that can meet the requirements we back out the inlining.
Thsi is just one of a number of examples of where we use the abaility to morph code at run-time to improve hotspot performance.
JET achieves similar performacne, but only be precompilign EVERY version and building them ALL into the executable.
here endeth the lesson.
Irrelelvent data point. This has to do with what the different envirionments do for you, not the compilation technology. Java provides a great deal of run-time functionality., This has over-head no matter how you implement it. As SWP points out, howeverm, Its relatively insignificant in today’s world. (About 4K worth for a console hello-world.) Reflection information can also get quite large, but you can always run an obfuscator if you want that back.
You need to comapre apples and apples. Go get yourslef a Java compiler and see for yourself. For any significantly compelx program you will either get slower code, or bloated code. Its a physical law.
Startup time could be masked in this case. Eg you could start showing the loading screen and progress meters (as a static image) prior to actually starting the vm. Once the vm is loaded you can continue to draw it yourself. The felt startup time would be zero then. 
We need to be careful when we talk to seperate J2SE and J2ME as tpoday theya re very doifferent beasts.
Furthermore you need to destinguish between J2ME/CDC and J2ME/CLDC. What you really are talking about is J2ME/CLDC.
(Technically, J2ME/CLDC isn’t even Java by the Java VM spec as floating point i opstional in J2ME but required by the JVM spec.)
The initial crop of J2ME/CLDC devices were probably the worst possible environment to try to run Java code. No memory, slow processors, highly inconsistant hardwware. Ina very real sense, no J2ME/CLDC program COULD be :“signficantly complex” and thus frankly it brought all of the potnetial weaknesses of Java to the fore while removing most fo its benefits.
What J2ME people generally see still lags behind the desktop badly in Java technology HOWEVER this is changing as those devices grow into the more capable CDC profile. which is much closer to true desktop Java.
I think this is completely against Sun’s philosophy and therefore they don’t allow it. This is why the only ways to do that even on PC are through GNU open source means. Java doesn’t like it.
Actually, you don’t. You just thought you did. 8)
I hope I’ve helped clear that misconception up.
JK
CDC or CLDC that’s just the profile, the VM implementations are always going to differ (even with almost all companies using ARM processors), the only way to solve this would be to have a downloadable and installable VM for mobile phones (like we have for the desktop VM - JRE), that way one could chose to have the Default (possibly SUN Mobile VM) or the phone brand Mobile VM.
CLDC is here to stay for a long time… and even wend CDC devices start to overtake, that will only bring more fragmentation to the market, so basically you end up programming like a low-level programmer (the fragmentation problem is never going to go away) for much worse performance, the java high level abstraction brings nothing of value, in fact it only degrades performance, this solution is broken…
For Desktop java games i actually don’t see a problem with the VM startup time, even Native games have load times…
What i really dislike is the 30sec that i have to wait to get NetBeans to start 
I have to agree with Jeff on this one,
You really don’t want an AOT or a VM for that matter. Why? Because PS3 specs are never going to change that much, so to run an unnecessary layer of abstraction on top of an architecture that is never going to change does not make much sense performance wise, “cut the middle man”.
Traditional Game programming is all about knowing the design of the system and squeezing every ounce of performance out of the components (well in theory : ), if you use a VM you need to have a complete compatibility and more than that optimization on all platforms, looking at the actual panorama of desktop VMs that is not the reality and IMHO it is an utopia.
So porting companies can rest assured that they will have loads of work porting from platform to platform, for the next decades.
Traditional game development is f*cked. Budgets are wildly out of control and increasingly the industry is doing everything opposite to the way every other enterprise attempts to work.
For consoles to continue into the next decade they must consolidate on APIs such as OpenGL and DirectX and abstract away the funny to-the-metal features of the hardware. It is simply not going to be commercially viable to have to completely port games to different platforms.
The start of this trend can be seen with XBox, which shares its APIs with Windows. That one simple act of using DirectX as the core rendering library meant that simultaneously developers could get a huge headstart developing for the console and Microsoft were able to punt that console out fast and grow its numbers quickly.
A VM doesn’t make a great deal of difference to the overall equation - it’ll just slash a few percent off the overall schedule. But a common API without crazy hardware programming will have a significant impact on the business.
Sony ought to concentrate on getting OpenGL onto the PS3 rather than Java.
Cas
Correct me if I’m wrong, but OpenGL is the tech of choice for PS3.
-Chris
That’s what I have heard - or at least something “OpenGLish” - whatever that means
This is what I’ve heard too but until I see it I don’t believe it PS2 JVM cough
Cas
The last information that i have is that PS3 will use OpenGL ES 2.0 with extension more info about it http://www.khronos.org/opengles/2_X/ with cg for shader (since it is an nVidia chip).
I know i had more information on that, but i guess i don’t have it bookmarked ???
Incorrect. CDC or CLDC is the J2ME family, literally the definition of the VM. Profiles live above that. MIDP for instance, is a profile. CDC is designed for very very resource constrained dveices and thus is a minimal VM. CLDC is designed for the next wrung up and thus is a much more complex and faster VM ebcause the resources are available to create such.
J2SE is designed for top end devices where the resources are availabel to do a maximally compelx and maximally fast VM.
Your point? As long as they all meet a common specification, the implementation details should be fairly irellevent.
In what way?
Today much of J2ME is written like C code because of space considerations. Thats really the only reason.
This is an assertion not an argument.
EDIT: This line deleted because it failed the “punk-bastard test.”
We see no such performacne penalties on the larger machines. As the phone gets larger it will inherit all the performance tricks that larger platforms use today.
I already know of one manufacturer that is in planning for a phone with PSP level capabilities. Thats more the enough to run a version of hotspot. Our CDC VM today gets 85% of the performance of Hotspot and will run in mid range devices such as you will see in your pocket VERY soon.
Pardon, but then what are you doing here?
Most everyon here doing serious games has seen great improvements in their productivity and code correctness in moving to Java. Thats why we’re here. As I say, why are you?
Im about ready to classify this whole thing as “troll bait” and move on.
Ok let’s get things clear Jeff, by the way i don’t get all this forum aggressive behavior, but it is the nature of the beast…
I called it CDC/CDLC profile because you called it a profile “…grow into the more capable CDC profile. which is much closer to true desktop Java.” i thought you understood what i meant, as i understood what you meant by those words it would have been very easy for me to simply say INCORRECT the CDC is not a profile (but i believe that would have been a trolish thing to do since a VM alone cannot be used to run applications), anyone can go to http://java.sun.com/j2me/index.jsp and read all the wonderful definitions for the acronyms that we use:
The Connected Device Configuration (CDC), developed within the Java Community Process (JCP), is a framework for using Java technology to build and deliver applications that can be shared across a range of network-connected consumer and embedded devices, including smart communicators, high-end personal digital assistants (PDAs), and set-top boxes http://java.sun.com/products/cdc/index.jsp
I work in the J2ME space for the past year, so i am pretty familiar with all the definitions and really don’t like to spend my days telling people that oh that is not a profile that is a framework, that is a profile, that not all phones have the same abilities, what JSR are, that phones can use the KVM or Hotspot, etc… i usually refer them to some nice webpages like this one: http://java.sun.com/products/cldc/faqs.html
About platform fragmentation i am only too familiar with it, and that is why i stated that the fragmentation problem is not going away just because phone makers will ship more capable phones in fact with so many extensions and abilities it is only going to get worse and companies like http://www.tirawireless.com/default.htm are here to stay and no amount of memory in phones is going to change that.
“Today much of J2ME is written like C code because of space considerations. Thats really the only reason.”, now this is a statement form someone that clearly does not code in the J2ME world, space is a problem, but only one of the many, device capabilities/abilities, device differences (screen size, keypad, etc…).
There are already phones capable of playstation+ level from sonyEricsson and others, that use optional JSR184, OpenGL ES from companies like MascotCapsule or Hybrid, there are even phones that have hardware acceleration i don’t see your point, the fact is that a GBA system is much less powerful than the current generation of phones but you can do allot more (games can perform better) with it that you can with a mobile phone, at least using only the MIDP profiles (1.0,2.0 gamecanvas etc…) so there is a performance problem that you cannot get around since you have to code for the java platform (this has been discussed by John Carmak on his blog http://www.armadilloaerospace.com/n.x/johnc/Recent%20Updates).
“Pardon, but then what are you doing here?” Well i am here to discuss this is a forum is it not? I am not here to be a Fan boy of Sun or Java for that matter, i am here to participate
My only point in my previous post was to say that there is always going to be tweaking to do because of all these extensions and optional packages the first generation of phones used the MIDP1.0 profile and that brought extensions from nokia, and many others it was insufficient, the second generation with MIDP2.0 (gamecanvas, etc…) was still not sufficient, CDC devices that have the personal profile, foundation profile, personal basis profile… blah blah blah are still insufficient, manufacturers are now used to breaking standards and creating extensions (so basically what we have now, and will continue to have is a similar situation to the Microsoft JVM vs Sun JVM on the desktop) and this is BAD, Sun should provide more than CDC hotspot and RI they should do what they did on the desktop space a JRE so that we have on the ME space what we have on the SE desktop space, that is where java brought value, it is not bringing that to the Mobile space and it is going to hurt developers on the long term.
“Im about ready to classify this whole thing as “troll bait” and move on” you are free to do so, i will do the same.
I hope so. : From your statement the memory consumption is higher than for a C++ applciation, because Java uses late binding. That makes sense, but I believe an AOT (like JET) should not produce that much different codepaths due to optimization for different hardware since the one in a console should always the same - don’t know how much this saves. Futher, the mentioned total memory consumption, e.g. that meassured by the mentioned benchmark, hasn’t anything todo with the program itself but with run-time functionality, Java provides. What excactly do you mean by ‘run-time functionality’? From the language point of view or has this something todo with the provided packages (awt,…). If the latter is the case, fine a java ‘console edition’ without them would be the solution (such LWJGL), but if not: how to reduce the total memory consumed ?
That’s very interesting, indeed I don’t know that much about how the JRE can inline code. Unfortunately, I don’t understand how to determine a state, from which on only one destination is possible. You said if ‘there is one and only one class loaded that can meet the target rquirements’. Are target requirements the Type of the reference point to an Object ? (Number n = new Interger(0); <- in that case ‘Number’)
Does the mean an immutable array will never be inlined ? Take the following case:
AnyClass[] array = ..;
List<AnyClass> constArray = Collections.unmodifiableList(Arrays.asList(array));
constArray.get(0) -> Collections.UnmodifiableList.get(0) -> Arrays.ArrayList.get(0) -> array[0]
if that canot be inlined, because two classes with the List Interface are loaded: Collections.UnmodifiableList and Arrays.ArrayList. Thus it probably cannot be optimized, right?
Now, I really hope I understand something wrong 