Is there an equivalent of __clear_cache in the NDK?

[Paul Holland]

We have a JIT that we want to run on Android and need to call whatever
the equivalent of __clear_cache is after new instructions have been
written to RAM and prior to executing that code. Dalvik's JIT must do
something like this. Is there some function exported by the NDK for
this purpose?

[koba]

Hi,

I also used to make JIT compiler.
ARM linux kernel has a system call to flush cache. You can invoke
system call by "swi" instruction.
Try google "arm linux cacheflush swi" to get more info.

[Paul Holland]

Thanks koba,

I had see these references in previous Google searches. But what I am
looking for is a mechanism that Google will support as the official
way of doing this for Android.

[David Turner]

There is cacheflush() which is a kernel system call defined in <unistd.h> as:

int  cacheflush(long start, long end, long flags);

Note that this is only available on ARM kernels as far as I know.
It is used with flags == 0 by pixelflinger to flush the instruction cache (pixelflinger has a small JIT to generate optimized rendering loops)

Apart from that __clear_cache() is a gcc built-in. I believe it is used by the Dalvik VM to perform cache flushing too.

[John Ripley]

There's always the posix standard "msync" call, e.g:

  msync(address, 4096, MS_SYNC | MS_INVALIDATE);

This is a bit brutal, though: it'll commit/clean, flush and invalidate instruction and data caches (all levels), TLBs and so on, for the specified range. It's not slow, but if you're doing tons of self-modifying code (e.g a JIT) it'll take a small fraction out of your runtime speed.

I'm also not entirely sure modern ARM Linux kernels do the right thing with msync(). The kernel implementation looks entirely different from the last time i saw it a couple of years ago :)

Failing that, the kernel 'swi' interface is pretty stable. It's been around like that for about, hmm, 6-7 years I think? You can always use 'swi' if building for ARM targets, and fall back to msync() otherwise.

2009/8/14 Paul Holland <phol...@adobe.com>