My approach was just to share what few refs I wanted, but another
approach (like Luc's) is to share everything. The obvious advantage
being that you can set! the root binding of vars (like function
definitions). The goal with Terracotta is to make things as
transparent as possible, so I don't think "share everything" would be
a huge number of changes here. I think there are only a few
roadblocks.
1. Remove AtomicReferences from Namespace class. If this is possible,
I think a major win for the share everything approach would be to
share clojure.lang.Namespace.namespaces. Once that is done almost all
of the objects will get shared by nature of being included in the
clojure.lang.Namespace.namespaces object graph. Almost all of the
static members of classes are assigned by looking up a var in a
namespace, or by creating Symbols, which are not a problem as far as I
have seen.
2. Static members that are not assigned by looking up a var in a
namespace. I'm not sure how many there are, but one example would be
PersistentHashMap.EMPTY. There is one trick to sharing this.
PersistentHashMap depends upon APersistentMap to generate and assign
it's hashCode value to the _hash member. The first time that hashCode
is called on the PersistentHashMap.EMPTY instance, Terracotta throws
an exception because PersistentHashMap.EMPTY is changed outside of a
lock. This can be fixed by adding
<autolock auto-synchronized="true">
<method-expression>*
clojure.lang.APersistentMap.hashCode(..)</method-expression>
<lock-level>write</lock-level>
</autolock>
to the Terracotta config. This will make Terracotta guard the
APersistentMap.hashCode method. This works, but adding the
synchronized keyword to the APersistentMap.hashCode method (as well as
ASeq, APersistentSet, and APersistentVector) would be a simple change
(assuming there aren't any consequences I'm missing).
I don't see why any of the Persistent data structures would need to be
modified. There may be other issues that will come about after these
changes, but I think it would be a good first step. After that fine
tuning the lock definitions could be done (although one could always
just define a broad lock config). I could look into creating a
Terracotta Integration Module so that people could just say,
"Terracotta, I'm using Clojure," and all of the instrumented classes,
roots, and locks would be configured automagically, then the work
wouldn't have to be duplicated every time.
Paul
On Fri, Feb 27, 2009 at 9:55 PM, Luc Prefontaine
<lprefonta...@softaddicts.ca> wrote:
> You're right Rich,
>
> We all have to agree on the means used to implement this in the Clojure
> runtime.
> Any code we throw right now has to be somewhat aligned with these decisions.
>
> The decision to hide the AtomicReference class was easy to take. It was an
> unavoidable
> obstacle. Any other issues from the Clojure run time will need more thinking
> and
> there might be other ways to do work around these issues.
>
> I can post an update each 2 weeks or so or on demand before we spit out code
> if we face an issue.
>
> Right now we are busy writing a tool in Clojure to generate the terracotta
> configuration
> from a set of classes. Finding each dependent class one by one is too slow.
> We always end up missing one. It will also spit out the locking section with
> all these member functions.
>
> This tool will speed us a lot in getting the prototype up. We will get the
> master pieces of
> the XML configuration. We can them removing unwanted classes from the
> configuration
> and tune the locking strategy as you test things.
>
> Luc
>
> On Fri, 2009-02-27 at 18:05 -0800, Rich Hickey wrote:
>
> It would be great if you could mention the difficulties you face as
> you go, before you spend too much time on workarounds. I am interested
> in seeing Clojure on Terracotta and if there are things I can do
> easily to support this effort I will.
>
> Rich
>
> --
>
> Luc Préfontaine
>
> Off.:(514) 993-0320
> Fax.:(514) 993-0325
>
> Armageddon was yesterday, today we have a real problem...
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~----------~----~----~----~------~----~------~--~---
