| |||||||||||||
Should be: Goodnight, Perl 6.Should be: Goodnight, Perl 6.Posted Feb 11, 2013 8:53 UTC (Mon) by khim (subscriber, #9252)In reply to: Should be: Goodnight, Perl 6. by HelloWorld Parent article: Chromatic: Goodnight, Parrot
I mean, come on, it can't even collect reference cycles. Why is it a problem? Refcounting it probably the best compromise between predictability and convenience. Note how MacOS is losing the much lauded ability to handle reference cycles. Sure, you get an instrument which is less pleasing from the abstract beauty POV but which is infinitely more usable: you can use it to track external resources, you know exactly how much memory is used at any particular moment, etc. And it's not as if you can't leak memory with "proper" garbage collector. Proponents of "full-blown" garbage collectors start foaming at this point and explain how these memory leaks are not memory leaks at all but the fact remains: when your program runs out of memory it does not matter if your leaks are "real" (and can be removed by a "proper" garbage collector) or "unreal" (and thus will be around no matter what you do). If you know and can guarantee that all the references to "dead" data structures will be eliminated then usually it's easy to do the next extra step and break cycles apart, too, and if your data structures are so complex that you can't tear up the cycles then usually your program will consume endless amount of memory for "non-leaks" in some cases anyway.
(Log in to post comments)
Should be: Goodnight, Perl 6. Posted Feb 11, 2013 9:23 UTC (Mon) by alankila (subscriber, #47141) [Link]
The stated justification for losing the capability is to align even OS X developers with the iOS way of the world, where GC is apparently thought to be too expensive. Funnily though, Android phones show that GC is entirely feasible on mobile. I guess they should have tried harder.
And the "leaks" possible with garbage collector are usually not your father's memory leaks. The runtime doesn't lose track of the objects, it just can't release them because programming mistake prevents that. It's usually not hard to track down and fix, because you can capture snapshot of the heap and work out which objects are around by large numbers at the end of the day. (I do not think I've ever had to do this, whereas I've crashed production applications because of inadvertently introduced reference cycles. It shows to me which problem is more severe.)
Should be: Goodnight, Perl 6. Posted Feb 11, 2013 19:35 UTC (Mon) by khim (subscriber, #9252) [Link] Funnily though, Android phones show that GC is entirely feasible on mobile. Sure, if you'll throw dual-core 1.2GHz CPU on the task which works perfectly fine on 600MHz iPhone 3GS you'll get the expected result. But is it really wise use of resources? The stated justification for losing the capability is to align even OS X developers with the iOS way of the world, where GC is apparently thought to be too expensive. Which is kind of strange because iPhone 5 specs are about half of what desktop Mac had when garbage collection was introduced in MacOS X 10.5, isn't it? And next iPhone will probably be more powerful then these macs. No, I think they just found that garbage collection is just unacceptable: it introduces jitter which is not easily observable on a desktop with mouse but is a big problem for touchscreen. But of course there are PR and to say that all these decades of GC-science were just waste of time is not politically correct thing to do.
Should be: Goodnight, Perl 6. Posted Feb 11, 2013 20:55 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]
>Sure, if you'll throw dual-core 1.2GHz CPU on the task which works perfectly fine on 600MHz iPhone 3GS you'll get the expected result. But is it really wise use of resources?
First Android phones had 300MHz CPUs and were pretty snappy.
That's because Dalvik should be used as a glue system for native code and the UI layer.
Should be: Goodnight, Perl 6. Posted Feb 13, 2013 21:27 UTC (Wed) by khim (subscriber, #9252) [Link] >Sure, if you'll throw dual-core 1.2GHz CPU on the task which works perfectly fine on 600MHz iPhone 3GS you'll get the expected result. But is it really wise use of resources? Sorry, but no. Not sure which 300MHz you are talking around but I still have G1 which has 528MHz - and it's laggy as hell. Sometimes it does not react on click for a second or more when you just adjust alarm time! And when I need couple of seconds to go from "new SMS arrived" to the content of said SMS from the home screen... on an idle device with 192MB of RAM? No, it's the exact opposite of snappiness. Now, that's true that not all these freezes are caused by GC, but many of these are indeed a GC freezes. Especially when you scroll something. Basically the only way to have smooth scrolling on G1 was to allocate all the objects once and then reuse them as was noted before. I seriously doubt that's GC creators imagined it's use but in practice it's often the only thing that works reliably.
Should be: Goodnight, Perl 6. Posted Feb 13, 2013 22:46 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]
Try to connect to it and do GC debugging. You'd be surprised.
Most of pauses happen because there's very little RAM on the phone so it has to load applications every time you try to access them. And while Dalvik was specifically designed to make this fast, crappy flash layer often makes it slow.
Should be: Goodnight, Perl 6. Posted Feb 13, 2013 21:30 UTC (Wed) by khim (subscriber, #9252) [Link] That's because Dalvik should be used as a glue system for native code and the UI layer. But UI code is the code where latency is more important then throughput! It does not matter if you render new frame 10 milliseconds or 15 milliseconds, but if you usually render it in 5 milliseconds but occasionally need 50 then you have a problem - and this is exactly what typical GC does to your program.
Should be: Goodnight, Perl 6. Posted Feb 13, 2013 22:44 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]
GC in G1 rarely took more than 20ms _and_ it was designed to be interruptible. I've actually debugged laggy applications on G1 and most of lags were caused by the native libraries taking too much time to do stuff.
Flash drive on G1 is also pretty crappy and can sometimes pause for a long time even on simple operations.
GC or not GC Posted Feb 13, 2013 23:04 UTC (Wed) by marcH (subscriber, #57642) [Link]
> GC in G1 rarely took more than 20ms _and_ it was designed to be interruptible. I've actually debugged laggy applications on G1 and most of lags were caused by the native libraries taking too much time to do stuff.
In fact the real problem that this discussion demonstrates is the lack of transparency. Not just developers but semi-technical, "power users" should be able to do basic "lag troubleshooting" with relative ease, on the field, not requiring a PC and remote debugger.
GC or not, Android or iOS, all these systems should have basic self-monitoring and logging features *built-in* producing clear, power-user readable reports of all events like "ran out of memory, terminated X while Y was using 100M" and "ran GC for 2 seconds", etc.
Nothing beats name and shame. This is how Powertop multiplied by 2 or 3 the battery life of many Linux laptops.
GC or not GC Posted Feb 13, 2013 23:08 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]
You can get GC logs without debugger. But why do you need them? Debugging lags is not really a stuff that power users should do.
> GC or not, Android or iOS, all these systems should have basic self-monitoring and logging features *built-in* producing clear, power-user readable reports of all events like "ran out of memory, terminated X while Y was using 100M" and "ran GC for 2 seconds", etc.
GC or not GC Posted Feb 14, 2013 0:42 UTC (Thu) by marcH (subscriber, #57642) [Link]
> Debugging lags is not really a stuff that power users should do.
It's the only way to identify the guilty applications/services/system configurations/etc
As another example Windows' Resource Monitor (from Vista onwards) totally changed my Windows experience. I used to struggle against bloatware, taking random shots in the dark. Thanks to the Resource Monitor I am now doing surgical and very successful strikes in no troubleshooting time at all.
Too bad there is no "bootchart for Windows" yet. Or isn't there? Autoruns is nice but just a list.
Any complex and professional system has monitoring features built-in. Why not smartphones too? They are certainly complex enough to deserve this.
> Android has something like it, it can estimate the power use by application. You can use various apps to view these stats.
These are averages - the opposite of latency measurements.
GC or not GC Posted Feb 15, 2013 0:04 UTC (Fri) by marcH (subscriber, #57642) [Link]
> Android has something like it, it can estimate the power use by application. You can use various apps to view these stats.
In fact what's needed is something very similar to this. An interface just as simple that displays the list of what the CPU/memory/network/applications were too busy doing in the last minute or so when it failed to react quickly.
Should be: Goodnight, Perl 6. Posted Feb 13, 2013 22:53 UTC (Wed) by nybble41 (subscriber, #55106) [Link]
There are two general ways to deal with GC pauses in programs requiring a near-realtime response. You can use a realtime GC algorithm which amortizes the GC work across all allocations and guarantees a bounded response time, or you can guarantee that there is sufficient free memory available to run the critical path without invoking the GC. The latter is most suitable when the program can expect a certain amount of idle time, e.g. between frames. It should be a simple matter of determining how much memory is needed to render a frame and then adding a call to the GC just before going idle to free at least that much space for the next frame.
Realtime GC algorithms are rare, because they're not usually required and they tend to have more overhead. While Java has System.gc(), it's apparently not very well defined (could be anything from a no-op to a stop-the-world full GC pass), and JavaScript has no standardized control over the GC at all, probably for security reasons. The end result is that while GC response time is manageable in principle, applications written in the most popular GC languages are not provided with the necessary tools for the job.
Should be: Goodnight, Perl 6. Posted Feb 11, 2013 22:29 UTC (Mon) by marcH (subscriber, #57642) [Link]
> No, I think they just found that garbage collection is just unacceptable: it introduces jitter which is not easily observable on a desktop with mouse but is a big problem for touchscreen.
A problem so big that it prevents Android from selling in any significant numbers. Oh, wait...
Should be: Goodnight, Perl 6. Posted Feb 13, 2013 20:17 UTC (Wed) by efraim (subscriber, #65977) [Link]
It does not prevent Android from being sold in great numbers. It is however annoying as hell to have a freaking dial pad stall for several seconds on a 512 MiB RAM phone. I don't remember such basic functionality annoying me to no end on S40 phones with ~0.5MiB RAM.
Regardless, the greatest problem with GC IMHO is that they don't really collect memory. They collect objects, which reference resources. Those resources are typically much more scarce than memory - think DB connections, file locks. (ouch!) And an application which unpredictably does not free those resources will behave in a buggy way. Worse yet, most of the managed (either .NET or JavaScript) code I've seen is written with an attitude that GC will take care of resource disposal no matter what - and only the expected code execution path has a thought-through way of releasing those resources. If any exception shall occur, all bets are off. So the GC does not really help you. You still need to take care of all those resources - which means lots and lots of catching and rethrowing, not unlike C code which tries not to leak. So you either have an ugly code or exceptionally fragile code. (btw, have a look at the mess which is IDisposable in .NET framework - Microsoft developers had to decide whether to implement IDisposable when they designed each base class and interface in the standard library - based on an idea what those *inheriting* those classes might want to do - guess how many times they got that wrong; I do not blame them for it, seems like GC is simply the wrong idea if you want robust code which uses any external resources)
Should be: Goodnight, Perl 6. Posted Feb 13, 2013 20:52 UTC (Wed) by marcH (subscriber, #57642) [Link]
> It is however annoying as hell to have a freaking dial pad stall for several seconds on a 512 MiB RAM phone. I don't remember such basic functionality annoying me to no end on S40 phones with ~0.5MiB RAM.
Agreed but, once again, I never saw any definitive proof that GC was to blame for that. It could just be too many background apps/daemons starting simultaneously when you just wake up the phone to make a call - an entirely different problem.
By the way and for some fun try to google "slow ipad" or "slow iphone".
> So the GC does not really help you. You still need to take care of all those resources
A typical application has an order of magnitude less network connections and files than memory objects, so GC means a LOT less to worry about.
> which means lots and lots of catching and rethrowing, not unlike C code which tries not to leak.
Which language does better and how? Please give some pseudo code example.
Should be: Goodnight, Perl 6. Posted Feb 14, 2013 0:25 UTC (Thu) by HelloWorld (guest, #56129) [Link]
> Worse yet, most of the managed (either .NET or JavaScript) code I've seen is written with an attitude that GC will take care of resource disposal no matter what - and only the expected code execution path has a thought-through way of releasing those resources.
This is not a problem with garbage collection but with developers who don't know which problems a garbage collector solves and which it doesn't.
> You still need to take care of all those resources - which means lots and lots of catching and rethrowing, not unlike C code which tries not to leak.
> (btw, have a look at the mess which is IDisposable in .NET framework - Microsoft developers had to decide whether to implement IDisposable when they designed each base class and interface in the standard library - based on an idea what those *inheriting* those classes might want to do - guess how many times they got that wrong; I do not blame them for it, seems like GC is simply the wrong idea if you want robust code which uses any external resources
Should be: Goodnight, Perl 6. Posted Feb 14, 2013 6:46 UTC (Thu) by efraim (subscriber, #65977) [Link]
>>The right way to use IDisposable is through a using statement, not through the GC.
using statement is only useful under *very* limited circumstances. Far more
So according to what you say, modern GC languages have no way of handling shared resource problem (unlike, uh, C++, which has reference-counted RAII patterns at least)
Another problem is that .NET allows you to reference (not weak references, the real thing) IDisposable objects from non-IDisposable ones. So you may perfectly well be referencing a zombie object which has been disposed of, but not GC'ed.
Should be: Goodnight, Perl 6. Posted Feb 14, 2013 8:30 UTC (Thu) by alankila (subscriber, #47141) [Link]
Combine using with a refcount then, so you can reference the same thing in multiple using-statements. Or pool the object. It's not like this is intractable problem.
Altogether these claims sound strange to me. I've never run into it myself. I pass the objects from the scope that has the 'using' downwards to all parties that need it. This makes sense for me because it's usually database connection and I need to commit or rollbak transaction by the end of it.
Should be: Goodnight, Perl 6. Posted Feb 14, 2013 17:11 UTC (Thu) by HelloWorld (guest, #56129) [Link]
> using statement is only useful under *very* limited circumstances.
> [...] > So according to what you say, modern GC languages have no way of handling shared resource problem (unlike, uh, C++, which has reference-counted RAII patterns at least)
The using statement is useful under the *exact* same circumstances where a C++ destructor is useful: it's just a way to call a function as soon as a certain local variable goes out of scope.
> her problem is that .NET allows you to reference (not weak references, the real thing) IDisposable objects from non-IDisposable ones. So you may perfectly well be referencing a zombie object which has been disposed of, but not GC'ed.
Should be: Goodnight, Perl 6. Posted Feb 14, 2013 17:42 UTC (Thu) by efraim (subscriber, #65977) [Link]
>> The using statement is useful under the *exact* same circumstances where a C++ destructor is useful: it's just a way to call a function as soon as a certain local variable goes out of scope.
As I've already told you, using cannot be used in certain situations where reference counting can.
>> If you do the same mistake in C++, you'd have a dangling pointer, how is that any better?
You wouldn't, because you'd use a ref-counting pointer such as std::shared_ptr.
Should be: Goodnight, Perl 6. Posted Feb 14, 2013 20:24 UTC (Thu) by HelloWorld (guest, #56129) [Link]
> As I've already told you, using cannot be used in certain situations where reference counting can.
That's like saying that C++ destructors cannot be used in certain situations where refcounting can: it doesn't make any sense. Refcounting works just as well in C# as it does in C++, you just have to implement the refcounting logic in your Dispose method, similar to how shared_ptr implements its refcounting logic in the destructor. And actually, alankila already pointed this out, so I don't even know why I bother repeating it...
> You wouldn't, because you'd use a ref-counting pointer such as std::shared_ptr.
Should be: Goodnight, Perl 6. Posted Feb 14, 2013 21:01 UTC (Thu) by efraim (subscriber, #65977) [Link]
>> Refcounting works just as well in C# as it does in C++, you just have to implement the refcounting logic in your Dispose method, similar to how shared_ptr implements its refcounting logic in the destructor. And actually, alankila already pointed this out, so I don't even know why I bother repeating it...
Yes alankina already pointed it out, and it is wrong. Refcounting simply does not work in C#. Because all the helper classes, collections e.t.c, do NOT implement IDispose. That's the point. You cannot implement refcounting when half the standard library is working against you.
>> You would, because if you end up holding a reference to an object with refcount 0, that means you forgot to increase the reference count at some point, and that is perfectly possible with a shared_ptr<T>. You could call .get() on the shared_ptr<T> and store the returned T* somewhere. Or, more subtly, you can write a function that takes a T& and then stores that reference somewhere else. Then you pass *t (where t is a shared_ptr<T>) to that method and you've blown it.
Both would be really stupid things to do and any non-newbie programmer in C++ knows better.
Should be: Goodnight, Perl 6. Posted Feb 14, 2013 23:49 UTC (Thu) by HelloWorld (guest, #56129) [Link] Yes alankina already pointed it out, and it is wrong. Refcounting simply does not work in C#. Because all the helper classes, collections e.t.c, do NOT implement IDispose. That's the point. You cannot implement refcounting when half the standard library is working against you.Well, it's not all that bad. You can write an extension method for IEnumerable that will return an object whose Dispose method disposes of the objects contained within the collection. Then you can write something like
using (myCollection.Disposer()) {
...
}
Anyway, C++ still has the advantage that an object will implicitly call its member objects' destructors after running its destructor, and that it'll call the destructors of the already-constructed member objects when an exception is thrown within a constructor. So yeah, point taken, C++ probably does somewhat better in that regard.
Both would be really stupid things to do and any non-newbie programmer in C++ knows better.I wish! People mess up simple things like that all the time.
Should be: Goodnight, Perl 6. Posted Feb 14, 2013 23:54 UTC (Thu) by marcH (subscriber, #57642) [Link]
> Both would be really stupid things to do and any non-newbie programmer in C++ knows better.
How many non-newbie C++ programmers have you met for real? Three? Five?
Should be: Goodnight, Perl 6. Posted Feb 15, 2013 8:26 UTC (Fri) by efraim (subscriber, #65977) [Link]
Assuming you are asking this in good faith (as opposed to, say, condescension) actually around twenty. Of course in this day and age you don't really have to meet a programmer "for real" to know they exist - just look at the number of people giving competent C++ answers on stackoverflow.com.
Should be: Goodnight, Perl 6. Posted Feb 15, 2013 20:26 UTC (Fri) by marcH (subscriber, #57642) [Link]
It's hard not to make any harmful mistake in C++, much harder than in other languages. As a consequence good C++ programmers are few and a very large number of C++ programmers in service can be considered as newbies. You cannot dismiss mistakes as being "too stupid to do" in C++ as easily as in other languages.
Should be: Goodnight, Perl 6. Posted Feb 15, 2013 22:33 UTC (Fri) by efraim (subscriber, #65977) [Link]
While you are right that there are many gotchas in C++ which can trip newbies, pointers are pretty easy to get right by simple ownership rules:
1. If you get a shared_ptr or unique_ptr you can store it for use later.
2. Otherwise (if you get a raw pointer or a reference) you have to assume that you do not own the resource and can only use it in the method's scope.
3. By calling .get() you are saying you are going to take care of ensuring the object's existence during your use of the pointer - i.e. you get no help all bets are off.
Moreover other languages have much more subtle traps in basic parts of language than C++ does - look at JavaScript and PHPs type-casting rules - while wildly different, both are very counter-intuitive and prone to creating security issues.
Should be: Goodnight, Perl 6. Posted Feb 16, 2013 1:01 UTC (Sat) by marcH (subscriber, #57642) [Link]
I know nothing about JavaScript besides this funny description I've read some day: a functional language disguised behind curly brackets and some object-orientation not to scare away people afraid of maths :-)
http://javascript.crockford.com/javascript.html
You are probably right about JavaScript dangers. On the other hand, I know enough about PHP not to even consider it as programming language. Otherwise the differences between all other languages become negligible and they all become equally excellent
http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad...
Should be: Goodnight, Perl 6. Posted Feb 12, 2013 0:16 UTC (Tue) by HelloWorld (guest, #56129) [Link]
> garbage collection is just unacceptable: it introduces jitter
No it doesn't, not if you do it right. Incremental garbage collectors have been around for years, and measurements have generally shown that performance doesn't suffer significantly as long as enough memory is available, even with conservative garbage collectors like Boehm GC. Otoh, what people continuously push to the back of their mind is that calling free(3) isn't free. It does take time to free a big data structure.
Should be: Goodnight, Perl 6. Posted Feb 12, 2013 1:33 UTC (Tue) by wahern (subscriber, #37304) [Link]
Incremental garbage collectors don't remove jitter, they just help to mitigate it. Like generational collecting, it's an optimization. But there will always be jitter associated with GC. Whether you can perceive it or not is another matter.
What sells me on GC is the ability to handle things like lexical closures without trouble. Closures really cry out for GC, otherwise it's much too easy create cycles (as happens in Perl 5, often).
And the ability to manage external resources is largely a red-herring. A properly implemented C or C++ class will use reference counting internally, so that script references merely holds a lease, and don't control the lifetime, per se.
"Improperly" implemented classes however... well, if you're just tossing garbage C code into your application, then I have no sympathy for you. And adding a simple ref count should be easy enough.
As for GC memory leaks, AFAIU these are usually associated with caches, where you can create undetectable cycles between the key and the value in the cache. These can be solved by "ephemeron tables", although they're not computationally cheap. But then again, nothing is preventing you from manually breaking the cycle.
Should be: Goodnight, Perl 6. Posted Feb 11, 2013 20:48 UTC (Mon) by zlynx (subscriber, #2285) [Link]
Please don't use Android as a shining example of good garbage collection. I curse Android RAM management every time an app goes out to lunch and stops responding to finger input for a couple of seconds.
Should be: Goodnight, Perl 6. Posted Feb 11, 2013 22:30 UTC (Mon) by marcH (subscriber, #57642) [Link]
I think you are confusing Garbage Collection and swapping.
Should be: Goodnight, Perl 6. Posted Feb 12, 2013 0:15 UTC (Tue) by zlynx (subscriber, #2285) [Link]
No, I've seen the performance logs. It is GC. When the machine hits the limits it goes off and does serious GC, ie, not incremental but full.
Sometimes it also has to run out and kill off background tasks which seems to be time consuming. Does it wait for them to exit or something? KILL -9!
Many Android apps hits this problem when scrolling because they're dropping lots of objects from use and creating new ones. Then to fix that leads them into crazy object reuse schemes which start to make C++ look quite nice.
Should be: Goodnight, Perl 6. Posted Feb 12, 2013 1:25 UTC (Tue) by alankila (subscriber, #47141) [Link]
There is no swapping on android. It runs something like OOM killer that hunts for a process to murder based on some rules.
I do not see those long pauses reported here myself. My experience of a GC cycle is that it takes about 2 ms to do, though no doubt there are longer cycles occasionally.
IMHO larger problems are with the physical limits of the touchscreens and poor UI decisions. For instance, it takes some sampling to determine at suitable precision where the finger is, and that requires some low-pass filtering, making every UI movement already lag by default. Some UIs try to use doubleclick and singleclick for completely different actions, requiring singleclick processing to be delayed until it is known that doubleclick was not intended.
My personal #1 annoyance with my phone, a galaxy s2, is to do with the fact that the hardware takes around 1 second to wake up from sleep after I push the power button. That is a long time to wait. I once tried to logcat to see why, but it seems that waking up the hardware simply takes that long, whatever the reason.
And honestly, my phone has 1 GB of memory. It's hard to see it getting used up any time soon, because I'm just not the sort of power user these things are made for. Current shipping phones appear to have 2 GB. If you compare that to around 24 MB heap limit for most android applications, it's evident that something like 50 should be able to exist concurrently without system being even pressed for memory.
Should be: Goodnight, Perl 6. Posted Feb 13, 2013 21:01 UTC (Wed) by marcH (subscriber, #57642) [Link]
> There is no swapping on android. It runs something like OOM killer that hunts for a process to murder based on some rules.
I have a (too) cheap, Android 2.2 tablet with too little memory and it is slow because they enabled swap on it. I know for sure because they were honest about it and told about it in an official changelog. I also know because I installed another, non official build on it, disabled swap and it became much faster.
Should be: Goodnight, Perl 6. Posted Feb 11, 2013 12:35 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]
An interpreted dynamic language without GC is a dinosaur. Refcounting often misses even the obvious cycles in simple closures - and that's something that shouldn't happen.
iOS is losing GC because it never was feasible in the first place. Objective-C requires a conservative GC that fully scans the app's RAM for all possible pointer-like data - and that is not really a good idea on a small device. Precise GCs in Android, WebOS and WinPhone do not suffer from this.
|
|||||||||||||