-
Bug
-
Resolution: Not an Issue
-
P4
-
None
-
1.3.1
-
sparc
-
solaris_8
My customer runs into the OutOfMemoryError situation under jdk1.3.1 and traced
the problem to threads and the finalize method.
What they have experienced is very similar to BugId 4390238 and BugId 4484290.
The workaround for 4390238 is to use the -client flag instead of the -server
flag. This is unsatisfactory as they then run into SIGSEGVs after using the -client flag.
They've tried using the -XX:+UseLWPSynchronization option and
have also tried using an alternative thread library but to no avail.
Attached is a simple test case which involves threads and the finalize method.
It creates new objects continuously and runs into an OOM error very quickly. Now
the garbage collector should not allow that to happen because whenever resource
is running low it will in theory do its magic. We find this is not the case in
our code.
The use of -client and -server flags do not seem to have any effort on the OOM
error. The use of -Xmx300m doesn't seem to help although it delayed the
occurrence of OOM.
To execute the test, issue the command:
java finalTest 500 10000 1 3 1
500=object array size
10000=object array size
1=number of Chew threads
3=number of Alloc threads
1=loop count in FinalObj
The customer says,
If you do a heavy load test (over 85% cpu) of WebLogic 5.1 sp9 with jdk1.3.1
using SSL clients(https), you will see memory usage increasing very quickly.
We did our tests with both production code (a many tiers application) and
simple, plain servlets.
The difference was just in throughput and # of user transactions per second.
The finalization problem shows up in both scenarios.
As far as the performance statistics are concerned, a quantitative measure
obviosly depend on the hardware you run the test on.
As for a qualitative measure, we found out 1.3.X is as fast as 1.2.2_007 only if
you use "-server" switch (which can't be used in production because of well
known SIGSEGV, which you also get if you use -XOptimize under 1.2.2_007).
The "-client" switch is some 10% slower that 1.2.2_007.
I've had the chance to run the test case (attached) and it seems to pretty much mimic the problem we have here. I've done some hprof checking and I see a lot of
Finalizers, FinalObjs and byte arrays on the heap.
the problem to threads and the finalize method.
What they have experienced is very similar to BugId 4390238 and BugId 4484290.
The workaround for 4390238 is to use the -client flag instead of the -server
flag. This is unsatisfactory as they then run into SIGSEGVs after using the -client flag.
They've tried using the -XX:+UseLWPSynchronization option and
have also tried using an alternative thread library but to no avail.
Attached is a simple test case which involves threads and the finalize method.
It creates new objects continuously and runs into an OOM error very quickly. Now
the garbage collector should not allow that to happen because whenever resource
is running low it will in theory do its magic. We find this is not the case in
our code.
The use of -client and -server flags do not seem to have any effort on the OOM
error. The use of -Xmx300m doesn't seem to help although it delayed the
occurrence of OOM.
To execute the test, issue the command:
java finalTest 500 10000 1 3 1
500=object array size
10000=object array size
1=number of Chew threads
3=number of Alloc threads
1=loop count in FinalObj
The customer says,
If you do a heavy load test (over 85% cpu) of WebLogic 5.1 sp9 with jdk1.3.1
using SSL clients(https), you will see memory usage increasing very quickly.
We did our tests with both production code (a many tiers application) and
simple, plain servlets.
The difference was just in throughput and # of user transactions per second.
The finalization problem shows up in both scenarios.
As far as the performance statistics are concerned, a quantitative measure
obviosly depend on the hardware you run the test on.
As for a qualitative measure, we found out 1.3.X is as fast as 1.2.2_007 only if
you use "-server" switch (which can't be used in production because of well
known SIGSEGV, which you also get if you use -XOptimize under 1.2.2_007).
The "-client" switch is some 10% slower that 1.2.2_007.
I've had the chance to run the test case (attached) and it seems to pretty much mimic the problem we have here. I've done some hprof checking and I see a lot of
Finalizers, FinalObjs and byte arrays on the heap.
- relates to
-
-
- Closed
-