The next 20 years of Python [LWN.net]

The next 20 years of Python

Posted Jul 12, 2013 10:34 UTC (Fri) by Cato (guest, #7643)
In reply to: The next 20 years of Python by b7j0c
Parent article: The next 20 years of Python

Unfortunately Go suffers from a severe GC problem on 32-bit architectures, see https://groups.google.com/forum/#!topic/golang-nuts/qxlxu... (bug 909) for details.

This means that many people can't really use it for long-running 32-bit desktop or server apps, including on smaller VPSs that may be 32-bit since they only need 1 or 2 GB RAM.

to post comments

The next 20 years of Python

Posted Jul 13, 2013 6:01 UTC (Sat) by b7j0c (guest, #27559) [Link] (2 responses)

twenty years from now you will only find 32-bit architectures in museums, so i'm not sure why you are bringing this up (everyone who works with go has heard it numerous times before and rightly sees it as a nonissue)

The next 20 years of Python

Posted Jul 13, 2013 9:12 UTC (Sat) by Cato (guest, #7643) [Link]

For people who have to build 32-bit apps now, this could be a real issue so it's worth flagging it. However, it seems to have been solved to some extent since I last looked at it.

The next 20 years of Python

Posted Jul 14, 2013 8:02 UTC (Sun) by dlang (guest, #313) [Link]

you mean like there are no 8 bit architectures being used any longer?

ohh, I guess you haven't heard that there are more 8 bit processors being built and sold today than ever before, far more 8 bit processors are sold than 32 bit processors.

Now, it's true you don't see general purpose computers being sold with 8 bit processors any longer, but that's not the same as "only found in museums"

The next 20 years of Python

Posted Jul 13, 2013 8:57 UTC (Sat) by lab (guest, #51153) [Link] (2 responses)

To be fair, this problem appears to be chipped away at consistently, and should already be much less of a problem than it has been. Quoting from http://code.google.com/p/go/issues/detail?id=909#c59 :

"For a problem of this generality, "fixed" is a difficult word. The core problem is that the garbage collector is not fully precise. This can cause a value that does not contain a pointer to appear to be a pointer, which prevents the garbage collector from collecting the memory block to which the non-pointer appears to point. In practice this happens most often with floating point values; integers rarely appear to be pointers, but floating point value sometimes do.

So much for the background. In Go 1.1 the GC is far more precise than the GC in Go 1.0. That means that these sorts of problems are vastly less likely to occur when using Go 1.1 than they are with Go 1.0. In particular in Go 1.1 the heap is almost entirely precisely typed, and floating point values in the heap will never be mistaken for pointers.

However, the problem is not entirely fixed because even in Go 1.1 the GC is not entirely precise. In particular in Go 1.1 stack frames are not precisely typed. So if, for example, you have a bunch of floating point local variables, those variables can appear to be pointers while the function is live and cause the GC to fail to collect various memory blocks. This is not likely to be a problem for most programs, but it is certainly possible.

In Go 1.2 the GC will be even more precise than it is in Go 1.1. On tip the GC is already precise for function arguments and results. Go 1.2 may be precise for local variables on the stack. It may even be fully precise. But it's too early to tell whether this work, which is ongoing, will be complete for Go 1.2.

So the current status is that most programs that did not work with Go 1.0 should now work fine with Go 1.1. However, it is possible to construct test cases that will not work well with Go 1.1. And there is a very small chance that your real program will accidentally happen to be one of those test cases. But it's a very small chance. Also, if you are so unfortunate as to encounter that chance, you do have options in Go 1.1 that you did not have in Go 1.0: you can force your non-pointers that appear to be pointers off the stack into the heap. That will give you a bit more heap allocation, but in return the GC will collect more data."

The next 20 years of Python

Posted Jul 13, 2013 9:15 UTC (Sat) by Cato (guest, #7643) [Link] (1 responses)

Thanks for this useful clarification - seems like progress is being made to fix this.

In the short term, it may be enough for server apps on 32-bit to just restart after a number of transactions, or a period of time.

It's a bit harder to do such restarts on desktops when user is using the app - however, desktop app restarts are not so uncommon due to software updates, so perhaps a minor update could be pushed forcing an app restart.

The next 20 years of Python

Posted Jul 13, 2013 9:28 UTC (Sat) by lab (guest, #51153) [Link]

It would seem that for the vast majority of programs one should not even have to consider doing restarts, or taking other special measures. In other words: "It should just work now" (with Go 1.1 at least). Of course, when deploying a longrunning program written in *any* language, it will always be prudent to monitor it's behaviour, at least in the beginning, to see whether there are any problems or not. In other other words: There should no longer be any special reasons, to have special worries about Go programs. But as always, check it anyway.