Add option to toggle Dokka Generator Worker API isolation

[martinbonnin]

I have this locally for testing so opening the PR while I'm on this. Feel free to close if you think process isolation is better.

Reasons I like classloader isolation are:

• I only need to monitor one JVM. In my build I had to bump the fork Xmx to > 2GB when my main build already has 8GB so theorically means the build could use 10GB or so.
• It's easier to debug (no need to find the daemon and hook the debugger there)
• Might be a bit faster too?

If the worker leaks then it becomes a problem but better fix the leaks?

[aSemy]

Thanks! Classloader isolation should be better in theory.

I've tidied up your suggestion and allowed for it to be configurable. Unfortunately I got a lot of test failures due to metaspace limits when using classloader isolation, but perhaps that's not a problem - the tests in this project are quite atypical, and run many different projects. Maybe the build/JUnit config needs to be updated to fork the process for each test suite?

[martinbonnin]

due to metaspace limits when using classloader isolation

Sounds like a classloader leak somewhere :/. Maybe those coroutine dispatcher threads holding onto classloader references or so.

[aSemy]

Status update:

I haven't seen any more memory issues. Perhaps it was some Gradle/Windows issue (e.g. gradle/gradle#23959 gradle/gradle#23965). So I'm happy to proceed.

I want to have at least one test (using Gradle TestKit) first though. Maybe it's possible to parameterise an existing test to toggle between classloader/process isolation. I can pick this up, but it might take some time. Contributions to speed this up would be welcome :)

I also wonder what might happen in a multimodule project, if some subproject use process isolation and others use classloader isolation. Probably it still works. I wonder if performance will be better with process isolation? Or does that require a shared Build Service so that Gradle will re-use the worker queue?

[martinbonnin]

if some subproject use process isolation and others use classloader isolation. Probably it still works.

I think it'll still work but TBH I don't expect that to be a big use case. Most of the users will use the default. And the ones who change them would IMO change it everywhere.

Contributions to speed this up would be welcome :)

No promises but I'll try to look into this!

[martinbonnin]

Attempt at a test here. I'm no kotest expert so not sure if there's a more idiomatic way to do this but this seemed to run the tests at least.
It doesn't do any assertion on classloader vs process isolation. Not sure how to test this.

[aSemy]

Thanks for this! I really appreciate it, I've finished it off.

I've made some tweaks (the Isolation mode is configured via the Dokkatoo extension, added some docs).

I moved your test to the multi-module test just to make the test more thorough, and added some assertions to make sure the isolation mode was set properly.

[martinbonnin]

Thanks! Good trick about asserting on the logs 👍