Increase the maximum Java memory to 1280 Mebibytes

[david-a-wheeler]

Increase the maximum Java memory to 1280 Mebibytes (MiB) when using the provided Windows batch files. Without this change, mmj2 is likely to fail on Windows when processing big databases (especially set.mm) due to a lack of memory.

This maximum is carefully selected to work on 32-bit Windows as well as 64-bit Windows, so it should mean that mmj2 will "just work" on any plausible Windows system.

The underlying cause of the problem is that the file set.mm keeps getting bigger and that mmj2 includes an Earley parser (which uses more memory). As a result, the old maximum of 512 Mebibytes (512MiB) is likely to lead to startup failure when processing set.mm.

This commit increases the maximum to 1280 Mebibytes (1024MiB + 256MiB). Currently 1024MiB is enough to handle set.mm; adding another 256MiB provides more room for growth without issue. This number is intentionally under 1500MiB, which is around the most that 32-bit Windows systems can handle (the actual number varies, this commit is conservative). 64-bit systems can support a much larger maximum, but there is no expectation that a larger number will be needed for many years, and by that time we think it will be reasonable to require the use of 64-bit system for proof development even for people with limited resources.

This commit does not change the starting memory size, just the maximum, because a user might choose a database other than set.mm which doesn't require a lot of memory.

This commit also converts the .bat files (but only the .bat files) to MS-DOS text format (CRLF for end-of-line). These files are only executed by Windows systems, and some Windows programs (particularly most versions of Notepad) can only handle MS-DOS text format well. Switching only those files should make it easier for Windows users to get programs started. Everything else continues to use the POSIX standard text format (where lines end in only LF); once mmj2 is started, the mmj2 text editor can handle POSIX text format properly.

Signed-off-by: David A. Wheeler dwheeler@dwheeler.com

[digama0]

git doesn't like CRLF files in the repo. It is set up to automatically convert LF to CRLF on windows, so I don't see the problem. Does windows execute the batch files correctly with LF? I don't really care if Notepad mangles the file - if you are using Notepad for programming you deserve what you get.

[david-a-wheeler]

On April 19, 2020 8:10:39 PM EDT, Mario Carneiro notifications@github.com wrote:

git doesn't like CRLF files in the repo. It is set up to automatically convert LF to CRLF on windows, so I don't see the problem. Does windows execute the batch files correctly with LF? I don't really care if Notepad mangles the file - if you are using Notepad for programming you deserve what you get.

-- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: https://github.com/digama0/mmj2/pull/35#issuecomment-616249103

I don't know what you mean by doesn't like. You can configure it different ways, I typically don't recommend automatic conversions. I normally use cygwin on windows, so lf is not translated into crlf.

I can check if LF by itself Works in batch files. I suspect it does.

Notepad is a terrible program, but for many people that's all they have. Editing a batch file is technically programming, but not something that people would typically download a special editor for.

--- David A.Wheeler

[digama0]

By "doesn't like", I mean it can cause spurious diffs, and can often accidentally be reverted to LF because of the auto-conversion. It's definitely recommended that you keep LF in the repo and check it out to CRLF if you need to. That's how git does cross-platform synchronization. There is a setting core.autocrlf that is set to true by default on windows and input on unix. If running git in cygwin has caused this setting to be set wrong, then that is a configuration problem on your end, which can be fixed by git config --global core.autocrlf true. The only reason to check in CRLF files is if git is incorrectly recognizing a binary file as text and the autoconversion is mangling the file.

[david-a-wheeler]

You can set things differently in git, but that's fine.

I checked and Windows will run batch files correctly even if they use POSIX end-of-line format. So it doesn't matter, so I changed this to use POSIX end-of-line format as requested!

[david-a-wheeler]

All good for a merge? I think I've resolved everything you mentioned, it should be fine to merge.

[david-a-wheeler]

Done by #38