Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: harmony-dev@incubator.apache.org
Received-SPF: neutral (hermes.apache.org: local policy)
Message-ID: <42891E03.104@anu.edu.au>
Date: Tue, 17 May 2005 08:26:11 +1000
From: Steve Blackburn <Steve.Blackburn@anu.edu.au>
Reply-To: Steve.Blackburn@anu.edu.au
Organization: Australian National University
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510
MIME-Version: 1.0
To: harmony-dev@incubator.apache.org
Subject: Persistence (was Re: Introduction, and a question)
References: <E0467379DD4FA84BAF6E42D3161A9A08ADD445@inhyms21.ca.com>
In-Reply-To: <E0467379DD4FA84BAF6E42D3161A9A08ADD445@inhyms21.ca.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

If you're interested in snapshot and restart of VM state, your biggest 
issue is concurrency.  There is a large literature on "orthogonal 
persistence".  In a nutshell, the goal of orthogonal persistence is that 
persistence be a properprty orthogonal to all other aspects of the 
language---the entire program state should persist.  The checkpoint() 
model is the simplest, but has two drawbacks: a) injecting 
persistent-specific code into your program, and more importantly b) the 
problem of acquiring a consistent cut across threads.

Implementing a trivial checkpoint mechanism is not difficult at all---it 
has been done many times for Java.  People have also used such 
mechanisms to perform thread migration in distributed Java systems.

Implementing full orthogonal persistence is more challenging, 
particularly with regards to language design issues (how do you combine 
concurrency and persistence semantics in a way that does not impinge on 
the language?).

Many years ago, we build an orthogonally persistent Java (OPJ) which 
performed well.  While other folks embedded their mechanism in the VM, 
we did ours exclusively by transforming classes at classloading time.  
We eventually generallized this to be able to extend java semantics in 
all sorts of interesting ways.  We called it the Semantic Extension 
Framework  (SEF).  I moved to the US and the key author left for 
industry and so our SEF never really made it into the mainstream.  A 
year or so later we saw AOP emerge, which carries many of the same ideas.

There was also a major project at Sun (http://research.sun.com/forest) 
which worked on this.  Their approach was to modify the VM internals.

There is a project at ANU (dJVM) looking at distributed jvms 
(http://djvm.anu.edu.au/).

The SEF and OPJ work was a lot of fun, but I don't think it has much to 
do with core VM design as I think the best approach is to build it using 
the dynamic classloader. :-)

Cheers,

--Steve

http://cs.anu.edu.au/~Steve.Blackburn/pubs/abstracts.html#opj-pos9
http://cs.anu.edu.au/~Steve.Blackburn/pubs/abstracts.html#fly-pjw3