On 2009.11.16., at 23:27, Charles Oliver Nutter wrote: > Another wrinkle is the use of immutable structures, as in Clojure. I'm > curious whether such systems generate more garbage than those that > permit the use of in-place-mutable structures (seems to me that they > would)
Certainly - computation of any new value requires creation of at least one object. > and how that plays into memory bandwidth, allocation and GC > rates, and whether the bulk of the extra garbage is young or gets > tenured in typical usage. That'd be an interesting thing to measure, and I'd have to measure it as I can't guess at the right answer by just thinking about it :-) On a side note, I had an interesting discussion with Cam Purdy and Rich Hickey back in Aarhus this year about VM design. One thing that came up is that it'd be really beneficial if GC could know that an object is immutable, as it could optimize certain operational aspects for immutable objects. Namely, if you move an immutable object as part of a compacting phase, you don't have to lock it down to prevent concurrent mutation, since there is no mutation at all. Unfortunately, this doesn't go as far as giving the GC a leisure to slowly update the references to the moved objects, because that would break pointer-based identity comparison. Nevertheless, you could have a separate compact phase of a compacting GC that'd compact immutable objects first and not worry about locking anything while it does it, then only do reference updates atomically under some lock once it's done compacting. Of course, you could also have a VM that doesn't use pointers for identity comparison... This immutability information is currently not available (or insufficient) in JVM - final fields are a compiler construct not enforced on the bytecode level, and furthermore there are no immutable arrays. > We have been trying to explore the next steps for JRuby performance, > and we have begun to suspect that we're hitting memory/alloc/GC > bottlenecks for many (most?) cases. This is obviously harder to > investigate than straight-up execution performance, since even looking > at the Hotspot assembly output doesn't always make it clear what > memory effects a piece of code will have. I know someone who's writing a tool that might help you with that. I'll check up on him whether/when he can (or wants to) come public with it. Attila. > > So what have you all been seeing, and what tools are you using to > investigate the memory/alloc/GC impact of your languages? > > - Charlie -- You received this message because you are subscribed to the Google Groups "JVM Languages" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/jvm-languages?hl=.
