| |||||||||||||
That's the problem witrh GCThat's the problem witrh GCPosted Aug 22, 2011 3:35 UTC (Mon) by alankila (subscriber, #47141)In reply to: That's the problem witrh GC by khim Parent article: HP dropping webOS devices
A question of finesse:
Does objC run object releases in batches after an iteration in the main loop has executed, or does it release them synchronously when I type [foo release]? One of the supposed advantages of GC over malloc/free style management is that the VM can attempt to arrange GC to occur asynchronously with respect to other work being done. I think Dalvik does something like this.
Dalvik does not have a compacting GC last time I heard, so heap fragmentation could in theory result in more unusable memory and therefore more common GC cycles. There's nothing I can do about heap fragmentation on either iOS or Android, so I don't worry about it.
(Log in to post comments)
That's the problem witrh GC Posted Aug 22, 2011 16:37 UTC (Mon) by endecotp (guest, #36428) [Link]
> Does objC run object releases in batches after an iteration
> in the main loop has executed, or does it release them > synchronously when I type [foo release]?
If you [foo release], it releases it synchronously. If you [foo autorelease], it releases it later.
> One of the supposed advantages of GC over malloc/free style
Right. I have never heard anyone claim that objC's autorelease is faster than synchronous release, however. My guess is that any benefit of postponing the actual release is offset by the effort needed to add it to the autorelease pool in the first place.
The most successful example of this sort of "postponed release" that I've seen is Apache's memory pools. Apache manages per-connection and per-request memory pools from which allocations can be made contiguously, with no tracking overhead. These allocations don't need to be individually freed, but rather the whole pool is freed at the end of the request or connection. I am surprised that this sort of thing is not done more often, as it should have both performance and ease-of-coding benefits.
That's the problem witrh GC Posted Aug 22, 2011 19:31 UTC (Mon) by kleptog (subscriber, #1183) [Link]
Memory pools are also used in PostgreSQL. They have the fantastic property of being able to say 'this transaction is aborted, forget everything related to it in almost constant time'. They're useful when dealing with user code because you can arrange for the code the work in a particular context and when the code is done, you simple clear the context in one go.
It's not free though. It does mean that if you want data to survive for longer periods it means you need to copy the data to a new context. It means that for functions the context of associated memory becomes part of the API and you need to be careful that people respect the conventions, or you get dangling pointers easily. And valgrind gets confused. And external libraries don't get along well with it some times. And you don't get destructors (although I understand Samba has a memory pool architecture with destructors).
But you never get memory leaks, which is good for reliability. And that makes up for a lot.
That's the problem witrh GC Posted Aug 23, 2011 10:59 UTC (Tue) by jwakely (subscriber, #60262) [Link]
Yeah, memory pools are great. In a previous life I grafted C++ destructors onto Apache memory pools, IIRC by overloading 'new' to register functions to be run when the pool gets torn down.
|
|||||||||||||