I tried the naive approach to removing AntiGC (see the attached patch1.diff), but that led to many IllegalThreadStateExceptions in suites.All. This can also be seen by shutting down the only booted database and rebooting it in the same JVM:
ij> connect 'jdbc:derby:db1;create=true';
ij> connect 'jdbc:derby:db1;shutdown=true';
ERROR 08006: Database 'db1' shutdown.
ij> connect 'jdbc:derby:db1';
ERROR XJ040: Failed to start database 'db1' with class loader sun.misc.Launcher$AppClassLoader@fabe9, see the next exception for details.
ERROR XJ001: Java exception: ': java.lang.IllegalThreadStateException'.
The problem with removing AntiGC is that BaseMonitor has a daemon ThreadGroup in which all service threads are started. Since the thread group is a daemon group, it will be destroyed automatically when its thread count becomes zero. AntiGC would prevent the thread group from being destroyed as long as the driver was loaded, since it would stay alive until the driver was unloaded and keep the thread count greater than zero. When there is no AntiGC thread to keep up the thread count, it may go down to zero on database shutdown, as in the example above, even if the driver is still loaded. The next attempt to start a service thread will then fail, since one cannot add threads to a destroyed thread group.
I suppose we could make the thread group a non-daemon group and destroy it manually when the driver is unloaded, but then we'd first have to wait for all service threads to complete, which may introduce possibilities for hangs on system shutdown (for example because of
DERBY-594). Another option may be to detect that this has happened and create a new daemon group when needed.