Currently runtime.NumCPU() int exposes the number of cpu cores, which is easily useful for limiting concurrent cpu-bound goroutines. It would be similarly useful if there were a runtime.TotalMemory() uint64 call to help limit memory-intensive goroutines from swapping. I think semantics similar to NumCPU are fine - just detect total memory during startup and do not attempt to track available memory.
An example use case where this would be awesome: I have multiple terabytes of data and want to do all-against-all comparisons. By dividing the data into pairwise batches that fit into memory I can process it more efficiently without needing to pre-process or configure based on what system it's running on. Also my development system uses a different OS and has significantly less memory than my production systems (e.g. using a linux-specific package would make testing and development more difficult).
FWIW, this would also provide a platform-independent way to implement #21795 in userspace.
Currently
runtime.NumCPU() intexposes the number of cpu cores, which is easily useful for limiting concurrent cpu-bound goroutines. It would be similarly useful if there were aruntime.TotalMemory() uint64call to help limit memory-intensive goroutines from swapping. I think semantics similar to NumCPU are fine - just detect total memory during startup and do not attempt to track available memory.An example use case where this would be awesome: I have multiple terabytes of data and want to do all-against-all comparisons. By dividing the data into pairwise batches that fit into memory I can process it more efficiently without needing to pre-process or configure based on what system it's running on. Also my development system uses a different OS and has significantly less memory than my production systems (e.g. using a linux-specific package would make testing and development more difficult).
FWIW, this would also provide a platform-independent way to implement #21795 in userspace.