On Mon, Nov 26, 2018 at 11:02:24 +0000, Alex Bennée wrote:
> Emilio G. Cota <c...@braap.org> writes:
> > On Fri, Nov 23, 2018 at 17:00:59 +0000, Alex Bennée wrote:
> >> What is the purpose of letting the plugin know a flush has occurred?
> >
> > Plugins might allocate per-TB data that then they get passed each
> > time the TB is executed (via the *userdata pointer). For example,
> > in a simulator we'd allocate a per-TB struct that describes the
> > guest instructions, after having disassembled them at translate time.
> >
> > It is therefore useful for plugins to know when all TB's have been
> > flushed, so that they can then free that per-TB data.
>
> Would they need a generation count propagated here or would it just be
> flush anything translation related at this point?
The callback is guaranteed to be called in an exclusive context, so
plugins can just rely on that; since no code execution can happen at
that time, there's no need to pass further info, since the plugins
can free that data right from the callback.
> >> It shouldn't have any knowledge of the details of liveliness of the
> >> translated code and if it still exits or not. If all it wants to do is
> >> look at the counts then I think we can provide a simpler less abuse-able
> >> way to do this.
> >
> > I'm confused. What does "look at the counts" mean here?
> >
> > To reiterate, plugins should have a way to know when a TB doesn't
> > exist any longer, so that they can reclaim memory.
>
> OK that makes sense. Could you expand the commit message just to explain
> the use case?
>
> Reviewed-by: Alex Bennée <alex.ben...@linaro.org>
Updated the commit message with:
translate-all: notify plugin code of tb_flush
Plugins might allocate per-TB data that then they get passed each
time a TB is executed (via the *userdata pointer).
Notify plugin code every time a code cache flush occurs, so
that plugins can then reclaim the memory of the per-TB data.
Thanks,
Emilio
