Simple graphs with time on the x-axis, and some numeric values on the y-axis. Updated every Z/UNIT.

Examples:

• transfers
• objects
• allocations
• joins
• exceptions (from JavaScript)
• coverage
• UDPAs
• refinements
• calls (+ user / native)
• ...

Some work has been done in by @algobardo here: "tajs-graphing and performance monitor in tajs-meta in our JSRACES group".

I would be nice if TAJS-specific dependencies were abstracted to make the Inspector more meaningful for other analyses/languages

See TODOs in:

• dk.brics.inspector.api.model.lines.MessageSeverity
• dk.brics.inspector.api.model.lines.MessageStatus
• dk.brics.inspector.api.model.options.OptionData
• dk.brics.inspector.api.model.values.DescribedProperties
• dk.brics.inspector.api.model.values.ObjectKind

If the backend analysis is able to serialize its entire state into a snapshot (this is more than just the abstract states it has computed, it is also things such as the worklist and the configuration options). Then many interesting features become possible.

• timeline of snapshots to see how the analysis progresses
• graph timeline of numeric values from the snapshots, e.g. worklist size, memory use
• diff of two snapshot (i.e. "what has changed in the last 1000 node transfers)
• rendering of the snapshots on a different machine (or just at a later timer)
• restart of the analysis from a snapshot (see #2)
• restart of the analysis from a snapshot - with changed configuration options (this is less related to the inspector)

Support for the usual features:

• pause
• continue
• stop
• breakpoint (= pause the analysis when the analysis is about to analyse the specified program point, conditional breakpoints should also be considered)

The "drop frame" feature can be supported when analysis-state snapshotting is implemented.

Interaction with the IDE debugger can be achieved through the following hack:

public void BREAKPOINT(){ // part of InspectorAPI
    return; // add a permanent breakpoint on this line in the IDE
}

The implementation of the breakpoint functionality simply calls the BREAKPOINT method, at which point the IDE will take over.

There are currently 2 issues preventing to update to Java 9:

• The current building on TAJS inspector relies on the plugin cz.habarta.typescript-generator that doesn't work properly on Java 9.
• Current version of gradle (3.5) doesn't even recognise version 9 as a valid version.

For performance reasons, the gutters-API should be separated into two parts:

• api/get-gutters -> [{name: 'foo', description: 'foo % per bar'}, ...]
• api/get-gutter-data?gutter-name=FOO&fileID=42 -> LineMap

In this way, the (expensive) computation of gutter data is only done on demand

It can be useful to navigate directly on the flowgraph, since predecessor/successor navigation could end up being in very small (and confusing steps).

API: flowgraph as a data structure (as fragments: the UI should not have to worry about which nodes are relevant beyond saying it needs nodes for some location +/- some lines/neighbor distance).

UI: rendering of flowgraph, clickable for navigation

@algobardo has done some work on this:

It is mostly in http://casadev.cs.au.dk/JSRACES/TAJS-meta/commit/226078dacc2905c39f909186fcf3412b2783d3d8

There are two minor fixes in the following two commits.

Let me use it before I can say if it is useful :-D

(dynamic information = value log information from the JalangiLogger project)

Display of:

• raw concrete values
• overapproximations (precision losses)
• underapproximations (unsoundness errors)

If the deltas above are implemented, then it should done with a future diff between two TAJS snapshots in mind.

Backend

• Raw data
• Delta-computations from arguments or simply deltas for location (undecided)

Frontend

• More content in the bottom panel
• Fancy highlighting of under/overapproximations (red/green?)

The server supports more navigation than the client: the client should be extended to support more navigation.

(the UI for navigation should also be improved. It should (also) use the same kind of tree view as the call hierarchy does)