This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Possible inline malloc alternatives: bitmap
- From: Paul Eggert <eggert at cs dot ucla dot edu>
- To: Ondřej Bílka <neleai at seznam dot cz>
- Cc: Carlos O'Donell <carlos at redhat dot com>, libc-alpha at sourceware dot org
- Date: Sat, 3 Mar 2018 12:24:20 -0800
- Subject: Re: Possible inline malloc alternatives: bitmap
- Authentication-results: sourceware.org; auth=none
- References: <20180301213318.GB3062@domone> <085a3206-4ae8-5d0a-800c-134d9d508ba1@redhat.com> <6d67177c-4cfe-4eba-ab27-6f75d74ca63e@cs.ucla.edu> <20180303125546.GA6516@domone>
Ondřej Bílka wrote:
This is paywalled so I didn't read it.
You can freely read an older NightWatch paper here:
Guo R, Liao X, Jin H, Yue J, Tan G. NightWatch: Integrating Lightweight and
Transparent Cache Pollution Control into Dynamic Memory Allocation Systems.
USENIX ATC. 2015. 307-18.
https://www.usenix.org/system/files/conference/atc15/atc15-paper-guo.pdf
Although NightWatch's source code is freely readable (it's on GitHub), it does
not specify a software licence so I have not read it and don't recommend that
you read it.
One problem is that it merges several different issues.
Yes, a problem common to many systems papers.
I didn't quite follow your profiling proposals. As near as I can make out you'd
like to log calls to malloc, free, etc. But for good results don't you also need
to log memory accesses? Otherwise how will you know which objects are hot?