[david-allison]

Note

Assisted-by: Claude Opus 5 - implementation

Note

(cherry picked from commit cde8375) - the change should not have gone to main without review.

Each Classloader needs a separate on-disk file or a UnsatisfiedLinkError is thrown.

To fix this:

• Persist a collection of 10 files on-disk
  • We do this as we cannot guarantee file deletion on Windows

librsdroid-<sha1>.dylib      the extracted library
librsdroid-<sha1>-1.dylib    a copy of the library, created if a second classloader requires it

• Walk through the libraries using a cursor and load an unused one
• Devise a script for Anki-Android to warn developers if there are too many stale copies on disk (each is 60MB)

---

• Fixes most of the following, a merge of an updated backend library will resolve it [Bug] Unit Tests: java.lang.UnsatisfiedLinkError: 'byte[][] net.ankiweb.rsdroid.NativeMethods.openBackend(byte[])' when mixing RunWith(AndroidJUnit4::class) Anki-Android#14796

[BrayanDSO]

I'm okay with the compromise.

Is the ideal number of copies 10? Could it be less or is it the best alternative?

[david-allison]

10 exists to allow for some growth room. I'd be happy to halve it to 5.

I suspect in reality we'll be fine with 3 for a while, but this will need to be merged and implemented to know for certain

[david-allison]

Halved to 5. Will squash when I'm back at a PC

[criticalAY]

I am ok with this change, just one question rest is good

[criticalAY]

Can this fail?

[david-allison]

Yes - security issues/disk space issues. Thanks!

A later UnsatisfiedLinkError would expose this, but I've fixed it to be more explicit

[david-allison]

I plan to add 2/3 more commits here

[mikehardy]

Human note: the changes in general looked good to me but there seem to be a few edge cases to puzzle through based on an agent look
Assisted-by: Grok 4.7

The copy-per-classloader approach is the right fix for already loaded in another classloader. A few edge cases in the new helpers:

createAtomically replaces the destination on macOS and Linux

File.renameTo replaces an existing file on POSIX and returns true, so !renameTo && !exists() misses a lost race. Windows keeps the existing file because rename fails when the target exists. Both writers currently write the same bytes, so a race still publishes a valid library, but the comment's guarantee ("their file is left in place") holds on Windows only. A partial or different winner would be published.

Files.move with ATOMIC_MOVE and without REPLACE_EXISTING, catching FileAlreadyExistsException, matches that comment on both platforms.

A zero-length destination is reused forever

numberedCopy skips the write when exists() is true. A crash leftover, or a failed publish that still created the path, is then loaded as-is. Runtime.load throws an UnsatisfiedLinkError whose message is not "already loaded in another classloader", so the cursor does not advance to the next slot. Compare the destination length to the source and rewrite when they differ.

Exhaustion path

loadCopyFreedByGc() calls System.gc() and Thread.sleep(50) ten times on the test thread, inside ensureSetup's monitor. System.gc() does not unload the library; the classloader cleaner does that later, and a sandbox that is still referenced never frees its copy. A worker that is out of slots pays for those GCs on every later load and then throws.

Thread.sleep also clears the interrupt flag, and the exception leaves ensureSetup. Restore the interrupt status and return.

The failure text says "More than $maxCopies classloaders". Capacity is the original file plus maxCopies copies (6 with the default). The KDoc already describes it that way.

Copies accumulate with no signal

Copies stay in java.io.tmpdir for the life of that checksum (~60MB each, original plus up to maxCopies per backend version). The README assigns cleanup warnings to the caller, and the PR description mentions a script for Anki-Android, but this diff never logs that a copy was created. One line at creation (index, cap, path, size) gives that caller something to warn on.

The PR description and the first commit message still say 10 files. The code default is 5.

Other

• nextCopy is a system property updated with no lock. Two classloaders can start at the same slot. The walk still finds a free file, so this stays correct.
• No tests for slot order, wrap from maxCopies back to 1, "destination already exists", or the exhaustion error. The cursor math does not need a 60MB library.
• New files use an SPDX header. RustBackendLoader.kt still has the full GPL header.
• On macOS, dlopen can collapse two files that share an LC_ID_DYLIB. Worth one AnkiDroid run on macOS that enters a second sandbox and calls a backend method. This repo's CI does not do that.

[david-allison]

Still awaiting me

[mikehardy]

Assisted-by: Grok 4.7

Approving. The earlier notes are addressed: atomic publish under a lock, length checks so a short copy is rewritten, the capacity message counts the original file, the interrupt flag is restored, copy creation is logged, and a second classloader actually calls into the backend. macOS, Windows, and Ubuntu CI are green on f365014.

The GC-and-wait when every copy is still owned is the right tradeoff. Waiting is better than the current failure.

One possible follow-on, not a blocker: the copy-creation line goes to stderr, and the backend has usually already redirected that stream by the time a later classloader creates a copy. David has likely already thought through how Anki-Android will pick this up.

[david-allison]

@criticalAY @BrayanDSO

To confirm: can we land this? CI and testing speedup in exchange for up to 6 more copies of the backend library existing per version

I'll add a cleanup script to Anki-Android to handle old versions