Bill Dortch wrote:
Yup, it was the new ObjectProxyCache I committed this morning. Fixed in
r5371. From my comments:
Thanks for digging in and finding the problem. It looks like I'm running
clean now.
"Fixed PermGen issue in build caused by daemon "vulture" thread in new
ObjectProxyCache. OPC was not being finalized due to this thread (which
must have prevented the entire runtime from being finalized, as the OPC
instances weren't using a lot of memory themselves). With the build
spinning up 189 runtimes, this quickly led to blown PermGen (though not
when running test-interpreted).
"Will have to find another way to do the OPC vulture thread. It's not
essential (I've simply disabled it); put/getOrCreate also expunge dead
entries, and the objects/proxies are held by weak/soft references and
will be gc'ed anyway, but in some cases an initial flurry of activity
will populate the cache, with little or no subsequent 'put' activity
that might trigger cleanup. (I observed this today while debugging.) "
So I haven't looked at the code, but is this basically the same issue we
had with ObjectSpace, where periodically we needed to clean out old
WeakRefs? In that case we did it on the "next call" whenever that call
might happen, so whatever thread was invoking ObjectSpace "helped out"
by cleaning up entries at that moment. I'm not advocating that, but it
might be a short-term option.
What does the SE WeakHashMap do internally?
Now that this is working, I'm encountering other build failures (in
addition to the Win/Jar/Dir/File issues I reported yesterday in
JRUBY-1785 <http://jira.codehaus.org/browse/JRUBY-1785>). These look
like they may also be Windows-specific. In run-junit-precompiled, I get
this sequence over and over (hard to tell where the top is):
Ok...then we'll see about getting this corrected. Boy, we sure could use
a Windows-based CI box :)
- Charlie
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
