My game is more on the graphically demanding side; It loads a lot of high resolution diffuse textures, normalmaps, specularmaps, and glossmaps. On 64-bit JRE’s this is no problem. But I cant seem to allocate enough ram to get the game to boot with 32-bit ones.
This is my command line:
java -Xmx1024M -Xms1024M -jar client.jar
Why can’t you increase the memory allocated to the JVM?
Here’s some code to modify the ram allocation on a machine that can support it.
java -Xmx2G -Xms2G -jar client.jar
Change those numbers to your liking, but over 4 gigabytes the 32 bit JVM doesn’t support it.
Also if you’re using OpenGL, most assets are streamed into VRAM without a copy on the client side… So unless you have a huge custom cursor icon, Textures and Images shouldn’t be a RAM issue. ( I believe )
If you’re concerned about things taking up too much memory, check out VisualVM. theagentd recommended it to me and it saved my life. It gives you detailed info about a Java programs memory.
Increasing the ram doesn’t seem to help. 32bit JRE still says there isn’t enough memory.
On my friends computer (who has a 32 bit JRE), he is unable to allocate more than 1024 MB using the command line.
Seems to be a known problem:
http://www.oracle.com/technetwork/java/hotspotfaq-138619.html#gc_heap_32bit
Why can’t I get a larger heap with the 32-bit JVM?
The maximum theoretical heap limit for the 32-bit JVM is 4G. Due to various additional constraints such as available swap, kernel address space usage, memory fragmentation, and VM overhead, in practice the limit can be much lower. On most modern 32-bit Windows systems the maximum heap size will range from 1.4G to 1.6G. On 32-bit Solaris kernels the address space is limited to 2G. On 64-bit operating systems running the 32-bit VM, the max heap size can be higher, approaching 4G on many Solaris systems.
As of Java SE 6, the Windows /3GB boot.ini feature is not supported.
If your application requires a very large heap you should use a 64-bit VM on a version of the operating system that supports 64-bit applications. See Java SE Supported System Configurations for details.
Is there a specific reason why you want to support 32-bit JVMs?
I found that I was generally unable to allocate over 1GB of RAM with the 32 bit VM. I switched to 64-bit and never looked back. >95% of the worlds desktop computers are now 64 bit and rising, and it solves so many little niggly issues it’s a no brainer.
Cas 
32 bit jvms need contiguous memory, so even if your system has a lot more free, if it is fragmented you still won’t be able to use it. Your best bet is to shut everything down then open your app. Or best of all move to 64 bit where you don’t have any limitations.
[quote=“abcdef,post:7,topic:58763”]
Back when I was dealing with this I would try that but generally it’s at best an unreliable work-around and not gonna work for anyone else - the only real solution is as you say, move to 64 bit. Or figure out how to use a much smaller heap 
Cas
Not at all. I don’t want to. But almost half of everyone I send the game to has a 32bit JRE installed (on their 64bit OS’s).
Give 'em an embedded VM.
Cas
Hi
If you really plan to drop 32-bit support, maybe you can include the JRE in your game, AdoptOpenJDK provides prebuild OpenJDK builds for numerous 64-bit operating systems including GNU Linux, Microsoft Windows and Mac OS X.
As do Azul at https://www.azul.com/products/zulu-and-zulu-enterprise/. Has the benefit of being certified, which IIRC AdoptOpenJDK isn’t? Longer term I’d favour AdoptOpenJDK, but while they’re not recommending it for production purposes, Azul’s OpenJDK build might be a better option.
Both have pros and cons. AdoptOpenJDK isn’t governed by a single corporation that might be tempted to provide only non free of charge builds in the future, it has several sponsors, it passes the OpenJDK test suite and some other tests designed by the community. Its aim isn’t to provide formally certified builds, its maintainers advise to get them from commercial providers. Moreover, I’m trying to convince some maintainers to provide 32-bit binary builds for Intel. I don’t want to encourage planned obsolescence.
We pretty much have the same viewpoint. Just pointing out that while AdoptOpenJDK themselves emphasise it’s “work in progress” it might not be the better option. Longer term I hope it becomes the go-to option.
If it works then it works, as far as I’m concerned 
I’m 100% behind AdoptOpenJDK.
Now if only there were JVMs that ran on PS4 and XBOne…
Cas
Azul provides some installers, this is more convenient for non technical end users but it’s useless for programmers who want to put the JRE into their own bundles.
Do a lot of your end users still use 32-bit Intel computers?
For me, it’s the Steam market, which last time I looked was under 5% of users still using 32-bit OSes and falling.
Cas
They provide both!
Yes I know that but the installers aren’t very useful without applet and Java Webstart, are they?
Applets and WebStart tech are dead, except in some intranet apps in companies that can’t shed their legacy. Hardly relevant for JGO audiences.