April 19, 2012
On Apr 18, 2012, at 4:02 PM, deadalnix wrote:

> Le 18/04/2012 20:53, Sean Kelly a écrit :
>> On Apr 18, 2012, at 2:56 AM, deadalnix wrote:
>>> 
>>> I think you certainly can remove all indirection. Additionally, I wonder why most of theses functions are extern(C).
>> 
>> So the GC implementation is opaque and the GC can therefore be chosen at link-time.  Similar to how the compiler runtime code hides behind a raft of extern© functions.
> 
> I know, but this is now impossible anyway because of the modification of TypeInfo anyway.

I'm not sure I follow.  Are you saying the change breaks having the GC behind extern C functions?  How?

April 19, 2012
Le 19/04/2012 02:08, Sean Kelly a écrit :
> On Apr 18, 2012, at 4:02 PM, deadalnix wrote:
>
>> Le 18/04/2012 20:53, Sean Kelly a écrit :
>>> On Apr 18, 2012, at 2:56 AM, deadalnix wrote:
>>>>
>>>> I think you certainly can remove all indirection. Additionally, I wonder why most of theses functions are extern(C).
>>>
>>> So the GC implementation is opaque and the GC can therefore be chosen at link-time.  Similar to how the compiler runtime code hides behind a raft of extern© functions.
>>
>> I know, but this is now impossible anyway because of the modification of TypeInfo anyway.
>
> I'm not sure I follow.  Are you saying the change breaks having the GC behind extern C functions?  How?
>

No it doesn't break GC behind C functions. It break the possibility of changing GC at link time, because different GC needs different data generated in TypeInfo.

So the indirection become useless.
April 19, 2012
On 4/18/2012 6:46 PM, Sean Kelly wrote:
> Leandro's GC (CDGC) is already set up to support precise scanning.  It's in the Druntime git repository, but lacks the features added to the Druntime GC compared to the Tango GC on which CDGC is based.  Still, it may be easier to update CDGC based on a diff between the Druntime and Tango GC than it would to add precise scanning to the GC Druntime currently uses.  Worth a look if anyone is interested anyway.
>

Or, failing that, I can look at it to get ideas about how to handle various annoying plumbing issues.  The plumbing issues (i.e. getting the GCInfo pointers from the allocation routines into the guts of the GC) are actually the hard part of this project.  Once the GC has the the GCInfo pointer, making it use that for precise scanning is trivial in that I've done it before and remember roughly how I did it.
April 19, 2012
On 04/19/2012 02:21 AM, deadalnix wrote:
> Le 19/04/2012 02:08, Sean Kelly a écrit :
>> On Apr 18, 2012, at 4:02 PM, deadalnix wrote:
>>
>>> Le 18/04/2012 20:53, Sean Kelly a écrit :
>>>> On Apr 18, 2012, at 2:56 AM, deadalnix wrote:
>>>>>
>>>>> I think you certainly can remove all indirection. Additionally, I
>>>>> wonder why most of theses functions are extern(C).
>>>>
>>>> So the GC implementation is opaque and the GC can therefore be
>>>> chosen at link-time. Similar to how the compiler runtime code hides
>>>> behind a raft of extern© functions.
>>>
>>> I know, but this is now impossible anyway because of the modification
>>> of TypeInfo anyway.
>>
>> I'm not sure I follow. Are you saying the change breaks having the GC
>> behind extern C functions? How?
>>
>
> No it doesn't break GC behind C functions. It break the possibility of
> changing GC at link time, because different GC needs different data
> generated in TypeInfo.
>
> So the indirection become useless.

The indirection is there for better shared library support.
1 2
Next ›   Last »