[LLVMdev] Garbage Collection Project

[Granville Barnett]

>
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090618/155b0703/attachment.html>