Scripts in `bin/` should not enforce heap space limits and allow for user control

[c-dilks]

Most of the scripts in bin/ run java with hard-coded heap size settings (-Xms and -Xmx). Correct me if I'm wrong, but these are not overridable, e.g., with JAVA_OPTIONS, since when an option is set in both JAVA_OPTIONS and in CLI java option arguments, the CLI option arguments are used.

We need a way to override these hard-coded limits in some cases.

#561 is a start, but it's not general, and I'm wondering if there's a better approach here.
@baltzell's more general approach: #561 (comment)

[c-dilks]

I'd even be happy with some custom environment variable the user can just use:

[ -z "${COATJAVA_HEAP_MAX-}" ] && export COATJAVA_HEAP_MAX=1536m  # use default value, if not set
java -Xmx$COATJAVA_HEAP_MAX .....

Aside: My motivation here is dealing with sporadic OOMs from using hipo-utils in batch jobs (with hipo-multi-merge)

[c-dilks]

Aside: My motivation here is dealing with sporadic OOMs from using hipo-utils in batch jobs (with hipo-multi-merge)

Ooops... this one's actually a bug in hipo-multi-merge. PR incoming soon for that, but we ought to deal with that script's hard-coding too (the COATJAVA_HEAP_MAX environment variable approach would be easy here too)

[baltzell]

closed by #608 and/or #620