Nabble - codehaus - janino

Re: FW: Janino and Code Cache OutOfMemoryError

2009-10-27T07:19:59Z

Paul~

I am not entirely sure about your situation, but I would guess that this is from instances of the generated classes surviving longer then you expect. Every object in Java holds a reference to its Class and every Class holds an reference to its ClassLoader, so if your code instantiates the Class that you are generating, then the code objects and the ClassLoader will survive as long as that instance does.

If you are not instantiating the classes at all, I would examine the static and thread local variables that are referenced in your traces below to ensure that they are not squirreling away Class or ClassLoader references.

Matt

On Tue, Oct 27, 2009 at 5:14 AM, Paul Nolan <paul.nolan@...> wrote:

I should also add, when I look at what references org.codehaus.janino.ByteArrayClassLoader@0x1af0f9f0, I get pages and pages of classes that reference it, including many static references to it from "system" classes. This does not make a lot of sense since the classes that would be required to compile the code passed in to the ClassBodyEvaluator are not that many. For example, here is a reference to the ByteArrayClassLoader:

Static reference from net.sf.cglib.core.ReflectUtils.defaultLoader (from class net.sf.cglib.core.ReflectUtils) :
--> java.net.URLClassLoader@0x18030720 (63 bytes) (field classes:)
--> java.util.Vector@0x18079b60 (24 bytes) (field elementData:)
--> [Ljava.lang.Object;@0x191ff2a8 (40968 bytes) (Element 769 of [Ljava.lang.Object;@0x191ff2a8:)
--> class <mycompany>.cuf.datasource.portal.PortalDataSource (84 bytes) (static field _connectionManager:)
--> <mycompany>.jaf.services.database.ConnectionManagerBase@0x18030090 (184 bytes) (field _checkerThread:)
--> java.lang.Thread@0x18ac30d8 (104 bytes) (field group:)
--> java.lang.ThreadGroup@0x18030030 (43 bytes) (field groups:)
--> [Ljava.lang.ThreadGroup;@0x1a8024a0 (40 bytes) (Element 0 of [Ljava.lang.ThreadGroup;@0x1a8024a0:)
--> java.lang.ThreadGroup@0x180798f8 (43 bytes) (field threads:)
--> [Ljava.lang.Thread;@0x1b176678 (40 bytes) (Element 2 of [Ljava.lang.Thread;@0x1b176678:)
--> java.lang.Thread@0x1a92b240 (104 bytes) (field threadLocals:)
--> java.lang.ThreadLocal$ThreadLocalMap@0x1ab3b138 (20 bytes) (field table:)
--> [Ljava.lang.ThreadLocal$ThreadLocalMap$Entry;@0x1add1f68 (264 bytes) (Element 12 of [Ljava.lang.ThreadLocal$ThreadLocalMap$Entry;@0x1add1f68:)
--> java.lang.ThreadLocal$ThreadLocalMap$Entry@0x1af03218 (28 bytes) (field value:)
--> com.<mycompany>.ro.plugin.rules.RuleValidation$CommonBody@0x1af031c8 (16 bytes) (field cbe:)
--> org.codehaus.janino.ClassBodyEvaluator@0x1af031e8 (48 bytes) (field result:)
--> org.codehaus.janino.ByteArrayClassLoader@0x1af0f9f0 (54 bytes)

here is another:

Static reference from org.apache.commons.configuration.ConfigurationUtils.class$org$apache$commons$configuration$ConfigurationUtils (from class org.apache.commons.configuration.ConfigurationUtils) :
--> class org.apache.commons.configuration.ConfigurationUtils (84 bytes) (??:)
--> java.net.URLClassLoader@0x18030720 (63 bytes) (field classes:)
--> java.util.Vector@0x18079b60 (24 bytes) (field elementData:)
--> [Ljava.lang.Object;@0x191ff2a8 (40968 bytes) (Element 769 of [Ljava.lang.Object;@0x191ff2a8:)
--> class <mycompany>.cuf.datasource.portal.PortalDataSource (84 bytes) (static field _connectionManager:)
--> <mycompany>.jaf.services.database.ConnectionManagerBase@0x18030090 (184 bytes) (field _checkerThread:)
--> java.lang.Thread@0x18ac30d8 (104 bytes) (field group:)
--> java.lang.ThreadGroup@0x18030030 (43 bytes) (field groups:)
--> [Ljava.lang.ThreadGroup;@0x1a8024a0 (40 bytes) (Element 0 of [Ljava.lang.ThreadGroup;@0x1a8024a0:)
--> java.lang.ThreadGroup@0x180798f8 (43 bytes) (field threads:)
--> [Ljava.lang.Thread;@0x1b176678 (40 bytes) (Element 2 of [Ljava.lang.Thread;@0x1b176678:)
--> java.lang.Thread@0x1a92b240 (104 bytes) (field threadLocals:)
--> java.lang.ThreadLocal$ThreadLocalMap@0x1ab3b138 (20 bytes) (field table:)
--> [Ljava.lang.ThreadLocal$ThreadLocalMap$Entry;@0x1add1f68 (264 bytes) (Element 12 of [Ljava.lang.ThreadLocal$ThreadLocalMap$Entry;@0x1add1f68:)
--> java.lang.ThreadLocal$ThreadLocalMap$Entry@0x1af03218 (28 bytes) (field value:)
--> com.<mycompany>.ro.plugin.rules.RuleValidation$CommonBody@0x1af031c8 (16 bytes) (field cbe:)
--> org.codehaus.janino.ClassBodyEvaluator@0x1af031e8 (48 bytes) (field result:)
--> org.codehaus.janino.ByteArrayClassLoader@0x1af0f9f0 (54 bytes)

thanks,

- Paul.

On Tue, Oct 27, 2009 at 9:07 AM, Paul Nolan <Paul.Nolan@...> wrote:

From: Paul Nolan [mailto:paul.nolan@...]
Sent: 27 October 2009 08:58
To: user@...
Subject: [janino-user] Janino and Code Cache OutOfMemoryError

Hi,

I have a ituation where I am running some code inside our home grown application server. This code uses Janino to generate code on the fly using the ClassBodyEvaluator and, to a lesser extend, the SimpleCompiler. This code is not executed in any way - we compile the code to "test" rules input by users into our system to make sure that the rules are correct.

First I should say that permGen space is *not* filling up, just the code cache. I am seeing a situation where the code cache is filling up. Now, my understanding of this is that the reason the code cache is filling up is due to some reference to the class compiled by ClassBodyEvaluator is still hanging around in the system. However, my confusion is this: If this is the case then surely the permGen space should alse fill up (or possibly it does so at a much smaller pace than the code cache since it stores meta data only?).

I have passed a custom class loader into the ClassBodyEvaluator to see if this solves the issue but it does not e.g.

            ClassBodyEvaluator cbe = new ClassBodyEvaluator();
            cbe.setParentClassLoader(RVClassLoaderFactory.getRVClassLoader());
            cbe.cook(code);

In my testing code, I nullify my custom class loader when I am finished with it but the code cache still grows and does not get garbage collected. Using JDK 6.

I have used jmap and jhat to try and see what is referencing my class, the following information is from a jmap dump:

      1. ClassLoader for my generated class: org.codehaus.janino.ByteArrayClassLoader@0x1af0f9f0 (54 bytes) (note: not my custom classLoader I pass in above).

      2. In my investiagations using jmap, the finger consistently points at org.codehaus.janino.ByteArrayClassLoader@0x1af0f9f0, even though I pass in a custom class loader above when I am generating the code.

Now, it is well possible that my understanding of how Janino uses classLoaders is limited or how classLoaders work, so if so apologies.

My general question is can someone enlighten me as to the best way to ensure that my code cache does not fill up? Is it as simple as calling Thread.currentThread().setContextClassLoader() ?

regards,

- Paul.

From forum: janino - user

Re: FW: Janino and Code Cache OutOfMemoryError

2009-10-27T02:14:50Z

I should also add, when I look at what references org.codehaus.janino.ByteArrayClassLoader@0x1af0f9f0, I get pages and pages of classes that reference it, including many static references to it from "system" classes. This does not make a lot of sense since the classes that would be required to compile the code passed in to the ClassBodyEvaluator are not that many. For example, here is a reference to the ByteArrayClassLoader:

Static reference from net.sf.cglib.core.ReflectUtils.defaultLoader (from class net.sf.cglib.core.ReflectUtils) :

--> java.net.URLClassLoader@0x18030720 (63 bytes) (field classes:)
--> java.util.Vector@0x18079b60 (24 bytes) (field elementData:)
--> [Ljava.lang.Object;@0x191ff2a8 (40968 bytes) (Element 769 of [Ljava.lang.Object;@0x191ff2a8:)
--> class <mycompany>.cuf.datasource.portal.PortalDataSource (84 bytes) (static field _connectionManager:)
--> <mycompany>.jaf.services.database.ConnectionManagerBase@0x18030090 (184 bytes) (field _checkerThread:)
--> java.lang.Thread@0x18ac30d8 (104 bytes) (field group:)
--> java.lang.ThreadGroup@0x18030030 (43 bytes) (field groups:)
--> [Ljava.lang.ThreadGroup;@0x1a8024a0 (40 bytes) (Element 0 of [Ljava.lang.ThreadGroup;@0x1a8024a0:)
--> java.lang.ThreadGroup@0x180798f8 (43 bytes) (field threads:)
--> [Ljava.lang.Thread;@0x1b176678 (40 bytes) (Element 2 of [Ljava.lang.Thread;@0x1b176678:)
--> java.lang.Thread@0x1a92b240 (104 bytes) (field threadLocals:)
--> java.lang.ThreadLocal$ThreadLocalMap@0x1ab3b138 (20 bytes) (field table:)
--> [Ljava.lang.ThreadLocal$ThreadLocalMap$Entry;@0x1add1f68 (264 bytes) (Element 12 of [Ljava.lang.ThreadLocal$ThreadLocalMap$Entry;@0x1add1f68:)
--> java.lang.ThreadLocal$ThreadLocalMap$Entry@0x1af03218 (28 bytes) (field value:)
--> com.<mycompany>.ro.plugin.rules.RuleValidation$CommonBody@0x1af031c8 (16 bytes) (field cbe:)
--> org.codehaus.janino.ClassBodyEvaluator@0x1af031e8 (48 bytes) (field result:)
--> org.codehaus.janino.ByteArrayClassLoader@0x1af0f9f0 (54 bytes)

here is another:

Static reference from org.apache.commons.configuration.ConfigurationUtils.class$org$apache$commons$configuration$ConfigurationUtils (from class org.apache.commons.configuration.ConfigurationUtils) :

--> class org.apache.commons.configuration.ConfigurationUtils (84 bytes) (??:)
--> java.net.URLClassLoader@0x18030720 (63 bytes) (field classes:)
--> java.util.Vector@0x18079b60 (24 bytes) (field elementData:)
--> [Ljava.lang.Object;@0x191ff2a8 (40968 bytes) (Element 769 of [Ljava.lang.Object;@0x191ff2a8:)
--> class <mycompany>.cuf.datasource.portal.PortalDataSource (84 bytes) (static field _connectionManager:)
--> <mycompany>.jaf.services.database.ConnectionManagerBase@0x18030090 (184 bytes) (field _checkerThread:)
--> java.lang.Thread@0x18ac30d8 (104 bytes) (field group:)
--> java.lang.ThreadGroup@0x18030030 (43 bytes) (field groups:)
--> [Ljava.lang.ThreadGroup;@0x1a8024a0 (40 bytes) (Element 0 of [Ljava.lang.ThreadGroup;@0x1a8024a0:)
--> java.lang.ThreadGroup@0x180798f8 (43 bytes) (field threads:)
--> [Ljava.lang.Thread;@0x1b176678 (40 bytes) (Element 2 of [Ljava.lang.Thread;@0x1b176678:)
--> java.lang.Thread@0x1a92b240 (104 bytes) (field threadLocals:)
--> java.lang.ThreadLocal$ThreadLocalMap@0x1ab3b138 (20 bytes) (field table:)
--> [Ljava.lang.ThreadLocal$ThreadLocalMap$Entry;@0x1add1f68 (264 bytes) (Element 12 of [Ljava.lang.ThreadLocal$ThreadLocalMap$Entry;@0x1add1f68:)
--> java.lang.ThreadLocal$ThreadLocalMap$Entry@0x1af03218 (28 bytes) (field value:)
--> com.<mycompany>.ro.plugin.rules.RuleValidation$CommonBody@0x1af031c8 (16 bytes) (field cbe:)
--> org.codehaus.janino.ClassBodyEvaluator@0x1af031e8 (48 bytes) (field result:)
--> org.codehaus.janino.ByteArrayClassLoader@0x1af0f9f0 (54 bytes)

thanks,

- Paul.

On Tue, Oct 27, 2009 at 9:07 AM, Paul Nolan <Paul.Nolan@...> wrote:

From: Paul Nolan [mailto:paul.nolan@...]
Sent: 27 October 2009 08:58
To: user@...
Subject: [janino-user] Janino and Code Cache OutOfMemoryError

Hi,

I have a ituation where I am running some code inside our home grown application server. This code uses Janino to generate code on the fly using the ClassBodyEvaluator and, to a lesser extend, the SimpleCompiler. This code is not executed in any way - we compile the code to "test" rules input by users into our system to make sure that the rules are correct.

First I should say that permGen space is *not* filling up, just the code cache. I am seeing a situation where the code cache is filling up. Now, my understanding of this is that the reason the code cache is filling up is due to some reference to the class compiled by ClassBodyEvaluator is still hanging around in the system. However, my confusion is this: If this is the case then surely the permGen space should alse fill up (or possibly it does so at a much smaller pace than the code cache since it stores meta data only?).

I have passed a custom class loader into the ClassBodyEvaluator to see if this solves the issue but it does not e.g.

            ClassBodyEvaluator cbe = new ClassBodyEvaluator();
            cbe.setParentClassLoader(RVClassLoaderFactory.getRVClassLoader());
            cbe.cook(code);

In my testing code, I nullify my custom class loader when I am finished with it but the code cache still grows and does not get garbage collected. Using JDK 6.

I have used jmap and jhat to try and see what is referencing my class, the following information is from a jmap dump:

      1. ClassLoader for my generated class: org.codehaus.janino.ByteArrayClassLoader@0x1af0f9f0 (54 bytes) (note: not my custom classLoader I pass in above).

      2. In my investiagations using jmap, the finger consistently points at org.codehaus.janino.ByteArrayClassLoader@0x1af0f9f0, even though I pass in a custom class loader above when I am generating the code.

Now, it is well possible that my understanding of how Janino uses classLoaders is limited or how classLoaders work, so if so apologies.

My general question is can someone enlighten me as to the best way to ensure that my code cache does not fill up? Is it as simple as calling Thread.currentThread().setContextClassLoader() ?

regards,

- Paul.

From forum: janino - user

Janino and Code Cache OutOfMemoryError

2009-10-27T01:58:17Z

Hi,

I have a ituation where I am running some code inside our home grown application server. This code uses Janino to generate code on the fly using the ClassBodyEvaluator and, to a lesser extend, the SimpleCompiler. This code is not executed in any way - we compile the code to "test" rules input by users into our system to make sure that the rules are correct.

First I should say that permGen space is *not* filling up, just the code cache. I am seeing a situation where the code cache is filling up. Now, my understanding of this is that the reason the code cache is filling up is due to some reference to the class compiled by ClassBodyEvaluator is still hanging around in the system. However, my confusion is this: If this is the case then surely the permGen space should alse fill up (or possibly it does so at a much smaller pace than the code cache since it stores meta data only?).

I have passed a custom class loader into the ClassBodyEvaluator to see if this solves the issue but it does not e.g.

            ClassBodyEvaluator cbe = new ClassBodyEvaluator();
            cbe.setParentClassLoader(RVClassLoaderFactory.getRVClassLoader());
            cbe.cook(code);

In my testing code, I nullify my custom class loader when I am finished with it but the code cache still grows and does not get garbage collected. Using JDK 6.

I have used jmap and jhat to try and see what is referencing my class, the following information is from a jmap dump:

      1. ClassLoader for my generated class: org.codehaus.janino.ByteArrayClassLoader@0x1af0f9f0 (54 bytes) (note: not my custom classLoader I pass in above).

      2. In my investiagations using jmap, the finger consistently points at org.codehaus.janino.ByteArrayClassLoader@0x1af0f9f0, even though I pass in a custom class loader above when I am generating the code.

Now, it is well possible that my understanding of how Janino uses classLoaders is limited or how classLoaders work, so if so apologies.

My general question is can someone enlighten me as to the best way to ensure that my code cache does not fill up? Is it as simple as calling Thread.currentThread().setContextClassLoader() ?

regards,

- Paul.

From forum: janino - user

Re: Java varargs Compilation problem

2009-10-27T01:44:29Z

Thanks Matt, I was mistaken - this never compiled, hence the confusion.

best,

- Paul.

On Mon, Oct 26, 2009 at 3:07 PM, Matt Fowles <matt.fowles@...> wrote:

Paul~

Not sure if Janino used to support var-args or not. If it used to, then this is likely a regression. Regardless, you can work around the problem by generating code that directly calls the String[] variant.

Matt

On Fri, Oct 23, 2009 at 5:52 PM, Paul Nolan <paul.nolan@...> wrote:

Weird one here guys,

Using JDK:

java version "1.6.0_16"

Java(TM) SE Runtime Environment (build 1.6.0_16-b01)

Java HotSpot(TM) Client VM (build 14.2-b01, mixed mode, sharing)

To the problem:

I am using janino-2.5.0 and I am noticing that the ClassBodyEvaluator is not compiling Java varargs anymore J It definitely compiled under JDK 5 and I think it did previously under JDK 6 but of course I know that makes no sense.

If I have a function:

public static boolean inListStripLeadingZeros(String search, String ... string) { // note var args at end

The following code is passed to ClassBodyEvaluator (along with more code):

if (MyFunctions.inListStripLeadingZeros(record.tariff_Class,"527", "777", "3027", "619", "869", "3169", "628", "878", "3128", "567", "817", "3067", "502", "752", "3002", "503", "504", "505", "506", "605", "564", "565", "526", "528", "533", "753", "754", "755", "756", "855", "814", "815", "778", "3003", "3004", "3005", "3006", "3105", "3064", "3065", "675", "557", "521", "597", "684", "685", "501", "564", "565", "925", "807", "771", "934", "935", "751", "814", "815")) {

return true;

}

This is the error I am now getting with Janino 2.5.0 and JDK 1.6:

No applicable constructor/method found for actual parameters "java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String"; candidates are: "boolean MyFunctions.inListStripLeadingZeros(java.lang.String, java.lang.String[])"

Has this been fixed in later version? I scanned the changelogs but could not find it.

Thanks.

From forum: janino - user

Re: Java varargs Compilation problem

2009-10-26T08:07:41Z

Paul~

Not sure if Janino used to support var-args or not. If it used to, then this is likely a regression. Regardless, you can work around the problem by generating code that directly calls the String[] variant.

Matt

On Fri, Oct 23, 2009 at 5:52 PM, Paul Nolan <paul.nolan@...> wrote:

Weird one here guys,

Using JDK:

java version "1.6.0_16"

Java(TM) SE Runtime Environment (build 1.6.0_16-b01)

Java HotSpot(TM) Client VM (build 14.2-b01, mixed mode, sharing)

To the problem:

I am using janino-2.5.0 and I am noticing that the ClassBodyEvaluator is not compiling Java varargs anymore J It definitely compiled under JDK 5 and I think it did previously under JDK 6 but of course I know that makes no sense.

If I have a function:

public static boolean inListStripLeadingZeros(String search, String ... string) { // note var args at end

The following code is passed to ClassBodyEvaluator (along with more code):

if (MyFunctions.inListStripLeadingZeros(record.tariff_Class,"527", "777", "3027", "619", "869", "3169", "628", "878", "3128", "567", "817", "3067", "502", "752", "3002", "503", "504", "505", "506", "605", "564", "565", "526", "528", "533", "753", "754", "755", "756", "855", "814", "815", "778", "3003", "3004", "3005", "3006", "3105", "3064", "3065", "675", "557", "521", "597", "684", "685", "501", "564", "565", "925", "807", "771", "934", "935", "751", "814", "815")) {

return true;

}

This is the error I am now getting with Janino 2.5.0 and JDK 1.6:

No applicable constructor/method found for actual parameters "java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String"; candidates are: "boolean MyFunctions.inListStripLeadingZeros(java.lang.String, java.lang.String[])"

Has this been fixed in later version? I scanned the changelogs but could not find it.

Thanks.

From forum: janino - user

Java varargs Compilation problem

2009-10-23T14:52:01Z

Weird one here guys,

Using JDK:

java version "1.6.0_16"

Java(TM) SE Runtime Environment (build 1.6.0_16-b01)

Java HotSpot(TM) Client VM (build 14.2-b01, mixed mode, sharing)

To the problem:

I am using janino-2.5.0 and I am noticing that the ClassBodyEvaluator is not compiling Java varargs anymore J It definitely compiled under JDK 5 and I think it did previously under JDK 6 but of course I know that makes no sense.

If I have a function:

public static boolean inListStripLeadingZeros(String search, String ... string) { // note var args at end

The following code is passed to ClassBodyEvaluator (along with more code):

if (MyFunctions.inListStripLeadingZeros(record.tariff_Class,"527", "777", "3027", "619", "869", "3169", "628", "878", "3128", "567", "817", "3067", "502", "752", "3002", "503", "504", "505", "506", "605", "564", "565", "526", "528", "533", "753", "754", "755", "756", "855", "814", "815", "778", "3003", "3004", "3005", "3006", "3105", "3064", "3065", "675", "557", "521", "597", "684", "685", "501", "564", "565", "925", "807", "771", "934", "935", "751", "814", "815")) {

return true;

}

This is the error I am now getting with Janino 2.5.0 and JDK 1.6:

No applicable constructor/method found for actual parameters "java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String"; candidates are: "boolean MyFunctions.inListStripLeadingZeros(java.lang.String, java.lang.String[])"

Has this been fixed in later version? I scanned the changelogs but could not find it.

Thanks.

From forum: janino - user

[jira] Commented: (JANINO-137) Assignment conversion not possible from type "double[]" to type "double[]"

2009-10-17T13:25:27Z

[ http://jira.codehaus.org/browse/JANINO-137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=195136#action_195136 ]

Matt Fowles commented on JANINO-137:
------------------------------------

The problem was a race condition in lazy initialization of static values. The patch (which you can see) guards the initialization more carefully.

Prior to this patching being applied, your test failed between 1 in 6 and 1 in 10 times on my machine. After this patch is applied, it successfully ran over 100 times without failure.

> Assignment conversion not possible from type "double[]" to type "double[]"
> --------------------------------------------------------------------------
>
> Key: JANINO-137
> URL: http://jira.codehaus.org/browse/JANINO-137
> Project: Janino
> Issue Type: Bug
> Affects Versions: 2.5.15
> Environment: This issue has been recreated on Linux (Ubuntu) and OSX
> Reporter: Michael Ward
> Assignee: Arno Unkrig
> Attachments: Calculator.java, error.txt, JANINO-137.diff, MultiThreadedIssueTest.java
>
>
> We have discovered an issue when using Janino from multiple threads. No state is shared across these threads. We are using ClassBodyEvaluator.createFastClassBodyEvaluator. As is the case with most threading issues we do NOT see this issue every time. A simple test has been attached.
> Thanks,
> Mike
> Stacktrace:
> Caused by: org.codehaus.janino.CompileException: File Calculator_33, Line 25, Column 3: Assignment conversion not possible from type "double[]" to type "double[]"
> at org.codehaus.janino.UnitCompiler.compileError(UnitCompiler.java)
> at org.codehaus.janino.UnitCompiler.assignmentConversion(UnitCompiler.java)
> at org.codehaus.janino.UnitCompiler.compile2(UnitCompiler.java)
> at org.codehaus.janino.UnitCompiler.access$1700(UnitCompiler.java)
> at org.codehaus.janino.UnitCompiler$4.visitReturnStatement(UnitCompiler.java)
> at org.codehaus.janino.Java$ReturnStatement.accept(Java.java)
> at org.codehaus.janino.UnitCompiler.compile(UnitCompiler.java)
> at org.codehaus.janino.UnitCompiler.compile2(UnitCompiler.java)
> at org.codehaus.janino.UnitCompiler.access$700(UnitCompiler.java)
> at org.codehaus.janino.UnitCompiler$4.visitBlock(UnitCompiler.java)
> at org.codehaus.janino.Java$Block.accept(Java.java)
> at org.codehaus.janino.UnitCompiler.compile(UnitCompiler.java)
> at org.codehaus.janino.UnitCompiler.compile(UnitCompiler.java)
> at org.codehaus.janino.UnitCompiler.compileDeclaredMethods(UnitCompiler.java)
> at org.codehaus.janino.UnitCompiler.compileDeclaredMethods(UnitCompiler.java)
> at org.codehaus.janino.UnitCompiler.compile2(UnitCompiler.java)
> at org.codehaus.janino.UnitCompiler.compile2(UnitCompiler.java)
> at org.codehaus.janino.UnitCompiler$3.visitPackageMemberClassDeclaration(UnitCompiler.java)
> at org.codehaus.janino.Java$PackageMemberClassDeclaration.accept(Java.java)
> at org.codehaus.janino.UnitCompiler.compile(UnitCompiler.java)
> at org.codehaus.janino.UnitCompiler.compileUnit(UnitCompiler.java)
> at org.codehaus.janino.SimpleCompiler.compileToClassLoader(SimpleCompiler.java)
> at org.codehaus.janino.ClassBodyEvaluator.compileToClass(ClassBodyEvaluator.java)
> at org.codehaus.janino.ClassBodyEvaluator.cook(ClassBodyEvaluator.java)
> at org.codehaus.janino.ClassBodyEvaluator.<init>(ClassBodyEvaluator.java)
> at org.codehaus.janino.ClassBodyEvaluator.createFastClassBodyEvaluator(ClassBodyEvaluator.java)
> at me.mward.janino.MultiThreadedIssueTest.create(MultiThreadedIssueTest.java:52)
> ... 2 more

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Nabble - codehaus - janino

Re: FW: Janino and Code Cache OutOfMemoryError

Static reference from net.sf.cglib.core.ReflectUtils.defaultLoader (from class net.sf.cglib.core.ReflectUtils) :

Static reference from org.apache.commons.configuration.ConfigurationUtils.class$org$apache$commons$configuration$ConfigurationUtils (from class org.apache.commons.configuration.ConfigurationUtils) :

Re: FW: Janino and Code Cache OutOfMemoryError

Static reference from net.sf.cglib.core.ReflectUtils.defaultLoader (from class net.sf.cglib.core.ReflectUtils) :

Static reference from org.apache.commons.configuration.ConfigurationUtils.class$org$apache$commons$configuration$ConfigurationUtils (from class org.apache.commons.configuration.ConfigurationUtils) :

Janino and Code Cache OutOfMemoryError

Re: Java varargs Compilation problem

Re: Java varargs Compilation problem

Java varargs Compilation problem

[jira] Commented: (JANINO-137) Assignment conversion not possible from type "double[]" to type "double[]"

[jira] Updated: (JANINO-137) Assignment conversion not possible from type "double[]" to type "double[]"

[jira] Commented: (JANINO-137) Assignment conversion not possible from type "double[]" to type "double[]"

[jira] Commented: (JANINO-137) Assignment conversion not possible from type "double[]" to type "double[]"

[jira] Commented: (JANINO-137) Assignment conversion not possible from type "double[]" to type "double[]"

[jira] Created: (JANINO-137) Assignment conversion not possible from type "double[]" to type "double[]"

Re: Ignore Annotations

Ignore Annotations

[jira] Commented: (JANINO-136) Covariant return types for abstract methods fail to compile

[jira] Created: (JANINO-136) Covariant return types for abstract methods fail to compile

Re: Dependency injection - Cannot determine simple type name

Dependency injection - Cannot determine simple type name

[jira] Created: (JANINO-135) Jensen Ackles Nude

[jira] Created: (JANINO-134) Free Anal Sex Pics

[jira] Commented: (JANINO-133) Janino failed compiling with ClassCastException when the source code's size is too large

[jira] Commented: (JANINO-133) Janino failed compiling with ClassCastException when the source code's size is too large

[jira] Updated: (JANINO-133) Janino failed compiling with ClassCastException when the source code's size is too large

[jira] Commented: (JANINO-133) Janino failed compiling with ClassCastException when the source code's size is too large

[jira] Updated: (JANINO-133) Janino failed compiling with ClassCastException when the source code's size is too large

[jira] Commented: (JANINO-133) Janino failed compiling with ClassCastException when the source code's size is too large

[jira] Created: (JANINO-133) Janino failed compiling with ClassCastException when the source code's size is too large

[jira] Commented: (JANINO-132) Inaccessible methods should be ignored for method resolution

[jira] Created: (JANINO-132) Inaccessible methods should be ignored for method resolution

[jira] Commented: (JANINO-31) IncompatibleClassChangeError when loading nested classes

[jira] Commented: (JANINO-126) ExpressionEvaluator isn't handling NaN correctly

[jira] Commented: (JANINO-129) incorrect max stack size

[jira] Commented: (JANINO-127) LocalVariableTable code attribute not created, giving debuggers problems with classfiles

[jira] Commented: (JANINO-122) static field access through instance variables fails

[jira] Commented: (JANINO-130) wide versions of IINC and RET are broken