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

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

On Thu, Nov 21, 2002 at 10:54:20PM +0100, Grzegorz Prokopski wrote:
> Thanks to Bdale I have some real results now.
> Shortly: it doesn't work!
>=20
> We tried two versions of _svmf_iflush (for ia64):
> 1)
> __asm__ __volatile__ ("fc %0;; sync.i;; srlz.i;;" :: "r"(pword));
>=20
> 2)
>   extern void __clear_cache (char *beg, char *end);
> called this way:
>   __clear_cache((char*) pword, ((char*)pword)+SVM_WORD_SIZE);

You might want to try two things:

1- Implement _svmf_iflush as a "complete flush" of *both* data AND
instruction caches.

2- To better isolate the problem, it is easiest to test with a very
small inline-threaded interpreter, rather than a full JVM. To this
end, here is a few useful URLs:

 a) The paper introducing the original inline-threading technique:

    http://www-sor.inria.fr/publi/summaries/1998/ODCSI_pldi98.html

 b) The related small inline-threaded interpreter source code:

    http://www-sor.inria.fr/~piumarta/pldi98/

Now, if you can get http://www-sor.inria.fr/~piumarta/pldi98/vm.c to
work, we'll be in shape to find out if there's any small hidden bugs
in SableVM, and/or flag appropriate instructions as "inlineable" or
not on ia64.

Yes, automating the inlinability flagging would be an interesting
thing to do, but until them , there's a semi-automatic method:

1- Do a very small change in SableVM's prepare_code file, to force
sablevm to only build inlined sequences of single instructions.

2- Run Java programs exercising most (or ideally all) bytecodes.

3- Use DDD (or gdb...) to extract explicit segfault point, and
identify the currently executed bytecode at time of signal.

4- Flag identified bytecode as non-inlineable on ia64.

5- Repeat until all programs run.

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

The segfault really seems happening in inlined code.

> 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?

Try the little vm.c program above.  I've tried it on SPARC, and it
works, indeed.  I haven't yet tried SableVM, though.

But the only difference between SableVM direct-threading engine and
the inline-threaded one, is the dispatch mechanism (e.g. inlined
instruction sequences).  So, I would suspect that getting vm.c to work
would be a first thing to try.

> 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?

Yes, we need to review the "inlinable (or not)" property of each
bytecode, for every architecture.  In reality, this is much simpler
than it looks: Most non-inlinable instructions are already identified
as such because they can be determined as such just by looking at the
C source code. E.g.: NEW, INVOKE*, ... are not inlinable.

For the remaining ones, you do as I suggested above.

> 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.

We can definitely try it too.

Thanks,

Etienne

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