tlaplus: "ran out of memory" checking spec with a large tuple

Hello, I’m continuing development of my trace-checker. (We began discussion in #367, I’m following Ron Pressler’s method from “Verifying Software Traces Against a Formal Specification with TLA+ and TLC”.)

Currently, I have a Python script that parses a MongoDB log file and generates a TLA+ spec with a tuple of 6532 states. Each state is a tuple of variable values. Some of these values are large, including tuples up to 1014 elements long. The whole spec is 130MB of TLA+.

Here is the spec and config file.

TLC can parse this file, although it takes some time. The problem is this: TLC runs out of memory during model-checking. This surprises me, because there are only 6532 states. I increased the heap size to nearly the size of my physical RAM with -Xmx60g. That didn’t prevent the crash, it only delayed it.

TLC2 Version 2.14 of 10 July 2019 (rev: 0cae24f)
Running breadth-first search Model-Checking with fp 115 and seed 4672165855747705837 with 1 worker on 16 cores with 54613MB heap and 64MB
 offheap memory (Linux 4.15.0-55-generic amd64, Private Build 1.8.0_232 x86_64, MSBDiskFPSet, DiskStateQueue).
Parsing file /mirror/co/repl-trace-checker/Trace.tla
Parsing file /tmp/Integers.tla
Parsing file /tmp/Sequences.tla
Parsing file /tmp/Naturals.tla
Parsing file /mirror/co/repl-trace-checker/RaftMongo.tla
Parsing file /tmp/FiniteSets.tla
Parsing file /tmp/TLC.tla
Semantic processing of module Naturals
Semantic processing of module Integers
Semantic processing of module Sequences
Semantic processing of module FiniteSets
Semantic processing of module TLC
Semantic processing of module RaftMongo
Semantic processing of module Trace
Error: Java ran out of memory.  Running Java with a larger memory allocation
pool (heap) may fix this.  But it won't help if some state has an enormous
number of successor states, or if TLC must compute the value of a huge set.
Finished in 03h 52min at (2020-01-05 14:13:12)

Is there a way to diagnose why TLC needs so much memory, so I can determine a solution to the problem? Do you think I should use a different data structure rather than a tuple of tuples?