Welcome! Please see the About page for a little more info on how this works.

0 votes
in Compiler by

Compiling a function that references a non loaded (or uninitialized) class triggers its init static. When the init static loads clojure code, some constants (source code I think) are leaked into the constants pool of the function under compilation.

It prevented CCW from working in some environments (Rational) because the static init of the resulting function was over 64K.

Steps to reproduce:

Load the leak.main ns and run the code in comments: the first function has 15 extra fields despite being identical to the second one.

`
(ns leak.main)

(defn first-to-load []
leak.Klass/foo)

(defn second-to-load []
leak.Klass/foo)

(comment
=> (map (comp count #(.getFields %) class) [first-to-load second-to-load])
(16 1)
)
`

`
package leak;

import clojure.lang.IFn;
import clojure.lang.RT;
import clojure.lang.Symbol;

public class Klass {
static {

RT.var("clojure.core", "require").invoke(Symbol.intern("leak.leaky"));

}
public static IFn foo = RT.var("leak.leaky", "foo");
}
`

`
(ns leak.leaky)

(defn foo
"Some doc"
[]
"hello")

(def unrelated 42)
`

https://gist.github.com/cgrand/5dcb6fe5b269aecc6a5b#file-main-clj-L10

Patch: clj-1620-v5.patch

33 Answers

0 votes
by

Comment made by: cgrand

Patch from Nicola Mometto

0 votes
by

Comment made by: bronsa

Attached the same patch with a more informative better commit message

0 votes
by

Comment made by: laurentpetit

I'd like to thank Christophe and Alex for their invaluable help in understanding what was happening, formulating the right hypothesis and then finding a fix.

I would also mention that even if non IBM rational environments where not affected by the bug to the point were CCW would not work, they were still affected. For instance the class for a one-liner function wrapping an interop call weighs 700bytes once the patch is applied, when it weighed 90kbytes with current 1.6 or 1.7.

0 votes
by

Comment made by: laurentpetit

In CCW for the initial problematic function, the -v2 patch produces exactly the same bytecode as if the referenced class does not load any namespace in its static initializers.
That is, the patch is valid. I will test it live in the IBM Rational environment ASAP.

0 votes
by

Comment made by: laurentpetit

I confirm the patch fixes the issue detected initially in the IBM Rational environment

0 votes
by

Comment made by: michaelblume

I have absolutely no idea why, but if I apply this patch, and the patch for CLJ-1544 to master, and then try to build a war from this test project https://github.com/pdenhaan/extend-test I get a scary-looking traceback:

`
$ lein do clean, war!
Exception in thread "main" java.lang.NoSuchFieldError: thunk0__, compiling:(route.clj:1:1)

at clojure.lang.Compiler$InvokeExpr.eval(Compiler.java:3606)
at clojure.lang.Compiler.compile1(Compiler.java:7299)
at clojure.lang.Compiler.compile1(Compiler.java:7289)
at clojure.lang.Compiler.compile(Compiler.java:7365)
at clojure.lang.RT.compile(RT.java:398)
at clojure.lang.RT.load(RT.java:438)
at clojure.lang.RT.load(RT.java:411)
at clojure.core$load$fn__5415.invoke(core.clj:5823)
at clojure.core$load.doInvoke(core.clj:5822)
at clojure.lang.RestFn.invoke(RestFn.java:408)
at clojure.core$load_one.invoke(core.clj:5613)
at clojure.core$load_lib$fn__5362.invoke(core.clj:5668)
at clojure.core$load_lib.doInvoke(core.clj:5667)
at clojure.lang.RestFn.applyTo(RestFn.java:142)
at clojure.core$apply.invoke(core.clj:628)
at clojure.core$load_libs.doInvoke(core.clj:5706)
at clojure.lang.RestFn.applyTo(RestFn.java:137)
at clojure.core$apply.invoke(core.clj:628)
at clojure.core$require.doInvoke(core.clj:5789)
at clojure.lang.RestFn.invoke(RestFn.java:436)
at extend_test.core.handler$loading__5301__auto____66.invoke(handler.clj:1)
at clojure.lang.AFn.applyToHelper(AFn.java:152)
at clojure.lang.AFn.applyTo(AFn.java:144)
at clojure.lang.Compiler$InvokeExpr.eval(Compiler.java:3601)
at clojure.lang.Compiler.compile1(Compiler.java:7299)
at clojure.lang.Compiler.compile1(Compiler.java:7289)
at clojure.lang.Compiler.compile(Compiler.java:7365)
at clojure.lang.RT.compile(RT.java:398)
at clojure.lang.RT.load(RT.java:438)
at clojure.lang.RT.load(RT.java:411)
at clojure.core$load$fn__5415.invoke(core.clj:5823)
at clojure.core$load.doInvoke(core.clj:5822)
at clojure.lang.RestFn.invoke(RestFn.java:408)
at clojure.core$load_one.invoke(core.clj:5613)
at clojure.core$load_lib$fn__5362.invoke(core.clj:5668)
at clojure.core$load_lib.doInvoke(core.clj:5667)
at clojure.lang.RestFn.applyTo(RestFn.java:142)
at clojure.core$apply.invoke(core.clj:628)
at clojure.core$load_libs.doInvoke(core.clj:5706)
at clojure.lang.RestFn.applyTo(RestFn.java:137)
at clojure.core$apply.invoke(core.clj:628)
at clojure.core$require.doInvoke(core.clj:5789)
at clojure.lang.RestFn.invoke(RestFn.java:421)
at extend_test.core.servlet$loading__5301__auto____7.invoke(servlet.clj:1)
at clojure.lang.AFn.applyToHelper(AFn.java:152)
at clojure.lang.AFn.applyTo(AFn.java:144)
at clojure.lang.Compiler$InvokeExpr.eval(Compiler.java:3601)
at clojure.lang.Compiler.compile1(Compiler.java:7299)
at clojure.lang.Compiler.compile1(Compiler.java:7289)
at clojure.lang.Compiler.compile1(Compiler.java:7289)
at clojure.lang.Compiler.compile(Compiler.java:7365)
at clojure.lang.RT.compile(RT.java:398)
at clojure.lang.RT.load(RT.java:438)
at clojure.lang.RT.load(RT.java:411)
at clojure.core$load$fn__5415.invoke(core.clj:5823)
at clojure.core$load.doInvoke(core.clj:5822)
at clojure.lang.RestFn.invoke(RestFn.java:408)
at clojure.core$load_one.invoke(core.clj:5613)
at clojure.core$compile$fn__5420.invoke(core.clj:5834)
at clojure.core$compile.invoke(core.clj:5833)
at user$eval5.invoke(form-init180441230737245034.clj:1)
at clojure.lang.Compiler.eval(Compiler.java:6776)
at clojure.lang.Compiler.eval(Compiler.java:6765)
at clojure.lang.Compiler.eval(Compiler.java:6766)
at clojure.lang.Compiler.load(Compiler.java:7203)
at clojure.lang.Compiler.loadFile(Compiler.java:7159)
at clojure.main$load_script.invoke(main.clj:274)
at clojure.main$init_opt.invoke(main.clj:279)
at clojure.main$initialize.invoke(main.clj:307)
at clojure.main$null_opt.invoke(main.clj:342)
at clojure.main$main.doInvoke(main.clj:420)
at clojure.lang.RestFn.invoke(RestFn.java:421)
at clojure.lang.Var.invoke(Var.java:383)
at clojure.lang.AFn.applyToHelper(AFn.java:156)
at clojure.lang.Var.applyTo(Var.java:700)
at clojure.main.main(main.java:37)

Caused by: java.lang.NoSuchFieldError: thunk0__

at instaparse.core__init.load(Unknown Source)
at instaparse.core__init.<clinit>(Unknown Source)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:344)
at clojure.lang.RT.loadClassForName(RT.java:2141)
at clojure.lang.RT.load(RT.java:430)
at clojure.lang.RT.load(RT.java:411)
at clojure.core$load$fn__5415.invoke(core.clj:5823)
at clojure.core$load.doInvoke(core.clj:5822)
at clojure.lang.RestFn.invoke(RestFn.java:408)
at clojure.core$load_one.invoke(core.clj:5613)
at clojure.core$load_lib$fn__5362.invoke(core.clj:5668)
at clojure.core$load_lib.doInvoke(core.clj:5667)
at clojure.lang.RestFn.applyTo(RestFn.java:142)
at clojure.core$apply.invoke(core.clj:628)
at clojure.core$load_libs.doInvoke(core.clj:5706)
at clojure.lang.RestFn.applyTo(RestFn.java:137)
at clojure.core$apply.invoke(core.clj:628)
at clojure.core$require.doInvoke(core.clj:5789)
at clojure.lang.RestFn.invoke(RestFn.java:436)
at clout.core$loading__5301__auto____273.invoke(core.clj:1)
at clout.core__init.load(Unknown Source)
at clout.core__init.<clinit>(Unknown Source)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:344)
at clojure.lang.RT.loadClassForName(RT.java:2141)
at clojure.lang.RT.load(RT.java:430)
at clojure.lang.RT.load(RT.java:411)
at clojure.core$load$fn__5415.invoke(core.clj:5823)
at clojure.core$load.doInvoke(core.clj:5822)
at clojure.lang.RestFn.invoke(RestFn.java:408)
at clojure.core$load_one.invoke(core.clj:5613)
at clojure.core$load_lib$fn__5362.invoke(core.clj:5668)
at clojure.core$load_lib.doInvoke(core.clj:5667)
at clojure.lang.RestFn.applyTo(RestFn.java:142)
at clojure.core$apply.invoke(core.clj:628)
at clojure.core$load_libs.doInvoke(core.clj:5706)
at clojure.lang.RestFn.applyTo(RestFn.java:137)
at clojure.core$apply.invoke(core.clj:628)
at clojure.core$require.doInvoke(core.clj:5789)
at clojure.lang.RestFn.invoke(RestFn.java:482)
at compojure.core$loading__5301__auto____68.invoke(core.clj:1)
at compojure.core__init.load(Unknown Source)
at compojure.core__init.<clinit>(Unknown Source)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:344)
at clojure.lang.RT.loadClassForName(RT.java:2141)
at clojure.lang.RT.load(RT.java:430)
at clojure.lang.RT.load(RT.java:411)
at clojure.core$load$fn__5415.invoke(core.clj:5823)
at clojure.core$load.doInvoke(core.clj:5822)
at clojure.lang.RestFn.invoke(RestFn.java:408)
at clojure.core$load_one.invoke(core.clj:5613)
at clojure.core$load_lib$fn__5362.invoke(core.clj:5668)
at clojure.core$load_lib.doInvoke(core.clj:5667)
at clojure.lang.RestFn.applyTo(RestFn.java:142)
at clojure.core$apply.invoke(core.clj:628)
at clojure.core$load_libs.doInvoke(core.clj:5706)
at clojure.lang.RestFn.applyTo(RestFn.java:137)
at clojure.core$apply.invoke(core.clj:628)
at clojure.core$require.doInvoke(core.clj:5789)
at clojure.lang.RestFn.invoke(RestFn.java:457)
at compojure.route$loading__5301__auto____1508.invoke(route.clj:1)
at clojure.lang.AFn.applyToHelper(AFn.java:152)
at clojure.lang.AFn.applyTo(AFn.java:144)
at clojure.lang.Compiler$InvokeExpr.eval(Compiler.java:3601)
... 75 more

Subprocess failed
`

0 votes
by

Comment made by: michaelblume

https://github.com/MichaelBlume/clojure/tree/no-field
https://github.com/MichaelBlume/extend-test/tree/no-field

mvn clean install in the one, lein ring uberwar in the other.

0 votes
by

Comment made by: bronsa

Michael, thanks for the report, I've tried investigating this a bit but the big amount of moving parts involved make it really hard to figure out why the combination of the two patches causes this issue.

A helpful minimal case would require no lein and no external dependencies, I'd appreciate some help in debugging this issue if anybody has time.

0 votes
by

Comment made by: michaelblume

Ok, looks like the minimal case is

(ns foo (:require (link: instaparse.core)))

(ns bar (:require (link: foo)))

and then attempt to AOT-compile both foo and bar.

I don't yet know what's special about instaparse.core.

0 votes
by

Comment made by: michaelblume

Well, not a minimal case, of course, but one without lein, at least.

0 votes
by

Comment made by: michaelblume

ok, problem is instaparse's defclone macro, I've extracted it to a test repo

https://github.com/MichaelBlume/thunk-fail

lein do clean, compile will get you a failure, but the repo has no dependencies so I'm sure there's a way to do that without lein.

0 votes
by

Comment made by: gshayban

Sorry for the barrage of questions, but these classloader bugs are subtle (and close to being solved I hope). Your report is immensely valuable, and yet it will help to be even more specific. There are a cluster of these bugs -- and keeping them laser-focused is key.

The minimal case to which you refer is the NoSuchFieldError?
How are is this being invoked this without lein?
What are you calling to AOT? (compile 'bar) ?
What is the classpath? When you invoke originally, is ./target/classes empty?
Does the problem go away with CLJ-979-7 applied?

0 votes
by

Comment made by: michaelblume

I have tried and failed to replicate without leiningen. When I just run

java -Dclojure.compile.path=target -cp src:../clojure/target/clojure-1.7.0-aot-SNAPSHOT.jar clojure.lang.Compile thunk-fail.first thunk-fail.second

everything works fine.

0 votes
by

Comment made by: gshayban

The NoSuchFieldError is related to the keyword lookup sites.

Replacing defclone's body with
`(do (:foo {})) is enough to trigger it, with the same ns structure.

0 votes
by

Comment made by: bronsa

I have updated the patch for CLJ-1544, now the combination of the new patch + the patch from this ticket should not cause any exception.

That said, a bug in this patch still exists since while the patch for CLJ-1544 had a bug, it was causing a perfectly valid (albeit hardly reproducible) compilation scenario so we should keep debugging this patch with the help of the bugged patch for CLJ-1544.

I guess the first thing to do is figure out what lein compile is doing differently than clojure.Compile

...