Re: [Sablevm-developer] Instruction cache flush (non)portability

[Etienne M. G. <eti...@uq...>]

Hi Grzegorz,

You are doing some very interesting work.

A simple comment: we will probably need to be ready to fine tune the
flushing strategy for specific architectures.  Should we act upon the
"data" cache or the "instruction" cache, or both, and what is the
ideal granularity of this action (single word (or cache line), or
general flush), what do we flush (write back buffer only, all entries
in the cache, ...). Yep, a lot of fun ahead...

The simplest strategy, on the short term, would be a full cache flush
( of both instruction and data caches). As this only happens "once"
for each executed method (at the end of method preparation), the
simple approach might have no significant impact on the running time,
while allowing the inline-threaded engine to work on modern
processors.

Of course, once we're done with the inline-threaded engine, we will
have to attack the multi-processor cache coherency problem...

Thanks a lot for this very important work.

Etienne

On Tue, Nov 19, 2002 at 11:11:41PM +0100, Grzegorz Prokopski wrote:
> W li?cie z wto, 19-11-2002, godz. 18:23, Grzegorz Prokopski pisze: 
> > Hi!
> I was a bit in a hurry, so see the corections below.
> 
> (below paragraph is about already compiled binary version
> of sablevm which should survive upgrade of glibc, gcc etc.)
> > It's even more complicated if we link to that symbol and it's
> > definition changes. On i386 (and most of the arches) we're
> > _staticly_ linked to libgcc2 library (which contains the symbol).
> > Thus - we don't have to worry about gcc upgrades etc.
> > However on some arches, like m68k
> this lib (libgcc2) is dynamically linked with every program
> > - or so I was told
>  
> > I personally would vote that we use this symbol in one of next
> > versions, after my old "every arch" patch is applied.
> Not sure yet, but it would be possible to use
> #include <linux/types.h>
> when available and fallback to autodetection when it fails.
> 
> BTW: I was yet unable to actually test that __clear_cache
> function (sorry), because it does nothing for i386 and Bdale
> is very busy today so we haven't managed to test that for ia64
> yet :-/
> 
> (I have assembler version for ia64 ready for another test anyway)
> 
> 					GBP
> 
> 



-- 
Etienne M. Gagnon                    http://www.info.uqam.ca/~egagnon/
SableVM:                                       http://www.sablevm.org/
SableCC:                                       http://www.sablecc.org/