1) AtomicReference is used in several places. Instead of changing it, we think we can keep it when Clojure runs "locally" and provide an alternative when running in "shared" mode.
AtomicReference is optimized to be efficient in a standalone JVM. We would like to keep it that way. Eventually Terracotta will provide instrumentation on this class by default so the "shared" implementation could be thrown away in the near future. We see the double implementations as a transition period until Terracotta supports it directly. 2) Noted Shared versus local mode: That's what we have in mind, getting Clojure to work in a "shared" mode versus a local/standalone mode. We want 0 impacts on the user code. Eventually we could use meta data to provide some hints that would allow us to fine tune shared interactions from user code. This would not impact "local" mode behaviours. We're not there yet but we know that this possibility exists so that's reassuring for the future. Integration is pretty simple once the common code base integrates the necessary changes. We need a shell script, a Terracotta configuration that will be maintained as part of the Clojure code base and some documentation. As of now we use a system property to toggle the modes, we will implement a transparent way (testing the presence of a terracotta property most probably). Luc On Sat, 2009-02-28 at 06:35 -0500, Paul Stadig wrote: > 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... > > > > -- 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 -~----------~----~----~----~------~----~------~--~---
