Re: [Sablevm-developer] Implementing Deadlock Exceptions for SableVM

[Fancong Z. <fz...@cs...>]

> On Tue, Apr 20, 2004 at 10:58:25AM -0400, Fancong Zeng wrote:
> > Hi,
> > 
> > I just read your Ph.D. thesis. I like your extension of thin locks. 
> 
> Note that the deflation part of Onodera's algorithm could still be
> implemented, and also that when releasing a thin lock that was under
> contention, while it's not _necessary_ to inflate it, in some
> cases it is faster.  So, there are still some neat things to be done,
> but as to how they affect performance, you'd need a pretty
> lock-intensive program to see the benefits.

They recently have some idea called "lock reservation" for Java locks. The
idea is in OOPSLA'02 and ECOOP'04.
 
> > I am now looking into the SableVM system and I hope SableVM has
> > the following features:
> > 
> > 1) Being able to run large real-life sever programs. E.g., Tomcat.
> > 2) Supporting true parallelism. This requires kernel-level preemptive 
> > thread scheduling and SMP support --- I noticed a note about flaws in SMP,
> > possible to improve the SMP support?
> 
> You should read Doug Lea's JSR-133 cookbook, for a discussion of how
> compiler and VM developers can implement fixes for the Java Memory
> Model, which is currently broken.  These things affect all VM's.
> 
> http://gee.cs.oswego.edu/dl/jmm/cookbook.html

I haven't read the cookbook. Will read it soon. I read some papers by
Bill Pugh on JMM.

> I put StoreLoad barriers in the right places for x86-PO architectures,
> and some inline assembly is required for the others.  AFAIK, SableVM
> doesn't treat Java volatiles explicitly, and the easiest / most
> efficient solution I can see is to use our Soot compiler framework to
> either supply attributes to SableVM telling it where barriers are
> needed, or to insert dummy method calls that are recognized by SableVM
> at runtime and turned into SableVM-specific barrier instructions
> during code preparation.  I haven't heard Etienne comment on these
> ideas about volatiles though.

I like the idea of using SOOT to add attributes to bytecode, and making
the
JVM exploit the attributes at runtime. In general, this is a promising
direction of integrating static and dynamic analyses.

> After this, I don't think there will be _too_ many problems with
> multiprocessors.  There have been / still are issues with respect to
> thread initialization, but I have run several different
> multithreaded benchmarks on an SMP machine (mtrt, and most of the Java
> Grande Forum threaded benchmarks).  The best is if you try it out for
> yourself with the applications you're interested in.

I would be more itnersted in running some server programs like Muffine,
Tomcat, etc.

> > 3) Accomodating JIT compilers seamlessly. I have some ideas to have
> > a JIT generate recovery code, and I expect to see the JIT
> > compilers to be incorporated to (the public version of) SableVM.   
> > 
> > Any comments/information on the three issues I list above?
> > 
> 
> That's it for what I know :) I should mention that when we do find
> problems with the implementation and decide on a solution, it's
> typically a very small amount of code that must be changed; the
> structure is clean and the right hooks are in place.  Also Subversion
> is a joy to work with ;)

When will you release SAbleJIT to public? Within 3 months?

> Cheers,
> Chris
> 

Best,

Fancong