Osmosis hangs on windows in the merge or map creation phase (out of heapspace)

[Ebe66]

Expected Behavior

For WHC to finish either successful or to produce an error message

Current Behavior

Tried to create my home tile on an old Win10 16Gb laptop with python -m wahoomc cli -xy 131/84 -dw. WMC starts, the laptops gets to do some hard work notably by running the cpu fan on "fast & furious" mode. After some time the fan slows down and stops but the program never ends.
Eventually I tried to see what happens by replacing the line run_subprocess_and_log_output( cmd, f'! Error in Osmosis with tile: {tile["x"]},{tile["y"]}') With the old style result = subprocess.run(cmd, check=True) and, no surprise there, it showed Osmosis running into an out of heapspace error. What is a surprise is that it does not return/exit on this error. I guess this is the cause of a lot of older now closed issues in the past years.

Steps to Reproduce the Issue

1. It's environment depended but run python -m wahoomc cli -xy 131/84 -dw on a low spec Win system and default Osmosis.bat file

Context

• OS/Platform: Windows
• Other information regarding your environment (optional): Low spec/mem system

Log Output / Stack Trace

    java.lang.OutOfMemoryError: Java heap space
        at com.google.protobuf.LongArrayList.addLong(LongArrayList.java:174)
        at crosby.binary.Osmformat$Way.<init>(Osmformat.java:14277)
        at crosby.binary.Osmformat$Way.<init>(Osmformat.java:14153)
        at crosby.binary.Osmformat$Way$1.parsePartialFrom(Osmformat.java:15920)
        at crosby.binary.Osmformat$Way$1.parsePartialFrom(Osmformat.java:15914)
        at com.google.protobuf.CodedInputStream$ArrayDecoder.readMessage(CodedInputStream.java:860)
        at crosby.binary.Osmformat$PrimitiveGroup.<init>(Osmformat.java:4649)
        at crosby.binary.Osmformat$PrimitiveGroup.<init>(Osmformat.java:4574)
        at crosby.binary.Osmformat$PrimitiveGroup$1.parsePartialFrom(Osmformat.java:6604)
        at crosby.binary.Osmformat$PrimitiveGroup$1.parsePartialFrom(Osmformat.java:6598)
        at com.google.protobuf.CodedInputStream$ArrayDecoder.readMessage(CodedInputStream.java:860)
        at crosby.binary.Osmformat$PrimitiveBlock.<init>(Osmformat.java:3113)
        at crosby.binary.Osmformat$PrimitiveBlock.<init>(Osmformat.java:3048)
        at crosby.binary.Osmformat$PrimitiveBlock$1.parsePartialFrom(Osmformat.java:4432)
        at crosby.binary.Osmformat$PrimitiveBlock$1.parsePartialFrom(Osmformat.java:4426)
        at com.google.protobuf.AbstractParser.parsePartialFrom(AbstractParser.java:135)
        at com.google.protobuf.AbstractParser.parseFrom(AbstractParser.java:168)
        at com.google.protobuf.AbstractParser.parseFrom(AbstractParser.java:180)
        at com.google.protobuf.AbstractParser.parseFrom(AbstractParser.java:185)
        at com.google.protobuf.AbstractParser.parseFrom(AbstractParser.java:25)
        at crosby.binary.Osmformat$PrimitiveBlock.parseFrom(Osmformat.java:3521)
        at org.openstreetmap.osmosis.pbf2.v0_6.impl.BlobToBlockMapper.parsePrimitiveBlock(BlobToBlockMapper.java:52)
        at org.openstreetmap.osmosis.pbf2.v0_6.impl.BlobToBlockMapper.apply(BlobToBlockMapper.java:28)
        at org.openstreetmap.osmosis.pbf2.v0_6.impl.PbfBlobDecoder.runAndValidate(PbfBlobDecoder.java:352)
        at org.openstreetmap.osmosis.pbf2.v0_6.impl.PbfBlobDecoder.run(PbfBlobDecoder.java:365)
        at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
        at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
        at java.base/java.lang.Thread.runWith(Unknown Source)
        at java.base/java.lang.Thread.run(Unknown Source)

Suggestion: Consider adding a Debug or Verbose gui/cli parameter that changes the capture_output=True option of subprocess.run to False. The result is that all output of the subprograms is displayed which might be less visually pleasing but DOES provide the user with an option to see what is going wrong and a better opportunity to report it.

Possible solution: I am using Eclipse Temurin Java but this might/should work on other (openjdk) java versions.

I modified the following line in the Osmosis .bat file: From

set DEFAULT_JVM_OPTS=

To

set DEFAULT_JVM_OPTS=""-server -Xmx80G -Xmn70G -XX:+UseG1GC""

The 80Gb of ram is even accepted on my, again, 16Gb system. The 70Gb page file option does however need

1. A page file to be present
2. For it to have a size of at least 70Gb.

After which the map is successfully created.

Don't know if this osmosis.bat file change can be integrated into the project but it may at least be worth a mention I think in the documentation as a possible solution for the Windows users out there.