Thanks Gerd, r188 contains your patch. WanMil
reverts the changes that calculated the MaxNodeId and nodeCount values. The default is now to assume a highest node id of 2^31 and resize when needed. This still needs much fewer memory compared to r181 because it allocates exactly two of these large arrays, while r181 typically allocated 8. So, on my machine splitting germany.osm.pbf took 938 secs with r181 (GC very busy because of -Xmx1600m ) and only 638 secs with patchv4 (optimize-mem=false). With optimize-mem=true, the program is typically ~ 10% slower.
I've also increased the allowed number of areas per pass, because this is now limited only by available memory and by the number of elements in the dictionary. If the latter reaches 32767 the program will crash, but I doubt that this will happen with real OSM data.