SPLASH/ISSTA 2026 Tool Demonstrations

FlowLog: Re-thinking Datalog forFast and Extensible Static Analysis

Zhenghong Yu¹ Hangdong Zhao² Wanzhu Hou¹ Paraschos Koutris¹

¹

²

ArecursiveDatalogruleA simple Datalog program: Reachability

A declarative logic programming language

R₀ Head

:-

R₁, R₂, …, R_n Body

Reach(y):-Source(y). Reach(y):-Reach(x), Edge(x, y).

Head

Body

Reach = {a}{a, b, c}{a, b, c, d}{a, b, c, d, e}

0:30–1:40 Datalog is a declarative logic programming language. We provide input facts and write rules that derive new facts. ACTION: Reveal the feedback arrow. New facts can feed back into the rules until no new facts can be derived. ACTION: Reveal the rule syntax briefly. Read a rule from right to left: when its conditions hold, derive the fact on the left. ACTION: Show the reachability graph and rules. Here the input is a graph and one source node, a. We want to find which nodes are reachable from a. The underbraces mark the same head and body we just introduced. In the first rule, the body matches Source(a), so the head derives Reach(a). In the recursive rule, the body matches a known Reach fact together with an Edge fact, and the head derives a new Reach fact. ACTION: Reveal b and c. Here the body matches Reach(a) and Edge(a, b), so the head derives Reach(b). The edge from a to c similarly derives Reach(c). ACTION: Reveal d. These new facts let the same rule reach d. Both paths derive the same fact, Reach(d), which appears only once in the result. ACTION: Reveal e and the result. Then d lets us reach e. No further nodes can be added, so we have reached a fixpoint. We specify the rules, and the engine carries out the recursive computation.

Challenges in Building Datalog Engines

Building from scratch

Fine-grained control over evaluation
Datalog-specific optimizations

New features require
invasive changes
Incrementality and scale-out
require major engineering

Building on an existing engine

Reuse mature execution primitives
Inherit parallelism or incrementality

Datalog-aware optimization
becomes difficult
Runtime costs are dictated
by the substrate

RecStepDDlog

40–50 seconds. Existing systems illustrate two design approaches. Building from scratch gives fine-grained control over evaluation and Datalog-specific optimization. But extending these specialized designs with incremental execution or new semantics often requires substantial engineering. Building on an existing database or dataflow engine reuses mature operators and can inherit parallelism or incrementality. However, existing designs can constrain Datalog-aware optimization and incur additional costs: RecStep synchronizes with the database each iteration, while studies report high memory use for DDlog. These are tradeoffs in the existing designs, rather than inherent limitations of every possible reuse-based design. The question is how to retain efficiency while making extensions easier. FlowLog combines the advantages of both approaches, as the next slide shows. Sources: flowlog-vldb-system-design.html, “Existing Approach I: Build from Scratch” and “Existing Approach II: Reuse a Data System”; flowlog_demo_splash/camera-ready/sections/introduction.tex.

FlowLog combines both.

Mature Differential Dataflow^[1] primitives

Fine-grained, Datalog-aware optimization

[1] McSherry et al. “Differential Dataflow.” CIDR 2013.

FlowLog architecture

Demo 1 · One-shot mode

Efficient and scalable
static analysis

DOOP · Context-insensitive points-to analysis

ArealDatalogprogram in FlowLog

DOOP^* uses Datalog rules to compute points-to information for Java programs. Here we use its context-insensitive analysis.

// Input (EDB) facts extracted from Java bytecode
.decl MainClass(class: string)
.input MainClass
// ... other input relations omitted

// Derived (IDB) relations used by the analysis
.decl Reachable(method: string)
.decl LoadInstanceField(base: string, sig: string, to: string, inmethod: string)
// Variable var may point to object heap
.decl VarPointsTo(heap: string, var: string)
// Field sig of object baseHeap may point to object heap
.decl InstanceFieldPointsTo(heap: string, sig: string, baseHeap: string)// Propagate points-to information through a field load
VarPointsTo(heap, to) :-
  Reachable(inmethod),
  LoadInstanceField(base, sig, to, inmethod),
  VarPointsTo(baseheap, base),
  InstanceFieldPointsTo(heap, sig, baseheap).// Output: variable-to-object points-to information
.output VarPointsTo

Soufflé-style syntax

.decl Relation(...)Declare a relation schema

.input RelationLoad input facts

Head :- Body.Derive tuples with a rule

.output RelationEmit a relation as program output

FlowLog port of DOOP

*DOOP Framework 101, plast-lab.github.io/doop-pldi15-tutorial/

35–40 seconds. DOOP is a points-to analysis for Java that determines which heap objects each variable may reference. FlowLog uses Soufflé-style syntax. A declaration defines a relation's columns and types; input directives load facts extracted from Java bytecode. MainClass is one such input. Reachable and LoadInstanceField are derived within the full DOOP program, along with the points-to relations shown here. This excerpt omits their defining rules. The field-load rule follows the object referenced by the base variable, reads the selected field, and derives a VarPointsTo result for the target variable. The head and body follow the same structure as our reachability rules. The output directive selects VarPointsTo to write. We will run the complete context-insensitive analysis in the Playground; the QR code links to its source.

Run DOOP with FlowLog

OptionDescription

-D <dir>output result directory

-F <dir>input fact directory

-o <path>output binary

-Penable profiling

# Compile the DOOP analysis
$ flowlog context-insensitive.dl -o doop-one-shot -F ./facts -D ./out

# Run in parallel with 32 workers
$ ./doop-one-shot -w 32

FlowLogis faston real analyses

Median runtime speedup over Soufflé 5.9×Polonius 3.9×DOOP

Runtime and peak-memory comparison of FlowLog, Soufflé, DDlog, and Ascent on Polonius Rust borrow-checking and DOOP Java points-to workloads at 32 threads; lower is better.

Figure from the SPLASH/ISSTA 2026 tool-demo paper · 32 threads · log scale · lower is better

FlowLogscaleson real analyses

Speedup as thread count grows for FlowLog, Soufflé, DDlog, and Ascent on Polonius Rust borrow-checking and DOOP Java points-to workloads.

Figure from the SPLASH/ISSTA 2026 tool-demo paper · speedup relative to one thread

Demo 2 · Incremental mode

Maintain analysis results
as inputs change

DOOP · Context-insensitive points-to analysis

Run DOOP in incremental mode

# Compile the same analysis in incremental mode
$ flowlog context-insensitive.dl -o doop-inc -F ./facts -D ./out --mode datalog-inc

# Launch the interactive shell with 32 workers
$ ./doop-inc -w 32

Shell commandPurpose

beginBegin an update round

put <rel> <tuple> <diff>Stage one tuple: +1 inserts, −1 retracts

file <rel> <path> <diff>Stage a fact file: +1 inserts, −1 retracts

commitApply all staged updates together

Target: 60–90 seconds with the session ready. The second demo maintains the same DOOP analysis as inputs change. Compile the same program with --mode datalog-inc, then start the executable with 32 workers. Explain the interactive shell: begin starts an update round; put stages one tuple; file stages updates from a fact file; commit applies all staged updates together. A diff of +1 inserts facts and -1 retracts them. Here we will retract one _loadinstancefield fact from the Tomcat inputs. BEFORE THE TALK: Open this Playground, start the incremental session, and wait for the initial Tomcat facts and results to finish loading. Return to the slides without stopping the session or reloading the deck. This demo has a separate persistent Playground from Demo 1. LIVE: Reopen the prepared session. Enter begin, paste the recorded retraction command, then commit. Inspect the affected VarPointsTo result and the reported update time. Recorded command:

put _loadinstancefield "<org.apache.commons.httpclient.util.ParameterParser: java.lang.String getToken(boolean)>/read-field-chars/0	5	<org.apache.commons.httpclient.util.ParameterParser: java.lang.String getToken(boolean)>/$stack44	<org.apache.commons.httpclient.util.ParameterParser: java.lang.String getToken(boolean)>/l0#_0	<org.apache.commons.httpclient.util.ParameterParser: char[] chars>	<org.apache.commons.httpclient.util.ParameterParser: java.lang.String getToken(boolean)>" -1

FlowLog updates the existing result incrementally. TIME BUDGET: If initialization is still pending or the session has expired, move to the measured result slide instead of waiting through compilation. Use the bottom-right next-slide control to continue.

Update DOOP as input changes

DOOP · Tomcat · Retract one LoadInstanceField fact

Full recomputation ≈ 4.9 s

Incremental update 28.45 ms

≈ 172× faster

Measured on the current demo machine · context-insensitive analysis

Demo 3 · Profiler

Diagnose and fix
performance bottlenecks

DOOP · Context-insensitive points-to analysis

Profiler-guided diagnosis

Revisit the field-load rule with a deliberately poor join order:

VarPointsTo(heap, to) :-
  Reachable(inmethod),
  LoadInstanceField(base, signature, to, inmethod),
  VarPointsTo(baseheap, base),
  InstanceFieldPointsTo(heap, signature, baseheap).
// Pin a poor join order for this demo
.plan (1,3,4,2)

# Enable per-operator profiling with -P
$ flowlog context-insensitive.dl -o doop-prof -F ./facts -D ./out -P
$ ./doop-prof -w 32

Target: 90–120 seconds, with the profiled run prepared. This follows the original tool-demo video: https://www.youtube.com/watch?v=DNU1Uzt47MI&t=230s . We reuse the same field-load rule, deliberately pinning .plan (1,3,4,2) to create a reproducible bottleneck. The plan combines the two large points-to relations before applying the more selective LoadInstanceField relation, producing an expensive intermediate. BEFORE THE TALK: Open this separate profiler Playground. It loads DOOP on Tomcat in batch mode, with 32 workers and Profile enabled. The field-load rule and its plan directive are automatically scrolled into view and highlighted (lines 567–572). Uncomment only // .plan (1,3,4,2), run, and prepare the interactive profile report. Keep the page open. LIVE: Show the field-load rule and pinned plan. Open the profile report, select the leading JoinMap in the active-time ranking, and show the linked source rule and plan node. Return to the Playground editor and comment out only .plan (1,3,4,2) to restore FlowLog's default join order. Rerun if time permits and compare execution time and results. The editor supports modifying that line directly. The Playground interface and its Safari code-highlighting fix are embedded in this HTML. Compiling and running still use the online FlowLog server; no local frontend is required. Use the current machine's observed times, not the old video's approximately 5.2-second operator time. TIME BUDGET: Have the slow-plan report ready before the talk so the live explanation can focus on diagnosis and the one-line fix.

Demo 4 · Extended semantics

Extensible recursive
semantics

K-core decomposition · Non-monotonic recursion

Control recursive evaluation

Recursive controls

fixpoint { ... }: Repeat until stable
.iterative R: R may gain or lose tuples across iterations
loop while { @it <= N } { ... }: Bound the number of iterations
loop until { Done } { ... }: Stop when Done becomes non-empty

K-core decomposition k = 3

fixpoint {
  .iterative active_edge
  .iterative degree

  active_edge(x, y) :-
    edge(x, y), !removed(x), !removed(y).
  degree(x, count(y)) :- active_edge(x, y).
  removed(x) :- degree(x, d), d < 3.
}

Repeatedly remove vertices with fewer than 3 neighbors.

60–90 seconds including the live demo. FlowLog provides explicit control over recursion. Fixpoint runs until stable; iterative relations may gain and retract facts between rounds. Loop while provides an iteration bound, and loop until supports a data-dependent stopping condition. Focus on fixpoint and iterative, the two controls used in this example. The code shown is the recursive block from the Playground's built-in 3-core program; declarations, initialization, and outputs remain in the full program. K-core repeatedly removes vertices with fewer than k current neighbors. Removing a vertex retracts incident active_edge tuples and replaces old degree facts, which can cause further removals. The input graph itself is fixed, unlike Demo 2's external input update. LIVE: Open Playground. It preloads K-Core Decomposition in batch mode with Profile off, and highlights the recursive block. Briefly point to fixpoint and the two iterative declarations. Switch to Input Facts to show the built-in graph, then click Run while that tab is visible. When results arrive, the graph highlights vertices 1, 2, 3, 4 as the 3-core and dims vertices 5, 6, 7 and their incident edges. The built-in visualization shows the before/after result, not a per-round animation. This particular input's three low-degree attachments can all be removed in the first peeling round; do not describe them as a multi-round cascade. Show removed = {5, 6, 7} and active_edge for the remaining core. Close with: This non-monotonic recursion runs through the same compiled FlowLog pipeline. Playground selects extended mode for a program containing fixpoint; the equivalent CLI compilation uses --mode extend-batch. PREP: Run this small example once before the talk to warm the compilation cache, then return to the program view. Keep its separate Playground frame open.

Real-world Applications

DOOP integration

In progress with the DOOP team
to support their analyses in FlowLog.

Agent verification

Developing FlowLog support
for agent verification.

…and more.

QR code for preliminary DOOP benchmark results

DOOP benchmarksPreliminary results →

FlowLog

Efficient

Scalable static analysis
Profiler-guided optimization

Extensible

Incremental updates
Extended recursive semantics

QR code for the FlowLog tutorial and Playground

Four Datalog systems in practice

¹

Mature one-shot toolchain

B-tree indexes limit join parallelism to the outer loop

Ascent ²

Lightweight, embedded in Rust macros

Features require engineering

Performance needs tuning

DDlog ³

Incremental execution

High memory use from duplicated stateful intermediates

FlowLog

Datalog-aware optimization

Fine-grained join parallelism

Incremental execution & richer semantics

¹ https://souffle-lang.github.io/² https://github.com/s-arash/ascent³ https://github.com/vmware-archive/differential-datalog

FlowLog: Re-thinking Datalog forFast and Extensible Static Analysis

ArecursiveDatalogruleA simple Datalog program: Reachability

Challenges in Building Datalog Engines

Building from scratch

Building on an existing engine

FlowLog architecture

Efficient and scalablestatic analysis

ArealDatalogprogram in FlowLog

Soufflé-style syntax

Run DOOP with FlowLog

FlowLogis faston real analyses

FlowLogscaleson real analyses

Maintain analysis resultsas inputs change

Run DOOP in incremental mode

Update DOOP as input changes

Diagnose and fixperformance bottlenecks

Profiler-guided diagnosis

Extensible recursivesemantics

Control recursive evaluation

Recursive controls

K-core decomposition k = 3

Real-world Applications

DOOP integration

Agent verification

Efficient

Extensible

Tutorial & Playground

Star us on GitHub ★

Demo Paper

Four Datalog systems in practice

Efficient and scalable
static analysis

Maintain analysis results
as inputs change

Diagnose and fix
performance bottlenecks

Extensible recursive
semantics

Star us on GitHub