Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-4525290

Thread Finalizers problem & OutOfMemoryError under jdk1.3

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Not an Issue
    • Icon: P4 P4
    • None
    • 1.3.1
    • hotspot
    • 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.

            chegar Chris Hegarty
            duke J. Duke
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

              Created:
              Updated:
              Resolved:
              Imported:
              Indexed: