increasing stack size for agents et. al.

58 views
Skip to first unread message

hank

unread,
Jun 29, 2012, 1:38:06 PM6/29/12
to clojure...@googlegroups.com
Per default newly created threads have a stack size of 8kb on Android/Dalvik which is a *lot* less than the usual 256-512 kB on a 'normal' JVM. This limit is easily hit when e.g. "eval"-ing moderately complex expressions.

In places where one is in control of creating new threads in one's own project one can easily use the Thread constructor that allows one to specify a stack size. However Clojure creates plenty of threads implicitly, e.g. for agents, futures etc.

This indirection may even be twofold through the use of the Executors library from Java, which in turn creates thread implicitly, so just grepping for "new Thread" won't do.

My plan is to go through the Clojure code and find such instances of thread creation and 'correct' them by specifying larger stack sizes.

Any comments.

hank

unread,
Jun 30, 2012, 11:33:23 AM6/30/12
to clojure...@googlegroups.com
The only place I could find was createThreadFactory in clojure.lang.Agent so seems like a pretty simple fix.

Note that if you're using nREPL to remotely debug your Android app, nREPL seems to have recently (0.2.0 beta 8) reverted to using its own threads rather than agents as it did in the interim. So nREPL has to be fixed up with a bigger stack size, too: http://dev.clojure.org/jira/browse/NREPL-22

hank

unread,
Jul 3, 2012, 11:27:11 AM7/3/12
to clojure...@googlegroups.com
" This way it could be easy to create some stack-hungry definition using nREPL and forget about it in production. So Clojure itself has to incorporate the change too."

Only partially true. Note that it's the compilation/"eval"-ing of the expressions that consumes large amounts of stack, not the execution. Compilation is mostly done AOT in production Android projects.

But yeah I agree stack sizes should be larger for execution, too, hence the grepping of the clojure code and this issue: https://github.com/sattvik/clojure/issues/2
Reply all
Reply to author
Forward
0 new messages