49925 - Memory leak with Rhino

Status: RESOLVED INVALID

(Rhino Graveyard :: Core, defect, P3)

Description

[Dominique Sauquet]

From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 5.0; Windows NT; DigExt)
BuildID:    

							

Reproducible: Always
Steps to Reproduce:
I use rhino in a VoiceXML interpreter that I develop.
I try to test the robustness and if I make a loop in a the script evaluation I 
run "Out of Memory"
java.lang.OutOfMemoryError
	at java.lang.ClassLoader.defineClass0(Native Method)
	at java.lang.ClassLoader.defineClass(ClassLoader.java, Compiled Code)
	at java.lang.ClassLoader.defineClass(ClassLoader.java, Compiled Code)
	at org.mozilla.javascript.optimizer.JavaScriptClassLoader.defineClass
              (JavaScriptClassLoader.java, Compiled Code)
	at org.mozilla.javascript.optimizer.Codegen.compile(Codegen.java, 
Compiled Code)
	at org.mozilla.javascript.Context.compile(Context.java, Compiled Code)
	at org.mozilla.javascript.Context.compile(Context.java, Compiled Code)
	at org.mozilla.javascript.Context.compileReader(Context.java, Compiled 
Code)
	at org.mozilla.javascript.Context.evaluateReader(Context.java, Compiled 
Code)
	at org.mozilla.javascript.Context.evaluateString(Context.java, Compiled 
Code)		

Then I tried a very simple example with a loop :
public class RunScriptLoop {
    public static void main(String args[]) 
        throws JavaScriptException 
    {
        // Creates and enters a Context. The Context stores information
        // about the execution environment of a script.
        Context cx = Context.enter();
        
        // Initialize the standard objects (Object, Function, etc.)
        // This must be done before scripts can be executed. Returns
        // a scope object that we use in later calls.
        Scriptable scope = cx.initStandardObjects(null);
        
        // Collect the arguments into a single string.
        String s = "";
        for (int i=0; i < args.length; i++)
            s += args[i];
            
        while(true)
        {
        // Now evaluate the string we've colected.
          Object result = cx.evaluateString(scope, s, "<cmd>", 1, null);
        
        // Convert the result to a string and print it.
          System.err.println(cx.toString(result));
        }
        // Exit from the context.
        //Context.exit();
    }
}
What happen is that rapidly the process is very very slow.
Is there a problem of garbage collection ?

Comment 1

[Dominique Sauquet]

Attachment: Java file to test the memory leak

Comment 2

[Phil Schwartau]

Changing Product assignment to Rhino -

Comment 3

[Phil Schwartau]

Reassigning to Norris -

Comment 4

[Norris Boyd]

Unfortunately classes (or at least the interned strings in them) aren't 
garbage collected by the JVM. Try using interpretive mode instead:

cx.setOptimizationLevel(-1);

Comment 5

[Phil Schwartau]

Verifying -

Comment 6

[Dominique Sauquet]

Thank you
With the  cx.setOptimizationLevel(-1);
It seems to work
I will start additional tests on several days this week end
In fact I do not know in advance the scripts that have to be interpreted since 
they are dynamically generated. So maybe the "compiled way" was not 
convenient ??
Do you think that the performances will be much lower on small scripts with 
 cx.setOptimizationLevel(-1); ?
Have you any idea of the benchmark between the 2 modes ?

Comment 7

[Norris Boyd]

   In fact I do not know in advance the scripts that have to be interpreted 
   since they are dynamically generated. So maybe the "compiled way" was not
   convenient ??
If your scripts are dynamically generated, I'd recommend interpretation.

    Do you think that the performances will be much lower on small scripts with
    cx.setOptimizationLevel(-1); ?
It depends. If you are always calling evaluateString or evaluateReader you may 
notice a performance *improvement* because compiling to class files is an 
expensive operation. Unless you can amortize that over multiple executions, 
overall performance can be slower with compiled mode.

    Have you any idea of the benchmark between the 2 modes ?
I haven't run our benchmarks recently--I'll try to do so soon. If you want to, 
they are in CVS at mozilla/js/benchmarks.

Comment 8

[Norris Boyd]

Here are some timings for benchpress.js.

Note, however, that this benchmark contains a lot of looping constructs and thus 
favors optimization. When running the regression tests interpretive mode is the 
fastest because those tests are a large number of scripts, each run once.

JVM         opt level        time (ms)
MS          -1               309716
MS          0                4447
MS          9                3257
Sun         0                5138
Sun         9                1851
Sun         -1               13680

Comment 9

[Igor Bukanov]

Targeting as resolved against 1.5R5