Open angussidney opened 3 years ago
The most obvious (but slowest) strategy to tackle this problem is to trawl through the code and classify all existing uses of objspace_xmalloc0
. Although Chris' team has offered their knowledge of the Ruby codebase to try and speed up this process, it is still going to be slow, boring and may introduce bugs.
Another strategy that I thought of was to utilise objspace_xfree
to help detect all instances of memory that should be explicitly managed. Currently, there is a check to avoid free()
ing MMTk managed memory. However, if we chuck a breakpoint on the inside of this if
statement, we can see whenever a chunk of memory is explicitly freed, and then work backwards to determine why it was incorrectly allocated. I'm not sure how this will work in practice, but it's worth a try.
Ideally, all memory allocated by Ruby should be separated into two types:
Currently, all of the 40-byte slots are allocated with
newobj_of
, which has been modified to use MMTk. This has been implemented as it semantically should.However, most other memory allocation is performed using
objspace_xmalloc0
(or an alias thereof), which is a wrapper aroundmalloc
. This function is used for both memory that is logically part of the GCed heap, and memory that should be explicitly managed. Currently, I have modified this function to call MMTk'salloc
; however, this has the side affect that some memory is being managed by MMTk when it really should be explicitly managed. This should be fixed before we make too much progress on actual GCs, because it may introduce bugs later down the line.