-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Balazs,
Balazs Michnay wrote: >> Are you sure they cannot be garbage-collected? How do you know? > > The profiler can perform garbage-collection at any time I press a > button. After pressing this, no memory is freed-up :( Are you forcing a full GC or just a small one? Depending on a /lot/ of things, those objects might not be freed until a full GC runs. >> Usually, JAR files are read to load class files. When class files >> are read, their code needs to be read into memory (in byte arrays). >> It also need to stay in memory in order to be executed. It's true, >> class loading uses memory ;) > > But does it load the classes each time I reload the page? Probably not. > Because > (just for testing) I have a simple, static page with only struts > <html:...> tags on it and pressing the reload button eats up some > more memory. Every request to the server creates many objects: request, response, extras for any wrappers that are created going through filters, etc. event objects fired for any session activity, maps of request parameters (whose Strings contain lots of byte[] objects), and on and on. Every request will eat up memory, but /should/ eventually be freed. Does your "simple" page have any filters operating on it? How about session interaction? >>> After browsing through about 80-100 pages I get an OutOfMemory >>> error... > >> Are you sure these facts are related? Class loading almost never >> causes a problem unless you are loading millions of classes. > > Well, I'm not sure, but since my page has "nothing" on it, I don't > know what else may cause such thing... and again, it's the profiler > that says memory is eaten up by the constructor of > InflaterInputStream class. So your testing strategy looks something like this: 1. Start up app server + attach profiler 2. Wait for app server to be ready for requests 3. Request simple page 4. Go to step #3 until OOM Is that accurate? And nobody else is using your server at the same time, right? When you say the profile claims that memory is eaten up in the InflaterInputStream constructor, I assume you mean that the memory is allocated in that method. It looks like the default byte buffer length is 512 bytes (in my Sun 1.5 source). How big are your byte arrays that seem to be piling up? I would bet that InflaterInputStream is responsible for eating up a chunk of memory due to class loading. Does the number of byte[] objects created by InflaterInputStream increase whenever you reload that page? Or are other objects increasing in size and/or count? Does your profiler confirm that all the byte[] objects are coming from InflaterInputStream, or does it list them separately and you browsed a few of them and say that they were all from that method? The reason I'm asking all of these seemingly stupid questions is that, with many Struts users out there, and such a simple problem, either everyone has this problem and Struts is untenable (which is clearly not true), or something is unique about your environment, or you are misinterpreting your data. What JVM, app server, etc. versions are you using? Finally, can you post the code to your "simple" page that can be observed to eat up memory? - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGVDlY9CaO5/Lv0PARAus4AJ9x9vs/Rs8sK2SfOJ99Xn/hH0lnegCePmKU gPOCQmdQ02HzxCmL0L4xen4= =J13G -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
