sablevm-developer

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

[Grzegorz P. <ga...@de...>]

Hi!

I have spent most of today's day searching for ways
to flush instruction cache in any more portable way,
than writing the "right" assembler for every arch.
Here's what I found out.

There's no exported and usable interface for this in
neither glibc nor gcc nor kernel headers, nor linux
headers (/usr/include/linux, /usr/include/asm).
There were such proposals, but none of them resulted
in anything usable by us.

From our POV we need simply a function
flush_icache_range(void *from, int len),
where len is same as word size for current arch.

However be warned, that this function not that simple
for some architectures and may require kernel function
call for ex. Other problem is that it's sometime cheaper
to clear all of the cache than flushing specific part
(don't ask me, that's what I found in gcc sources).

So if we don't want to implement needed assembler/other
not-that-nice-and-clean things ourselves for every
arch we want to support "inlined" engine on - we have
only one solution (it seems).

We need to link to __clear_cache symbol that comes from
gcc. It's GPL symbol, but with exception for when the usage
of it is because of gcc usage - so we fall under this anyway.

The upside is that we can simply define:
extern void __clear_cache (char *beg, char *end)
and just use it.

The downside is that
- this is internal symbol and as such may be subject to
change w/o prior notoice (not saying anything about backward
compatibility)
- it's only portable across arches where we use gcc (not that
big problem ATM anyway)

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 - or so I was told.

Upside once again:
- I doubt the symbol will change in some dramatical way.
In such case we could either reflect the change in our code
or
- we can always disable "inlined" engine for selected arches
(until a fix/other solution is found) but still support them.

I personally would vote that we use this symbol in one of next
versions, after my old "every arch" patch is applied.

What do you think?

				Grzegorz B. Prokopski

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

[Grzegorz P. <ga...@de...>]

W li=B6cie z wto, 19-11-2002, godz. 18:23, Grzegorz Prokopski pisze:=20
> 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
=20
> 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

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/

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

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

Hi Grzegorz,

Regarding the #include <linux/types.h> suggestion.

What is the license of <linux/types.h> ?  If it is the GPL, then we're ou=
t of=20
luck, as it would force us to GPL the whole SableVM code, and probably th=
e class=20
libraries too (making the Classpath exception useless).  I really hope it=
 is the=20
LGPL...

Did you investigate whether GNU libc had a similar include file?  GNU lib=
c is=20
LGPLed, and would cause no license related problems.

I know, these license things can seem quite annoying, but it's the right =
of the=20
copyright holder to determine the license terms on the code they write.

Etienne

Grzegorz Prokopski wrote:
> W li=B6cie z wto, 19-11-2002, godz. 18:23, Grzegorz Prokopski pisze:=20
>=20
>>Hi!
>=20
> I was a bit in a hurry, so see the corections below.
>=20
> (below paragraph is about already compiled binary version
> of sablevm which should survive upgrade of glibc, gcc etc.)
>=20
>>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
>=20
> this lib (libgcc2) is dynamically linked with every program
>=20
>>- or so I was told
>=20
> =20
>=20
>>I personally would vote that we use this symbol in one of next
>>versions, after my old "every arch" patch is applied.
>=20
> Not sure yet, but it would be possible to use
> #include <linux/types.h>
> when available and fallback to autodetection when it fails.
>=20
> 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 :-/
>=20
> (I have assembler version for ia64 ready for another test anyway)
>=20
> 					GBP
>=20
>=20

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