sablevm-developer

[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

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/

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

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

On Thu, Nov 21, 2002 at 11:54:04PM -0500, Etienne M. Gagnon wrote:
> Yes, automating the inlinability flagging would be an interesting
> thing to do, but until them , there's a semi-automatic method:

What was I thinking!  There's a simpler semi-automatic method:

1- Compile SableVM with all debug options. e.g.
   ./configure --enable-debugging-features

2- Run SableVM with tracing on;

sablevm -v -p sablevm.verbose.methods=true -p sablevm.verbose.instructions=true HelloWorld

Be ready to see a lot of text.

The thing is that it does give you a pretty good idea of where execution stopped.

You'll be amazed how much code needs to run just to execute HelloWorld. :)

I hope this helps.

Etienne

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