search

ModOrganizer2 / modorganizer

Mod manager for various PC games. Discord Server: https://discord.gg/ewUVAqyrQX if you would like to be more involved
http://www.nexusmods.com/skyrimspecialedition/mods/6194
GNU General Public License v3.0
2.18k stars 163 forks source link

Improve Java Runtime Environment Selection #672

Open LostDragonist opened 5 years ago

LostDragonist commented 5 years ago

Reference: https://github.com/ModOrganizer2/modorganizer/blob/583bc5b6c669bb0496b1818497ce62deb562ddc0/src/editexecutablesdialog.cpp#L167

This code should probably be changed to heavily encourage the user to use a 64-bit JRE. This can avoid issues with certain utilities like the SkyProc patcher (dual sheath redux, etc.).

For example, when a jar is selected, a dialog could be popped up asking whether to use the detected 64-bit JRE or the detected 32-bit JRE. A message would be present that suggests using a 64-bit JRE unless a 32-bit JRE is absolutely required. If either JRE is not detected, provide a link to where the user can download that JRE.

At the very least, the message about "MO requires 32-bit java" needs to be changed as it's not really true.

Make sure the behavior of the data list "add as executable" is consistent with the edit executables dialog.

LostDragonist commented 5 years ago

It might be overstepping a bit but also consider automatically adding -Xmx1024x -Xmx1024m arguments to any usage of the 32-bit JRE. Maybe even suggest adding Xmx2048x -Xmx2048m arguments to any usage of the 64-bit JRE.

These appear to have positive effects for SkyProc patchers but may have negative effects for other utilities...?

SuperSandro2000 commented 5 years ago

Why should it have negative effects? Only if the user has little to no memory free.

LostDragonist commented 5 years ago

I was thinking if the executable somehow has a higher memory limit defined and the arguments override it to a lower memory limit?... I have no clue if that makes sense (as with most things surrounding Java).

SuperSandro2000 commented 5 years ago

The flag is an arg to the jvm (java virtual machine) and as far as my basic knowledge can remember the application can't change that. Just add the flag and tweak it if necessary.

AnyOldName3 commented 5 years ago

I just googled the default maximum heap size for the 64-bit JVM and came up with a quarter of physical memory. Are we sure we want to go passing the JVM options to change it?

By the way, I'm not seeing what the x suffix means. I can see in the docs that no suffix is bytes, k is kilobytes and m is megabytes, but not a multiplier for x. I doubt it's gigabytes, as there's no way a 32-bit JVM is letting you allocate a terabyte of heap.

LostDragonist commented 5 years ago

It looks like I was contributing to some internet hearsay about that. I just copied that off some forum about the issue. Oracle Java refuses to run with that command at all for me.

The proper commands, per the batch files included with Dual Sheath Redux, should be -Xmx1024m and -Xmx2048m.

My default maximum heap size is 256MB for my 32-bit JVM and ~4GB for my 64-bit JVM. (32GB of RAM; determined with .\java -XX:+PrintFlagsFinal -version | findstr HeapSize)

So... it's probably worth leaving the 64-bit JVM alone unless something else happens.

SuperSandro2000 commented 5 years ago

I agree with you. Setting it to high will cause the GC to lag. We can already change the vars. Don't think there are any changes required.