[Gc] Removal of mark lock spinning for Win32
hans.boehm at hp.com
Wed Nov 12 13:42:12 PST 2008
I applied this one to my tree. (It's a clear win and makes diff42 apply correctly. And I'm trying to get caught up with the parallel marking code.)
Your performance test had the other app (separate process?) using up cpu time during the GC? So the processors were overcommitted? In that case, the results don't seem surprising. Maybe I'm misunderstanding something.
> -----Original Message-----
> From: gc-bounces at napali.hpl.hp.com
> [mailto:gc-bounces at napali.hpl.hp.com] On Behalf Of Ivan Maidanski
> Sent: Saturday, November 01, 2008 3:47 AM
> To: gc at napali.hpl.hp.com
> Subject: [Gc] Removal of mark lock spinning for Win32
> It turned out that mark lock spinning (GC_WIN32_THREADS +
> PARALLEL_MARK + MARKLOCK_USES_SPIN) is almost useless (and
> only uselessly consumes CPU time) in practice (regardless of
> SPIN_MAX) since spinning is disabled by GC_wait_marker() most
> of run time.
> Here is sample (and approx.) locking statistics
> (spin_count/block_count/unlocked_count, on a dual-core CPU):
> - test.c (incremental, markers=2): 2/774/509
> - test.c (non-incremental, markers=2): 8/2346/1729
> - test.c (non-incremental, markers=4): 74/6855/920 (max)
> - a long running demo GUI app with several active threads
> (markers=2): 4/1952256/1002
> So, this patch removes mark lock spinning code blocks
> together with MARKLOCK_USES_SPIN macro.
> Several words about performance gain with parallel markers (Win32).
> I ran two instances (in parallel) of a long running demo GUI
> app with several active threads (one without PARALLEL_MARK
> and other with GC_markers=2, both in non-incremental mode,
> all optimizations on, no assertions, heapsize=35M). It gives
> me in average about 25% shorter world-stopped delays (no
> more) after 1500 collections. In the incremental mode (both,
> no time limit) I haven't noticed any performance gain at all.
More information about the Gc