Mesh: a new approach to memory compaction for C/C++

Gregor Mückl gregormueckl at gmx.de
Tue Sep 24 13:24:34 UTC 2019


On Sunday, 22 September 2019 at 16:15:08 UTC, Emery Berger wrote:
> On Wednesday, 18 September 2019 at 09:31:07 UTC, Gregor Mückl 
> wrote:
>> On Tuesday, 17 September 2019 at 11:42:51 UTC, Per Nordlöw 
>> wrote:
>>> strangeloop talk here:
>>>
>>> https://www.youtube.com/watch?v=c1UBJbfR-H0
>>>
>>> and github repo here:
>>>
>>> https://github.com/plasma-umass/Mesh
>>>
>>> Sounds to me like making D's GC precise by default to enable 
>>> memory compaction is worth pursuing.
>>
>> I'm am thinking about the implications for debugging. Mapping 
>> the same page to two virtual memory addresses on the heap 
>> creates weird situations where writing over the bounds of one 
>> object doesn't trash allocations with nearby memory addresses, 
>> but can affect seemingly far away allocations that ended up 
>> randomly aliased to the same page. Even worse, Mesh randomizes 
>> allocations within pages to get more opportunities to alias 
>> pages. This means that some heap-smashing bug will likely 
>> present itself differently on each run. Have fun finding the 
>> root cause of that :/.
>
> You can always seed the random number generator with a fixed 
> value to get reproducible runs.
>
> More interestingly, it's also possible to exploit an 
> Exterminator-like approach  (see 
> https://people.cs.umass.edu/~emery/pubs/p87-novark.pdf) to 
> automatically find the source of such bugs! This is 
> specifically enabled by randomization. We implemented 
> Exterminator for a previous randomizing allocator (DieHard: 
> code here, including Exterminator -- 
> https://github.com/plasma-umass/DieHard), and there's no 
> technical barrier to doing the same for Mesh.
>
> -- emery (Mesh co-author)

I've recently had a cursory look into some of the work of your 
group. You've got some wonderfully crazy ideas and it's nice to 
see the proofs of concept.

I'm not sure I see the practical value of Exterminator for 
application developers. As I understand it, MS included a 
derivative of DieHard on Windows to be able to cheat misbehaving 
applications into crashing less often. As I see it, this is a 
pretty desperate workaround for when you can't fix the actual bug 
directly.

I am really curious about one thing: what can Exterminator do 
that valgrind cannot when I'm debugging a program locally? For 
the sake of discussion, let's assume that valgrind gets full heap 
allocation information from the GC (which currently isn't the 
case for the D garbage collector as I understand it; other GCs 
like moarvm's have that integration).

Also, to put my foot squarely into my own mouth: I have a fair 
bit of reservation regarding probabilistic algorithms on a system 
level. I generally prefer the underlying systems I work with to 
be as deterministic as possible. I also develop Monte Carlo 
simulations for a living... ;)


More information about the Digitalmars-d mailing list