x86 jitter

Ian Piumarta Ian.Piumarta at inria.fr
Mon Apr 9 04:30:11 UTC 2001


On Sun, 8 Apr 2001, Tom wrote:
> On Sun, Apr 08, 2001 at 01:22:21PM -0700, Raab, Andreas wrote:
> > > * If so, where does it do this? (into malloc'd memory)?
> > Yes.
> 
> 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.

Besides, on Intel it doesn't matter: insn fetch snoops on the d-cache.  
The i/d-caches therefore _always_ appear consistent.  (J3's cache flushing
routine on Intel is a no-op.)

The problem is generally the other way round (assuming you have a real
processor which doesn't snoop).  After writing insns into memory, you need
to flush part of the d-cache and then invalidate the corresponding part of
the i-cache before attempting to run the code.  But you only need to do
this once, any time between generating the code and executing it.  (Or if
you ever do a compacting collection on the memory in which your code is
stored.)

If you have some other argument as to why running code in malloc()ed
memory is dangerous, I'd very much like to read a detailed explanation of
the problem!

Ian








More information about the Squeak-dev mailing list