[Bug-kawa] [bug #25593] memory leak in CallContext

[Jean-Philippe Gariepy]

URL:
  <http://savannah.gnu.org/bugs/?25593>

                 Summary: memory leak in CallContext
                 Project: Kawa
            Submitted by: gawi
            Submitted on: Sun 15 Feb 2009 10:26:34 PM GMT
                Category: Code generation
                Severity: 3 - Normal
              Item Group: Unexpected result
                  Status: None
                 Privacy: Public
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any

    _______________________________________________________

Details:

Tested with kawa-1.9.1.

A memory leak occurs within the CallContext class:


test/Test.java:

package test;

import kawa.standard.Scheme;

public class Test
{
    public static void main(String[] args)
    {
        Scheme.registerEnvironment();

        byte[] bytes = new byte[240 * 1024 * 1024];
        System.out.println("(main) length: " + bytes.length);

        new TestKawaSimpleClass().printArrayLength(bytes);

        bytes = null; //allow garbage collect

        bytes = new byte[240 * 1024 * 1024];
        System.out.println("(main) length: " + bytes.length);

    }
}

test/TestKawa.scm:

(module-name <test.TestKawa>)
(module-static 'init-run)
(module-export print-length)

(define-simple-class <TestKawaSimpleClass> (<Object>)
  ((printArrayLength (array :: <byte[]>)) :: void
    (print-length array)))
  
(define (print-length (array :: <byte[]>)) :: void
  (format #t "(print-length) length: ~a~%" (field array "length")))

Compile Test.java w/ javac.  Compile TestKawa.scm with --full-tailcalls
option:

Running with 256M of heap (java -Xmx256M), I get the following:

(main) length: 251658240
(print-length) length: 251658240
Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
        at test.Test.main(Test.java:27)

The OutOfMemory error is unexpected because the first byte array should not
be [strongly] referenced at this point and should be garbage-collected.

Recompiling --no-full-tailcalls option, I get:

(main) length: 251658240
(print-length) length: 251658240
(main) length: 251658240

which is the expected behaviour. So the problem must be related to usage of
CallContext.

What happends is that the first byte array is still referenced by the value1
field of CallContext as shown by the following output of jhat (heap analysis
tool):

Java Local Reference (from
address@hidden) :
--> address@hidden (104 bytes) (field
group:)
--> address@hidden (43 bytes) (field groups:)
--> [Ljava.lang.ThreadGroup;@0xa44fbc58 (24 bytes) (Element 0 of
[Ljava.lang.ThreadGroup;@0xa44fbc58:)
--> address@hidden (43 bytes) (field threads:)
--> [Ljava.lang.Thread;@0xa44fbca8 (24 bytes) (Element 0 of
[Ljava.lang.Thread;@0xa44fbca8:)
--> address@hidden (104 bytes) (field threadLocals:)
--> address@hidden (20 bytes) (field
table:)
--> [Ljava.lang.ThreadLocal$ThreadLocalMap$Entry;@0xa44fbd78 (72 bytes)
(Element 1 of [Ljava.lang.ThreadLocal$ThreadLocalMap$Entry;@0xa44fbd78:)
--> address@hidden (28 bytes) (field
value:)
--> address@hidden (76 bytes) (field value1:)
--> address@hidden (251658248 bytes) 

Note that a similar problem can arise with the vstack field when using
multiple values.  In fact, we originally found it there.

We are using web applications under a webapp server and since it probably
uses a thread pool for request handling, the problem can exist on each idle
thread. 





    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?25593>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/