The triple reading/writing to memory along with the comparing would probably be a significant performance hit. You could just use a bit of extra memory for parity bits etc. instead
Of course you could trade implementation complexity for speed as always. My main point was to have effective ECC without any additional support from motherboard and memory modules.
I imagine soft-ECC would be more plausible if it could be applied/enabled:
1. Per-process (e.g. whole application)
2. Or fine-grained per-allocation within a process/application
I think both could be implemented through a (system) memory allocator by taking the advantage of page alignment LSBs and/or (non) addressable bits of the virtual memory. Those spare bits in memory can be used to store the encoding of ECC algorithm (Hamming, Reed-Solomon, or something more primitive but less robust).
And then, depending on the ECC algo, one could substantially minimize the performance impact of encode/decode by using SIMD.
Of course an application that marks GB of data this way could play havoc with other processes, so maybe some OS limits on how many non-executable pages a process can mark may be needed.
And there certainly might be some further dragons I'm not considering.
[1]: https://learn.microsoft.com/en-us/windows/win32/api/memoryap...