adr/2023-04-libxml-memory-management.md
ruby_xmalloc and ruby_xfree functions in libxml2Affirming the status quo since 2009 -- to use ruby_xmalloc et al -- but alternative behavior can be opted into by setting an environment variable:
# "default" here means "libxml2's default" which is system malloc
NOKOGIRI_LIBXML_MEMORY_MANAGEMENT=default
ruby_xmalloc and ruby_xfreeSince 2009, (0dbe1f82), Nokogiri has configured libxml2 to use ruby_xmalloc et al for memory operations by making this call in Init_nokogiri:
xmlMemSetup(
(xmlFreeFunc)ruby_xfree,
(xmlMallocFunc)ruby_xmalloc,
(xmlReallocFunc)ruby_xrealloc,
ruby_strdup);
The reason for doing this is so that Ruby's garbage collection ("GC") subsystem can track the total heap size, including malloc calls by C extensions, and is then able to trigger a GC cycle if the total amount of allocated memory exceeds a limit.
@SamSaffron has a great post that explains how this works, and the antipatterns that can emerge if Ruby is not aware of large amount of allocated memory, and I highly recommend that you read it for context:
We've recently run into a few situations where using ruby_xmalloc et al was problematic.
atexit handler called ruby_xfree after ObjectSpace was torn down, causing a segfaultruby_xmalloc and ruby_xfree) while finalizing a Document, preventing the use of RUBY_TYPED_FREE_IMMEDIATELY for Documentsruby_xfree after ObjectSpace was torn down, causing a segfaultAll the issues have the same root cause: calling ruby_xfree in an inappropriate situation, either:
These situations would not be inappropriate for using system malloc and free.
Using ruby_xmalloc and ruby_xfree has a real performance penalty, as well. Benchmarks at https://github.com/sparklemotion/nokogiri/pull/2843 indicate this penalty can make document parsing up to 34% slower than when the system malloc and free are used.
mallocThe primary alternative considered is defaulting to using the system malloc and free.
However, Sam's blog post (as well as other anecdotal data) makes a great case for being extremely careful about the choice of memory management functions.
Without more data, we're declining to change this behavior. But we are introducing the ability to collect some data by providing a runtime option for selecting the memory management suite.
mallocMaybe it's possible to build custom memory management functions that perform better but have some of the benefits of the ruby allocator? This feels well beyond the scope of a C extension.
After an inspection of the ruby memory management functions, it wasn't obvious to the author that there's an obvious performance win by eliminating one or the other of a) conditionally invoking GC if malloc fails, or b) tracking the number of bytes allocated using rb_gc_adjust_memory_usage.
We would welcome experimental results if other people are motivated to try something like this, though.
We're sticking with ruby_xmalloc et al for now. But we're also introducing an environment variable to allow people to experiment with the system malloc if they wish.
No changes to the status quo.
Memory-related issues:
Upstream libxml2 exit-time issues, commits, and discussion:
Performance-related discussion: