Package org.ek9lang.compiler.phase5.lockanalysis


package org.ek9lang.compiler.phase5.lockanalysis
Data model for slice-2 deadlock detection analysis results.

The records in this package form the single source of truth for compile-time deadlock analysis output, consumed by both MCP query tools and the IDE deadlock-detail panel. Populated during phase 5 by LockAnalysisListener (intra-function, Phase B.1) and InterproceduralLockAnalyzer (workspace-wide mayEnter fixpoint, Phase C).

Records carry direct ISymbol and IToken references for in-process navigation. String stableId fields allow records to reference each other and to survive serialisation to MCP JSON / LSP wire formats. The two representations coexist: in-memory identity for fast analyzer-side equality, stable string IDs for cross-reference and wire-format projection.

Lifecycle: LockAnalysis lives on CompilableProgram but is transient per-compile — each compilation rebuilds it from scratch, matching the call-graph and quality-tracker lifecycle. Previous instances are GC'd when the new analysis is swapped in atomically at the end of phase 5.

See docs/implementation/EK9_DEADLOCK_DETECTION_IMPLEMENTATION_PLAN.md for the full design and step-by-step rollout.

  • Class
    Description
    Single step in a DeadlockChain's rationale trace.
    A synthetic call-graph edge representing thread-boundary-crossing dispatch — passing a function as the handler argument to TCP.accept, Signals.register, or as a stage in cat ... | async.
    Full rationale for a single detected deadlock — either E08252 (nested enter on different lock identity) or E08253 (cross-thread same lock).
    Classifies a call-graph edge by its threading semantics, per EK9_CONCURRENCY_MODEL.md §5.2.
    A single MutexLock.enter(...) or MutexLock.tryEnter(...) call site observed during analysis.
    Distinguishes the two variants of MutexLock acquisition: blocking enter() vs non-blocking tryEnter().
    Per-function summary of lock activity.
    Classifies where a lock-identity descriptor originates.
    Phase C.3 of slice-2 deadlock detection — Phase 5 lock-order-cycle model.
    Phase C.2 of slice-2 deadlock detection: compute per-function mayEnter summaries by composing direct enters with reachable enters via the call graph and CrossThreadEdge list.
    Single source of truth for slice-2 deadlock analysis results.
    Catalogue entry for a single lock identity tracked by the slice-2 deadlock analysis.
    Workspace-wide lock-precedence graph used by Phase 5 cycle detection.
    One observed nested-enter relationship between two distinct lock identities.
    A MutexKey dynamic-function body — the lambda passed as the argument to enter(...) or tryEnter(...).
    Classifies a single step in a DeadlockChain's rationale trace.
    Single element of a function's mayEnter summary — an enter() site reachable from this function via some call path, with the lock identities after parameter substitution and the composed edge-kind of the reaching path.