case 1:
 delete ar;
case 2:
 ar.destroy();
case 3:
 GC.free(ar.ptr);
case 4:
 ar = null;// (assumed that ar is only one pointer to the same array)

What is the difference?

How to free memory to the system immediately?

___________________________
Thank You & Best Regards,
Ilya

Ilya Yaroshenko:

> case 1:
>  delete ar;

It's deprecated.


> case 4:
>  ar = null;// (assumed that ar is only one pointer to the same array)

It's the simpler way.


> How to free memory to the system immediately?

What is your use case?

Bye,
bearophile

Answer will make more sense if ar is assumed to be any heap-allocated object, not just dynamic array.

On Monday, 30 December 2013 at 06:52:20 UTC, Ilya Yaroshenko wrote:
> case 1:
>  delete ar;

Deprecated. Used to call destructor and GC.free after that

> case 2:
>  ar.destroy();

Current solution to free resources in deterministic way. Calls destructor and sets `ar` to init state so that it can be collected by GC at some unknown point later.

> case 3:
>  GC.free(ar.ptr);

Marks memory as freed in GC. Unsafe and discouraged because there can still be references pointing at it.

> case 4:
>  ar = null;// (assumed that ar is only one pointer to the same array)

Simply cleans the reference to an object. If it was the only reference, it will be destroyed and freed upon next GC cycle.

> What is the difference?
>
> How to free memory to the system immediately?

GC.free

However, if you want deterministic deallocation it makes more sense to use C malloc or custom allocators as GC tends to run faster if it is aware of less memory.

On Monday, 30 December 2013 at 06:52:20 UTC, Ilya Yaroshenko wrote:
> case 1:
>  delete ar;
> case 2:
>  ar.destroy();
> case 3:
>  GC.free(ar.ptr);
> case 4:
>  ar = null;// (assumed that ar is only one pointer to the same array)
>
> What is the difference?
>
> How to free memory to the system immediately?

It depends on how it is allocated. The `delete` operator is deprecated, so it is never appropriate.

For GC memory (memory allocated with `new`, the concatenation operators or array literals) then you should just `null` any reference that is no longer used, leaving it to the GC to collect the memory when it sees fit. This guarantees memory safety, which is the primary purpose of a memory garbage collector.

If you really, really must free a chunk of GC memory *right now*, you can use GC.free, but you lose any guarantee of memory safety. If you can't think of a reason your code needs to do this, then your code probably doesn't need it.

If the array is allocated from a non-GC heap, such as the C heap, use the corresponding freeing function (C heap using `malloc` + `free`).

`destroy` is for running destructors on, and then invalidating, instances of user-defined types (UDTs). For generic code purposes, you can use it on non-UDTs, in which case it will just invalidate them. Values invalidated with `destroy` must not be used after invalidation - it is a logic error. What it means by invalidation is up to the implementation, but it guarantees that it won't free memory. Currently, it zero-blasts the value (which may be different from the value's default initializer).

On Monday, 30 December 2013 at 08:13:30 UTC, bearophile wrote:
>> How to free memory to the system immediately?
>
> What is your use case?

The use case is: we want deterministic memory management, (and the application data is too big to fit into memory at once, so have to be processed batch by batch).

suppose:

  double[] data;  // D type: dynamic array


As of 2021 what's the correct way to allocate and deallocate (free memory to the system immediately) D's dynamic array?

If we use core.stdc.stdlib.malloc and free, e.g.

```
  data = core.stdc.stdlib.malloc(n * double.sizeof);
  // processing ...
  free(data.ptr);
```

-- will data.length be set correctly (since it's a D type) with malloc?

-- or we still need to manually set data.length = n? (in this case, will it become GC managed, which we want to avoid in this app)?

Thanks.

On Tue, Mar 16, 2021 at 11:28:00PM +0000, mw via Digitalmars-d-learn wrote: [...]
> suppose:
> 
>   double[] data;  // D type: dynamic array
> 
> As of 2021 what's the correct way to allocate and deallocate (free memory to the system immediately) D's dynamic array?
[...]

Note that T[] is just a slice, not the dynamic array itself. The dynamic array is allocated and managed by the GC when you append stuff to it, or when you create a new array with `new` or an array literal.

None of the latter, however, precludes you from using T[] for memory that you manage yourself. For example, you could do this:

	double[] data;
	data = cast(double[]) malloc(n * double.sizeof)[0 .. n];

Now you have a slice to memory you allocated yourself, and you have to manage its lifetime manually.  When you're done with it:

	free(data.ptr);
	data = []; // null out dangling pointer, just in case

The GC does not get involved unless you actually allocate from it. As long as .ptr does not point to GC-managed memory, the GC will not care about it. (Be aware, though, that the ~ and ~= operators may allocate from the GC, so you will have to refrain from using them. @nogc may help in this regard.)


T

-- 
Computers shouldn't beep through the keyhole.

On Tuesday, 16 March 2021 at 23:49:00 UTC, H. S. Teoh wrote:
> [snip]
>
> Note that T[] is just a slice, not the dynamic array itself. The dynamic array is allocated and managed by the GC when you append stuff to it, or when you create a new array with `new` or an array literal.
>
> None of the latter, however, precludes you from using T[] for memory that you manage yourself. For example, you could do this:
>
> 	double[] data;
> 	data = cast(double[]) malloc(n * double.sizeof)[0 .. n];
>
> Now you have a slice to memory you allocated yourself, and you have to manage its lifetime manually.  When you're done with it:
>
> 	free(data.ptr);
> 	data = []; // null out dangling pointer, just in case
>
> The GC does not get involved unless you actually allocate from it. As long as .ptr does not point to GC-managed memory, the GC will not care about it. (Be aware, though, that the ~ and ~= operators may allocate from the GC, so you will have to refrain from using them. @nogc may help in this regard.)
>
>
> T

This is one of those things that is not explained well enough.

On Wednesday, 17 March 2021 at 10:54:10 UTC, jmh530 wrote:
>
> This is one of those things that is not explained well enough.

Yes.
I made this article to clear up that point: https://p0nce.github.io/d-idioms/#Slices-.capacity,-the-mysterious-property

"That a slice own or not its memory is purely derived from the pointed area."

could perhaps better be said

"A slice is managed by the GC when the memory it points to is in GC memory"?

On Wednesday, 17 March 2021 at 14:30:26 UTC, Guillaume Piolat wrote:
> On Wednesday, 17 March 2021 at 10:54:10 UTC, jmh530 wrote:
>>
>> This is one of those things that is not explained well enough.

I want just to add, case 3 is wrong usage.
Right one is:

GC.free(GC.addrOf(ar.ptr));

On Wednesday, 17 March 2021 at 14:30:26 UTC, Guillaume Piolat wrote:
> On Wednesday, 17 March 2021 at 10:54:10 UTC, jmh530 wrote:
>>
>> This is one of those things that is not explained well enough.
>
> Yes.
> I made this article to clear up that point: https://p0nce.github.io/d-idioms/#Slices-.capacity,-the-mysterious-property
>
> "That a slice own or not its memory is purely derived from the pointed area."
>
> could perhaps better be said
>
> "A slice is managed by the GC when the memory it points to is in GC memory"?

I probably skimmed over the link when I originally read it without really understanding it. I'm able to understand it now.

I think the underlying issue that needs to get explained better is that when you do
int[] x = [1, 2, 3];
the result is always a GC-allocated dynamic array. However, z below
int[3] y = [1, 2, 3];
int[] z = y[];
does not touch the GC at all. For a long time, I operated under the assumption that dynamic arrays and slices are the same thing and that dynamic arrays are always GC-allocated. z is obviously a slice of y, but it is also a dynamic array in the sense that you can append to it and get an array with one more member than y (except in @nogc code). However, when appending to z, it seems that what's really happening is that the GC is allocating a new part of memory, copying over the original value of y and then copying in the new value. So it really becomes a new kind of thing (even if the type is unchanged).

One takeaway is there is no issue with a function like below
@nogc void foo(T)(T[] x) {}
so long as you don't actually need the GC within the function. A static array can be passed in just using a slice.