Precise GC

[Manu]

On 9 April 2012 21:20, deadalnix <deadalnix at gmail.com> wrote:

> Le 08/04/2012 14:02, Alex Rønne Petersen a écrit :
>
>  On 08-04-2012 11:42, Manu wrote:
>>
>>> On 8 April 2012 11:56, Timon Gehr <timon.gehr at gmx.ch
>>> <mailto:timon.gehr at gmx.ch>> wrote:
>>>
>>> On 04/08/2012 10:45 AM, Timon Gehr wrote:
>>>
>>> That actually sounds like a pretty awesome idea.
>>>
>>>
>>> Make sure that the compiler does not actually rely on the fact that
>>> the template generates a function. The design should include the
>>> possibility of just generating tables. It all should be completely
>>> transparent to the compiler, if that is possible.
>>>
>>>
>>> This sounds important to me. If it is also possible to do the work with
>>> generated tables, and not calling thousands of indirect functions in
>>> someone's implementation, it would be nice to reserve that possibility.
>>> Indirect function calls in hot loops make me very nervous for non-x86
>>> machines.
>>>
>>
>> Yes, I agree here. The last thing we need is a huge amount of
>> kinda-sorta-virtual function calls on ARM, MIPS, etc. It may work fine
>> on x86, but anywhere else, it's really not what you want in a GC.
>>
>>
> Nothing prevent the generated function to itself call other generated
> functions, when things are predictable. It avoid many indirect calls, and
> purely by lib, which is good (can be tuned for application/plateform).
>

Eh?
Not sure what you mean. The idea is the template would produce a
struct/table of data instead of being a pointer to a function, this way the
GC could work without calling anything. If the GC was written to assume GC
info in a particular format/structure, it could be written without any
calls.
I'm just saying to leave that as a possibility, and not REQUIRE an indirect
function call for every single allocation in the system. Some GC might be
able to make better use of that sort of setup.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20120409/c0a2e605/attachment.html>