[jira] [Commented] (GROOVY-9209) Compiler throws an exception in ClassNode#getTypeClass after checking ClassNode#isResolved
[
https://issues.apache.org/jira/browse/GROOVY-9209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16895700#comment-16895700
]
Jochen Theodorou commented on GROOVY-9209:
--
frankly I think getTypeClass should be removed from ClassNode. This method is
really only for classes, that can be realized as a class in the JVM. This is
obviously not the case here. Maybe it would be more correct for
DecompiledClassNode to not to return true for isResolved. But I am not sure
about the implications.
> Compiler throws an exception in ClassNode#getTypeClass after checking
> ClassNode#isResolved
> --
>
> Key: GROOVY-9209
> URL: https://issues.apache.org/jira/browse/GROOVY-9209
> Project: Groovy
> Issue Type: Bug
> Components: Compiler
>Affects Versions: 2.5.6
> Environment: intellij idea
>Reporter: Daniil Ovchinnikov
>Priority: Critical
>
> {noformat}
> Error:Groovyc: While compiling mn-gorm-example.main: BUG! exception in phase
> 'canonicalization' in source unit
> '/Users/pditommaso/Projects/mn-gorm-example/src/main/groovy/example/gorm/Bootstrap.groovy'
> JVM class can't be loaded for example.gorm.service.PersonService
> at
> org.codehaus.groovy.ast.decompiled.AsmReferenceResolver.resolveJvmClass(AsmReferenceResolver.java:86)
> at
> org.codehaus.groovy.ast.decompiled.DecompiledClassNode.getTypeClass(DecompiledClassNode.java:175)
> at org.codehaus.groovy.ast.ClassNode.getTypeClass(ClassNode.java:1381)
> at
> io.micronaut.ast.groovy.InjectTransform$InjectVisitor.resolveParameterType(InjectTransform.groovy:1117)
> ...
> {noformat}
> {code:java|title=InjectVisitor#resolveParameterType}
> ClassNode parameterType = parameter.type
> if (parameterType.isResolved()) {
> parameterType.typeClass // here
> } else {
> parameterType.name
> }
> {code}
> Code: [https://github.com/pditommaso/mn-gorm-example]
> Steps to reproduce:
> 1. make sure the build is not delegated to Gradle in Preferences | Build,
> Execution, Deployment | Build Tools | Gradle
> 2. rebuild project
> 3. make changes in Person.groovy and Bootstrap.groovy (to mark them as
> subject for recompilation)
> 4. build project
> What happens with {{-Dgroovyc.asm.resolving.only=false}}:
> 1. Bootstrap.groovy and Person.groovy are added to
> {{CompilationUnit#queuedSources}}
> 2. {{ResolveVisitor}} visits Bootstrap.groovy and tries to load PersonService
> 3. {{asmResolving}} flag is set to {{false}} by IntelliJ, this results in
> skipping {{findDecompiled}} call inside
> {{ClassNodeResolver#tryAsLoaderClassOrScript}}
> 4. the PersonService class fails to load because of missing Person class
> 5. {{tryAsScript}} kicks in and adds PersonService to
> {{CompilationUnit#queuedSources}}
> 6. when it comes to Micronaut {{ClassNode#isResolved}} returns {{false}} for
> PersonService
> What happens without {{-Dgroovyc.asm.resolving.only=false}}:
> 1. same
> 2. same
> 3. {{asmResolving}} is not set by IntellliJ
> 4. {{findDecompiled}} returns {{DecompiledClassNode}} for PersonService
> 5. when it comes to Micronaut {{ClassNode#isResolved}} returns {{true}} for
> PersonService, and this results in an exception because the class cannot be
> loaded actually.
> I've tried to fix it in the compiler but I'm not sure what's the proper fix
> would be.
> Please let me know if I can do something within IntelliJ.
> The issue in JB YouTrack for the reference:
> [https://youtrack.jetbrains.com/issue/IDEA-218698]
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[GitHub] [groovy] blackdrag commented on issue #968: Fixed the Reference of the metaclass in ClassInfo.java to use a Weak…
blackdrag commented on issue #968: Fixed the Reference of the metaclass in ClassInfo.java to use a Weak… URL: https://github.com/apache/groovy/pull/968#issuecomment-516226121 But the metaclass has hard references on the class it is a metaclass for I thought. Therefore it should be impossible to unload the classes without also or first unloading the meta classes. The usual approach is to actually create a cache for compiled scripts and avoid the creation of the classes again and again. From what I understood in your case it can happen that you have, over a session, just two many different rules as scripts, so that this is not possible.. Which would mean you have ten thousands of them... Is that right? 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
[jira] [Updated] (GROOVY-9209) Compiler throws an exception in ClassNode#getTypeClass after checking ClassNode#isResolved
[
https://issues.apache.org/jira/browse/GROOVY-9209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniil Ovchinnikov updated GROOVY-9209:
---
Description:
{noformat}
Error:Groovyc: While compiling mn-gorm-example.main: BUG! exception in phase
'canonicalization' in source unit
'/Users/pditommaso/Projects/mn-gorm-example/src/main/groovy/example/gorm/Bootstrap.groovy'
JVM class can't be loaded for example.gorm.service.PersonService
at
org.codehaus.groovy.ast.decompiled.AsmReferenceResolver.resolveJvmClass(AsmReferenceResolver.java:86)
at
org.codehaus.groovy.ast.decompiled.DecompiledClassNode.getTypeClass(DecompiledClassNode.java:175)
at org.codehaus.groovy.ast.ClassNode.getTypeClass(ClassNode.java:1381)
at
io.micronaut.ast.groovy.InjectTransform$InjectVisitor.resolveParameterType(InjectTransform.groovy:1117)
...
{noformat}
{code:java|title=InjectVisitor#resolveParameterType}
ClassNode parameterType = parameter.type
if (parameterType.isResolved()) {
parameterType.typeClass // here
} else {
parameterType.name
}
{code}
Code: [https://github.com/pditommaso/mn-gorm-example]
Steps to reproduce:
1. make sure the build is not delegated to Gradle in Preferences | Build,
Execution, Deployment | Build Tools | Gradle
2. rebuild project
3. make changes in Person.groovy and Bootstrap.groovy (to mark them as subject
for recompilation)
4. build project
What happens with {{-Dgroovyc.asm.resolving.only=false}}:
1. Bootstrap.groovy and Person.groovy are added to
{{CompilationUnit#queuedSources}}
2. {{ResolveVisitor}} visits Bootstrap.groovy and tries to load PersonService
3. {{asmResolving}} flag is set to {{false}} by IntelliJ, this results in
skipping {{findDecompiled}} call inside
{{ClassNodeResolver#tryAsLoaderClassOrScript}}
4. the PersonService class fails to load because of missing Person class
5. {{tryAsScript}} kicks in and adds PersonService to
{{CompilationUnit#queuedSources}}
6. when it comes to Micronaut {{ClassNode#isResolved}} returns {{false}} for
PersonService
What happens without {{-Dgroovyc.asm.resolving.only=false}}:
1. same
2. same
3. {{asmResolving}} is not set by IntellliJ
4. {{findDecompiled}} returns {{DecompiledClassNode}} for PersonService
5. when it comes to Micronaut {{ClassNode#isResolved}} returns {{true}} for
PersonService, and this results in an exception because the class cannot be
loaded actually.
I've tried to fix it in the compiler but I'm not sure what's the proper fix
would be.
Please let me know if I can do something within IntelliJ.
The issue in JB YouTrack for the reference:
[https://youtrack.jetbrains.com/issue/IDEA-218698]
was:
{noformat}
Error:Groovyc: While compiling mn-gorm-example.main: BUG! exception in phase
'canonicalization' in source unit
'/Users/pditommaso/Projects/mn-gorm-example/src/main/groovy/example/gorm/Bootstrap.groovy'
JVM class can't be loaded for example.gorm.service.PersonService
at
org.codehaus.groovy.ast.decompiled.AsmReferenceResolver.resolveJvmClass(AsmReferenceResolver.java:86)
at
org.codehaus.groovy.ast.decompiled.DecompiledClassNode.getTypeClass(DecompiledClassNode.java:175)
at org.codehaus.groovy.ast.ClassNode.getTypeClass(ClassNode.java:1381)
at
io.micronaut.ast.groovy.InjectTransform$InjectVisitor.resolveParameterType(InjectTransform.groovy:1117)
...
{noformat}
{code:java|title=InjectVisitor#resolveParameterType}
ClassNode parameterType = parameter.type
if (parameterType.isResolved()) {
parameterType.typeClass // here
} else {
parameterType.name
}
{code}
Code: [https://github.com/pditommaso/mn-gorm-example]
Steps to reproduce:
1. make sure the build is not delegated to Gradle in Preferences | Build,
Execution, Deployment | Build Tools | Gradle
2. rebuild project
3. make changes in Person.groovy and Bootstrap.groovy (to mark them as subject
for recompilation)
4. build project
What happens with {{-Dgroovyc.asm.resolving.only=false}}:
1. Bootstrap.groovy and Person.groovy are added to
{{CompilationUnit#queuedSources}}
2. {{ResolveVisitor}} visits Bootstrap.groovy and tries to load PersonService
3. {{asmResolving}} flag is set to {{false}} by IntelliJ, this results in
skipping {{findDecompiled}} call inside
{{ClassNodeResolver#tryAsLoaderClassOrScript}}
4. the PersonService class fails to load because of missing Person class
5. {{tryAsScript}} kicks in and adds PersonService to
{{CompilationUnit#queuedSources}}
6. when it comes to Micronaut {{ClassNode#isResolved}} returns {{false}} for
PersonService
What happens with {{asmResolving}}:
1. same
2. same
3. {{asmResolving}} is not set by IntellliJ
4. {{findDecompiled}} returns {{DecompiledClassNode}} for PersonService
5. when it comes to Micronaut {{ClassNode#isResolved}} returns {{true}} for
PersonService, and this results in an exception because the class cannot be
loaded actually.
I've tried to fix
[jira] [Commented] (GROOVY-8625) Groovy Lexer does not accept UTF-8 characters like ° or § ... and a lot more
[
https://issues.apache.org/jira/browse/GROOVY-8625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16895500#comment-16895500
]
Isaac Dooley commented on GROOVY-8625:
--
I've run into an issue that matches the title of this issue, but has nothing to
do with the discussion of DSLs. Specifically, in 3.0.0b2, the lexer doesn't
allow some valid characters to be part of an identifier.
The \u2040 character for example ought to be considered a valid character in an
identifier because the [https://groovy-lang.org/syntax.html] says it should be,
and also the Java Character class claims it should be:
{code:java}
assert Character.isJavaIdentifierPart("\u2040" as char){code}
Does the new grammar intentionally exclude '\u0100' to '\uFFFE' for some reason?
> Groovy Lexer does not accept UTF-8 characters like ° or § ... and a lot more
>
>
> Key: GROOVY-8625
> URL: https://issues.apache.org/jira/browse/GROOVY-8625
> Project: Groovy
> Issue Type: Bug
> Components: Compiler
>Affects Versions: 2.5.0
>Reporter: Alexander Klein
>Priority: Major
> Labels: compiler, grammar, lexer
>
> The grammar uses a similar specification for LETTERs as the old Java-grammar.
> By intention most UTF-8 characters should possible to use for names to enable
> localization in languages using non-latin characters. This is especially
> important for DSLs.
> Ast-transformations will take place after the Lexer. With the Lexer accepting
> his characters, ast-transformations are now able to handle more things like
> creating custom operators and so on.
> This is a problem only for ANTLR 2.
> ANTLR 4 is only missing the '#'-sign.
> This maybe introduces a breaking change, because GStrings like
> "$first#$second" worked in the past, and now will not anymore. Before this
> change, "$first#" is interpreted as the value of the variable first plus a
> '#' sign. Now it is interpreted as the value of the variable first#.
> This, of cause, is a problem for all newly added letters.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (GROOVY-9068) GroovyScriptEngine causes Metaspace OOM
[
https://issues.apache.org/jira/browse/GROOVY-9068?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16895257#comment-16895257
]
Daniel Wehrle commented on GROOVY-9068:
---
[~daniel_sun]
Any suggestion from you how to integrate your proposal in our 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.14#76016)
