Problem Description

The causality graph analysis program uses typeflow saturation for two reasons:

• Mimic the behavior of the real analysis
• Achieve massive speedup - due to reduced algorithmic runtime and a specialized memory-friendly data structure.

Previously, upon saturation, there would be a conceptual edge created from the AllInstantiated-typeflow to the saturated one.
However, this is not correct and may make the result indeterministic, depending on the visiting order of nodes: A typeflow may saturate with types not contained in the AllInstantiated-typeflow, which then get lost due to stopped propagation. This may occur because the model deviates a bit from the original analysis with regards to saturation rules.

ToDo

• Change the saturation mechanics to incorporate all types flowing into saturated flows.
• Adjust the shortest-path algorithm accordingly
• Reflect on the design decision, with respect to semantic correctness

Description

We thought about integrating the results of the analysis process inside an IDE. For this we'd need to set up a language server. In order to do so, we need to do some background research.

Goals:

• What is needed to set up a language server?
• How do we define what the language server supports/does?
• How to integrate a language server into tools like IDE-plugins?

Acceptance Criteria

• Should answer the goal-questions on a wiki page
• Should supply an mvp for later reference

When adding Universes, a default name should be provided
May be

• cool random names
• the name of the file before ".json"

so this is avoided

depends on #46

Description

On November 2nd we brainstormed data and visualization parameters for some of the visualizations. These should be noted down in the wiki so that we don't lose track of them.

Hints and Thoughts

• We should document the data and visual parameters independent from each other as the data parameters are what we have in general and the visualization parameters can differ between visualizations
• For each visualization we should have a wiki page where the visualization parameters are documented
• On the visualization's wiki page we should also document the mapping from data parameters to the visualization's parameters.

Here the parameters we gathered last time:

Acceptance Criteria

• Should document data parameters on one page
• Should document the visualization parameters and the mapping from data parameters on a dedicated page for each visualization
  • Call-Graph-Breakdown

Description

Some code sites where types get marked reachable by the analysis are yet ignored wrt. the Causality Export:

• AnalysisUniverse.lookupAllowUnresolved()
• Class/DynamicHub-Objects found on the heap: ImageHeapScanner and ReflectionDataBuilder

Description

One Problem that we want to solve is to display which parts of the native image belong to which package/class. For this we want to explore different visualizations. The goal of this issue is to generate 10 new ideas on how to do that.

Hints and Thoughts

Avoid looking at visualizations specifically made for this. That would limit our creative output

Acceptance Criteria

• For each of the 10 ideas, we have a rough sketch describing the idea of a visualization
• Each of these sketches is documented with an explanation on a wiki page

depends on #56

Description

On November 16th we will present us / our project in front of the chair. This presentation needs to be prepared

Hints and Thoughts

Parts of the presentation:

• Welcome
• This is us
• This is our project
• This is what we did so far
• This is what we plan to do for the next weeks
• This is what we need from the chair

Acceptance Criteria

• Should have a finished script
• Should have presentation slides

Description

One Problem that we want to solve is to display which parts of the code talks to which other part. For this we want to explore different visualizations. The goal of this issue is to generate 10 new ideas on how to do that.

Hints and Thoughts

• Avoid looking at visualizations specifically made for this. That would limit our creative output
• Also think about different granularity: package vs class vs method vs property vs ...

Acceptance Criteria

• For each of the 10 ideas, we have a rough sketch describing the idea of a visualization
• Each of these sketches is documented with an explanation on a wiki page

Idea: Could be a little blink for the added item like seen here
https://www.w3docs.com/tools/code-editor/13723

See https://github.com/hpi-swa-lab/MPWS2022RH1-graalvm/pull/3

Description

We decided to use a micronaut app as benchmark for out tools. Therefore we should make sure that it works on each of our development setups.

Steps:

1. Clone the repository
2. Try to compile the micronaut app into a native image
3. Try to run the random conference generator

Acceptance Criteria

• Works on Christoph's machine
• Works on Joana's machine
• Works on Luc's machine
• Works on Lina's machine
• Works on Marcel's machine

keywords:

• attribute list?

takes two nodes, outputs a node

• possible for inclusive union & exclusive
• should be for an abstraction level

Description

So far we did not document any issues here but only on telegram. That can lead to missing some stuff. Therefore all issues written on telegram should be transformed into issues

Acceptance Criteria

• There is an Issue for all todos
  • Try to compile and use the micronaut app on out dev systems (everyone)
  • Documenting our plan for the next weeks
  • Documenting the visualization ideas we had
  • research on lsp
  • ideation on visualizations for size compostions for native images
  • ideation on graph visualizations for relations of packages, classes, methods, etc.
  • Create a presentation for November 16th

When cutting a node, highlight what's removed
or split the tree in 2:

• remainder of the tree
• and what's about to be removed

Description

As of now, we haven't really used color to convey something meaningful. It would be nice to have different options that can be switch during the exploration.

Additional Questions to Answer / Consider

• Package hierarchy
• Diff
• Complexity (size of code that uses a library vs size of the library)

Acceptance Criteria

• Should allow different versions to color the code in
• Allow to switch between the versions in the UI
• The switch is applied immediately

Description

Jens want to have the sizes be measured differently:

• leaf nodes have their size
• the size is calculated so that the area of the circle is the code size, not the radius
• all other nodes have a min size

And this marking/flagging/highlighting is kept across visualizations

Subtasks:

• Implement Controls
  • integrate plain controls
  • style controls
  • implement controls' interaction
• Implement Visualization
• Wireup between Controls and Visualization

Description

On November 2nd we talked about some visualization ideas / rough sketches that we came up with. These should be documented in the wiki as well.

Hints and Thoughts

Acceptance Criteria

• For each idea there should be a wiki page

Description

On November 2nd we made a plan for what is to do in the next weeks. That plan should be documented in the wiki.

Hints and Thoughts

Acceptance Criteria

• There is a wiki page explaining the next steps we want to take

Description

Currently, all visualizations are stand-alone. It would be nice to have some way to switch the visualization while maintaining the context.

Notes

Acceptance Criteria

• Should have some sorts of "VisualizationManager" that is responsible for switching visualizations
• Should have a method in the visualization interface so that the visualization knows which element to focus
• Should have further issues for each visualization to implement that interface

• make universe names editable
• list already uploaded files
• make already uploaded files deletable

Problem description

Currently, the graph resulting from the Causality Export reflects the results of -H:+InlineBeforeAnalysis (which is enabled by default).
This is problematic:
Image methods A, B, C which form a call chain A -> B -> C. In reality, the reachability of C is dependent on the existence of B (given that there are no other ingoing edges to C).
However, due to inlining, our causality graph model contains a direct edge A -> C. According to it, removing B would have no effect.

Practical motivation

In projects where the main-Method is trivial (i.e. only calling a framework entry routine), such as Micronaut or Spring apps, It gets inlined into JavaMainWrapper.runCore0(...), while still existing due to a reflection registration. Then, successive purge analysis yields a minimal cut-weight instead of the expected tremendous one.

ToDo

• Expose Inlining through method edges
• Use inlined method as caller when call happens in inlined code
• Use inlined methods as containers when typeflow originates from inlined code

or things like highlighting, selection, etc

Die müssen per default erstmal nicht angezeigt werden, aber der Nutzer muss die Möglichkeit haben die (performant) einzusehen

Description

At one point in time we will build a system and have tests for it. These test should be executed automatically with a CI job.

Additional Questions to Answer / Consider

• Which testing system are we using?

Acceptance Criteria

• Should add a CI workflow as a GitHub Action to the project
• Should add a minimal example on a test that is executed through the CI

Problem description

The heap assignment tracing agent aims to trace and expose all side effects happening in class initializers at image build time that are relevant to the analysis.
Yet one is missing: The code executed by class initializers is responsible for the initialization of all other classes used by its code.
Currently, this relation is only recorded for classes that were not initialized until required by a running class initializer. Their initialization is then accounted only to the class initializer that (possibly randomly) first used them.

Actions to take

In order to get a correct causality export, during the run of a particular class initializer we'd have to track each action that would trigger the initialization of another class, irrespective of the fact that it may also be triggered by other reasons. That is:

• Calls to static methods of other classes
• Loads/stores from/to static fields of other classes
• Object instantiations