Spoofax 2.0.0-beta1 API

Minor issue: after closing Spoofax, some thread is still running. I found out when running the following program via the maven exec plugin (mvn clean package exec:java -Dexec.mainClass="Example")

import org.metaborg.core.MetaborgException;
import org.metaborg.spoofax.core.Spoofax;

public class Example {

  public static void main(String[] args) {
    
    try (final Spoofax spoofax = new Spoofax()) {
       // do nothing
    } catch (MetaborgException e) {
      e.printStackTrace();
    }
  }
}

Output:

14:17:24.674 [oracle.pgql.lang.example.Example.main()] DEBUG org.metaborg.core.MetaBorg - Closing the MetaBorg API
[WARNING] thread Thread[com.google.inject.internal.util.$Finalizer,5,oracle.pgql.lang.example.Example] was interrupted but is still alive after waiting at least 14999msecs
[WARNING] thread Thread[com.google.inject.internal.util.$Finalizer,5,oracle.pgql.lang.example.Example] will linger despite being asked to die via interruption
[WARNING] NOTE: 1 thread(s) did not finish despite being asked to  via interruption. This is not a problem with exec:java, it is a problem with the running code. Although not serious, it should be remedied.
[WARNING] Couldn't destroy threadgroup org.codehaus.mojo.exec.ExecJavaMojo$IsolatedThreadGroup[name=oracle.pgql.lang.example.Example,maxpri=10]
java.lang.IllegalThreadStateException
	at java.lang.ThreadGroup.destroy(ThreadGroup.java:775)
	at org.codehaus.mojo.exec.ExecJavaMojo.execute(ExecJavaMojo.java:328)
	at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:207)
	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
	at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
	at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
	at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
	at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
	at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:307)
	at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:193)
	at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:106)
	at org.apache.maven.cli.MavenCli.execute(MavenCli.java:863)
	at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:288)
	at org.apache.maven.cli.MavenCli.main(MavenCli.java:199)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:606)
	at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
	at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
	at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
	at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 17.746 s
[INFO] Finished at: 2016-05-10T14:17:39-07:00
[INFO] Final Memory: 27M/620M
[INFO] ------------------------------------------------------------------------

Besides the output, the program also waits 5 seconds for the thread and only then terminates (it’s possible to avoid this with the -Dexec.cleanupDaemonThreads=false flag, but that doesn’t solve the real issue).

When doing a thread dump and comparing it to the thread dump on page https://github.com/ReactiveX/RxJava/issues/2833, I found out it’s a thread named “com.google.inject.internal.util.$Finalizer”.

Perhaps something is not closed properly? Again, it’s not not a big issue but perhaps the fix is easy.

oskar@oskar-sun:~/repos/pgx/shell$ jstack 21481
2016-05-10 14:47:21
Full thread dump Java HotSpot(TM) 64-Bit Server VM (24.80-b11 mixed mode):

"Attach Listener" daemon prio=10 tid=0x00007f8f74001000 nid=0x541e waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"com.google.inject.internal.util.$Finalizer" daemon prio=10 tid=0x00007f8f5c33b800 nid=0x5409 in Object.wait() [0x00007f8f63ffe000]
   java.lang.Thread.State: WAITING (on object monitor)
	at java.lang.Object.wait(Native Method)
	- waiting on <0x00000000f4088330> (a java.lang.ref.ReferenceQueue$Lock)
	at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:135)
	- locked <0x00000000f4088330> (a java.lang.ref.ReferenceQueue$Lock)
	at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:151)
	at com.google.inject.internal.util.$Finalizer.run(Finalizer.java:114)

"Service Thread" daemon prio=10 tid=0x00007f8fb40a9800 nid=0x5403 runnable [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"C2 CompilerThread1" daemon prio=10 tid=0x00007f8fb40a7800 nid=0x5402 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"C2 CompilerThread0" daemon prio=10 tid=0x00007f8fb40a4800 nid=0x5401 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"Signal Dispatcher" daemon prio=10 tid=0x00007f8fb40a2000 nid=0x5400 runnable [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"Finalizer" daemon prio=10 tid=0x00007f8fb4079000 nid=0x53ff in Object.wait() [0x00007f8f9d6bc000]
   java.lang.Thread.State: WAITING (on object monitor)
	at java.lang.Object.wait(Native Method)
	- waiting on <0x00000000f4098258> (a java.lang.ref.ReferenceQueue$Lock)
	at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:135)
	- locked <0x00000000f4098258> (a java.lang.ref.ReferenceQueue$Lock)
	at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:151)
	at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:209)

"Reference Handler" daemon prio=10 tid=0x00007f8fb4077000 nid=0x53fe in Object.wait() [0x00007f8f9e6bd000]
   java.lang.Thread.State: WAITING (on object monitor)
	at java.lang.Object.wait(Native Method)
	- waiting on <0x00000000f4088320> (a java.lang.ref.Reference$Lock)
	at java.lang.Object.wait(Object.java:503)
	at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:133)
	- locked <0x00000000f4088320> (a java.lang.ref.Reference$Lock)

"main" prio=10 tid=0x00007f8fb400a000 nid=0x53f4 in Object.wait() [0x00007f8fb9720000]
   java.lang.Thread.State: TIMED_WAITING (on object monitor)
	at java.lang.Object.wait(Native Method)
	- waiting on <0x00000000f40a0000> (a com.google.inject.internal.util.$Finalizer)
	at java.lang.Thread.join(Thread.java:1289)
	- locked <0x00000000f40a0000> (a com.google.inject.internal.util.$Finalizer)
	at org.codehaus.mojo.exec.ExecJavaMojo.joinThread(ExecJavaMojo.java:408)
	at org.codehaus.mojo.exec.ExecJavaMojo.terminateThreads(ExecJavaMojo.java:451)
	at org.codehaus.mojo.exec.ExecJavaMojo.execute(ExecJavaMojo.java:324)
	at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:207)
	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
	at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
	at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
	at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
	at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
	at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:307)
	at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:193)
	at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:106)
	at org.apache.maven.cli.MavenCli.execute(MavenCli.java:863)
	at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:288)
	at org.apache.maven.cli.MavenCli.main(MavenCli.java:199)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:606)
	at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
	at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
	at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
	at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)

"VM Thread" prio=10 tid=0x00007f8fb4072800 nid=0x53fd runnable 

"GC task thread#0 (ParallelGC)" prio=10 tid=0x00007f8fb4020000 nid=0x53f5 runnable 

"GC task thread#1 (ParallelGC)" prio=10 tid=0x00007f8fb4021800 nid=0x53f6 runnable 

"GC task thread#2 (ParallelGC)" prio=10 tid=0x00007f8fb4023800 nid=0x53f7 runnable 

"GC task thread#3 (ParallelGC)" prio=10 tid=0x00007f8fb4025800 nid=0x53f8 runnable 

"GC task thread#4 (ParallelGC)" prio=10 tid=0x00007f8fb4027800 nid=0x53f9 runnable 

"GC task thread#5 (ParallelGC)" prio=10 tid=0x00007f8fb4029000 nid=0x53fa runnable 

"GC task thread#6 (ParallelGC)" prio=10 tid=0x00007f8fb402b000 nid=0x53fb runnable 

"GC task thread#7 (ParallelGC)" prio=10 tid=0x00007f8fb402d000 nid=0x53fc runnable 

"VM Periodic Task Thread" prio=10 tid=0x00007f8fb40b4800 nid=0x5404 waiting on condition 

JNI global references: 162
Submitted by Oskar van Rest on 11 May 2016 at 00:02

On 11 May 2016 at 00:02 Oskar van Rest tagged minor

On 18 May 2016 at 23:21 Oskar van Rest commented:

On 19 May 2016 at 13:08 Gabriël Konat commented:

Spoofax does not launch any threads itself. com.google.inject.internal.util.$Finalizer is a Guice thing. I’ve never had any problems with that thread not closing, but maybe you can find more info at the Guice page?


On 4 July 2016 at 15:28 Gabriël Konat commented:

Did you find a solution to this Oskar?


On 17 August 2016 at 14:44 Gabriël Konat closed this issue.

Log in to post comments