[llvm-dev] RFC: EfficiencySanitizer working set tool

Derek Bruening via llvm-dev llvm-dev at lists.llvm.org
Wed Apr 20 10:43:57 PDT 2016

On Wed, Apr 20, 2016 at 1:15 PM, Filipe Cabecinhas <filcab at gmail.com> wrote:

> On Wed, Apr 20, 2016 at 6:44 AM, Derek Bruening via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
> > We will divide the program execution into regular intervals and record a
> > snapshot of the working set at each interval boundary.  An adaptive
> strategy
> > can keep the number of snapshots bounded across varying total execution
> time
> > by combining adjacent snapshots via logical or.  When a snapshot is
> > recorded, the shadow memory is cleared so that the next snapshot starts
> with
> > a blank slate.  If we use a 64 byte to 1 byte shadow mapping, we can use
> the
> > upper bits to store up to 8 consecutive snapshots in the shadow memory
> > itself by shifting rather than clearing the shadow memory on a snapshot.
> I forgot to add my previous questions:
> About the working set tool:
> How are you thinking about doing the snapshots? How do you plan to
> sync the several threads?
> Spawning an external process/"thread" (kind of like LSan), or internally?
> I know I'm getting to low(ish)-level details, but if you've already
> thought about this (possibly about several ways to do this), I'd like
> to know more about what avenues you're planning on exploring.
> I'm ok with a "we haven't thought that far ahead about this tool yet" :-)

Our plan is to live with races between shadow memory updates in other
threads and the thread making a copy of the shadow memory.  The nature of
the tool means that pinpoint accuracy is not required.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160420/02fe9be3/attachment.html>

More information about the llvm-dev mailing list