diff options
author | Richard Carlsson <[email protected]> | 2011-08-13 21:28:16 +0200 |
---|---|---|
committer | Björn Gustavsson <[email protected]> | 2011-08-15 16:47:13 +0200 |
commit | caad36a5e2fc09d6a416fe31a7053bdfdb35c62d (patch) | |
tree | a2ceb31c3254d58c5859ae40cb39ae2100409266 /EPLICENCE | |
parent | 4a5a75811e2cd590b5c94f71864a5245fd511ccf (diff) | |
download | otp-caad36a5e2fc09d6a416fe31a7053bdfdb35c62d.tar.gz otp-caad36a5e2fc09d6a416fe31a7053bdfdb35c62d.tar.bz2 otp-caad36a5e2fc09d6a416fe31a7053bdfdb35c62d.zip |
fix 64-bit issues in the garbage collection
We discovered that if a single Erlang process tried to grow above 32
GB (i.e., more 64-bit words than can be counted by a 32-bit number),
the VM failed to find the next larger heap size, even though there
were plenty more heap sizes left to pick from and even though we had a
lot more memory available on the machine. (Obviously, this is only
applicable on 64-bit Erlang.)
It turned out to be due to some 'int' variables in the heap resizing
parts of erl_gc.c not being properly updated to 'Uint' or 'Sint'. Once
that was fixed, I got segfaults instead as soon as the heap got larger
than 2^32 words, due to even more 'int' declarations in the same file,
but now in the GC code.
After fixing this as well, I successfully ran an Erlang node in which
a single Erlang process had a heap so large that I'm not at liberty to
divulge the exact size, but I think the scientific term is
"humongous", and I'm confident that there are no further immediate
problems with very very large individual process heaps.
Diffstat (limited to 'EPLICENCE')
0 files changed, 0 insertions, 0 deletions