dokkaJavadocJar fires "java.lang.OutOfMemoryError: Metaspace"

[elect86]

Question

I added the following in my build.gradle.kts

val dokkaJavadocJar by tasks.register<Jar>("dokkaJavadocJar") {
    dependsOn(tasks.dokkaJavadoc)
    from(tasks.dokkaJavadoc.get().outputDirectory.get())
    archiveClassifier.set("javadoc")
}

val dokkaHtmlJar by tasks.register<Jar>("dokkaHtmlJar") {
    dependsOn(tasks.dokkaHtml)
    from(tasks.dokkaHtml.get().outputDirectory.get())
    archiveClassifier.set("html-doc")
}

val sourceJar = task("sourceJar", Jar::class) {
    dependsOn(tasks["classes"])
    archiveClassifier.set("sources")
    from(sourceSets.main.get().allSource)
}

artifacts {
    archives(dokkaJavadocJar)
    archives(dokkaHtmlJar)
    archives(sourceJar)
}

However dokkaJavadocJar produces the titled error:

java.lang.OutOfMemoryError: Metaspace

and the following

Task :compileJava FAILED

But I'm pretty sure is dokkaJavadocJar the error root because if I comment it out, it works flawless

In order to fix this, I added in gradle.properties

org.gradle.jvmargs=-XX:MaxMetaspaceSize=512m

Installation

• Operating system: macOS/Windows/Linux
• Build tool: Gradle 6.6
• Dokka version: 1.4.0-dev-62

I wonder if this is "fine" or something nasty is happening in the background I shall be aware of

Ps: the very same problem happens also in other projects

[Kordyjan]

This is really bizarre. Dokka is indeed memory-intensive in some parts, which are not yet optimized, but it should only affect heap space. I don't know what could cause overflow of metaspace. We will definitely profile that.

[Kordyjan]

Also thanks for suggesting a workaround. I'll repost it for the better visibility.

Workaround:

put org.gradle.jvmargs=-XX:MaxMetaspaceSize=512m in gradle.properties

[Kordyjan]

Could you check if this is reproducible if you run ./gradlew --stop before running any tasks or even put org.gradle.daemon=false in your gradle.properties?

[gabrielittner]

If you need a project to reproduce it happens in the integration tests of our Gradle plugin which runs dokka.

The commit https://github.com/vanniktech/gradle-maven-publish-plugin/commit/3ef0227c39a64336f8cdb1c65504e08646e7c2a6 The ci run https://travis-ci.org/github/vanniktech/gradle-maven-publish-plugin/builds/723577862 (also happens locally when running ./gradlew integrationTest)

[elect86]

Could you check if this is reproducible if you run ./gradlew --stop before running any tasks or even put org.gradle.daemon=false in your gradle.properties?

Both seem working

[elect86]

What does this have to do with the daemon, @Kordyjan?

[elect86]

Just got again java.lang.OutOfMemoryError: Metaspace with org.gradle.daemon=false

[altavir]

I get the same error for dokkaHtml for a not-so-large multi-module project. And yes, it is reproducible. Enlarging metaspace seems to be working.

[gciatto]

I'm getting the same problem here, with or without the daemon. I'm working on a multi-platform & multi-project project. Here's the branch I'm working on: https://gitlab.com/pika-lab/tuprolog/2p-in-kotlin/-/commits/feature/dokka-1.4

[joffrey-bion]

In my case I had to bump the metaspace even further (1024m). I have a multi-module project with 8 modules, half of which are multiplatform. Note that I'm running dokkaHtml, not dokkaJavadoc, but I get the same error with javadoc.

[ansman]

I believe one reason for this is parallel execution which spawns multiple processes which fight over the same resource. Running with the --no-parallel seems to help, at least for our project.

[ansman]

Although --no-parallel gets further (as in more modules get completes), eventually I do hit the same error. This could indicate that this is caused by a memory leak.

512MB is not enough for my project, I also had to bump to 1024. I wouldn't be surprised you need even more if you have more modules

[ansman]

Any updates on this? It's turning out to be a pretty massive issue because we're having trouble publishing our library that has lots of modules. Happy to spend some time debugging if someone can point me in the right direction.

[ansman]

This issue is even more problematic since the Gradle Daemon doesn't die but rather hangs so you have to manually kill it. The error in question something like this:

  Process exited with code 1
    Gradle failure report
    FAILURE: Build failed with an exception.

    * What went wrong:
    Gradle could not start your build.
    > Could not create service of type ResourceSnapshotterCacheService using GradleUserHomeServices.createResourceSnapshotterCacheService().
       > Timeout waiting to lock file hash cache (/Users/user/.gradle/caches/6.6/fileHashes). It is currently in use by another Gradle instance.
         Owner PID: 71496
         Our PID: 71896
         Owner Operation:
         Our operation:
         Lock file: /Users/user/.gradle/caches/6.6/fileHashes/fileHashes.lock

[cohenor]

This issue is even more problematic since the Gradle Daemon doesn't die but rather hangs so you have to manually kill it. The error in question something like this:

  Process exited with code 1
    Gradle failure report
    FAILURE: Build failed with an exception.

    * What went wrong:
    Gradle could not start your build.
    > Could not create service of type ResourceSnapshotterCacheService using GradleUserHomeServices.createResourceSnapshotterCacheService().
       > Timeout waiting to lock file hash cache (/Users/user/.gradle/caches/6.6/fileHashes). It is currently in use by another Gradle instance.
         Owner PID: 71496
         Our PID: 71896
         Owner Operation:
         Our operation:
         Lock file: /Users/user/.gradle/caches/6.6/fileHashes/fileHashes.lock

I'm having the exact same experience in a rather small multi-module project. Already tried to increase metaspace and to disable parallelism but it didn't provide any deterministic results. Any updates on this? 🙏

[willbuck]

I am also experiencing the same issue in https://github.com/micronaut-projects/micronaut-kotlin/tree/issue-78

Running --no-parallel with org.gradle.daemon=false and org.gradle.jvmargs=-XX:MaxMetaspaceSize=2g does seem to solve the problem for a clean build (though I do still see these bizarre warnings, see below) but that isn't really a practical solve for our github actions to publish our documentation.

Definitely seems a memory leak is the culprit, please let us know how profiling that bit goes!

WARN: error in opening zip file: /home/will/.gradle/caches/modules-2/files-2.1/org.graalvm.nativeimage/svm-hosted-native-linux-amd64/20.2.0/55f876b0688181a47436128f0e06b9ab93e17a32/svm-hosted-native-linux-amd64-20.2.0.tar.gz
java.util.zip.ZipException: error in opening zip file

WARN: error in opening zip file: /home/will/.gradle/caches/modules-2/files-2.1/org.graalvm.truffle/truffle-nfi-native-darwin-amd64/20.2.0/d3ad1011cba788a2b36792ee2ea128b90d5a4f8e/truffle-nfi-native-darwin-amd64-20.2.0.tar.gz
java.util.zip.ZipException: error in opening zip file

[asarkar]

Frequent OOM error in a fairly small project.

> Task :okgrpc-cli:dokkaHtml
Dokka 1.4.* is an alpha project
Initializing plugins
Validity check
Creating documentation models

Exception in thread "DefaultDispatcher-worker-8" java.lang.OutOfMemoryError: Metaspace
Daemon will be stopped at the end of the build after running out of JVM memory
Exception in thread "DefaultDispatcher-worker-1" java.lang.OutOfMemoryError: Metaspace
Exception in thread "DefaultDispatcher-worker-3" java.lang.OutOfMemoryError: Metaspace

Since the usual first response from any OOS maintainer is "have you tried the latest version", I'm running v1.4.10.2.

@willbuck A Javadoc engine shouldn't need 2G RAM to generate a dozen or so HTML files (that's how many for me).

[ileasile]

Mee too, pretty small project: https://github.com/Kotlin/kotlin-jupyter/tree/notebook-api Getting the error only on CI, locally I had org.gradle.jvmargs=-Xmx2048m, and it worked well.

[MarvinSchramm]

I have the same issue, simple multimodule object. This prevents me from publishing the libraries with javadoc at the moment

The gradle properties helps locally, but my CI system is github actions, i dont have 2G available there

[ansman]

Today I saw some new errors related to this:

...
java.lang.OutOfMemoryError: Metaspace
WARN: Could not read file: /Users/nicklas/.gradle/caches/modules-2/files-2.1/org.jetbrains.kotlin/kotlin-stdlib/1.4.20/9be77b243a362b745e365f286627b8724337009c/kotlin-stdlib-1.4.20.jar!/kotlin/SuspendKt.class; size in bytes: 1108; file type: CLASS
java.lang.OutOfMemoryError: Metaspace
WARN: Could not read file: /Users/nicklas/.gradle/caches/modules-2/files-2.1/org.jetbrains.kotlin/kotlin-stdlib/1.4.20/9be77b243a362b745e365f286627b8724337009c/kotlin-stdlib-1.4.20.jar!/kotlin/ThrowsKt.class; size in bytes: 540; file type: CLASS
java.lang.OutOfMemoryError: Metaspace
WARN: Could not read file: /Users/nicklas/.gradle/caches/modules-2/files-2.1/org.jetbrains.kotlin/kotlin-stdlib/1.4.20/9be77b243a362b745e365f286627b8724337009c/kotlin-stdlib-1.4.20.jar!/kotlin/TuplesKt.class; size in bytes: 1904; file type: CLASS
java.lang.OutOfMemoryError: Metaspace

This time it actually shows some more info on when you get OOM. It seems to be while reading the metadata/class files for the kotlin stdlib in my case.

This happened while generating gfm docs specifically.

[andreihh]

I'm getting the same issue on Travis CI for this project. This build works fine locally, but fails on CI server.

I tried everything suggested here (disabling the daemon, disabling parallel builds, increasing metaspace memory to 2 GB), but nothing worked.

[marcphilipp]

We're seeing the same issue with https://github.com/gradle-nexus/publish-plugin/.

[willbuck]

Anything any of us out in the user community can do to help resolve this issue? I'd really love to highlight dokka docs for https://github.com/micronaut-projects/micronaut-kotlin/tree/master/kotlin-extension-functions but this is a major thorn in doing so. I will read up on Contributing and see if I can step debug enough to figure out what I'm looking at but I'm afraid debugging gradle tasks is not my area of expertise.

[asarkar]

OSS maintainers often feel it's a thankless and underappreciated job, but any paid project with an OOM error for 6 months would be shut down and the project members would be looking for new jobs. But not if it's OSS :)

[kamildoleglo]

Long story short: it's a memory leak (mostly) caused by kotlinx.coroutines https://github.com/Kotlin/kotlinx.coroutines/issues/2558

Dokka 1.4.30 will (partially) fix this. There's actually nothing more we can do apart from force-closing dispatchers right now. We could remove coroutines from our code (and/or use JVM's threads), but this would be a painful, long job with the effect of degraded performance (initially Dokka was single threaded and slower by several orders of magnitude).

Giving the JVM more heap and metaspace memory and not reusing the Gradle daemon (which holds all the references that prevent the GC from doing its job) is still a viable workaround that we personally use

[marcphilipp]

@kamildoleglo Thanks for the update. If 1.4.30 will partially fix this, is this issue still assigned to the correct milestone?

[kamildoleglo]

Nope, I've forgot to do the grooming, sorry

[willbuck]

Thank you so much for the updates @kamildoleglo

@asarkar open source software benefits everyone, it would be great if more people paid to help support it (or better yet, understand it and contribute to it) but that sadly is not the reality we live in. You are always welcome to find and propose solutions though!

[asarkar]

@willbuck

it would be great if more people paid to help support it

It's a slippery slope. As soon as people start paying, there's going to be an expectation of accountability, which I'm sure will drive away many OSS contributors. I personally donate to Wikipedia, but I don't need Wikipedia to do my job; that's not the same with OSS, so when I pay for someone's time, I'll fully expect issues to be handled in a timely fashion and with a specific ETA.

I've contributed to several OSS myself, and also maintain some in my free time. I'd not want someone paying $5 start owning my time.

Anyway, I digress.

[ZacSweers]

@kamildoleglo the 1.4.30 release notes don't mention this, did any specific fixes for this make it in?