[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

CPU affinity on SMP systems and SableVM



Hello!

You may remember that with some of your help I have done basic port
of SableVM to IA64 architecture. Now the time has come to finish
the work and get the fastest way of how SableVM can work.
It's called inlined-threading engine and is about 3 times faster
than currently used (on IA64) direct-threading engine.

Unfortunatelly inlined-threading engine makes some assumptions
about for ex. cache<->memory coherency. And it can only work
on non-SMP, uniprocessor systems (for now, but it's non-trivial
task to get it *really* working on SMP systems).

The problem is that all IA64 machines available to Debian developers
are SMP systems. So for me to finish porting there are apparently
two options:

1. Get access to non-SMP IA64 system to make the port.
2. Use CPU-affinity on SMP system to workaround the problem.

As it's not directly clear why a JVM can be non-working on SMP
systems here's an explaination from SableVM author, Etienne Gagnon.

<<In order for "thinlocks" to work on SMP, one must issue cache-specific
instructions (flush), so that the semantics of Java monitors are
fulfilled.  As the cache design and instructions of SMP systems vary
widely, it is difficult to encode these instruction in an efficient
& portable manner.  The cache desing of an SMP system has many side
effects on the internal requirements for consistency in a JVM.
  For example, the JVM must deal with dynamic loading, lazy method
preparation and many other things for which, sometmes, using standard
heavy-weith synchronization would kill the performance of the JVM.
For this reason, to date, no Free/Commercial JVM is consisten with the
JVM specification in regards to the "Java memory model". In fact, many
JVMs can yeild undefined behavior in certain occasions.
  As the SableVM project tries to build a robust system, it was decided
that not supporting SMP in the first version was better than supporting
a faulty model, and then try to retrofit fixes.
  In summary: Doing correct execution of Java bytecode and keeping
internal JVM data structures integrity on SMP systems is difficult.
  The SableVM project wants to first make the JVM robust on
uni-processors, then when this is done, SMP problems will be addressed.
Even most other Free JVMs such as gij are already broken in respect to
SMP systems.  In fact, gij is even broken for muti-threaded programs on
single-processor systems. So, it would be a gain, overall, to at least
have one highly portable Free "unbroken" JVM for multi-threaded programs
on single-processor (or affinity) systems.>>

As for no.1 option - I'd be very grateful for access to such system
because it's easier for everyone, me including. So if anyone could
help here - please stand up.

As for no.2 option - unfortunatelly it requires at least kernel patch.
http://www.kernel.org/pub/linux/kernel/people/rml/cpu-affinity/v2.4/cpu-affinity-rml-2.4.18-1.patch
There are two version of the patch - one uses /proc (above link),
the second uses syscals but that requires glibc patch. [0]

I belive I could just set CPU affinity at the start of SableVM and
then work just like on uniprocessor system.

I am *seriously* interested in getting SableVM fully work on IA64.
So if you could give me any help that would allow me to finish
the work - I'd be very thankful.

Best regards

					Grzegorz B. Prokopski

[0]
http://www.kernel.org/pub/linux/kernel/people/rml/cpu-affinity/README-cpu-affinity
-- 
Grzegorz B. Prokopski <gadek@debian.org>
Debian http://www.debian.org/

Attachment: signature.asc
Description: PGP signature


Reply to: