My favorites | Sign in
Project Home Downloads Wiki Issues
New issue   Search
  Advanced search   Search tips   Subscriptions
Issue 6193: Memory-leak in pure-Java's c.g.g.core.client.impl.WeakMapping (used in RequestFactory, server-side)
21 people starred this issue and may be notified of changes. Back to list
Status:  Fixed
Closed:  Sep 2011

Sign in to add a comment
Project Member Reported by t.broyer, Mar 28, 2011
Found in GWT Release (e.g. 1.5.3, 1.6 RC):
trunk @ r9848 but the class hasn't had any significant change since it was introduced almost 2 year ago:

Detailed description (please be as specific as possible):
ProxyAutoBean's createShim creates a circular reference between the ProxyAutoBean and the "shim", which prevents the entry add to the WeakMapping from being reclaimed (as the WeakMapping keeps a strong reference on the value, which in turn here references the key).

This is not an issue in the "prod mode" version of the class, which stores the value in a property of the key object; and isn't an issue in DevMode either (client-side), as the only culprit is ProxyAutoBean which is a server-only class.

To better mimic the prod-mode implementation, I think the value would have to be kept as a WeakReference. I can't think of any issue that could be caused by such a change in the server-side code.

Workaround if you have one:

Links to relevant GWT Developer Forum posts:
May 3, 2011
Project Member #2 t.broyer
As discussed in the code review, the issue actually isn't in WeakMapping proper (or at least it cannot be fixed there) but in how it's used by AutoBeans.
Someone could fix the issue summary? (w/ something like "memory leak in AutoBean VM implementation (and thus in RequestFactoryServlet)")
May 20, 2011
Status: ReviewPending
Labels: Milestone-2_4 Category-Other
May 20, 2011
Status: FixedNotReleased
Jun 1, 2011
FWIW, I compiled these updates up the day they were released and my Android client no longer gets OOM errors (which took sometimes only a single request to overburden my 32MB of Dalvik heap). 

Where can I go to find out expected release dates of GWT 2.4? My GWT server is still running the stock 2.3 jar because I am loath to bugger up a production server with "untested" jars and it is having memory issues I believe are related to this issue. This RPC layer is still only in testing so my server can handle the slow leak, but I have been needing to restart the GlassFish server weekly when I never had to in the previous 6 months.
Jun 12, 2011
It seems I spoke to soon. I am still getting too much memory consumption on the client side. It takes longer to explode but if I wait long enough it still eventually consumes all my limited Android memory. I'm trying to use RequestFactory (RF) as a simple data transfer protocol from a GWT app to an Android client. If I never intend to send the object back to the server is there a way to grab the data and never cache anything in the WeakMapping object (that is still slowly growing as opposed to rapidly growing like it did before I patched my jar). I'd love a .fireAndForget(new Receiver<Proxy>()) {}); method. Am I just doing it wrong?
Jun 13, 2011
#7 *
i used and then created super-source to expose Reference.get() with an empty unused stub to pass validation and had stable g1gc heap

Jun 14, 2011
I set every Proxy = null after I read the values out of them and still my WeakMapping class keeps a copy of all the JSON that comes down the wire. 

I finally decided to just add this method to WeakMapping and I call it when I know everything has been read. My problem is solved, but considering that RQ was advertised at Google IO as an Android RPC solution something needs to be done because this just doesn't work when you only have a couple of MB to your name.

public static void forceCleanup() {
Jun 14, 2011
"a copy of all the JSON"  That rings a bell.  The JsonSplittable class used on Android uses WeakMappings to provide canonical instances.  I'm not sure that behavior is really necessary and it would eliminate a source of GC complexity.
Status: Started
Labels: Priority-Critical
Jun 15, 2011

This patch uses Thomas's approach of keeping all ProxyAutoBeans referenced with WeakReferences.
Status: ReviewPending
Jun 15, 2011
I'd like to test this, but I'm sort of retarded with this diff stuff. Any chance I can find the patched .java files somewhere?
Jun 16, 2011
svn checkout google-web-toolkit-read-only
patch -p0 -i issue1451819_1.diff
Jun 16, 2011
All my HUNKS fail. I don't really know what that means other than I still don't have any patched java files, nor do I have anyway to look at patched source in a way that I can copy it even if I was willing to use a mouse to copy and paste manually (which I am). I could do it line by line, but the odds of not screwing it up seem slim to me as there are so many lines to do.

The side-by-side view is nearly good enough except that its all in one text window so you can't copy just the patched code. One wonders why the download button doesn't offer the ability to just download the .java or at least the unpatched file and the .diff with instructions on what to do next. I'm sure there is an easy way to do this, but I don't see a FAQ on the code-review screen that explains how I am supposed to use this stuff. 

Jun 17, 2011
Try syncing to r10344 and let me know if that helps.
Jun 17, 2011
I installed the patch on our (gwt server-side) production servers last night, after a little internal testing.

Just analyzed heap dumps from 2 servers and found no evidence of leaked proxies or JsponSplittable's. It is promising because we have been leaking >1GB per day for a while, but since it is Friday and almost summer holiday it is difficult to be 100% sure.
Jun 20, 2011
I tried the patched class files on my Android client. The garbage collector is much more proactive with it's clean up responsibilities now. GC_CONCURRENTs are hitting my log as I null Proxy references now. This is a welcome outcome. 
Jun 21, 2011
(No comment was entered for this change.)
Status: FixedNotReleased
Aug 25, 2011
Thanks Thomas for the patch
Sep 7, 2011
Released in 2.4
Status: Fixed
Oct 19, 2011
I'm beginning to suspect that this bug did not get completely fixed in 2.4.

I am experiencing a very reproducible memory leak when I make repeated queries using the request factory.

I've entered a new bug ( issue 6899 ) with a zipped up sample app that demonstrates the bug.

Anybody else still having issues?

Sign in to add a comment

Powered by Google Project Hosting