These are chat archives for sbt/sbt

Aug 2015
Aug 23 2015 05:00
Can someone please tell sbt to stop setting -XX:MaxMetaspaceSize=256m ?
Just because you need to set a MaxPermSize, and metaspace is instead of permgen,
By default class metadata allocation is limited by the amount of available native memory (capacity will of course depend if you use a 32-bit JVM vs. 64-bit along with OS virtual memory availability).
A new flag is available (MaxMetaspaceSize), allowing you to limit the amount of native memory used for class metadata. If you don’t specify this flag, the Metaspace will dynamically re-size depending of the application demand at runtime.
So while permgen had a small default and you need -XX:MaxPermSize to increase it,
metaspace is by default unlimited, and you only need to use XX:MaxMetaspaceSize to prevent leaks from affecting other programs
eugene yokota
Aug 23 2015 09:45
@nafg Could you file a Github issue on
sbt/sbt-launcher-package#78 This seems to be where it was introduced
Tomáš Janoušek
Aug 23 2015 13:28
On the other hand those leaks seem to be very much real, otherwise I wouldn't get those OutOfMemoryError: Metaspace errors.
Stefan Ollinger
Aug 23 2015 16:33
What is the rationale behind the Task/Setting difference? I sometimes stumble upon the fact that a Setting can not depend on a Task.
Aug 23 2015 16:43
setting only occurs once, is immutable and generally without side effects
a task is a side effecting operation that can occur many times
making a setting depend on a task implies that its value could change
Stefan Ollinger
Aug 23 2015 17:10
Wouldnt it be possible to have everything as a Task?
Aug 23 2015 17:11
unless you like recomputing things that should only be computed once
Dale Wijnand
Aug 23 2015 17:49
Settings are just memoising tasks
Aug 23 2015 17:51
pretty much
Stefan Ollinger
Aug 23 2015 18:07
One idea would be to memoize a Setting, but as soon as a Setting depends on a Task, it wont get memoized any longer.
Aug 23 2015 18:50
that would suck
eugene yokota
Aug 23 2015 20:17
i think there are pros and cons to having tasks and settings separated
on one hand you could say that it's an early optimization that may not buy much
I think the benefit of setting is that it's evaluated at the load time of the build, so you can catch things upfront rather than the runtime of the command
Stefan Ollinger
Aug 23 2015 20:38
An issue is that the developer of a plugin has to make a decision. Does he make it a setting, then that setting can never depend on a task. Does he make it a task, then no other setting can depend on it. It is a non-trivial decision. Imo the setting gives a (small?) performance gain, but limits the language considerably.
Josh Suereth
Aug 23 2015 21:03
It's actually about flatmap
Settings do not have it
And we know dependencies perfectly
Tasks, on the other hand, do allow it, and in a way we can't track dependencies for any "dyn" tasks
But I agree about the conceptual frustrations
If we could, I'd lean towards everything as a task-ish entity
There's a lot of good simplification, and hard optimization we'd have to do
Oh, additionally there's some fun meta issues, e.g. you can configure the task engine with settings
How do you configure the task engine if you only have tasks?
We already have that issue with the setting system (I.e. runtime configurations are done via system properties, not the most ideal)
eugene yokota
Aug 23 2015 21:09
if we go down the road of generalizing, you could say that setting vs task is a 2 stage initalization
and we could do n-stage by introducing some concept of stage, like build level
so everything can be task or setting or whatever it's called