ruby-changes:60200
From: Takashi <ko1@a...>
Date: Wed, 26 Feb 2020 16:49:08 +0900 (JST)
Subject: [ruby-changes:60200] 55923ba883 (master): Note a situation around xmalloc vs free in MJIT [ci skip]
https://git.ruby-lang.org/ruby.git/commit/?id=55923ba883 From 55923ba88366658c6bfdecd8b0b25070d70c569d Mon Sep 17 00:00:00 2001 From: Takashi Kokubun <takashikkbn@g...> Date: Tue, 25 Feb 2020 23:36:09 -0800 Subject: Note a situation around xmalloc vs free in MJIT [ci skip] shared by ko1 diff --git a/mjit_worker.c b/mjit_worker.c index f55942e..117bcb7 100644 --- a/mjit_worker.c +++ b/mjit_worker.c @@ -10,6 +10,19 @@ https://github.com/ruby/ruby/blob/trunk/mjit_worker.c#L10 // call Ruby methods (C functions that may call rb_funcall) or trigger // GC (using ZALLOC, xmalloc, xfree, etc.) in this file. +/* However, note that calling `free` for resources `xmalloc`-ed in mjit.c, + which is currently done in some places, is sometimes problematic in the + following situations: + + * malloc library could be different between interpreter and extensions + on Windows (perhaps not applicable to MJIT because CC is the same) + * xmalloc -> free leaks extra space used for USE_GC_MALLOC_OBJ_INFO_DETAILS + (not enabled by default) + + ...in short, it's usually not a problem in MJIT. But maybe it's worth + fixing for consistency or for USE_GC_MALLOC_OBJ_INFO_DETAILS support. +*/ + /* We utilize widely used C compilers (GCC and LLVM Clang) to implement MJIT. We feed them a C code generated from ISEQ. The industrial C compilers are slower than regular JIT engines. -- cgit v0.10.2 -- ML: ruby-changes@q... Info: http://www.atdot.net/~ko1/quickml/