Skip to content

v0.7.0

Latest

Choose a tag to compare

@penspanic penspanic released this 19 Oct 16:08
· 1 commit to main since this release
f2b4767

Ready to be public: an unload-leak check that works on CoreCLR, a content-based cache key, a sample report from a real run and a walked pre-release checklist. Philosophy unchanged: annotate, do not refuse.

Tested Editors: 6000.7.0b2 (Mono) and 7000.0.0a9 (CoreCLR). macOS (Apple silicon) with this version; Windows x64 with 0.6.0, through the CI of two consumer projects (MatterKit and Spill). 7000.0.0a7 is the known-leaking control for the unload counter.

Fixed

  • A prepared copy of a revision variant is now keyed by content, not by commit. The cache key used to contain the resolved commit, so any commit, even one that only touched a workflow file or a README, made the next run prepare every copy again (minutes of copy, prepare and re-import per variant); on a CI branch that moves all the time the cache was almost never reused. The key now holds the git tree of the project directory at that commit (for a project at the repository root: the trees of Assets, Packages and ProjectSettings only) and, for every file: dependency in Packages/manifest.json, the tree (or blob, for a tarball) of the path it points to at that commit; a file: path outside the repository is keyed by a digest of its files' paths, sizes and times, as a plain copy is. The package-lock digest and the project's place in the repository stay in the key. A plain copy is keyed as before.
  • The commit is still recorded, in the provenance and the report. When a run reuses a copy that was made at an older commit with the same content, the provenance names this run's commit and adds prepared_from_commit; the report's "Project commit" cell says so. cache list shows the commit the entry was made at.
  • The cache format is 2: entries written by 0.6.0 and earlier are not read (entry was written by another cache format) and are removed by cache prune; the first run prepares each copy once more.

New

  • Unloaded code contexts that stay alive (#18). On a CoreCLR Editor, Loaded Assemblies and AssemblyLoadContexts cannot show an unload leak: AppDomain.GetAssemblies() and AssemblyLoadContext.All drop a context as soon as Unload() is called, even when it is never collected, so both stayed flat on 7000.0.0a7 while every reload leaked the previous context (about 120 MB). The leak workloads now keep a weak GCHandle to each generation of the package's code across reloads and report, after every reading and up to five more forced collections, leak/Unloaded contexts still alive and leak/Unloaded contexts (counts). A healthy Editor keeps 0; a leaking one keeps one per reload. A Mono Editor lists the counter as not available.
  • The result of a leak workload comes first: a table per variant with the App Resident Memory slope per cycle (least squares, range over processes) and the unloaded contexts still alive after the last cycle; leak_headline in summary.json.
  • alc_leak_detection = true on editor.reload_leak / editor.play_leak runs the Editor with -enable-alc-leak-detection 1, moves the Logs/ALCLeaks-*.json reports it writes into <run dir>/alc-leaks/<process>/ and reports the number of files and leaked objects and the first path to a root. alc_leaks on the process row and in summary.json.

Behaviour that changes

  • examples/minimal.toml uses 7000.0.0a9 for its Unity 7 variant (7000.0.0a7 leaks every script reload, see #18).
  • package.json and the framework are 0.7.0.

Documentation

  • methodology no longer says that a rising assembly count detects an unload leak, and corrects the v0.6 reading of the first runs ("both flat" did not mean that no old code stayed loaded). It says why App Resident Memory, not RSS, is the process metric for a leak on macOS (in a leaking run, RSS 1.4 GB against a physical footprint of 13.6 GB), and how the survivor count works (Unloaded contexts).
  • The README's sample report is from a run of examples/minimal.toml with this version, with n, machine, date, framework commit and machine load stated; it replaces the v0.2 one. The README says which Editors and platforms were tested and points to Reproducing a published result.
  • Pre-release checklist: walked for this release; the security items that can only be set on a public repository are marked for the day it goes public.

First public release. Install from a checkout with pip install . (Python 3.11+), then start with the Quickstart.