<https://kotlinlang.slack.com/archives/C19FD9681/p...

# gradle

[dsvoronin]

https://kotlinlang.slack.com/archives/C19FD9681/p1542018400136700
Is there any plans to backport 1.0.x dsl to 4.x gradle?
Android devs kinda stuck between unstable Android Studio 3.4 canary (gradle 5 rc not even supported yet) and 4.9 kotlin dsl.
dsl 1.0rc in 4.10.x has memory leak issue (https://github.com/gradle/kotlin-dsl/pull/1188)
i’m only one seeing this?

[jlleitschuh]

@dsvoronin I'd highly doubt that the Kotlin DSL will ever be back ported to the 4.0 API.

[dsvoronin]

it is for 1.0-rc6 or so

[dsvoronin]

4.10.2 has 1.0-rc6 bundled

[jlleitschuh]

Correct.

[jlleitschuh]

I've been using the Gradle Kotlin DSL since 0.5.1. The 1.0-rc6 of the Kotlin DSL is pretty dang stable.
You can use it in your builds at least without too much concern about them breaking too much when you update to 5.0.

[dsvoronin]

but… i have memory leak issue with it
it’s in first message in this thread

[jlleitschuh]

Ah. Yea. And you can't update to 5.0-rc-3 because of the android support?

[dsvoronin]

it’s so bad, i have to manually kill kotlin compiler process every 2-3 builds

[dsvoronin]

yep

[dsvoronin]

gradle daemon has no control over kotlin daemon, so disabling gradle daemon doesn’t help much

[jlleitschuh]

@eskatos @bamboo Do either of you have a suggested workaround to this problem?

You could consider running the Kotlin compiler in-process?

[eskatos]

that leak was in the gradle build daemon, if you have memory issues with the kotlin compiler daemon then that’s something else

[dsvoronin]

it maybe in gradle daemon
we disabled it, it became better, but there is also a compiler daemon problem, i’d research it after got to fixed kotlin dsl version

[dsvoronin]

its truly a gradle daemon ) it’s with org.gradle.daemon=false in ~/.gradle/gradle.properties

[dsvoronin]

3 top java processes - gradle
418mb ram -> kotlin daemon

[dsvoronin]

Timeout waiting for all daemons to stop. Waited 1 mins 40.632 secs.

[eskatos]

that looks bad

[eskatos]

to rule things out, one at a time, do you use the kotlin-dsl plugin?

[dsvoronin]

yep, in buildSrc

[dsvoronin]

there are multiple modules there, most of them uses kotlin-dsl plugin, but not root one

[eskatos]

ok, that’s the guy that triggers the memory leak we fixed in 1.0

[eskatos]

can you confirm only your gradle daemon is suffering from memory starvation? just wanna rule out any other unrelated problem with the kotlin compiler daemon

[dsvoronin]

what do you mean? only mine? whole team daemons )

[eskatos]

no I mean gradle build daemon vs. kotlin compiler daemon

[dsvoronin]

it’s hard to say. right now only gradle daemon peaks and hangs. but i encounter situation with kotlin compiler daemon too

[eskatos]

okay

[dsvoronin]

i don’t have in-process mode enabled in properties (like an issue in gradle integration tests)

[eskatos]

could you try adding kotlinDslPluginOptions.experimentalWarning.set(false) to all your build scripts that apply the kotlin-dsl plugin?

[eskatos]

it should short-circuit the leaky code path

[dsvoronin]

just added based on your PR fix, i’ll try it now

[dsvoronin]

🤞 but it looks better now, what instances should i look into for memory dump? i’ll double check it later

[eskatos]

Project instances would be a good indicator

[dsvoronin]

Thanks for the workaround!
For backporting stable version of dsl to 4.x . answer is no?

[eskatos]

Not planned

[dsvoronin]

i just don’t know if there any big anchors in 5.x api

[dsvoronin]

ok; we’ll try to carry till android support 5.x gradle

[dsvoronin]

another build log fast-failure custom check, now for “warning kotlindsl uses experimental blabla” 😛

[dsvoronin]

after multiple success builds with daemon enabled (both from console and IDE)

[eskatos]

what is this app? what are the two columns? hard to say anything without more context