[erlang-questions] Max heap size

Richard A. O'Keefe ok@REDACTED
Thu Apr 28 01:27:37 CEST 2016



On 27/04/16 7:12 PM, Lukas Larsson wrote:
>
> https://github.com/erlang/otp/pull/1032

Where is the documentation?
    - what are the units in which 'size' is measured?
     It would be *very* nasty if a program that worked fine in a 32-bit
     environment stopped working in a 64-bit environment because the
     size was in bytes.

   - are size, kill, and error_logger the only suboptions?

   - what is the performance cost of this?
    (Presumably it gets checked only after a garbage collection,
    prior to increasing the size of a process.)

   - I get twitchy when a parameter that can result in the death of
    a process is defined as the sum of something that *is* under
    the process's control and something that is *not*, and further,
    how much of that uncontrolled stuff is counted is determined
    by yet another flag that wasn't there in 18.2.  As it is, the
    effect is that a process can be killed because *another* process
    is doing something bad.  What, if anything, can be done to
    prevent that needs to be explained.

  - Guidelines about how to choose sensible sizes would be valuable.
    No, wait. They are *indispensable*.

Of *course* this is useful, but it's starting to smell like
pthread_attr_setstacksize(), where there is *no* way, given even
complete knowledge of the intended behaviour of the code and
sensible bounds on the amount of data to be processed, that
you can determine a *safe* stack size by anything other than
experiment.  You are entirely at the mercy of the implementation,
and the C implementation has no mercy.

I'd personally be happier with something like ulimit(), where there
is a hard limit (the one where you kill the process) and a soft
limit (where you raise() an exception in the process to let it know
there's going to be a problem soon).

The garbage collector explanation we were recently told about is
a good beginning.  Memory management measures and options are
now so complex that we need a complete and exceedingly clear
chapter in the official Erlang documentation to explain them.




More information about the erlang-questions mailing list