[Soot-list] Using soot to optimize transactional memory

[Richard L. Halpert]

Arie,

This type of work was actually one of our top suggestions for future work
when we published in PACT 2007 and my thesis.  The information needed to
automatically allocate locks is exactly the same info needed to optimize
transactional memory: which objects might have concurrent accesses.

The soot.jimple.toolkits.thread.synchronization package contains code that
does lock allocation.  This particular code uses existing synchronized
regions/methods as its *Critical Sections*, but the bulk of the code is
general-purpose and could be made to work with different input and output.
The lock allocation uses points-to analysis, may happen in parallel
analysis, thread local objects analysis, and side effects analysis to
determine which field accesses might conflict with other threads.  These
accesses are the only ones which would need to be logged to ensure atomicity
(though I suspect your roll-back code would still need to track the values
of other fields that are written by the atomic section).

If you don't mind my asking, is this for university research?  Which
university?

-Richard

On Sun, Aug 23, 2009 at 6:32 AM, Eric Bodden <
bodden at st.informatik.tu-darmstadt.de> wrote:

> Hi Arie
>
> >From what I understand, ThreadLocalObjectsAnalysis and the classes
> that use it address exactly the problem you are describing. See
> http://www.sable.mcgill.ca/publications/papers/#pact2007
> http://www.sable.mcgill.ca/publications/thesis/#richardsMastersThesis
>
> Eric
>
> 2009/8/23 Arie Zilberstein <arie.zilberstein at gmail.com>:
> > Hi,
> >
> >
> >
> > I'm working on an software transactional memory (STM) implementation in
> > Java.
> >
> > The idea is that methods marked with @Atomic annotation will execute
> > atomically with respect to each other. This means that at runtime, every
> > method reachable from an @Atomic method will have a variant which logs
> all
> > reads and writes. The @Atomic method itself will call those variants and
> > will handle the logic to commit or rollback and retry, as necessary.
> >
> >
> >
> > Currently my goal is to optimize the STM. There are several opportunities
> > for optimizations. For example, all operations on non-shared objects, do
> not
> > need to be logged. This includes objects which were created inside a
> > transaction.
> >
> >
> >
> > I wonder what kind of analyses can Soot offer in this area? I am trying
> to
> > understand what Soot is currently offering before I go and roll my own
> code.
> > I noticed some interesting classes such as the ThreadLocalObjectsAnalysis
> > class, but they seem tailored for regular synchronization.
> >
> >
> >
> > I would appreciate any input.
> >
> >
> >
> > Best,
> >
> > Arie
> >
> > _______________________________________________
> > Soot-list mailing list
> > Soot-list at sable.mcgill.ca
> > http://mailman.cs.mcgill.ca/mailman/listinfo/soot-list
> >
> >
>
>
>
> --
> Eric Bodden
> Software Technology Group
> Technical University Darmstadt, Germany
> _______________________________________________
> Soot-list mailing list
> Soot-list at sable.mcgill.ca
> http://mailman.cs.mcgill.ca/mailman/listinfo/soot-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.cs.mcgill.ca/pipermail/soot-list/attachments/20090824/d9b222b1/attachment.html