[fpc-devel] Modernising Pascal

[Jamie McCracken]

DrDiettrich wrote:
> Jamie McCracken wrote:
> 
> 
>>GC is very inefficient with memory and current implementations tend to
>>cost a lot performance wise too.
> 
> 
> I don't see how GC is inefficient with memory?
> Reference counting and (mark/sweep) garbage collection have a different
> runtime behaviour: Reference counting occurs with many references to
> objects, whereas GC only runs when required, or when idle time is left.


The problem with GC is the lifetime of (dead) objects is significantly 
extended under GC. This means it hogs more memory for much longer. 
Memory allocation is also potentially slowed as a result of more objects 
remaining allocated on the heap so less chance of holes appearing which 
can be reused (unless you use a compacting GC).

GC runs in a seperate thread so will incur additional overhead from that 
too and you cant always predict when it runs and it can snare you at the 
most inappropriate times (EG if memory is in short supply the thread 
must become extremeley aggressive to avoid swap so you will lose 
performance big time in those cases and with compacting variety even 
more so if it does end up in swap)


> 
> 
> 
>>GC gets a lot slower with the more objects you create.
> 
> 
> It's not the creation that costs GC time, instead it's the destruction
> of the objects.

Its potentially both. All GCs have a tradeoff between memory usage and 
performance. A compacting one may have faster allocation but uses more 
memory as a result. There is no perfect GC that both uses memory 
efficiently and gives good performance (when compared to manual).


> 
> 
>>Mixing unmanaged with managed code cause severe performance issues
>>(marshalling penalties calling ummanaged c functions)
>>
>>Interoperability with C gets increasingly difficult. Writing bindings
>>becomes much more complicated and time consuming.
> 
> 
> IMO it's never a good idea to mix managed and unmanaged code, to suffer
> from the worst from two worlds at the same time :-(
> 
> 
>>>GC is worse here because the pointers are not static in GC so 
> 
> referencing an object means looking up the actual address in a lookup 
> list (so more overhead whenever you call a method or pass an object 
> reference). GC does not use the stack efficiently and has to use a lot 
> of heap so its extremely inefficient. Ever see GC compact swap?<<
> 
> I don't know what GC implementation you're referring to. When memory
> gets too much fragmented, every memory manager has to do a compaction,
> that's inevitable. But GC offers a chance to update the references to
> moved objects, so that no address tables are required. Other memory
> managers don't know about the locations of pointers to the objects, so
> that moving objects is not possible at all! Consequently GC allows for
> better use of available memory, where other methods have to stop with
> "out of memory".
> 
> IMO you should learn a bit more about memory management, your
> argumentation doesn't look well founded to me.

There are over a dozen different GC strategies so some of my points 
apply to some but not others (same with a lot of the replies here) thats 
why this thread has become long and controversial - you simply cant make 
  a lot of generalities without specifying which type of GC you are 
reffering to.


jamie.