Message9932

I came across this while running the `zodbshootout` to get an idea of Jython's performance under ZODB with high-concurrency. There were two threads running, each of which calls `gc.collect` at the beginning of a certain phase of the benchmark (roughly halfway through).

  Traceback (most recent call last):
  File "/jython2.7rc3/Lib/site-packages/zodbshootout/fork.py", line 66, in run
    res = self.func(self.param, self.sync)
  File "/jython2.7rc3/Lib/site-packages/zodbshootout/main.py", line 233, in read
    return self.read_test(db_factory, n, sync)
  File "/jython2.7rc3/Lib/site-packages/zodbshootout/main.py", line 177, in read_test
    conn.cacheMinimize()
  File "//ZODB/src/ZODB/Connection.py", line 272, in cacheMinimize
    connection._cache.minimize()
  File "//persistent/persistent/picklecache.py", line 281, in full_sweep
    return self._sweep(0)
  File "//persistent/persistent/picklecache.py", line 75, in locked
    return f(self, *args, **kwargs)
  File "//persistent/persistent/picklecache.py", line 420, in _sweep
    gc.collect()
  RuntimeError: maximum recursion depth exceeded (Java StackOverflowError)

Even setting -Xss to 16M still overflowed.

ZODB (or more specifically, persistent) does use the `gc.monitorObject` API as well as `weakref.WeakValueDictionary`: the values in the dictionary are monitored because we need a more deterministic cleanup of them then standard Java GC semantics offer.

I tried the tip from #2258 (org.python.core.Options.showJavaExceptions = True) to get the Java stack, but that didn't produce additional output.