[jira] [Commented] (GROOVY-9068) GroovyScriptEngine causes Metaspace OOM

2019-04-10 Thread Daniel Sun (JIRA)


[ 
https://issues.apache.org/jira/browse/GROOVY-9068?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16815103#comment-16815103
 ] 

Daniel Sun commented on GROOVY-9068:


The following code should work with Groovy 2.5.6+ too:
{code:java}
private static final GroovyClassLoader GCL = new GroovyClassLoader();
public static Object evaluate(String scriptText) {
GroovyCodeSource gcs = AccessController.doPrivileged(new 
PrivilegedAction() {
public GroovyCodeSource run() {
return new GroovyCodeSource(scriptText, "script" + 
System.currentTimeMillis() +
Math.abs(scriptText.hashCode()) + ".groovy", 
"/groovy/script");
}
});
gcs.setCachable(true); // the key part
return GCL.parseClass(gcs);
}
{code}


> GroovyScriptEngine causes Metaspace OOM
> ---
>
> Key: GROOVY-9068
> URL: https://issues.apache.org/jira/browse/GROOVY-9068
> Project: Groovy
>  Issue Type: Bug
>  Components: GroovyScriptEngine
>Affects Versions: 2.4.9
> Environment: macOS Mojave, MacBook Pro (Retina, 15-inch, Mid 2015)
>Reporter: Jingfei Hu
>Priority: Major
>  Labels: GroovyScriptEngineImpl, Metaspace, OOM
>
> Hello team,
> We've encountered this troublesome Metaspace OOM in our application recently 
> as the number of groovy scripts increases. The groovy usage pattern in our 
> application is evaluating scripts adhoc and directly. There are no any kinds 
> of caches. And we use below code to do the evaluation. 
>  
> {code:java}
> engine.eval(scriptText, bindings);
> {code}
> We thought the cache of GroovyScriptEngineImpl which is below field would 
> take effect, but actually not in the multi-threading context
> {code:java}
> // script-string-to-generated Class map
> private ManagedConcurrentValueMap classMap = new 
> ManagedConcurrentValueMap(ReferenceBundle.getSoftBundle());
> {code}
> So without proper cache, our application continuously leverages the groovy 
> class loader of GroovyScriptEngineImpl to parse scripts to generate Class 
> objects and fill up Metaspace eventually. 
>  
> And below code snippets can easily reproduce this.  
>  
> {code:java}
> package com.jingfei;
> import java.util.concurrent.ExecutorService;
> import java.util.concurrent.Executors;
> public class Main {
> static final GroovyScriptExecutor groovyScriptExecutor = new 
> GroovyScriptExecutor();
> public static void main(String[] args) throws InterruptedException {
> ExecutorService executor = Executors.newFixedThreadPool(1);
> while (true)  {
> executor.execute(new Runnable() {
> @Override
> public void run() {
> try {
> groovyScriptExecutor.executeScript("(1..10).sum()");
> } catch (Exception e) {
> e.printStackTrace();
> }
> }
> });
> }
> }
> }
> package com.jingfei;
> import java.util.HashMap;
> import java.util.Map;
> import javax.script.CompiledScript;
> import javax.script.ScriptEngine;
> import javax.script.ScriptEngineManager;
> import javax.script.ScriptException;
> import groovy.lang.GroovyClassLoader;
> import org.codehaus.groovy.jsr223.GroovyCompiledScript;
> import org.codehaus.groovy.jsr223.GroovyScriptEngineImpl;
> /**
>  * @author jingfei
>  * @version $Id: GroovyScriptExecutor.java, v 0.1 2019-04-02 20:07 jingfei 
> Exp $$
>  */
> public class GroovyScriptExecutor {
> /**  Script Engine Manager */
> private static final ScriptEngineManager factory = new 
> ScriptEngineManager();
> /**  Script engine */
> private static final ScriptEngine engine  = 
> factory.getEngineByName("groovy");
> public void executeScript(final String scriptText) throws ScriptException 
> {
> System.out.println(engine.eval(scriptText));
> }
> }{code}
> Looking into the Metaspace dump, we find out within the Metaspace there are 
> hundreds of class loader objects named 
> *groovy/lang/GroovyClassLoader$InnerLoader* and all of Class meta info loaded 
> by them with the naming pattern *Script.*
>  
> Since the script is all the same, i.e. 
> {code:java}
> (1..10).sum(){code}
> , this behavior seems totally odd to me, because I thought due to the 
> existence of the cache, there would be only one class loader created 
> necessary to parse the script. 
>  
> Any help is appreciated to work out this problem! Thanks!



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Assigned] (GROOVY-9074) CompileStatic does not throw expected exception

2019-04-10 Thread Daniel Sun (JIRA)


 [ 
https://issues.apache.org/jira/browse/GROOVY-9074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Daniel Sun reassigned GROOVY-9074:
--

Assignee: Daniel Sun

> CompileStatic does not throw expected exception
> ---
>
> Key: GROOVY-9074
> URL: https://issues.apache.org/jira/browse/GROOVY-9074
> Project: Groovy
>  Issue Type: Bug
>  Components: Compiler
>Affects Versions: 2.5.5
>Reporter: Robert Stagner
>Assignee: Daniel Sun
>Priority: Major
>
> While reading about Java Generics and wildcards (see 
> [https://docs.oracle.com/javase/tutorial/extra/generics/wildcards.html]), I 
> came across the following code in the referenced oracle document
> {code:java}
> Collection c = new ArrayList();
>  c.add(new Object()); // Compile time error{code}
> Now, I decided to wrap this in a class and try it out in Java and then in 
> Groovy.
> Here is the Java code
>  
> {code:java}
> import java.util.*;
> public class TestCollection {
>  static Collection c = new ArrayList();
>  public static void main(String[] args) {
>c.add(new Object()); // Compile time error
>  }
> }
> {code}
>  
>   
> and here is the groovy code
>  
> {code:java}
> import java.util.*;
> import groovy.transform.CompileStatic;
> @CompileStatic
> public class TestCollection {
>  static Collection c = new ArrayList();
>  public static void main(String[] args) {
>c.add(new Object()); // Compile time error
>println c.first();
>  }
> }
> {code}
>  
> When I attempt to compile the Java code I get the following expected error
> {code:java}
> $ javac TestCollection.java
>  TestCollection.java:7: error: incompatible types: Object cannot be converted 
> to CAP#1
>  c.add(new Object()); // Compile time error
>  ^
>  where CAP#1 is a fresh type-variable:
>  CAP#1 extends Object from capture of ?{code}
> But, when I run the code through Groovy, I do not get a compile-time error.  
> Instead, I get the following output
> {code:java}
> java.lang.Object@41a0aa7d{code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Comment Edited] (GROOVY-9068) GroovyScriptEngine causes Metaspace OOM

2019-04-10 Thread Daniel Sun (JIRA)


[ 
https://issues.apache.org/jira/browse/GROOVY-9068?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16815091#comment-16815091
 ] 

Daniel Sun edited comment on GROOVY-9068 at 4/11/19 5:52 AM:
-

{{GroovyCodeSource}} object is not cacheable by default, please try with Groovy 
2.5.6+ :


{code:java}
import groovy.transform.CompileStatic
import org.codehaus.groovy.runtime.InvokerHelper
import org.codehaus.groovy.runtime.memoize.ConcurrentCommonCache
import org.codehaus.groovy.runtime.memoize.EvictableCache

@CompileStatic
class GroovyUtils {
private static EvictableCache SCRIPT_CONTENT_CACHE = new 
ConcurrentCommonCache<>()

static eval(String scriptPath, Map bindingMap = [:]) {
def scriptClass = SCRIPT_CONTENT_CACHE.getAndPut(scriptPath, { key ->
return new 
GroovyClassLoader().parseClass(GroovyUtils.getResourceAsStream(key).getText('UTF-8'))
})

return InvokerHelper.createScript(scriptClass, new 
Binding(bindingMap)).run()
}
}
{code}



was (Author: daniel_sun):
{{GroovyCodeSource}} object is not cacheable by default, please try:


{code:java}
import groovy.transform.CompileStatic
import org.codehaus.groovy.runtime.InvokerHelper
import org.codehaus.groovy.runtime.memoize.ConcurrentCommonCache
import org.codehaus.groovy.runtime.memoize.EvictableCache

@CompileStatic
class GroovyUtils {
private static EvictableCache SCRIPT_CONTENT_CACHE = new 
ConcurrentCommonCache<>()

static eval(String scriptPath, Map bindingMap = [:]) {
def scriptClass = SCRIPT_CONTENT_CACHE.getAndPut(scriptPath, { key ->
return new 
GroovyClassLoader().parseClass(GroovyUtils.getResourceAsStream(key).getText('UTF-8'))
})

return InvokerHelper.createScript(scriptClass, new 
Binding(bindingMap)).run()
}
}
{code}


> GroovyScriptEngine causes Metaspace OOM
> ---
>
> Key: GROOVY-9068
> URL: https://issues.apache.org/jira/browse/GROOVY-9068
> Project: Groovy
>  Issue Type: Bug
>  Components: GroovyScriptEngine
>Affects Versions: 2.4.9
> Environment: macOS Mojave, MacBook Pro (Retina, 15-inch, Mid 2015)
>Reporter: Jingfei Hu
>Priority: Major
>  Labels: GroovyScriptEngineImpl, Metaspace, OOM
>
> Hello team,
> We've encountered this troublesome Metaspace OOM in our application recently 
> as the number of groovy scripts increases. The groovy usage pattern in our 
> application is evaluating scripts adhoc and directly. There are no any kinds 
> of caches. And we use below code to do the evaluation. 
>  
> {code:java}
> engine.eval(scriptText, bindings);
> {code}
> We thought the cache of GroovyScriptEngineImpl which is below field would 
> take effect, but actually not in the multi-threading context
> {code:java}
> // script-string-to-generated Class map
> private ManagedConcurrentValueMap classMap = new 
> ManagedConcurrentValueMap(ReferenceBundle.getSoftBundle());
> {code}
> So without proper cache, our application continuously leverages the groovy 
> class loader of GroovyScriptEngineImpl to parse scripts to generate Class 
> objects and fill up Metaspace eventually. 
>  
> And below code snippets can easily reproduce this.  
>  
> {code:java}
> package com.jingfei;
> import java.util.concurrent.ExecutorService;
> import java.util.concurrent.Executors;
> public class Main {
> static final GroovyScriptExecutor groovyScriptExecutor = new 
> GroovyScriptExecutor();
> public static void main(String[] args) throws InterruptedException {
> ExecutorService executor = Executors.newFixedThreadPool(1);
> while (true)  {
> executor.execute(new Runnable() {
> @Override
> public void run() {
> try {
> groovyScriptExecutor.executeScript("(1..10).sum()");
> } catch (Exception e) {
> e.printStackTrace();
> }
> }
> });
> }
> }
> }
> package com.jingfei;
> import java.util.HashMap;
> import java.util.Map;
> import javax.script.CompiledScript;
> import javax.script.ScriptEngine;
> import javax.script.ScriptEngineManager;
> import javax.script.ScriptException;
> import groovy.lang.GroovyClassLoader;
> import org.codehaus.groovy.jsr223.GroovyCompiledScript;
> import org.codehaus.groovy.jsr223.GroovyScriptEngineImpl;
> /**
>  * @author jingfei
>  * @version $Id: GroovyScriptExecutor.java, v 0.1 2019-04-02 20:07 jingfei 
> Exp $$
>  */
> public class GroovyScriptExecutor {
> /**  Script Engine Manager */
> private static final ScriptEngineManager factory = new 
> ScriptEngineManager();
> /**  Script engine */
> private static final ScriptEngine engine  = 
> factory.getEngineByName("groovy");
>   

[jira] [Comment Edited] (GROOVY-9068) GroovyScriptEngine causes Metaspace OOM

2019-04-10 Thread Daniel Sun (JIRA)


[ 
https://issues.apache.org/jira/browse/GROOVY-9068?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16815089#comment-16815089
 ] 

Daniel Sun edited comment on GROOVY-9068 at 4/11/19 5:51 AM:
-

I tried to execute {{(1..10).sum()}} for 1 times with the default JVM heap 
size, everything is OK.
{code:java}
def sh = new GroovyShell()
1.times {
sh.evaluate "(1..10).sum()"
}
{code}

The following code you provided is not thread safe.
{code:java}
Class getScriptClass(String script)
throws CompilationFailedException {
Class clazz = classMap.get(script);
if (clazz != null) {
return clazz;
}

// The breakpoint is below line
clazz = loader.parseClass(script, generateScriptName());
classMap.put(script, clazz);
return clazz;
}
{code}






was (Author: daniel_sun):
I tried to execute {{(1..10).sum()}} for 1 times with the default JVM heap 
size, everything is OK.
{code:java}
def sh = new GroovyShell()
1.times {
sh.evaluate "(1..10).sum()"
}
{code}

The following code you provided is not thread safe.
{code:java}
Class getScriptClass(String script)
throws CompilationFailedException {
Class clazz = classMap.get(script);
if (clazz != null) {
return clazz;
}

// The breakpoint is below line
clazz = loader.parseClass(script, generateScriptName());
classMap.put(script, clazz);
return clazz;
}
{code}

Please try the following code with Groovy 2.5.6:
{code:java}
private static final GroovyClassLoader GCL = new GroovyClassLoader();
public static Object evaluate(String scriptText) {
Class scriptClass = GCL.parseClass(scriptText);
return InvokerHelper.createScript(scriptClass, new Binding()).run();
}
{code}




> GroovyScriptEngine causes Metaspace OOM
> ---
>
> Key: GROOVY-9068
> URL: https://issues.apache.org/jira/browse/GROOVY-9068
> Project: Groovy
>  Issue Type: Bug
>  Components: GroovyScriptEngine
>Affects Versions: 2.4.9
> Environment: macOS Mojave, MacBook Pro (Retina, 15-inch, Mid 2015)
>Reporter: Jingfei Hu
>Priority: Major
>  Labels: GroovyScriptEngineImpl, Metaspace, OOM
>
> Hello team,
> We've encountered this troublesome Metaspace OOM in our application recently 
> as the number of groovy scripts increases. The groovy usage pattern in our 
> application is evaluating scripts adhoc and directly. There are no any kinds 
> of caches. And we use below code to do the evaluation. 
>  
> {code:java}
> engine.eval(scriptText, bindings);
> {code}
> We thought the cache of GroovyScriptEngineImpl which is below field would 
> take effect, but actually not in the multi-threading context
> {code:java}
> // script-string-to-generated Class map
> private ManagedConcurrentValueMap classMap = new 
> ManagedConcurrentValueMap(ReferenceBundle.getSoftBundle());
> {code}
> So without proper cache, our application continuously leverages the groovy 
> class loader of GroovyScriptEngineImpl to parse scripts to generate Class 
> objects and fill up Metaspace eventually. 
>  
> And below code snippets can easily reproduce this.  
>  
> {code:java}
> package com.jingfei;
> import java.util.concurrent.ExecutorService;
> import java.util.concurrent.Executors;
> public class Main {
> static final GroovyScriptExecutor groovyScriptExecutor = new 
> GroovyScriptExecutor();
> public static void main(String[] args) throws InterruptedException {
> ExecutorService executor = Executors.newFixedThreadPool(1);
> while (true)  {
> executor.execute(new Runnable() {
> @Override
> public void run() {
> try {
> groovyScriptExecutor.executeScript("(1..10).sum()");
> } catch (Exception e) {
> e.printStackTrace();
> }
> }
> });
> }
> }
> }
> package com.jingfei;
> import java.util.HashMap;
> import java.util.Map;
> import javax.script.CompiledScript;
> import javax.script.ScriptEngine;
> import javax.script.ScriptEngineManager;
> import javax.script.ScriptException;
> import groovy.lang.GroovyClassLoader;
> import org.codehaus.groovy.jsr223.GroovyCompiledScript;
> import org.codehaus.groovy.jsr223.GroovyScriptEngineImpl;
> /**
>  * @author jingfei
>  * @version $Id: GroovyScriptExecutor.java, v 0.1 2019-04-02 20:07 jingfei 
> Exp $$
>  */
> public class GroovyScriptExecutor {
> /**  Script Engine Manager */
> private static final ScriptEngineManager factory = new 
> ScriptEngineManager();
> /**  Script engine */
> private static final ScriptEngine engine  = 
> factory.getEngineByName("groovy");
> public void executeScript(final String 

[jira] [Commented] (GROOVY-9068) GroovyScriptEngine causes Metaspace OOM

2019-04-10 Thread Daniel Sun (JIRA)


[ 
https://issues.apache.org/jira/browse/GROOVY-9068?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16815091#comment-16815091
 ] 

Daniel Sun commented on GROOVY-9068:


{{GroovyCodeSource}} object is not cacheable by default, please try:


{code:java}
import groovy.transform.CompileStatic
import org.codehaus.groovy.runtime.InvokerHelper
import org.codehaus.groovy.runtime.memoize.ConcurrentCommonCache
import org.codehaus.groovy.runtime.memoize.EvictableCache

@CompileStatic
class GroovyUtils {
private static EvictableCache SCRIPT_CONTENT_CACHE = new 
ConcurrentCommonCache<>()

static eval(String scriptPath, Map bindingMap = [:]) {
def scriptClass = SCRIPT_CONTENT_CACHE.getAndPut(scriptPath, { key ->
return new 
GroovyClassLoader().parseClass(GroovyUtils.getResourceAsStream(key).getText('UTF-8'))
})

return InvokerHelper.createScript(scriptClass, new 
Binding(bindingMap)).run()
}
}
{code}


> GroovyScriptEngine causes Metaspace OOM
> ---
>
> Key: GROOVY-9068
> URL: https://issues.apache.org/jira/browse/GROOVY-9068
> Project: Groovy
>  Issue Type: Bug
>  Components: GroovyScriptEngine
>Affects Versions: 2.4.9
> Environment: macOS Mojave, MacBook Pro (Retina, 15-inch, Mid 2015)
>Reporter: Jingfei Hu
>Priority: Major
>  Labels: GroovyScriptEngineImpl, Metaspace, OOM
>
> Hello team,
> We've encountered this troublesome Metaspace OOM in our application recently 
> as the number of groovy scripts increases. The groovy usage pattern in our 
> application is evaluating scripts adhoc and directly. There are no any kinds 
> of caches. And we use below code to do the evaluation. 
>  
> {code:java}
> engine.eval(scriptText, bindings);
> {code}
> We thought the cache of GroovyScriptEngineImpl which is below field would 
> take effect, but actually not in the multi-threading context
> {code:java}
> // script-string-to-generated Class map
> private ManagedConcurrentValueMap classMap = new 
> ManagedConcurrentValueMap(ReferenceBundle.getSoftBundle());
> {code}
> So without proper cache, our application continuously leverages the groovy 
> class loader of GroovyScriptEngineImpl to parse scripts to generate Class 
> objects and fill up Metaspace eventually. 
>  
> And below code snippets can easily reproduce this.  
>  
> {code:java}
> package com.jingfei;
> import java.util.concurrent.ExecutorService;
> import java.util.concurrent.Executors;
> public class Main {
> static final GroovyScriptExecutor groovyScriptExecutor = new 
> GroovyScriptExecutor();
> public static void main(String[] args) throws InterruptedException {
> ExecutorService executor = Executors.newFixedThreadPool(1);
> while (true)  {
> executor.execute(new Runnable() {
> @Override
> public void run() {
> try {
> groovyScriptExecutor.executeScript("(1..10).sum()");
> } catch (Exception e) {
> e.printStackTrace();
> }
> }
> });
> }
> }
> }
> package com.jingfei;
> import java.util.HashMap;
> import java.util.Map;
> import javax.script.CompiledScript;
> import javax.script.ScriptEngine;
> import javax.script.ScriptEngineManager;
> import javax.script.ScriptException;
> import groovy.lang.GroovyClassLoader;
> import org.codehaus.groovy.jsr223.GroovyCompiledScript;
> import org.codehaus.groovy.jsr223.GroovyScriptEngineImpl;
> /**
>  * @author jingfei
>  * @version $Id: GroovyScriptExecutor.java, v 0.1 2019-04-02 20:07 jingfei 
> Exp $$
>  */
> public class GroovyScriptExecutor {
> /**  Script Engine Manager */
> private static final ScriptEngineManager factory = new 
> ScriptEngineManager();
> /**  Script engine */
> private static final ScriptEngine engine  = 
> factory.getEngineByName("groovy");
> public void executeScript(final String scriptText) throws ScriptException 
> {
> System.out.println(engine.eval(scriptText));
> }
> }{code}
> Looking into the Metaspace dump, we find out within the Metaspace there are 
> hundreds of class loader objects named 
> *groovy/lang/GroovyClassLoader$InnerLoader* and all of Class meta info loaded 
> by them with the naming pattern *Script.*
>  
> Since the script is all the same, i.e. 
> {code:java}
> (1..10).sum(){code}
> , this behavior seems totally odd to me, because I thought due to the 
> existence of the cache, there would be only one class loader created 
> necessary to parse the script. 
>  
> Any help is appreciated to work out this problem! Thanks!



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (GROOVY-9068) GroovyScriptEngine causes Metaspace OOM

2019-04-10 Thread Daniel Sun (JIRA)


[ 
https://issues.apache.org/jira/browse/GROOVY-9068?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16815089#comment-16815089
 ] 

Daniel Sun commented on GROOVY-9068:


I tried to execute {{(1..10).sum()}} for 1 times with the default JVM heap 
size, everything is OK.
{code:java}
def sh = new GroovyShell()
1.times {
sh.evaluate "(1..10).sum()"
}
{code}

The following code you provided is not thread safe.
{code:java}
Class getScriptClass(String script)
throws CompilationFailedException {
Class clazz = classMap.get(script);
if (clazz != null) {
return clazz;
}

// The breakpoint is below line
clazz = loader.parseClass(script, generateScriptName());
classMap.put(script, clazz);
return clazz;
}
{code}

Please try the following code with Groovy 2.5.6:
{code:java}
private static final GroovyClassLoader GCL = new GroovyClassLoader();
public static Object evaluate(String scriptText) {
Class scriptClass = GCL.parseClass(scriptText);
return InvokerHelper.createScript(scriptClass, new Binding()).run();
}
{code}




> GroovyScriptEngine causes Metaspace OOM
> ---
>
> Key: GROOVY-9068
> URL: https://issues.apache.org/jira/browse/GROOVY-9068
> Project: Groovy
>  Issue Type: Bug
>  Components: GroovyScriptEngine
>Affects Versions: 2.4.9
> Environment: macOS Mojave, MacBook Pro (Retina, 15-inch, Mid 2015)
>Reporter: Jingfei Hu
>Priority: Major
>  Labels: GroovyScriptEngineImpl, Metaspace, OOM
>
> Hello team,
> We've encountered this troublesome Metaspace OOM in our application recently 
> as the number of groovy scripts increases. The groovy usage pattern in our 
> application is evaluating scripts adhoc and directly. There are no any kinds 
> of caches. And we use below code to do the evaluation. 
>  
> {code:java}
> engine.eval(scriptText, bindings);
> {code}
> We thought the cache of GroovyScriptEngineImpl which is below field would 
> take effect, but actually not in the multi-threading context
> {code:java}
> // script-string-to-generated Class map
> private ManagedConcurrentValueMap classMap = new 
> ManagedConcurrentValueMap(ReferenceBundle.getSoftBundle());
> {code}
> So without proper cache, our application continuously leverages the groovy 
> class loader of GroovyScriptEngineImpl to parse scripts to generate Class 
> objects and fill up Metaspace eventually. 
>  
> And below code snippets can easily reproduce this.  
>  
> {code:java}
> package com.jingfei;
> import java.util.concurrent.ExecutorService;
> import java.util.concurrent.Executors;
> public class Main {
> static final GroovyScriptExecutor groovyScriptExecutor = new 
> GroovyScriptExecutor();
> public static void main(String[] args) throws InterruptedException {
> ExecutorService executor = Executors.newFixedThreadPool(1);
> while (true)  {
> executor.execute(new Runnable() {
> @Override
> public void run() {
> try {
> groovyScriptExecutor.executeScript("(1..10).sum()");
> } catch (Exception e) {
> e.printStackTrace();
> }
> }
> });
> }
> }
> }
> package com.jingfei;
> import java.util.HashMap;
> import java.util.Map;
> import javax.script.CompiledScript;
> import javax.script.ScriptEngine;
> import javax.script.ScriptEngineManager;
> import javax.script.ScriptException;
> import groovy.lang.GroovyClassLoader;
> import org.codehaus.groovy.jsr223.GroovyCompiledScript;
> import org.codehaus.groovy.jsr223.GroovyScriptEngineImpl;
> /**
>  * @author jingfei
>  * @version $Id: GroovyScriptExecutor.java, v 0.1 2019-04-02 20:07 jingfei 
> Exp $$
>  */
> public class GroovyScriptExecutor {
> /**  Script Engine Manager */
> private static final ScriptEngineManager factory = new 
> ScriptEngineManager();
> /**  Script engine */
> private static final ScriptEngine engine  = 
> factory.getEngineByName("groovy");
> public void executeScript(final String scriptText) throws ScriptException 
> {
> System.out.println(engine.eval(scriptText));
> }
> }{code}
> Looking into the Metaspace dump, we find out within the Metaspace there are 
> hundreds of class loader objects named 
> *groovy/lang/GroovyClassLoader$InnerLoader* and all of Class meta info loaded 
> by them with the naming pattern *Script.*
>  
> Since the script is all the same, i.e. 
> {code:java}
> (1..10).sum(){code}
> , this behavior seems totally odd to me, because I thought due to the 
> existence of the cache, there would be only one class loader created 
> necessary to parse the script. 
>  
> Any help is appreciated to work out this problem!

[jira] [Commented] (GROOVY-9068) GroovyScriptEngine causes Metaspace OOM

2019-04-10 Thread Jingfei Hu (JIRA)


[ 
https://issues.apache.org/jira/browse/GROOVY-9068?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16815037#comment-16815037
 ] 

Jingfei Hu commented on GROOVY-9068:


[~daniel_sun] Thanks for your reply and sorry for delay. I tried 2.5.6 with no 
luck. I changed my code to be 10 threads and debugged this method 

 
{code:java}
Class getScriptClass(String script)
throws CompilationFailedException {
Class clazz = classMap.get(script);
if (clazz != null) {
return clazz;
}

// The breakpoint is below line
clazz = loader.parseClass(script, generateScriptName());
classMap.put(script, clazz);
return clazz;
}
{code}
It turns out it's still hit 10 times which means the *classMap* doesn't work as 
my expectation. I am not sure whether you get the same results in your side or 
am I missing something. 

> GroovyScriptEngine causes Metaspace OOM
> ---
>
> Key: GROOVY-9068
> URL: https://issues.apache.org/jira/browse/GROOVY-9068
> Project: Groovy
>  Issue Type: Bug
>  Components: GroovyScriptEngine
>Affects Versions: 2.4.9
> Environment: macOS Mojave, MacBook Pro (Retina, 15-inch, Mid 2015)
>Reporter: Jingfei Hu
>Priority: Major
>  Labels: GroovyScriptEngineImpl, Metaspace, OOM
>
> Hello team,
> We've encountered this troublesome Metaspace OOM in our application recently 
> as the number of groovy scripts increases. The groovy usage pattern in our 
> application is evaluating scripts adhoc and directly. There are no any kinds 
> of caches. And we use below code to do the evaluation. 
>  
> {code:java}
> engine.eval(scriptText, bindings);
> {code}
> We thought the cache of GroovyScriptEngineImpl which is below field would 
> take effect, but actually not in the multi-threading context
> {code:java}
> // script-string-to-generated Class map
> private ManagedConcurrentValueMap classMap = new 
> ManagedConcurrentValueMap(ReferenceBundle.getSoftBundle());
> {code}
> So without proper cache, our application continuously leverages the groovy 
> class loader of GroovyScriptEngineImpl to parse scripts to generate Class 
> objects and fill up Metaspace eventually. 
>  
> And below code snippets can easily reproduce this.  
>  
> {code:java}
> package com.jingfei;
> import java.util.concurrent.ExecutorService;
> import java.util.concurrent.Executors;
> public class Main {
> static final GroovyScriptExecutor groovyScriptExecutor = new 
> GroovyScriptExecutor();
> public static void main(String[] args) throws InterruptedException {
> ExecutorService executor = Executors.newFixedThreadPool(1);
> while (true)  {
> executor.execute(new Runnable() {
> @Override
> public void run() {
> try {
> groovyScriptExecutor.executeScript("(1..10).sum()");
> } catch (Exception e) {
> e.printStackTrace();
> }
> }
> });
> }
> }
> }
> package com.jingfei;
> import java.util.HashMap;
> import java.util.Map;
> import javax.script.CompiledScript;
> import javax.script.ScriptEngine;
> import javax.script.ScriptEngineManager;
> import javax.script.ScriptException;
> import groovy.lang.GroovyClassLoader;
> import org.codehaus.groovy.jsr223.GroovyCompiledScript;
> import org.codehaus.groovy.jsr223.GroovyScriptEngineImpl;
> /**
>  * @author jingfei
>  * @version $Id: GroovyScriptExecutor.java, v 0.1 2019-04-02 20:07 jingfei 
> Exp $$
>  */
> public class GroovyScriptExecutor {
> /**  Script Engine Manager */
> private static final ScriptEngineManager factory = new 
> ScriptEngineManager();
> /**  Script engine */
> private static final ScriptEngine engine  = 
> factory.getEngineByName("groovy");
> public void executeScript(final String scriptText) throws ScriptException 
> {
> System.out.println(engine.eval(scriptText));
> }
> }{code}
> Looking into the Metaspace dump, we find out within the Metaspace there are 
> hundreds of class loader objects named 
> *groovy/lang/GroovyClassLoader$InnerLoader* and all of Class meta info loaded 
> by them with the naming pattern *Script.*
>  
> Since the script is all the same, i.e. 
> {code:java}
> (1..10).sum(){code}
> , this behavior seems totally odd to me, because I thought due to the 
> existence of the cache, there would be only one class loader created 
> necessary to parse the script. 
>  
> Any help is appreciated to work out this problem! Thanks!



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (GROOVY-9074) CompileStatic does not throw expected exception

2019-04-10 Thread Robert Stagner (JIRA)


 [ 
https://issues.apache.org/jira/browse/GROOVY-9074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robert Stagner updated GROOVY-9074:
---
Summary: CompileStatic does not throw expected exception  (was: 
CompileStatic )

> CompileStatic does not throw expected exception
> ---
>
> Key: GROOVY-9074
> URL: https://issues.apache.org/jira/browse/GROOVY-9074
> Project: Groovy
>  Issue Type: Bug
>  Components: Compiler
>Affects Versions: 2.5.5
>Reporter: Robert Stagner
>Priority: Major
>
> While reading about Java Generics and wildcards (see 
> [https://docs.oracle.com/javase/tutorial/extra/generics/wildcards.html]), I 
> came across the following code in the referenced oracle document
> {code:java}
> Collection c = new ArrayList();
>  c.add(new Object()); // Compile time error{code}
> Now, I decided to wrap this in a class and try it out in Java and then in 
> Groovy.
> Here is the Java code
>  
> {code:java}
> import java.util.*;
> public class TestCollection {
>  static Collection c = new ArrayList();
>  public static void main(String[] args) {
>c.add(new Object()); // Compile time error
>  }
> }
> {code}
>  
>   
> and here is the groovy code
>  
> {code:java}
> import java.util.*;
> import groovy.transform.CompileStatic;
> @CompileStatic
> public class TestCollection {
>  static Collection c = new ArrayList();
>  public static void main(String[] args) {
>c.add(new Object()); // Compile time error
>println c.first();
>  }
> }
> {code}
>  
> When I attempt to compile the Java code I get the following expected error
> {code:java}
> $ javac TestCollection.java
>  TestCollection.java:7: error: incompatible types: Object cannot be converted 
> to CAP#1
>  c.add(new Object()); // Compile time error
>  ^
>  where CAP#1 is a fresh type-variable:
>  CAP#1 extends Object from capture of ?{code}
> But, when I run the code through Groovy, I do not get a compile-time error.  
> Instead, I get the following output
> {code:java}
> java.lang.Object@41a0aa7d{code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Created] (GROOVY-9074) CompileStatic

2019-04-10 Thread Robert Stagner (JIRA)
Robert Stagner created GROOVY-9074:
--

 Summary: CompileStatic 
 Key: GROOVY-9074
 URL: https://issues.apache.org/jira/browse/GROOVY-9074
 Project: Groovy
  Issue Type: Bug
  Components: Compiler
Affects Versions: 2.5.5
Reporter: Robert Stagner


While reading about Java Generics and wildcards (see 
[https://docs.oracle.com/javase/tutorial/extra/generics/wildcards.html]), I 
came across the following code in the referenced oracle document
{code:java}
Collection c = new ArrayList();
 c.add(new Object()); // Compile time error{code}
Now, I decided to wrap this in a class and try it out in Java and then in 
Groovy.

Here is the Java code

 
{code:java}
import java.util.*;
public class TestCollection {
 static Collection c = new ArrayList();
 public static void main(String[] args) {
   c.add(new Object()); // Compile time error
 }
}
{code}
 

  

and here is the groovy code

 
{code:java}
import java.util.*;
import groovy.transform.CompileStatic;

@CompileStatic
public class TestCollection {
 static Collection c = new ArrayList();
 public static void main(String[] args) {
   c.add(new Object()); // Compile time error
   println c.first();
 }
}
{code}
 

When I attempt to compile the Java code I get the following expected error
{code:java}
$ javac TestCollection.java
 TestCollection.java:7: error: incompatible types: Object cannot be converted 
to CAP#1
 c.add(new Object()); // Compile time error
 ^
 where CAP#1 is a fresh type-variable:
 CAP#1 extends Object from capture of ?{code}
But, when I run the code through Groovy, I do not get a compile-time error.  
Instead, I get the following output


{code:java}
java.lang.Object@41a0aa7d{code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[GitHub] [groovy] mkutz opened a new pull request #908: Found and removed extra "a"

2019-04-10 Thread GitBox
mkutz opened a new pull request #908: Found and removed extra "a"
URL: https://github.com/apache/groovy/pull/908
 
 
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services