Hi,

On Sep 6, 2013, at 23:48, Sean Luke <[log in to unmask]> wrote:

> So in order to handle this with the threadpool meant adding some features to the threadpool that ECJ already has, which OF COURSE meant rewriting it from scratch and refactoring the various classes which use it.  :-)  I *think* the new version works but (ahem) who knows.
> 
> Here are some new classes you can try.  

:)

> Tell me if things work a bit better.
>  The general idea was to push the thread back in the thread pool when it was finished rather than killing it; that way you'd not be recreating zillions of threads which is causing the Java VM memory leak you're seeing.
> 
> <ThreadPool.java><SlaveConnection.java><SlaveMonitor.java><Slave.java><SimpleEvaluator.java>

I just tried the code - but since I am not working on the current SVN branch and I changed some things in the code for my analysis I roughly adapted some things.

Nevertheless I noticed

a.) Connects and Disconnects are fast
b.) the threadpool tends to get larger (and larger) ... and the threads are not reused? ... I attached two thread dumps 
b.1.) after a few hundred connects and disconnects with (no slave connected then dumping the threads)