[LLVMdev] Garbage Collection Project

[Granville Barnett]

My first point, i.e. the custom allocator was in relation to the fact that
key data structures are allocated to private memory reserved for the runtime
so things tend to be laid out pretty well so the extra hop is not that
expensive. Just thought I'd make that clearer.

2009/6/18 Granville Barnett <granvillebarnett at googlemail.com>

> That is similar to the approach I used, although HLVM provides a pointer
>
> directly to the type, saving you a single hop.
>
>
> I'm not so sure that is a very good reason, depending on your
> implementation data structures that are fundamental to the type system of
> the virtual machine use custom allocators so the extra hop carries little to
> no expense.
>
> I would not have considered it had I not seen the damage done to F# by the
>
> CLR's typeless nulls. You want an unallocated constant for many different
>
> purposes in F#, such as representing the empty option type None, the empty
>
> list [] and maybe the unit value (). Unfortunately, using "null" means you
>
> don't get any type information and that means that none of those values
>> work
>
> correctly with anything requiring run-time type information such as generic
>
> printing, serialization and so on. The only alternative is to use an
>
> allocated value but the allocator and (concurrent) GC are very slow so that
>
> gives you the functionality you want but only at a grave cost in terms of
>
> performance.
>
>
>
>> Consequently, they chose to represent the empty list with an allocated
>> value
>
> (so [] prints correctly) but the option type uses null. Hence printf "%A"
>
> None prints "<null>". They've also used other tricks like having an
>> internal
>
> set representation that uses nulls but is wrapped in another representation
>
> that handles them correctly but only at the cost of an extra level of
>
> indirection.
>
>
> I know little to nothing about that so I find it hard to comment.
>
> The only alternative is to use an allocated value but the allocator and
>> (concurrent) GC are very slow so that
>
>  gives you the functionality you want but only at a grave cost in terms of
>>
>
>  performance
>
>
> I find this hard to believe, the GC used in CLR 2.0 is very fast. Surely
> its only downfall is that it uses a general mark-sweep generational
> algorithm so some languages (yours may be one of them) may suffer because of
> its generality. It sounds though as if you are using the fast allocator in
> the runtime anyway (which most objects do) which is incredibly fast as it
> does little to no checks before allocating space for the object.
>
> It may be that your solution cuts some of the time off the GC, but I really
> don't think that the GC in the second incarnation of the CLR is slow.
>
> 2009/6/18 Jon Harrop <jon at ffconsultancy.com>
>
>> On Thursday 18 June 2009 12:28:57 Cory Nelson wrote:
>>
>> > I'm also curious what language uses this and why it is useful :)
>>
>> HLVM is intended to be a general-purpose VM rather than a particular
>> language.
>>
>> > Also, things like this would make lock-free algorithms difficult or
>> > impossible.
>>
>> True. Perhaps that is a good argument for providing both kinds. However,
>> nulls
>> are certainly more common than concurrent data structures. :-)
>>
>> The entire source code for HLVM is available for free under a
>> commerce-friendly BSD license, BTW:
>>
>>  http://forge.ocamlcore.org/projects/hlvm/
>>
>> --
>> Dr Jon Harrop, Flying Frog Consultancy Ltd.
>> http://www.ffconsultancy.com/?e
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>
>
>
> --
> Granville Barnett
> http://gbarnett.github.com
>



-- 
Granville Barnett
http://gbarnett.github.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090618/01acc52b/attachment.html>