Re: GC dead-locking ?

2013-07-01 Thread Marco Leise
Am Tue, 18 Jun 2013 19:12:06 -0700 schrieb Sean Kelly : > On Jun 18, 2013, at 7:01 AM, Marco Leise wrote: > > > Am Mon, 17 Jun 2013 10:46:19 -0700 > > schrieb Sean Kelly : > > > >> On Jun 13, 2013, at 2:22 AM, Marco Leise wrote: > >> > >>> Here is an excerpt from a stack trace I got while pro

Re: GC dead-locking ?

2013-06-18 Thread Sean Kelly
On Jun 18, 2013, at 7:01 AM, Marco Leise wrote: > Am Mon, 17 Jun 2013 10:46:19 -0700 > schrieb Sean Kelly : > >> On Jun 13, 2013, at 2:22 AM, Marco Leise wrote: >> >>> Here is an excerpt from a stack trace I got while profiling >>> with OProfile: >>> >>> #0 sem_wait () from /lib64/libpthread

Re: GC dead-locking ?

2013-06-18 Thread Marco Leise
Am Mon, 17 Jun 2013 10:46:19 -0700 schrieb Sean Kelly : > On Jun 13, 2013, at 2:22 AM, Marco Leise wrote: > > > Here is an excerpt from a stack trace I got while profiling > > with OProfile: > > > > #0 sem_wait () from /lib64/libpthread.so.0 > > #1 thread_suspendAll () at core/thread.d:2471 >

Re: GC dead-locking ?

2013-06-17 Thread Sean Kelly
On Jun 13, 2013, at 2:22 AM, Marco Leise wrote: > Here is an excerpt from a stack trace I got while profiling > with OProfile: > > #0 sem_wait () from /lib64/libpthread.so.0 > #1 thread_suspendAll () at core/thread.d:2471 > #2 gc.gcx.Gcx.fullcollect() (this=...) at gc/gcx.d:2427 > #3 gc.gcx.

Re: GC dead-locking ?

2013-06-13 Thread Marco Leise
One more note: I get this consistently during profiling, but not without. I don't count kernel involvement out either, since OProfile is a kernel based profiler and there could be a quirk in its interaction with semaphores. -- Marco

GC dead-locking ?

2013-06-13 Thread Marco Leise
Here is an excerpt from a stack trace I got while profiling with OProfile: #0 sem_wait () from /lib64/libpthread.so.0 #1 thread_suspendAll () at core/thread.d:2471 #2 gc.gcx.Gcx.fullcollect() (this=...) at gc/gcx.d:2427 #3 gc.gcx.Gcx.bigAlloc() (this=..., size=16401, poolPtr=0x7fc3d4bfe3c8, a