49205 - optimizer wastes memory through class loader

Status: VERIFIED INVALID

(Rhino Graveyard :: Core, defect, P3)

Description

[Shawfe Sung]

This refers to both the version 1.5 release 1 and the current rhino tip.

I ran the following program:

import org.mozilla.javascript.*;
public class Test
{
    public static void main( String[] argv )
    {
        Context cx = Context.enter();
        Scriptable scope = cx.initStandardObjects( null );
        while( true ){
            Object result;
            result = cx.evaluateString( scope, "//nothing", "cmd", 1, null );
        }
    }
}

and kept watch on the memory usage, which would climb up steadily
until I stop the process.

However, if I insert
        
        cx.setOptimizationLevel( -1 );

before the infinite loop, there would be no memory wasting.


It seems that in the compile function of
org.mozilla.javascript.optimizer.Codegen, the line

clazz = classLoader.defineClass( name, classFile );

was causing memory usage.  I printed the "name" variable at each
iteration and found their values to be

org.mozilla.javascript.gen.c1
org.mozilla.javascript.gen.c2
org.mozilla.javascript.gen.c3
...

It seems that each time I evaluate "//nothing," Rhino would create and
load a class under a new name.



Shawfe Sung

Comment 1

[Norris Boyd]

We've known about this for a while (it's part of the reason interpretive mode 
was created). I consider it a bug in the JDK that the bytecode and interned 
strings associated with classloading aren't collected. 

I don't think it would work to reuse class names--I believe the primordial class 
loader would get confused. Have you tried it?

Comment 2

[Norris Boyd]

Workaround for JVM deficiency is to use interpretive mode.

Comment 3

[Shawfe Sung]

Looks like interpretive mode is the way to go.

From what I understand, the JVM does not reuse class names nor
collect unused classes because static members should only
be initialized once during the lifetime of the JVM.  

Creating new classes would ultimately exhaust the memory unless we
play around with the class loader...

Comment 4

[Phil Schwartau]

Verifying -