allocate array with new

[Jonathan M Davis]

On Wednesday, May 16, 2012 13:52:12 Steven Schveighoffer wrote:
> Where the GC gets into trouble is with allocation of large chunks of data.
> 
> If the data 'contains pointers', it creates a very good chance that the
> data keeps some unknown number of blocks from being deallocated.
> 
> And just by the sheer fact of how big the data is, it's bound to be
> pointed at by some piece of stack data, global data, or TLS data.
> 
> So you can go a long way by manually managing larger chunks of data. I
> think it's worth worrying about as you get into large chunks (on the order
> of 10MB or more).
> 
> What really really sucks about this is, as you allocate larger chunks of
> data, the chances that the GC incorrectly keeps garbage memory get
> larger. In other words, the more memory you allocate, the less likely it
> is that the GC will give you some of it back to you!

Using 64-bit helps with this.

> Precise GC will help this *tremendously*, but I'm unsure if we'll ever get
> to the point of having a fully-precise GC.

Any improvement to the GC is a welcome improvement.

> There will always be a need to
> do manual freeing of memory.

Yes, but my point is that it's something you do when the need arises due to 
performance concerns in a particular section of code. It's not something that 
you do as a matter of course in your code in general. If you're always trying 
to free memory as soon as you don't need it anymore rather than letting the GC 
do its job (or try to anyway), then you might as well be using malloc and 
free.

- Jonathan M Davis