[Sablevm-developer] Instruction cache flush - ia64 experience report

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

Hi!

Thanks to Bdale I have some real results now.
Shortly: it doesn't work!

We tried two versions of _svmf_iflush (for ia64):
1)
__asm__ __volatile__ ("fc %0;; sync.i;; srlz.i;;" :: "r"(pword));

2)
  extern void __clear_cache (char *beg, char *end);
called this way:
  __clear_cache((char*) pword, ((char*)pword)+SVM_WORD_SIZE);

* all build were done with --with-threading=inlined
* first build gave this:
/usr/lib/sablevm/bin/java -jar ./HelloWorld.jar 
sablevm: cannot create vm
* Bdale rebuilded with --disable-signals-for-exceptions
the result was: Segmentation fault
but I got strace and dbg output (both attached).

Now a few words to Etienne.

1.Can you find anything looking at the logs? ( ;-)

2. FWIK you haven't tested SableVM on any other arch than
i386 with inline threading enabled? If so - how can you be
sure that even if _svmf_iflush does it's work well - it's
enough to get the engine working right in inlined mode?

3. Looking at the backtrace; I'd suspect, that the first
address 0x600000000001d410 is where inline engine has put
the code for execution but sth. didn't work right.
Sth. like the code cache which hadn't been flushed right.

4. Threading engine on RISC machines.
Once you were explaining me, that you can only inline
parts which don't contain jumps. But if you compare RISC
and CISC arches (in general) - it's quite common that task
which can be done w/o a jump on CISC - can't be done this
way on RISC where a jump is needed. Ain't this affecting
the whole idea of threading engine? Wouldn't that force
us to reviev the code generated by every compiler and for
every single arch to find the pieces we can inline?

BTW: in gcc 3.0.4 sources __clear_cache is still there,
w/o visible changes compared to 2.95. So if that's all we
need - we should just use it and go on with other things IMO.

That's all for now.

				Grzegorz B. Prokopski