Although it is not used externally by node, it is needed by upstream and Plask.
This effectively reverts:
commit 1444801374
Author: Aaron Jacobs <jacobsa@google.com>
Date: Thu Mar 15 13:26:35 2012 +1100
typed arrays: unexport SizeOfArrayElementForType()
It isn't used anywhere else, so made it an implementation detail in
v8_typed_array.cc.
Work around an issue with the glibc malloc() implementation where memory blocks
are never returned to the operating system when they are allocated with brk()
and have overlapping lifecycles.
Fixes#4283.
OR'ing together two large values, like `SSL_OP_ALL | SSL_OP_NO_TICKET`,
produces a negative number. To wit:
assert((0x80000000 | 0x4000) === -0x7fffc000); // true
assert((0x80000000 | 0x4000) === 0x80004000); // false!
It's easy to work around by doing a logical shift, like this:
assert((0x80000000 | 0x4000) >>> 0 === 0x80004000); // true
But that's not very intuitive. Let's be more lenient in what we accept.
The purpose of this file was to remap the old libeio API to the new one.
We dropped libeio in ee77a6a and this file has been broken ever since.
Ergo, remove it.
* Added isIP method to make use of inet_pton to cares_wrap.cc
* Modified net.isIP() to make use of new C++ isIP method.
* Added new tests to test-net-isip.js.
Inform V8 that the zlib context object is tied to a large off-heap buffer.
This makes the GC run more often (in theory) and improves the accuracy of
--trace_external_memory.
In zlibBuffer(), don't wait for the garbage collector to reclaim the zlib memory
but release it manually. Reduces memory consumption by a factor of 10 or more
with some workloads.
Test case:
function f() {
require('zlib').deflate('xxx', g);
}
function g() {
setTimeout(f, 5);
}
f();
Observe RSS memory usage with and without this commit. After 10,000 iterations,
RSS stabilizes at ~35 MB with this commit. Without, RSS is over 300 MB and keeps
growing.
Cause: whenever the JS object heap hits the high-water mark, the V8 GC sweeps
it clean, then tries to grow it in order to avoid more sweeps in the near
future. Rule of thumb: the bigger the JS heap, the lazier the GC can be.
A side effect of a bigger heap is that objects now live longer. This is harmless
in general but it affects zlib context objects because those are tied to large
buffers that live outside the JS heap, on the order of 16K per context object.
Ergo, don't wait for the GC to reclaim the memory - it may take a long time.
Fixes#4172.
Fix a use-after-free bug and a memory leak in the error path of
DiffieHellman::ComputeSecret().
* the BIGNUM key was used after being freed with BN_free().
* the output buffer was not freed
Make buffers report the proper retained size in heap snapshots.
Before this commit, Buffer objects would show up in the heap profiler as being
only a few hundred bytes large, even if the actual buffer was many megabytes.
isaacs
Dean McNamee
Ben Noordhuis
Bert Belder
Fedor Indutny
Scott Blomquist
Sergey Kholodilov
Nathan Rajlich
Joshua Erickson
Anthony Pesch
Jan Wynholds
Aaron Jacobs
Andrew Paprocki
koichik