AudioText leaks memory for large-scale training datasets
Thanks, @vadimkantorov for reporting this. Will look into the solution and test it out.  Indeed, when @squire-tomsk investigated stubbing out `.data` in the UserList to our share-safe list holder in https://gist.github.com/vadimkantorov/86c3a46bf25bed3ad45d043ae86fff57, the memory leak goes away. The other solution with Manager'd ShareableDict objects may require Python 3.8, but it probably should be fine.

Also if supporting the full UserList interface is not necessary, it would be best to get rid of it, since slicing would require special care with these shareable list hacks. The leak will be even worse when persistent workers are used @titu1994 Is the issue fixed? Or superseded by another issue? Could you please provide any clarifying information about issue closing? Thank you! @vadimkantorov were you able to solve the issue using your tensorbacked arrays? I tried replacing audio_files in the __init__ function with a StringArray, but it crashes due to high cpu and memory load, probably when iterating through it Another option is to switch to [tarred datasets](https://docs.nvidia.com/deeplearning/nemo/user-guide/docs/en/stable/asr/datasets.html#tarred-datasets).  @samehraban btw do you know if TarDatasets from webdataset/in nemo support caching an index file? so that one does not need to always do a linear scan to discover what's storred in the tarball  @vadimkantorov Do you mean a single cache for all the tar files? I don't think so. A single index for all tar files, or even an index-per-tarfile... For if we have offset+count index, individual files can be read from tarfile by just doing seek
If I understand well, it appends and stores paths to audio files in a list:
https://github.com/NVIDIA/NeMo/blob/8d506d5e47367643328375e7e5b0ff6643ddb82b/nemo/collections/asr/parts/collections.py#L90

If this object is then scattered to all DataLoader workers, it leads to leaking Linux shared memory (measured by PSS) and gets some data loader threads killed by OOM killer halting the training process. Full explanation of the bug is in: https://github.com/pytorch/pytorch/issues/13246.

Large-scale training datasets contain a lot of audio files and hence a lot of audio path strings, this exacerbates the problem

One solution is to use Manager objects as proposed by @snakers4 in https://github.com/pytorch/pytorch/issues/13246#issuecomment-725488844

Another solution is to pack strings into tensors as done in my gist: https://gist.github.com/vadimkantorov/86c3a46bf25bed3ad45d043ae86fff57#file-tensorbackeddictarray-py-L32