3 ms·

I suspect the issue exists on 64-bit platforms as well, it's just that it doesn't impact as easily. In theory it is possible/common to have 64-bit machine with

I suspect the issue exists on 64-bit platforms as well, it's just that it doesn't impact as easily. In theory it is possible/common to have 64-bit machine with less than a ton of physical memory (VPS) and running 64-bit Go program which triggers this bug would result in similar impact as the 32-bit version. Why yes - Issue #909 essentially confirms this - running 64-bit doesn't fundamentally change anything - it just buys more time for impact because of larger address space and hope of more physical memory. Which is sad on many levels - just mind blowing that the language designers did not think of this upfront! (Oh and Go's built in packages trigger this problem too - per #909 commenting Unicode package makes the program run!)

4ad 15y ago
Physical memory does not have anything to do with it, the virtual address space is all that matters. It might be useful to consider that 2^64 is 2^32 * 2^32. This means the problem becomes important on 64 bit only if an application will use 10 orders of magnitude more memory. By considering the historic growth in memory capacity and usage, this will only happen around 2060.
- blinkingled 15y ago
  Check out http://code.google.com/p/go/issues/detail?id=909#c32 http://code.google.com/p/go/issues/detail?id=909#c32 and the following comment that agrees with it. This isn't just a address space leak - it is a real memory leak. On 64-bit the GC may not be so easily fooled as on 32-bit but it can still be fooled and that is a fundamental problem that will result in memory leaks - if I have 2GB RAM VPS - it doesn't help to have 2^64 bits of address space (actually it is more like 2^48 (http://en.wikipedia.org/wiki/X86-64#Virtual_address_space_details http://en.wikipedia.org/wiki/X86-64#Virtual_address_space_de... ) - if the GC leaks memory sooner or later my process will be killed by the OS.
  - 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 ago
      Care 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 ago
        But 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 ago
        It 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.

4ad 15y ago

Physical memory does not have anything to do with it, the virtual address space is all that matters. It might be useful to consider that 2^64 is 2^32 * 2^32. This means the problem becomes important on 64 bit only if an application will use 10 orders of magnitude more memory. By considering the historic growth in memory capacity and usage, this will only happen around 2060.

blinkingled 15y ago
Check out http://code.google.com/p/go/issues/detail?id=909#c32 http://code.google.com/p/go/issues/detail?id=909#c32 and the following comment that agrees with it. This isn't just a address space leak - it is a real memory leak. On 64-bit the GC may not be so easily fooled as on 32-bit but it can still be fooled and that is a fundamental problem that will result in memory leaks - if I have 2GB RAM VPS - it doesn't help to have 2^64 bits of address space (actually it is more like 2^48 (http://en.wikipedia.org/wiki/X86-64#Virtual_address_space_details http://en.wikipedia.org/wiki/X86-64#Virtual_address_space_de... ) - if the GC leaks memory sooner or later my process will be killed by the OS.
- 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 ago
    Care 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 ago
      But 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 ago
      It 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.