x86 jitter

Tom tmb at lumo.com
Mon Apr 9 04:54:22 UTC 2001


On Mon, Apr 09, 2001 at 06:30:11AM +0200, Ian Piumarta wrote:
> > However, if you ever free or garbage collect that memory, you have to
> > flush the instruction cache, or you are going to get some very strange,
> > very intermittent bugs.
> 
> Why?
> 
> If you ever execute code in memory that you have free()d, then your
> program has a "dangling pointer" bug.
> 
> And if your processor ever executes instructions from your memory after
> you've free()d it, just by virtue of them sharing a cache line with an
> insn from somewhere else, then your processor implementation is flawed for
> not having refilled the cache line all by itself, during insn fetch.  (The
> 68040 had a wonderful bug in exactly this part of its implementation.)
> 
> And after a free(), if any other part of your system receives the same
> memory for running code out of, it will certaily re-sync the caches before
> calling into it.

That's all I'm saying (in response to the question that was posted
"can you execute inside malloc'ed memory"): if a program mallocs and
frees memory containing executable code repeatedly, something needs to
flush the cache at some point on many processors.  Furthermore, since a
program generally can't tell whether it's "the same" memory, it needs
some convention whether the cache is flushed on "free" or flushed on
"malloc" (I think the latter is clearly preferable).

OTOH, you don't have to flush anything ever if you know that all
dynamically generated code hangs around forever (as it does in many
systems).

Cheers,
Tom.





More information about the Squeak-dev mailing list