DataSpell 2023.3 kernel cleanup: should heap-threshold warnings be configurable?
0 reputation · 10 Nov 2023, 02:40 UTC
Background
DataSpell 2023.3 (build 233.11799) fixed a memory leak where Jupyter kernel connections were not released after notebook closure, allowing heap growth up to the configured -Xmx limit (default 2 GB). The fix adds a background monitor that detects orphaned kernels and cleans them up on notebook close.
Remaining constraint
The IDE still relies on a user-defined -Xmx value with no automatic heap resizing based on notebook size. Increasing -Xmx beyond physical RAM risks OS swapping, which degrades performance more than the original leak.
Open design question
An unresolved behavior is whether DataSpell should proactively warn or restart kernels when heap usage exceeds a configurable threshold (for example, 80% of -Xmx) during long-running analyses. The current monitor only reacts after notebook closure; it does not intervene during active computation.
- Should a heap-usage threshold trigger a user-visible warning, an automatic kernel restart, or both?
- If configurable, what default percentage balances early detection against false positives for memory-intensive workloads?
- How should the feature interact with external kernels started outside DataSpell's built-in Jupyter integration?