On Tuesday 17 November 2009 04:14:10 Charles Oliver Nutter wrote: > On Mon, Nov 16, 2009 at 7:33 PM, Jon Harrop <[email protected]> wrote: > > I see allocation as contention because the heap is a global shared > > resource. If you want to recover the performance of the previous > > generation of standalone languages with GCs optimized for rapid recycling > > on a single thread (e.g. OCaml) then you need to reimplement a mini-heap > > local to your thread and that is left up to the user on VMs like the JVM > > and CLR. > > On the JVM, at least on Hotspot, threads get their own thread-local > allocation buffers (TLABs), which reduces most allocations to > pointer-bumping.
Only for the mutator. For the GC, the object is then reallocated on the shared heap and copied. That is expensive and it doesn't scale because the shared heap is a global resource. 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. > This reduces the contention for the heap, but it does > nothing to reduce the cost of rapidly burning through pointer > addresses, which leads to cache page misses more quickly than for > lower allocation rates. I suppose value types help remedy this problem > by localizing certain object allocations on the stack, so there's only > a single pointer bump entering a call and a single pointer bump > exiting it. Exactly. The benefits can be really huge in the context of complex numbers, 2D vectors, vertex data for transfer to the hardware and unboxed array. 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. > Value types or stack-allocated data structures would > certainly be welcome on the JVM. I believe at the moment the only > answer we have been given is that escape analysis "should do this for > us", but so far I've seen only mixed results. Does relying upon escape analysis make it impossible to pass unboxed arrays through the FFI? > > JVM-based languages could perform the same inlining and use > > monomorphization to avoid type erasure but the lack of value types is an > > insurmountable on the JVM. > > I'm not sure it's totally insurmountable, but the current answer (EA) > does not seem to be helping enough (not to mention being *heavily* > dependent on the JVM inlining the code you want to EA-optimize...a > special challenge for any languages with complicated or deep call > logic). Yes. -- Dr Jon Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/?e -- 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=.
