-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Balazs,
Balazs Michnay wrote: > I think it's just a "small" [GC], because sometimes when I click on > it several times, it frees up a little memory... Okay, that may be one thing complicating your instrumentation. >> Every request will eat up memory, but /should/ eventually be freed. Does >> your "simple" page have any filters operating on it? > > No. There are only struts <html:...> tags and some other <bean:...> tags. > There are no scriptlets on it. I meant filters defined in web.xml, not scriptlets. It's /possible/ that your <bean:> tags are using a whole lot of memory, but probably not (you'd have to be creating randomly-named session attributes over and over, and never freeing them... I'm guessing you're not doing that). > Well, since my last post I kept > on testing other pages and discovered that char[] and byte[] objects are > piled up by other methods as well. InflaterInputStream is there, however > it doesn't allocate as much memory than others do now. That's what I figured. From your screenshots, it appears that char[] objects are slightly worse than byte[] objects. char[] objects are almost certainly allocated for String object contents. > Now it seems that (among others) java.util.Arrays.copyOfRange eats up > lots of memory. Can you expand the "+" next to Arrays.copyOfRange to see what the rest of the stack trace is? I'm sure that a lot of things call Arrays.copyOfRange, so it's hard to determine what the problem is. Post another screenshot if you can. > This might be caused by me not properly using my > database connection pool, so here's how I use and probably everything > gets clear... I think you're speculating too much... if you were abusing your db connection pool, you'd probably be running out of connections, not memory. > 1) Every time I'd like to connect to my db, I use the java code > posted everywhere, but since I want to store more than 1 row of the > resultset, I declare an ArrayList. Probably this shouldn't be done > this way, because memory is eaten up by array operations... ArrayList doesn't store char[] anywhere, unless you are storing char[] objects in your ArrayList. Also, ArrayList uses System.arraycopy to expand and re-allocate its arrays, not Arrays.copyOfRange. > Here's my code: Your code looks just fine, although I might suggest factoring-out the code to mess with JNDI, the DataSource, etc. and just write a method that returns a Connection (or throws an exception). You are also closing your resources out of order (stmt first, then conn, then rst). Since you're closing those resources in your finally block, why bother closing them in the method body? It will be a cleaner method without this extra stuff in there, but functionally equivalent. In terms of design, I would write that method to return a List of application-specific objects instead of maintaining two separate (untyped) lists that just happen to be related. It is a much more understandable design and yields much more readable code. It will also simplify your JSP loop, etc. > It this the right way to use my connection pool? Connection pool use is just fine. Some other stuff ought to be re-thought, but it shouldn't run out of memory. > If not, this might be the reason of my memory leaks, because some > objects may not be able to be freed-up... Do you see any place where objects could not be freed-up? Where? > [InflaterInputStream allocations are] now nothing compared to those > allocated by java.util.Arrays.copyOfRange method... This is much more plausible. > Each request (a reload) causes a memory allocation of another 1-3 Mbytes that > the profiler gc() won't free up. Ouch! If you reload many times, does a JVM-initiated GC fire off? You should be able to look at the GC graph to see if the JVM is at least attempting to to a GC. It's possible to limit your JVM so much that even simple things cause OOMs, especially /during/ GC runs. >> What JVM, app server, etc. versions are you using? > > I have the latest Java installed (Version 6 Update 1). You mentioned you were using Tomcat as well. I'm assuming that since you're using Java 1.6 (Sun?), you're also using Tomcat 5.x or 6.x? > Any hey, thanks so much for taking a look at my code, and helping at all, I > appreciate it. No problem. We'll figure it out... but it might take a while. I remember when I first started profiling my apps. I started freaking out because I had no idea so many objects existed. At first I thought everything was leaking memory, and it turns out that everything was working just fine. The GC can play lots of tricks on you if you don't fully understand what you're seeing. - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGVE9m9CaO5/Lv0PARAuhkAKCWqS8u2aApySB7m0lxilr4ucI71gCgnopa 0CiD7XyrXMB+3/VBnLK0/ug= =Sc62 -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
