|
From: Andrew Y. <you...@gm...> - 2017-09-18 16:26:26
|
Hi Valgrind devs, Recently, Eclipse OMR[0] had a GSOC student complete a project to add Valgrind Memcheck support to the Garbage Collector component, using the Memory Pool API[1]. This is the garbage collector used in IBM's J9 JVM. We did have one problem: we had to add a new memory pool client request to Valgrind to get this working cleanly. What I want to know is if you would be interested in this API, so I can decide if it is worth completing the work (tests, docs, etc.), or if we should stick with the complicated work around. The actual API is simple: VALGRIND_MEMPOOL_CLEAR(pool, addr, size) Remove all chunks associated with `pool` from `address..address+size` as though they had `VALGRIND_MEMPOOL_FREE` called on them. I am open to suggestions on a better name (maybe VALGRIND_MEMPOOL_SWEEP?). This API is actually the opposite of VALGRIND_MEMPOOL_TRIM(pool, addr, size), which trims (i.e. VALGRIND_MEMPOOL_FREEs) all objects *outside* of a range. This makes the implementation very simple, as we can just copy what VALGRIND_MEMPOOL_TRIM. This API is used during the sweep phase of a GC. When sweeping the heap, free regions of memory have VALGRIND_MEMPOOL_CLEAR on them. The reason why existing API did not suffice is because they require us to call VALGRIND_MEMPOOL_FREE on every object which is free'd. The GC only keeps track of which objects are currently alive, it cannot tell if an object was actually free'd during a GC in any of the regions which were swept. We could theoretically work around this limitation by walking a swept region of memory, and calling VALGRIND_MEMPOOL_FREE on each address. Let me know what you think. I personally think this would be a great addition to the memory pool API, and it should make it easier for other mark-and-sweep garbage collectors to start using Valgrind. Best regards, Andrew Young [0] https://github.com/eclipse/omr [1] https://github.com/eclipse/omr/pull/1311#issuecomment-330190951 |