Skip to content

kickoff meeting

Jump to bottom
Manuel Benz edited this page Mar 1, 2018 · 1 revision

Immutable IR

  • Idee: Jimple immutable by default, Updatemechanismus, der über Listeners Komponenten über Updates informiert
  • Annotationen als First-Class Objekte, Tags eliminieren?
  • Erzeugung der IR-Objekte über Factory-Methoden, so dass man Subklassen erzeugen kann, die zusätzliche Informationen benutzen
    • Erfordert generische Typen für Jimple-Nutzungen
  • Evtl. auf Jimple++ aufsetzen
  • Unterstützung für nicht-Java Semantiken (.NET, Android InvokeDynamic, etc. …)
  • Optional generische Typen mit abbilden (z.B. beim Parsen von .NET oder Java Source Code) -Call-graph construction sollte das in Betracht ziehen
  • Evtl. Anbieten, Jimple auch ungetypt zu bauen

Multiple Versions of IR:

  • SootClasses sollten in einem Namespace aufgehängt werden
    • Beispiele: Classloader/JAR file, Java 9 Modul, .NET Assembly, DEX file, etc. …
    • Evtl. Hierarchisch
  • Analysis View:
    • Name nicht optimal
    • Workspace ("kompletter zu analysierender Code"), enthält n Namespaces
      • Filtermechanismus erlaubt "View" auf diesen Workspace einzuschränken, z.B. nur bestimmte Teile zu analysieren oder herauszuschreiben
        • Müssen darauf achten, dass wir evtl. zusätzliche Klassen herausschreiben wollen
    • View muss Registrierung und Updates von Analyse-Listeners erlauben
    • Möglichkeit, auf gewissen Standardanalysen (z.B. Typhierarchie, CallGraph) durch die View zugreifen zu können
      • Standardanalysen sollen reagieren auf Änderungen in der View
    • View sollte durch "Phase Options" ("View Options"?) parameterisierbar sein
      • Default Views bereitstellen für gängige Use Cases
  • Möglichkeit, mehrere Views vorzuhalten (für inkrementelle Analyse)
    • Sollte einen View von einem anderen ableiten könnten
    • Wenn IR geupdated wird, wird der View darf über informiert
    • Snapshot-View: spezieller View der nicht auf Änderungen generiert
  • Müssen Möglichkeit schaffen, aus zwei Analysis Views einen Delta-Tree zu berechnen
    • Inkrementelle Analyse bekommt dann View und Delta als Eingabe

Configuration / Bootstrapping:

  • Builder Pattern um Optionen programmatisch zu bauen
  • Trennung von Soot Library und Kommandozeilentool (CLI) - CLI-Tool muss dann CL-Options oder ggf. Konfigurationsdateien lesen und darauf basierend Code einlesen, Analysekomponenten aus der Soot Library entsprechend ansteuern, und ggf. Code herausschreiben
  • Konfigurationsdateien sollten Defaults bereitstellen, Dateiformat müssen wir klären
  • Möglichkeit der durchgängigen Dokumentation

Parallele Jimplification:

  • Erfordert Modularisierung
  • Jimplification erfordert Typhierarchie, daher kommen zyklische Abhängigkeiten
  • Evtl. über Aktormodell? Oder alternativ über asynchrones "eventually consistent" modell
  • Analysis Views haben Namespaces, diese sind dann verantwortlich für das Klassenladen - Typhierarchie gilt dann für ganze View, interagiert aber mit den einzelnen Namespaces - Nicht zwangsläufig, nicht für Java 9-Module

Frontends (Java Source, .NET CIL):

  • Möglichst gut kapseln, evtl. Dinge die mehrere Frontends gemeinsam haben herausfaktorisieren
  • Partielle Java 9-Frontends existieren (JavaParser von Rodrigo Bonifacio), Stevens Studenten haben was auf Basis von javac
  • .NET Frontend eher neu designen

Call-graph Framework:

  • CG-Analysen sollten konfigurierbar sein in Bezug drauf, wie sie mit Phantom Classes umgehen
  • Keine eigene CG-Phase mehr
  • CG-Analyse als "Actor": reagiert auf queries, kann Ergebnisse ahead-of-time oder on-demand berechnen
  • Möglichkeit der expliziten und einfachen Modellierung von Aufrufen zu Native Code etc. - Möglichst alle CG-Algorithmen sollten diese Modelle dann mit in Betracht ziehen
  • Standard-Algorithmen weiter drin lassen, jedoch Optionen angleichen, "aufräumen"
  • CG-Construction benutzt Class Loading

Performance und Regression-Tests:

  • Regression Tests: - "Soot Tests Projekt": Binaries einlesen, herausschreiben, Test-Ergebnisse vergleichen - Benötigen möglichst viele Binaries mit möglichst vielen Testfällen
  • Performance Tests:
    • Sollten performance-historie verfolgen
    • Idealer Weise auch Profiling einbauen, um anzuzeigen wo der Code langsamer geworden ist

Release Management:

  • Checklisten machen
  • Release plan aufstellen
  • Möglichst automatisieren - Müssen auch Abhängigkeiten releasen - In MavenCentral hinein - Evtl. Docker-Container

Ablaufplan:

  • Regression Tests ausbauen -> SHK?, für neuen Code wo sinnvoll Unit Tests anlegen
  • Typhierarchie von Jimple aufbauen, basierend auf der alten -> Manuel, Linghui
    • Immutable innerhalb von Bodies
    • Annotationen, Generics einbauen
    • Notification-Mechanismus
    • Factory-Methoden, siehe oben
    • Evtl. Ungetypte Variablen
    • Erweiterbar auf neue Sprachkonstrukte
      • Visitors nutzen
  • Klassenhierarchien für Namespaces, Views, etc. aufsetzen -> Andreas
  • Bytecode Frontend, modular gekapselt -> Ben?
    • Jimplification parallel implementiert, über AKKA Actor Library?
  • Call-Graph Framework -> Johannes, evtl. Melanie? - Eine Call-Graph Analyse sollte anderen Call Graph nutzen können - CG-Analyse muss Code in der aktuellen "Analysis View" betrachten - Evtl. Teile parallel implementieren
  • CLI aufbauen, Standard-Analysen aufsetzen
  • Java Source und .NET Frontends
  • Performance Tests

Table of Contents

Clone this wiki locally