4 ms·
These phones had like 1 MB, 2 MB, 4 MB of RAM. And these were 3D-accelerated games running on them. A GC language was definitely the wrong choice for the platfo
by kalleboo 5y ago
These phones had like 1 MB, 2 MB, 4 MB of RAM. And these were 3D-accelerated games running on them. A GC language was definitely the wrong choice for the platform, but J2ME was the industry standard because portable. So if you're allocating a dozen objects in a frame it's best to GC them in the same frame or you're going to lose tens of frames later.
Even in modern times, for the longest time Android Java apps had laggy scrolling due to GC hitches that the refcounting iOS Obj-C apps avoided.
- pjmlp 5y agoRefcounting has glitches as well.
- astrange 5y agoThe refcounting isn't so bad but freeing and running destructors can pause. There's also memory fragmentation from not having a compacting GC. It's all fixable though.
- kaba0 5y agoThough nowadays GC is also “fixable”, and probably more performant than refcounting, at least for non-single-threaded code.
- astrange 5y agoCross-thread refcounting is not that common and the CPU has very fast atomics anyway. It's still a better tradeoff than having to sweep (which might need to page in), make all pointers visible, accept the occasional peak memory increase, etc.
- kaba0 5y agoWhat are the options for sharing an object between threads then? And even with having good atomics, it is a very significant overhead. Also, the primary reason for modern GCs having significantly better performance than refcounting is that with GC one can move the majority of work to another thread, letting them continue the work. Refcounting is good for some simple programs where ownership is not trivial, and the language doesn’t support a GC/or when memory is constrained, etc. But it is not an accident that high level languages with GC doesn’t choose refcounting, and having the cost of destruction at the given thread is just one point, afaik circular references are similarly not an easily solved problem. And basically with every single “solution” to these problems you are moving towards a full-blown GC.
- astrange 5y ago> What are the options for sharing an object between threads then? It works fine, it’s just not done that often. (Specifically contended refcount changing isn’t done, which is why having fast uncontended atomic helps.) Transferring between threads happens and just works. ObjC has explicit weak pointers and ways to move destructors to another thread and it all works. Though you could use C# or JavaScript in your app, many people do. Actually, PHP and Python do use refcounting internally, I think PHP only GCs on exits from functions…
- kaba0 5y agoI don’t get your point. Of course refcounting is a possible and working solution, but it’s not an accident that Java, JS, and C#, languages with the best GCs, doesn’t use it.
- astrange 5y agoYes, C# is the best language to write a phone OS in if you want to go out of business.
- pjmlp 5y agoOther languages need special hardware to beat C#, so I guess the language wasn't the issue. https://github.com/ixy-languages/ixy-languages https://github.com/ixy-languages/ixy-languages https://blog.metaobject.com/2020/11/m1-memory-and-performance.html https://blog.metaobject.com/2020/11/m1-memory-and-performanc...
- astrange 5y agoThere is no "special refcounting hardware" in the M1, it has exactly what I said it has above this. Alas, nobody trusts me…
- pjmlp 5y agoJava and .NET also have weak references. Also C# can do everything that Objective-C is capable of, provided one actually knows how to use the language. CPython uses a mix of refcounting with a cycle collector tracing GC, other Python implementations use tracing GCs. The language does not specify GC semantics and counting on them is a recipe to break code when moving across implementations.
- kalleboo 5y agoSure, but it's glitches you control. Everything is deterministic. With a GC, your only solution is to call the GC explicitly on every frame and pray for the best.