Rana, Allocation helper inlining is turned on only in server mode (-Xem:server) and only for gc_cc Even running in server mode there is a nuance: we do not have OSR so let the method to be recompiled before testing. I can help you to prepare configuration for -Xem:opt mode and rerun the test. I think we will be as fast as SUN on windows, where FS[14] is used but not system call to access TLS. The problem with TLS system call is quite simple: we do not move it out from loop today.
On 12/7/06, Rana Dasgupta <[EMAIL PROTECTED]> wrote:
Since the allocation helper is inlined now, I reran the old allocation rate test( with the default heapsize 256 M ) ...while gc_gen and gc_cc are in the same ballpark, there is still some way to go to catch up with RI. Log attached. On 12/5/06, Mikhail Fursov <[EMAIL PROTECTED]> wrote: > > If you compare performance of allocation - allocation fast path helper > code > is all you need. > And we need to check performance not with microtests, but use real > benchmarks. Microtests can hide cache misses in our example. > > On 12/5/06, Ivan Volosyuk <[EMAIL PROTECTED]> wrote: > > > > Helper code is equal. GC code is not. Lets compare apples with > oranges. > > -- > > Ivan > > > > On 12/5/06, Mikhail Fursov <[EMAIL PROTECTED]> wrote: > > > The helpers code is equal, except this load. So if we have different > > > > performance -> this extra memory access is the cause. > > > > > > On 12/5/06, Ivan Volosyuk <[EMAIL PROTECTED]> wrote: > > > > > > > > I think in order to do this comparison, other conditions should be > > > > equal. Comparing helper with 1 dependent load in gc_cc and helper > with > > > > 2 dependent loads in gc_v5 makes no sense to me. > > > > > > -- > Mikhail Fursov > >
-- Mikhail Fursov
