Google JSIR: Eine MLIR-basierte Zwischenrepräsentation für JavaScript-Analyse

Google JSIR: Eine MLIR-basierte Zwischenrepräsentation für JavaScript-Analyse

lschvn5 Min. Lesezeit

Wenn eine Compiler-Zwischenrepräsentation (IR) in den Nachrichten auftaucht, weiß man, dass sie wichtig ist. Google hat JSIR veröffentlicht, ein neuartiges JavaScript-Analysewerkzeug auf MLIR-Basis, das bereits intern für Aufgaben eingesetzt wird, die zeigen, wie ambitioniert das Projekt ist: Dekomilierung von Hermes-Bytecode zurück nach JavaScript und KI-gestützte Deobfuskations-Pipelines, die JSIR mit Gemini kombinieren.

Warum das für Werkzeuge wichtig ist

Eine Zwischenrepräsentation ist die Datenstruktur, die ein Compiler oder Analysewerkzeug verwendet, um Code zwischen Parsing und Codegenerierung darzustellen. Wenn ein AST sagt, wie der Code strukturell aussieht, sagt eine IR, was er tut. Die Qualität der IR bestimmt, welche Art von Analyse und Transformation möglich ist.

JavaScript-Tooling hat lange unter fragmentierten IR-Ansätzen gelitten. Babel-Plugins arbeiten auf ASTs. ESLint-Regeln arbeiten auf ASTs. Bundler arbeiten oft mit eigenen internen Repräsentationen mit begrenzter Interoperabilität. Eine gemeinsame, gut gestaltete IR könnte es diesen Tools ermöglichen, Analysearbeiten zu teilen, und genau das schlägt Google mit JSIR vor.

Hoch- und Niedrigrangig gleichzeitig

Die zentrale technische Herausforderung, die JSIR löst, ist eine bekannte im Compiler-Design: Man muss sich typischerweise zwischen einer hochrangigen IR (bewahrt AST-Struktur, kann zu Quellcode angehoben werden) und einer niedrigrangigen IR (ermöglicht tiefe Datenflussanalyse wie Taint-Tracking und Konstantenpropagation) entscheiden. Die meisten Systeme wählen eines.

JSIR nutzt MLIR-Regionen, um JavaScripts Kontrollflussstrukturen, Closures, try-catch-finally, Async-Funktionen, Generator-Frames, präzise so zu modellieren, dass beide Richtungen gleichzeitig unterstützt werden. Man kann Code transformieren und zu Quellcode anheben, oder Taint-Analyse auf derselben Repräsentation ausführen.

Dies ermöglicht Anwendungsfälle, die zuvor unpraktisch waren:

Dekomilierung: JSIR wird bei Google eingesetzt, um Hermes-Bytecode komplett zurück nach JavaScript zu dekomilieren. Hermes kompiliert React Native Apps zu kompaktem Bytecode für schnellere Starts; JSIRs Quellcode-Hebbarkeit ist, was diese Dekomilierung möglich macht, wo andere Tools an eine Wand stoßen würden.

Deobfuskation: Google hat Forschung (CASCADE) zur Kombination von Gemini LLM mit JSIR für JavaScript-Deobfuskation veröffentlicht. Die KI arbeitet auf JSIRs strukturierter Repräsentation statt auf rohem obfuskiertem Quellcode und erzeugt Transformationen, die JSIR anwendet, um sauberen Code zu rekonstruieren.

Die MLIR-Grundlage

JSIR ist kein eigenständiges Projekt, es basiert auf MLIR, dem flexiblen IR-Framework des LLVM-Projekts. Das ist bedeutsam für die Ökosystem-Kompatibilität: MLIR hat bereits eine breite Palette existierender Dialekte, Transformationen und Tools. Durch die Ausdrucksweise der JavaScript-Analyse in MLIR-Begriffen kann sich JSIR in dieses Ökosystem einklinken, anstatt Infrastruktur neu zu erfinden.

Erste Schritte

JSIR ist auf GitHub unter github.com/google/jsir verfügbar. Das Projekt empfiehlt Docker für lokale Experimente:

docker build -t jsir:latest .
docker run --rm -v $(pwd):/workspace jsir:latest jsir_gen --input_file=/workspace/yourfile.js

Der Build aus den Quellen erfordert clang, Bazel und erhebliche Build-Zeit, das Projekt weist darauf hin, dass das Abrufen und Kompilieren von LLVM Zeit braucht. Der Docker-Weg ist der praktische Einstiegspunkt für die meisten Entwickler.

Was das für das Ökosystem bedeutet

Die meisten Entwickler werden in naher Zukunft nicht direkt mit JSIR interagieren, es ist eine Grundlage, auf der Werkzeugentwickler aufbauen. Aber die langfristigen Implikationen sind bedeutsam. Eine geteilte, gut gestaltete IR könnte ermöglichen:

  • Linter mit tieferem semantischem Verständnis (nicht nur Musterabgleich auf AST-Knoten)
  • Bundler mit besserer Todcode-Elimination durch Datenflussanalyse
  • Refactoring-Tools, die Code sicher über komplexe Kontrollflüsse hinweg transformieren können
  • Cross-Framework-Analyse, die unabhängig vom verwendeten Framework oder Build-Tool konsistent funktioniert

Google hat es quelloffen gemacht, was bedeutet, dass die Community auf dieser Grundlage aufbauen kann. Ob es an Traktion gewinnt, hängt davon ab, ob Tool-Maintainer genügend Vorteile sehen, um JSIR-basierte Analyse in ihre Pipelines zu integrieren, aber die technische Grundlage ist solide.

Häufig gestellte Fragen

Verwandte Artikel

Weitere Berichterstattung zu ähnlichen Themen und Tags.

Playwright v1.61.0: WebAuthn-Passkeys, eine echte WebStorage-API und Trace-artige Video-Modi für den Test-Runner
security

Playwright v1.61.0: WebAuthn-Passkeys, eine echte WebStorage-API und Trace-artige Video-Modi für den Test-Runner

Playwright v1.61.0 (15. Juni 2026) liefert einen virtuellen Authenticator für WebAuthn/Passkey-Zeremonien, eine erstklassige page.localStorage / page.sessionStorage-API, Netzwerk-Security-Details auf APIResponses und bringt die Video-Aufzeichnung des Test-Runners auf Parität mit der Trace-Aufzeichnung. Browser-Kanäle: Chromium 149, Firefox 151, WebKit 26.5.
esbuild 0.28.1: Erstes Release seit zwei Monaten mit einer High-Severity-Deno-RCE, einem Windows-Path-Traversal und einem `using`-Disposal-Bug
security

esbuild 0.28.1: Erstes Release seit zwei Monaten mit einer High-Severity-Deno-RCE, einem Windows-Path-Traversal und einem `using`-Disposal-Bug

esbuild v0.28.1 (11. Juni 2026) ist das erste Release seit April. Es behebt eine CVSS-8.1-Remote-Code-Execution in der Deno-API via NPM_CONFIG_REGISTRY, einen nur Windows betreffenden Path-Traversal im Dev-Server und einen Minifier-Bug, der das Ressourcen-Disposal mit `using` und `await using` stillschweigend kaputtgemacht hat.
Claude Code Bug #74066: Nutzer Melden Cross-Workspace-Kontext-Leaks auf Sonnet 5, Anthropic Hat Noch Nicht Antwortet
security

Claude Code Bug #74066: Nutzer Melden Cross-Workspace-Kontext-Leaks auf Sonnet 5, Anthropic Hat Noch Nicht Antwortet

Ein offener Bug, der am 2026-07-04 gegen Claude Code von einem [Enterprise-ZDR](https://docs.anthropic.com/en/docs/build-with-claude/zero-data-retention)-Nutzer eingereicht wurde, beschreibt eine Arbeitssitzung auf Sonnet 5, die plötzlich auf einen unrelated Minecraft-Tempelbau referenziert und dann im Recap bei der falschen Aufgabe bleibt. Der Reporter (GitHub: [@milesrichardson-edb](https://github.com/milesrichardson-edb), Issue [anthropics/claude-code#74066](https://github.com/anthropics/claude-code/issues/74066)) ist auf Enterprise Zero Data Retention, dem Tier, das Anthropic speziell als sitzungsisoliert vermarktet. Ein Triage auf der lokalen Sitzungs-JSONL des Reporters unter `~/.claude/projects/<encoded-cwd>/<session-id>.jsonl` zeigt, dass der geleakte Text nicht im Transkript enthalten ist, was einen lokalen Kontext-Leak durch Datei-Überlappung ausschließt. Vier andere Nutzer in den Kommentaren (mit Arbeitsgeschichten, die bis ins letzte Jahr zurückreichen) beschreiben nahezu identisches Verhalten über Claude Code, Claude Mobile und Claude Deep Research hinweg. Der plausibelste architektonische Fit ist geteilter KV-Cache-Zustand in der Inferenz ([laut @yv3nne in den Kommentaren](https://github.com/anthropics/claude-code/issues/74066#issuecomment-4880448776)), aber kein Anthropic-Ingenieur hat die Issue in den 22 Stunden seit der Einreichung kommentiert, und die Issue erreichte am 2026-07-04 die Spitze von [Hacker News](https://news.ycombinator.com/item?id=42481789). Der Ton im Thread ist gespalten: Die Hälfte vermutet echte Plattform-Cache-Wiederverwendung, die andere Hälfte vermutet eine [sonnet-5-spezifische Halluzination, ausgelöst durch einen Pygments-Lexer](https://github.com/anthropics/claude-code/issues/74066#issuecomment-4880334711). Beide Lesarten sind glaubwürdig.

Kommentare

Anmelden Melden Sie sich an, um an der Diskussion teilzunehmen.

Noch keine Kommentare. Seien Sie der Erste, der seine Gedanken teilt.