stillwater-sc / universal / 32593773442

85%

master: 84%

push

github

fix(elreal): stop the lazy producers owning themselves (#1379)

* fix(elreal): stop the lazy producers owning themselves

add() and infsum() built their tail thunk as a std::function holding a shared_ptr to
the control block that owned it. The function object owned itself, so releasing the
returned ZBCL could never bring the count to zero: every call stranded its state for
the life of the process.

Measured before, as live heap allocations per stream created and immediately dropped:

    add            4 allocations per call
    div_online    72
    mul_online   243

and in RSS terms 0.29 kB, 6.33 kB and 41.28 kB respectively -- 80,000 dropped
mul_online streams took a process from 3.5 MB to 2.3 GB, growing linearly and never
released. Every elreal operation goes through add(), and every multiply and divide
through infsum(), so a long-running high-precision computation leaked in proportion
to the block operations it performed.

Both now use a free function whose thunk captures only the state, the same shape
#1377 adopted for singleDiv after review:

    template<typename FpType>
    inline ZBCL<FpType> addRec_stream(std::shared_ptr<addRec_state<FpType>> st) {
        auto nxt = addRec_step(*st);
        if (!nxt) return ZBCL<FpType>{};
        block<FpType> head = *nxt;
        return ZBCL<FpType>::cons(head, [st]() { return addRec_stream<FpType>(st); });
    }

After: 0 allocations retained by any of the three, and RSS flat at 3668 kB across
160,000 created-and-dropped streams where it previously reached 2.3 GB. Laziness and
streaming behaviour are unchanged -- the thunk does the same work, it just does not
own the object holding it.

This is a memory fix, not a speed one: the LEVEL_4 transcendental suite runs 2m03.5s
against 2m06.0s before, which is noise.

Regression elastic/elreal/zbcl/lazy_lifetime.cpp counts live heap allocations across
500 created-and-dropped streams and fails if the count does not return to its
pre-loop level. It counts alloca... (continued)

13 of 13 new or added lines in 2 files covered. (100.0%)

43125 of 50491 relevant lines covered (85.41%)

7180376.23 hits per line