A few questions regarding GC.malloc.

When requesting a chunk of memory from GC.malloc am i right in assuming that this chunk is scanned for pointers to other GC resources in order to make decisions whether to collect them or not?

What does BlkAttr.FINALIZE do when used in the GC.malloc call?

On Thursday, 25 September 2014 at 20:58:29 UTC, Gary Willoughby wrote:
> A few questions regarding GC.malloc.
>
> When requesting a chunk of memory from GC.malloc am i right in assuming that this chunk is scanned for pointers to other GC resources in order to make decisions whether to collect them or not?

By default, yes, but you can use BlkAttr.NO_SCAN if you do not want that (eg, if you want to store integers). As a rule of thumb, you can use hasIndirections!T to know if or if not to scan (that's what most of phobos relies on).

> What does BlkAttr.FINALIZE do when used in the GC.malloc call?

I have no idea. I think its for classes though, since we (currently) don't finalize structs anyways.

On Thursday, 25 September 2014 at 21:43:53 UTC, monarch_dodra wrote:
> On Thursday, 25 September 2014 at 20:58:29 UTC, Gary Willoughby wrote:
>> A few questions regarding GC.malloc.
>>
>> When requesting a chunk of memory from GC.malloc am i right in assuming that this chunk is scanned for pointers to other GC resources in order to make decisions whether to collect them or not?
>
> By default, yes, but you can use BlkAttr.NO_SCAN if you do not want that (eg, if you want to store integers). As a rule of thumb, you can use hasIndirections!T to know if or if not to scan (that's what most of phobos relies on).

Yep.  It's generally just easier to do a "new T[]" when you want a block to ensure that the proper flags are set, as GC.malloc is conservative in terms of the flags it sets.

>> What does BlkAttr.FINALIZE do when used in the GC.malloc call?
>
> I have no idea. I think its for classes though, since we (currently) don't finalize structs anyways.

Yes it's for memory blocks containing class instances.  It basically tells the GC to call Object.~this() when collecting the block.

On 9/25/14 6:03 PM, Sean Kelly wrote:
> On Thursday, 25 September 2014 at 21:43:53 UTC, monarch_dodra wrote:
>> On Thursday, 25 September 2014 at 20:58:29 UTC, Gary Willoughby wrote:
>>> What does BlkAttr.FINALIZE do when used in the GC.malloc call?
>>
>> I have no idea. I think its for classes though, since we (currently)
>> don't finalize structs anyways.
>
> Yes it's for memory blocks containing class instances.  It basically
> tells the GC to call Object.~this() when collecting the block.

Just to add to Sean's statement, don't use this flag. It will crash the runtime, unless you have properly set up the classinfo pointer :) It does NOT work on structs, though I think there is a PR in the works to have structs destroyed from the GC.

-Steve

On Friday, 26 September 2014 at 18:03:40 UTC, Steven Schveighoffer wrote:
> On 9/25/14 6:03 PM, Sean Kelly wrote:
>> On Thursday, 25 September 2014 at 21:43:53 UTC, monarch_dodra wrote:
>>> On Thursday, 25 September 2014 at 20:58:29 UTC, Gary Willoughby wrote:
>>>> What does BlkAttr.FINALIZE do when used in the GC.malloc call?
>>>
>>> I have no idea. I think its for classes though, since we (currently)
>>> don't finalize structs anyways.
>>
>> Yes it's for memory blocks containing class instances.  It basically
>> tells the GC to call Object.~this() when collecting the block.
>
> Just to add to Sean's statement, don't use this flag. It will crash the runtime, unless you have properly set up the classinfo pointer :) It does NOT work on structs, though I think there is a PR in the works to have structs destroyed from the GC.
>
> -Steve

Kind of like APPENDABLE I guess, since it only works if you correctly setup the appendable data, and correctly slice at the correct offset, both of which are implementation defined.

On 9/26/14 3:24 PM, monarch_dodra wrote:
> On Friday, 26 September 2014 at 18:03:40 UTC, Steven Schveighoffer wrote:
>> On 9/25/14 6:03 PM, Sean Kelly wrote:
>>> On Thursday, 25 September 2014 at 21:43:53 UTC, monarch_dodra wrote:
>>>> On Thursday, 25 September 2014 at 20:58:29 UTC, Gary Willoughby wrote:
>>>>> What does BlkAttr.FINALIZE do when used in the GC.malloc call?
>>>>
>>>> I have no idea. I think its for classes though, since we (currently)
>>>> don't finalize structs anyways.
>>>
>>> Yes it's for memory blocks containing class instances.  It basically
>>> tells the GC to call Object.~this() when collecting the block.
>>
>> Just to add to Sean's statement, don't use this flag. It will crash
>> the runtime, unless you have properly set up the classinfo pointer :)
>> It does NOT work on structs, though I think there is a PR in the works
>> to have structs destroyed from the GC.
>
> Kind of like APPENDABLE I guess, since it only works if you correctly
> setup the appendable data, and correctly slice at the correct offset,
> both of which are implementation defined.

Well, kind of yes.

But the difference here is that if APPENDABLE is set, and you never actually append to an array in that block, then you are going to be fine. Even if you didn't set it up, it's most likely that you will not encounter a problem, because whatever is there is likely not the right size (and that simply results in a reallocation without touching anything). Even if you do manage to use appending on that block, and the data that happens to be where the allocated size is matches the current slice end, it will corrupt some data (or not, the smaller block sizes keep the append data at the end of the block). This could potentially crash, or it could do nothing.

If FINALIZE is set, when the GC collects the memory it WILL crash if you didn't set up some sort of mock classinfo.

I don't recommend using either, but FINALIZE is a much worse outcome IMO :)

-Steve