RE: large objects in sessions
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)
1 objects -> 12MB (6MB for 1 objects)
2 objects -> 18MB (12MB for 2 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 =1;
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 = 1;
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: large objects in sessions
Howdy, >And the hash in which you look up the object with the retrieved id can be >just something like a static hashtable in some class ? Yup. It's usually that simple. 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: large objects in sessions
Howdy,
This is a separate issue, how to measure an object (or object graph more
precisely) memory usage. I gave a snippet on purpose as an accurate
measurement is not trivial. There have been discussions on the list, as
well as some good articles (I recall one on JavaWorld about 2 years ago)
on how to do this.
You should do this with a fixed heap size, i.e. -Xmx=-Xmx, and a fixed
young generation size (I forget the JVM parameter name). You should
call System.gc() before and after the test, but that's just a suggestion
to the JVM and doesn't really matter: this is why N should be high, to
offset the gc effect. And you will end up with an average that's an
estimate. The test keeps MyObjects allocated and does not release them
(until it's done) on purpose.
Yoav Shapira
Millennium ChemInformatics
>-Original Message-
>From: Hans Wichman [mailto:[EMAIL PROTECTED]
>Sent: Wednesday, August 06, 2003 11:02 AM
>To: Tomcat Users List; Tomcat Users List
>Subject: RE: large objects in sessions
>
>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)
>1 objects -> 12MB (6MB for 1 objects)
>2 objects -> 18MB (12MB for 2 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 =1;
> 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/JPRAMFootpr
int.
>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 = 1;
>>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 onl
RE: large objects in sessions
Hi,
ok great, thanks for the reply.
And the hash in which you look up the object with the retrieved id can be
just something like a static hashtable in some class ?
Greetz
Hans
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 = 1;
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: large objects in sessions
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 = 1;
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: large objects in sessions
Ok, I just wanted to be sure everyone knew that. ;) > -Original Message- > From: Shapira, Yoav [mailto:[EMAIL PROTECTED] > Sent: Wednesday, August 06, 2003 9:15 AM > To: Tomcat Users List > Subject: RE: large objects in sessions > > > > Howdy, > > >And how does this approach save memory? You've simply replaced a > session > >object with a HashMap. Or am I missing something? > > It's not intended to save memory and doesn't. It's intended > to prevent putting non-serializable attributes in a session. > > Yoav Shapira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: large objects in sessions
Howdy, >And how does this approach save memory? You've simply replaced a session >object with a HashMap. Or am I missing something? It's not intended to save memory and doesn't. It's intended to prevent putting non-serializable attributes in a session. 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: large objects in sessions
Hi,
ok thanks, I will look into it!
greetz
Hans
At 11:08 AM 8/6/2003 -0400, you wrote:
Howdy,
This is a separate issue, how to measure an object (or object graph more
precisely) memory usage. I gave a snippet on purpose as an accurate
measurement is not trivial. There have been discussions on the list, as
well as some good articles (I recall one on JavaWorld about 2 years ago)
on how to do this.
You should do this with a fixed heap size, i.e. -Xmx=-Xmx, and a fixed
young generation size (I forget the JVM parameter name). You should
call System.gc() before and after the test, but that's just a suggestion
to the JVM and doesn't really matter: this is why N should be high, to
offset the gc effect. And you will end up with an average that's an
estimate. The test keeps MyObjects allocated and does not release them
(until it's done) on purpose.
Yoav Shapira
Millennium ChemInformatics
>-Original Message-
>From: Hans Wichman [mailto:[EMAIL PROTECTED]
>Sent: Wednesday, August 06, 2003 11:02 AM
>To: Tomcat Users List; Tomcat Users List
>Subject: RE: large objects in sessions
>
>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)
>1 objects -> 12MB (6MB for 1 objects)
>2 objects -> 18MB (12MB for 2 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 =1;
> 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/JPRAMFootpr
int.
>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 = 1;
>>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,
RE: large objects in sessions
And how does this approach save memory? You've simply replaced a session object with a HashMap. Or am I missing something? > -Original Message- > From: Shapira, Yoav [mailto:[EMAIL PROTECTED] > Sent: Wednesday, August 06, 2003 8:21 AM > To: Tomcat Users List > Subject: RE: large objects in sessions > > > > Howdy, > > >And the hash in which you look up the object with the > retrieved id can > be > >just something like a static hashtable in some class ? > > Yup. It's usually that simple. > > Yoav Shapira > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
