tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hans Wichman <h...@trimm.nl>
Subject RE: large objects in sessions
Date Wed, 06 Aug 2003 15:02:19 GMT
Hi,
it appears freeMemory is highly not to be trusted ;-):
Here is the free memory after each 1000 objects created:
#:717000
#:320080
#:1152992
#:512992
#:266208
#:1784800
#:1144800
#:504800
#:389088
#:3894240

The more objects I create the more memory I get ;-). In addition, how can 
the garbage collecter still collect any of these objects, if I have stored 
them in an array or is it collecting other objects (??)?

[.... testing testing ....]
ok after some more tests, it appears freeMemory keeps on returning 
different results because it allocates more and more memory as more is 
consumed. I ran the taskmanager and looked at the footprint, here is what 
it gave me:
no objects -> 6 MB
5000 objects-> 9MB (3MB for 5000 objects)
10000 objects -> 12MB (6MB for 10000 objects)
20000 objects -> 18MB (12MB for 20000 objects)

This seems to be pretty accurate, about 629 bytes per object (still seems 
low for what I am creating ;-)).

I rewrote the testing procedure to see if I could come up with the same, 
here it is:

       System.gc();
       int N =10000;
       int  valid = 0;//count object creations that did not cause 
additional memory to be allocated by the VM
       long last = -1;   //free memory during last run
       long current = 0; //free memory during current run
       long usedup = 0;   //total memory used up by all 'valid' allocations
       Object workers[] = new Object[N];
       for(int i = 0; i < N; i++) {
         workers[i] = new MyObject ();
         current = Runtime.getRuntime().freeMemory();
         if (current < last) {   //if allocation is deemed valid update 
administration
           valid++;
           usedup += last-current;
         }
         last = current;
       }
       System.out.println ("Footprint in bytes:"+usedup/valid);

Result 640 bytes. I hope it is not a coincidence ;-)

greetz
Hans

ps here is some more info as well:
http://java.sun.com/docs/books/performance/1st_edition/html/JPRAMFootprint.fm.html

At 09:03 AM 8/6/2003 -0400, Shapira, Yoav wrote:

>Howdy,
>
> >i've read in a number of locations that you shouldn't put large objects
>in
> >session, because of the overhead incurred.
> >Is this also true for non-serializable objects? Aren't they simply kept
>in
> >memory?
>
>Not exactly: I wouldn't put non-serializable objects in the session at
>all, regardless of their size.  You will get errors.  Instead, put the
>ID (or some other key allowing you to retrieve the object) in the
>session.
>
> >In addition does anybody know how I can accurately estimate the memory
> >footprint such an object has?
>
>The same way you estimate the memory footprint of any other object.
>
>For example, from a simple command-line program that does nothing else:
>
>int N = 10000;
>long freeBefore = Runtime.getRuntime().freeMemory();
>
>MyObject[] myArray = new MyObject[N];
>for(int i = 0; i < N; i++) {
>   myArray[i] = new MyObject();
>}
>
>long freeAfter = Runtime.getRuntime().freeMemory();
>long delta = freeAfter - freeBefore;
>long memPerObject = delta / N;
>
>(Use a large N to reduce impact of overhead, allocation, etc.)
>
>Yoav Shapira
>
>
>
>This e-mail, including any attachments, is a confidential business 
>communication, and may contain information that is confidential, 
>proprietary and/or privileged.  This e-mail is intended only for the 
>individual(s) to whom it is addressed, and may not be saved, copied, 
>printed, disclosed or used by anyone else.  If you are not the(an) 
>intended recipient, please immediately delete this e-mail from your 
>computer system and notify the sender.  Thank you.
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: tomcat-user-help@jakarta.apache.org


Mime
View raw message