4 ms·
Again, this has nothing to do with physical memory. It only has to do with the virtual address space. Of course if you bump into this, it's a real leak, who sa
by 4ad 15y ago
Again, this has nothing to do with physical memory. It only has to do with the virtual address space.
Of course if you bump into this, it's a real leak, who said otherwise? And yes, it's possible to artificially generate the collision on 64 bit as it's the same mechanism as with 32 bit. It's about whether it happens frequent enough under normal usage patterns to be a concern. Youtube, and everybody who tried Go in production say it isn't, and that's because of reasons outlined in my first reply to you.
- blinkingled 15y agoCare to explain why? You keep insisting without explaining. Have you checked #C32 and how it clearly says it is a memory leak on both 32 and 64 bit platforms? What is your explanation as to why this is not a memory leak and only a address space leak? [EDIT POST YOUR UPDATE] Ok - so we are on the same page. I wasn't arguing about the likelihood at all - just the fact that it is possible troubled me as a bad GC design. Sure people use lots of crappy software on servers - doesn't mean it's a sound idea :)
- 4ad 15y agoBut it is a real leak, it's just an artificially created leak. These might be interesting to investigate for DOS potential, but they don't happen under regular usage because you are searching a needle in a haystack. [edit after your update] Each GC strategy has its drawbacks, for example the one used by Go has the least overhead in extra memory usage, and it's also simple to understand and implement. Mono got its precise GC only last year, it survived 8 years with a conservative GC. Go is only two years old.
- luriel 15y agoIt is possible to artificially fool any GC into leaking memory, only question is whatever it happens in practice. In practice the Go GC never leaks memory on 64bit systems and for most programs never on 32bit systems either.