aboutsummaryrefslogtreecommitdiffstats
path: root/lib/odbc/test/oracle.erl
diff options
context:
space:
mode:
authorRichard Carlsson <[email protected]>2011-08-13 21:28:16 +0200
committerBjörn Gustavsson <[email protected]>2011-08-15 16:47:13 +0200
commitcaad36a5e2fc09d6a416fe31a7053bdfdb35c62d (patch)
treea2ceb31c3254d58c5859ae40cb39ae2100409266 /lib/odbc/test/oracle.erl
parent4a5a75811e2cd590b5c94f71864a5245fd511ccf (diff)
downloadotp-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 'lib/odbc/test/oracle.erl')
0 files changed, 0 insertions, 0 deletions