On 2008.11.15., at 15:25, Rich Hickey wrote:
> Welcome Attila, > > I've run findbugs on Clojure before and cleaned up a few things. These > that you mentioned, however, stand as a good example of such an > analyzer not knowing enough, and I count as spurious, if well- > intended. > > As mentioned by Phil, the refs are still correct. The UUID is some > unfinished work on ref persistence (of the db kind). Don't look behind > the curtain :) Ah, alright. If refs will get externalized then the UUID scheme will indeed make a lot of sense. > As far as the synchronization, let's take LazyCons. _first and _rest > are normally accessed under a lock. The semantics and behavior of the > class is such that these fields make a once-and-once-only transition > into a final state. Those transitions happen under locks, in first() > and rest(), and rest() calls first(). > > So, in the withMeta call, the call to rest() ensures that the > subsequent use of _first and _rest will see the final values. I don't > expect findbugs to understand that, but it's certainly correct. Indeed. *I* OTOH could've however certainly make an effort to examine these more closely before making noise on the list - sorry about that. I too have some code of my own where FindBugs is reporting locking inconsistencies and every few months I will get caught in re-reading said code, and always proving to myself again that it is in fact correct, just FindBugs fails to see it... > > CachedSeq is similar. In LazilyPersistentVector the v field is an > optimization cache and can be freely recreated. Right, and it's either null or has a final value, so it too remains nicely consistent. > As far as valueOf, Cliff Click at the JVM Languages Summit had some > interesting details about how those caches can thwart optimization in > the presence of escape analysis. Instead of having a simple path, they > cause a branch into array lookup code. Without such a branch an > optimizer could get rid of the boxed object entirely in some > circumstances. It left me skeptical of the universal value of valueOf. Yeah, it's a tradeoff. On one hand you have an array lookup that can defeat certain optimizations, on the other you have lot of short lived garbage that puts pressure on the GC when those optimizations aren't effected (i.e. because they aren't present yet in the VM, as most forms of escape analysis sadly aren't yet...). To me, it is sufficiently assuring to know that you're aware of the options and tradeoffs and have consciously decided on using one instead of the other. > Rich Attila. --~--~---------~--~----~------------~-------~--~----~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~----------~----~----~----~------~----~------~--~---
