Investigate setting `-XX:MaxRAMPercentage` to >25% of system memory

[taylor.smock]

The flag was added during the Java 8 update cycle (but not as part of the initial Java 8 release).

The default is 25% of system memory; we can probably safely use up to 75% of system memory.

We may also want to look into setting the minimum memory (Xms) to something semi-sane.

Possible minimums for Xms:

• 99mb: Clean JOSM install after starting
• 136mb: JOSM with minimal amount of data loaded (1129 nodes, 414 ways, 13 relations)
• 161mb: JOSM with minimal amount of data loaded + background layer

I'd probably round up to the nearest power of 2 though, so 128mb or 256mb.

[skyper]

Java 8, especially the 32bit version, was setting a too low Xmx by default. I am not sure what the default is for java 11+ but it should be between 25% and 33%. I think 75% is too high considering machines with small amount of total memory and that JOSM is not the the only application running. Why don't we stick with the java defaults and people can still set a higher number manually if needed?
On the other side, 128mb seems to be to low for Xms and I would set it to at least 256mb.

[taylor.smock]

The default for Java 11+ is 25%.

Something to keep in mind is that -XX:MaxRAMPercentage only sets the maximum amount of memory we can use, it doesn't allocate it until necessary (so it won't be a problem until someone decides to load more data than they should).

Realistically, I just want to keep enough memory available for the OS to not crash and give the user a chance to kill JOSM; I feel like 75% is "good enough".

For arguments sake, let us say that someone is using a computer with 1024m of ram, JOSM will use at most 768m.
This leaves 256m for everything else, assuming the user uses all of the potentially allocated memory.

What we care about for low memory systems is the Xms value, as that is what would always be allocated. If we are worried about people on old systems with very little ram, we'd want to set it to 128m instead of 256m. Since the JVM will deallocate ram that isn't used until our memory usage is equal to or less than the Xms value.

Minimum ram requirements (from ​https://docs.xfce.org/xfce/system-requirements )

• Just the shell: 120m
• CTWM: 220m
• IceWM: 295m
• Xfce: 395m
• KDE5: 620m

Quite frankly, at 1G memory, I would strongly recommend that the user upgrade their machine. Windows Vista (released on 2007-01-30 or 17 years ago) required 4G or more of memory.
That means that the user would be running something that fits the following criteria:

1. Incredibly ancient
2. Power inefficient per unit of work (they would probably save money if they were to upgrade, at least if they actually use the computer)
3. Running something that is likely to die at any time

The only modern machines that have less than 1G of memory are single-board computers (like the Raspberry Pi), and the experience for the desktop on that wasn't great in the RPi4 generation; I haven't gotten an RPi5 which (notably) only comes in 4G and 8G variants at this time.

[taylor.smock]

I should also add that I'm currently looking at only making it the default for mac and windows -- I'm just changing the etc/default/josm files to have -XX:MaxRamPercentage=75.0 instead of -Xmx2048m in the #JAVA_OPTS line. I might add some code to the linux start scripts to add -XX:MaxRamPercentage=75.0 if the computer has 4G+ of ram and JAVA_OPTS isn't set.

For mac, the oldest supported version supports hardware from 2013, and that was after 4G ram became standard.
As noted in the above post, Windows required 4G+ starting in 2007, although Windows XP was sold until 2010 or so.

[taylor.smock]

@sebastic: do you see anything stupid with my changes to the Linux start scripts?

[sebastic]

Replying to taylor.smock:

@sebastic: do you see anything stupid with my changes to the Linux start scripts?

It looks fine, shellcheck doesn't find anything problematic either.

Reading /proc/meminfo instead of parsing free(1) output might be more future proof, e.g.:

grep ^MemTotal: /proc/meminfo | awk '{print $2 / 1024}'

[taylor.smock]

I went with free instead of meminfo since I thought that free would be more future proof.

[sebastic]

Replying to taylor.smock:

I went with free instead of meminfo since I thought that free would be more future proof.

Both are unlikely to change (often), I thought that free(1) was subjected to locale but that doesn't seem to be the case.

Either is probably fine with output stability in mind.

By readying from /proc you can get rid of the pipes, though:

if [ "$(awk '/^MemTotal:/ {print int($2 / 1024)}' /proc/meminfo)" -gt 8192 ]; then

[skyper]

Ok, I have no problem with the proposed changes.

Replying to taylor.smock:

What we care about for low memory systems is the Xms value, as that is what would always be allocated. If we are worried about people on old systems with very little ram, we'd want to set it to 128m instead of 256m. Since the JVM will deallocate ram that isn't used until our memory usage is equal to or less than the Xms value.

Funny, in 23837.patch​ you added 256m for Xms instead of 128m. Mistake or did you change your mind?

[taylor.smock]

Depends upon which Xms you are looking at.

• linux: guarded by checking that memory is at least 8g
• mac: All supported mac systems should have 4g+
• windows: All supported windows systems should have 4g+
• jnlp: This is where I think you might have a point (but only on Linux systems). Unfortunately there is no way to dynamically set JVM arguments in the JNLP. With that said almost all systems sold since 2010 (give or take a year or so) have 4g+ of ram.

If a system does not have 4g+ of ram, it is probably time for an upgrade. Here are some numbers:

---

From a power efficiency standpoint, the current/last generation of CPU chips are ~450 (see ​cpu performance-per-watt which uses benchmark result/average energy required). The earliest CPU they have on that chart is from 2019 at ~100.

This means that for the same unit of work, a current CPU is going to use ~75% less power than a 5 year old CPU. This probably scales to even older CPUs, but that is a guess (~95% less power than a 10 year old CPU, assuming a further 75% improvement on performance per watt from 10 year old cpus to 5 year old cpus -- this actually matches something ​amd had set as a goal -- about 4% of the energy usage per work unit from 2014 to 2020).

In short, assuming the following:

• 20c/kWh
• $134 for i3-14100 (this looks like it would be an upgrade for me from my i5-4690 -- a 10 year old CPU)
• $100 for MB + RAM
• ~5kWh/week (see ​pcmag article; I cut their numbers by 50% since not everyone works from home)

With those numbers, we are looking at $52/year for the "current" running costs. This is a 6 year break at 20c/kWh and assuming a 75% improvement on performance per watt (from 5 year old CPU). If we assume there was an additional 75% perf/watt improvement from the 10 year old CPU to the 5 year old CPU, that is ~94% total, which gives us a 4.75 year break even.

Most people on a strict budget could use second-hand parts to decrease costs and move the break-even point closer.

---

All of that doesn't factor in the age of the hardware -- 10+ year old hardware is much more likely to fail than newer hardware.

[taylor.smock]

In 19215/josm:

Fix #23837: Set -XX:MaxRAMPercentage to >25% of system memory

This does not currently work for WebStart, see
​https://github.com/AdoptOpenJDK/IcedTea-Web/pull/954 .

As noted in the ticket, all supported MS Windows and Apple macOS machines have
4G+ of RAM. Linux machines don't have a baseline, and some have 1G or less. Where
we detect that a machine has <8G of memory in the linux start scripts, we don't
add the JVM parameters.

As a reminder to everyone reading the changelog: just because we ask for the
ability to use 75% of the system memory doesn't mean we will use all of that
memory. The JVM will free up unused memory for the rest of the system.

We additionally set the minimum memory allocation to 256m; while this can be
lower, that is for minimal amounts of data loaded. A clean JOSM install will use
99mb, for example. But once we add a minimal amount of data and a background
layer, static memory usage goes up to 161mb.

[taylor.smock]

In 19219/josm:

See #23837: Set -XX:MaxRAMPercentage to >25% of system memory

Drop RAM arguments since it causes issues with OWS.

[skyper]

Does only work on Linux if system language is English or not set (C), see #23951.