On Tue, Nov 17, 2009 at 4:46 AM, Attila Szegedi <[email protected]> wrote: > 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.
Yes, I've been communicating with folks on the Hotspot team about this exact issue. We have a number of places in JRuby where we access final fields repeatedly. Without Hotspot treating those fields as "really final", those accesses are irreducible, so we do them over and over and over again. Any special treatment for immutability would certainly need to also treat finals as final, at the very least for purposes of optimizing several inlined bodies that access the same final fields. Our canonical example is the preamble to most code bodies that retrieves a final org.jruby.Ruby instance off a thread-local object, to avoid accessing it multiple times for other purposes. Even when I can get multiple dyncalls to inline into the same compilation unit, those accesses remain. Then we have finals for method caches, serial numbers, and so on...all of which get accessed and re-accessed repeatedly. > 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. That would be spectacular. - 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=.
