GC failure w/ THREAD_LOCAL_ALLOC ?

Jeff Sturm jsturm@one-point.com
Fri Mar 22 18:25:00 GMT 2002


On Fri, 22 Mar 2002, Boehm, Hans wrote:
> Assuming it appears to work, I have the greatest confidence in
> GC_IGNORE_GCJ_INFO.  This sidesteps a lot of subtle issues in the collector,
> at the expense of possibly retaining extraneous memory.  But without fully
> understanding the problem, it's hard to say for sure.  Turning off
> THREAD_LOCAL_ALLOC would be my next choice.  My current assumption is that
> Jeff was seeing a different problem.

Well, I'm seeing problems with and without GC_IGNORE_GCJ_INFO, but only a
deadlock with.  The more I think about it, I'm starting to suspect my
problem is related to Bryce's and Michael's reports after all.

Hmm... might be on to something here.  What happens if a collection takes
place after a thread is created but before it gets a chance to start?

Our code is proprietary, but portions are based on free software
such as Apache JServ.  Here's the main loop from JServ:

        while (true) {
            //Here we make sure that the number of
            //parallel connections is limited
            semaphore.throttle();
            try {
                JServConnection connection = new JServConnection();
                Thread t = new Thread(connection);
                t.setDaemon(true);
                Socket clientSocket = listenSocket.accept();
                connection.init(clientSocket, semaphore);
                t.start();
            } catch (...
	...
	}

Notice the thread is created before blocking on accept().  After accept()
returns we start() the thread and create another... isn't it true that
this thread is momentarily invisible to the collector?  Since a return
from t.start() doesn't guarantee that t is running?

As an experiment I rearranged the loop above so that we keep a reference
to the previous thread until the next accept() returns.  That did seem 
to make a difference... the application no longer deadlocks easily.

What's the right thing to do?  I'd guess that Thread.start() should
arrange to keep a pointer to the new thread somewhere the collector can
see it.

Jeff



More information about the Java mailing list