What's the go with the GC these days?

Steven Schveighoffer schveiguy at gmail.com
Mon Jan 7 20:28:26 UTC 2019


On 1/7/19 2:52 PM, H. S. Teoh wrote:
> On Mon, Jan 07, 2019 at 02:33:56PM -0500, Steven Schveighoffer via Digitalmars-d wrote:
>> On 1/7/19 1:59 PM, Neia Neutuladh wrote:
> [...]
>>> Like I said before, casting to shared would have to invoke a runtime
>>> function. That's a runtime change and compiler change, but I don't
>>> think the spec says anything about whether any cast might invoke a
>>> runtime function.
>>>
>>
>> This is doable. Casting to/from shared should be a rare thing, and
>> probably fine to hook.
>>
>> However, the problem is more (for me) that the memory would have to be
>> copied, as the memory is currently in one pool and has to be moved to
>> another pool.
> [...]
> 
> I think what Neia has in mind, which he mentioned in another post, is to
> have the druntime function simply pin the object, whichever pool it
> belongs to.  The idea being to tell the respective thread-local GC "this
> object might be referenced by another thread, do not collect or move".

Imagine I have a shared piece of data, then I cast it to thread local. 
Now, it is able to point at thread local data, but it lives in the 
shared heap. Pinned or not, this means a local collection must scan the 
shared heap to see if it can collect any thread-local data. This defeats 
the purpose of having a thread-local heap in the first place (which you 
should be able to scan without having to stop-the-world).

-Steve


More information about the Digitalmars-d mailing list