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

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

> > > 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.
> 
> You might want to look at Feng Qian's work in our lab on array bounds
> check elimination in JikesRVM.  I'm using Soot myself for a
> speculative multithreading project in SableVM.
> 
> http://www.sable.mcgill.ca


I read many papers of you guys. Actually I am considering using SOOT 
in my current work for Java Deadlocks. If I have questions in using SOOT,
can I trouble you guys (maybe via personal communications or another
mailing list)?
  
  
> > > 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.
> 
> I don't know anything about these programs.  The best thing is just to
> try them.  SableVM is now relatively painless to install.
>  
> > > > 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?
> 
> I'll let David field that one :)

I hope to see SABLEJIT soon.

Fancong