On Fri, Nov 20, 2009 at 10:54 PM, Jon Harrop <[email protected]> wrote: > I was referring to a thread local *heap* rather than a generation. For > example, linked lists held as an array of cons cells where tails are indexes > into the array. This offers substantial performance improvements on the CLR > because it doesn't introduce any contention for the shared heap at all > (beyond the single allocation of the whole array) but it requires the array > elements (head+tail pairs) to be value types.
I'm not sure I understand how CLR's support for stack-based value types constitutes a thread-local heap. My understanding is that CLR does not have any support for thread-local heaps, though the stack-based stuff helps reduce GC pressure. > Perhaps the most compelling example of value types is hash tables: inserting > 10M float->float bindings into a hash table is 32x faster in F# than in Java. > I suspect the reason is primarily that the JVM is boxing those floats whereas > the CLR is not. This also has nothing to do with thread-local heaps, and is a result of CLR having fully-reified generics that can support primitive values. A hand-written float->float map in Java should perform as well or better than the generic version in CLR. Of course not having to write the primitive version by hand would be nice. I've written several myself over the years. > Does relying upon escape analysis make it impossible to pass unboxed arrays > through the FFI? If you're referring to the FFI for calling into Java from Ruby, then we're already pretty well stuck since there's a lot of megamorphic code in the reflection call chain that would never inline enough for EA to eliminate those arrays. This is a cost paid for all Ruby to Java calls in JRuby and paid for even more calls in Groovy since most calls end up being reflective. Method handles would make it possible for EA to work across Java FFI, since the actual call target could inline all the way back to the dynamic call site. - 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=en.
