[Soot-list] Using soot to optimize transactional memory

[Eric Bodden]

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