Implementing read/write barriers in LDC

[Leandro Lucarella]

Hello. I'm starting to experiment with LDC to improve the garbage
collection as part of my grade thesis[1].

I'd like to implement read/write barriers as suggested[2] by Frank
Benoit
a couple of years ago :)

Here is a fragment of the idea:

> Read/Write Barrier:
> Some GC need to run some code each time a reference is overwritten
> and/or if a reference is read.
> A flexible way can be, to give the compiler an function, to use for read
> and write accesses. These functions should always be inlined and
> optimized. e.g.:
> ___ref_assign( void * trg, void * src ){ trg = src; }
> void* ___ref_read( void * src ){ return src; }


I'm new to LDC and LLVM, so I appreciate any pointers you can give me
on how
this can be accomplished in LDC (if it's possible) and which parts of
LDC
should I see/modify, etc.

For now, my idea is to use this read/write barriers to collect data
about
how many pointers reads/writes are in a program and eventually
implement
a reference counting GC (probably toy-ish but still).


Thanks a lot!


[1] http://proj.llucax.com.ar/blog/dgc/blog/post/4a50b32b
[2] http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=35426

--
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
Run, rabbit run.
Dig that hole, forget the sun,
And when at last the work is done
Don't sit down it's time to dig another one.

[Christian Kamm]

Hey Leandro,

> I'm new to LDC and LLVM, so I appreciate any pointers you can give me
> on how this can be accomplished in LDC (if it's possible) and which parts of
> LDC should I see/modify, etc.

Currently we don't differentiate between stack stores and GC-memory stores. I
guess you'd want to split DtoLoad and DtoStore in gen/tollvm.cpp into two
pairs of functions and then replace all existing uses by one or the other. I'm
pretty sure there are still places where we create loads and stores manually,
though. If you haven't looked at it already, I'd also like to point you to our
short but useful 'hacking guide'
( http://www.dsource.org/projects/ldc/wiki/Hacking ).

> For now, my idea is to use this read/write barriers to collect data
> about how many pointers reads/writes are in a program and eventually
> implement a reference counting GC (probably toy-ish but still).

Sounds interesting! If you do any changes that might be generally useful (like
the aforementioned split), make sure to send in the patch!

Also, feel free to ask questions on IRC - you'll probably get quicker answers.

Best regards
Christian

[Leandro Lucarella]

On 2 abr, 13:03, Christian Kamm <k...@incasoftware.de> wrote:
> Hey Leandro,
>
> > I'm new to LDC and LLVM, so I appreciate any pointers you can give me
> > on how this can be accomplished in LDC (if it's possible) and which parts of
> > LDC should I see/modify, etc.
>
> Currently we don't differentiate between stack stores and GC-memory stores. I
> guess you'd want to split DtoLoad and DtoStore in gen/tollvm.cpp into two
> pairs of functions and then replace all existing uses by one or the other. I'm
> pretty sure there are still places where we create loads and stores manually,
> though.

Ok, it looks like a little more complicated than I thought =)

> If you haven't looked at it already, I'd also like to point you to our
> short but useful 'hacking guide'
> (http://www.dsource.org/projects/ldc/wiki/Hacking).

I 've seen it, thanks.

> > For now, my idea is to use this read/write barriers to collect data
> > about how many pointers reads/writes are in a program and eventually
> > implement a reference counting GC (probably toy-ish but still).
>
> Sounds interesting! If you do any changes that might be generally useful (like
> the aforementioned split), make sure to send in the patch!

Sure!

> Also, feel free to ask questions on IRC - you'll probably get quicker answers.

Thanks. I prefer to ask questions in the ML when I'm not in a hurry
because they get archived and searchable, so it might be useful for
future reference to have the answers here =)

But thanks for the pointer.

BTW, I don't know anything about LLVM, do you recommend to dive into
the LDC code directly and then find help on LLVM for things I don't
understand or it would be better to learn some LLVM first? Links to
recommended readings are welcome.

Thanks a lot.

[Tomas Lindquist Olsen]

I think it makes sense to look into LLVM a bit first.

http://llvm.org/docs/

has a lot of different links describing different parts of LLVM.
A good place to start is with the IR language reference:

http://llvm.org/docs/LangRef.html

This should give a good idea of how LDC might generate code for
different D constructs.

Next, I think for a project like this it makes sense to use LLVM's
framework for garbage collection:

http://llvm.org/docs/GarbageCollection.html

Getting all the load/store codegen updated is probably going to be a
bit painful, since unfortunately this kind of thing hasn't really been
considered across the codegen code.

grepping for DtoLoad, DtoStore, CreateLoad, CreateStore, LoadInst,
StoreInst should find all instances though.

> Thanks a lot.

Good luck and let us know if there's anything :)

-Tomas

[Leandro Lucarella]

On 2 abr, 18:37, Tomas Lindquist Olsen <tomas.l.ol...@gmail.com>
wrote:

> I think it makes sense to look into LLVM a bit first.
>
> http://llvm.org/docs/
>
> has a lot of different links describing different parts of LLVM.
> A good place to start is with the IR language reference:
>
> http://llvm.org/docs/LangRef.html
>
> This should give a good idea of how LDC might generate code for
> different D constructs.

Thanks for the links!

> Next, I think for a project like this it makes sense to use LLVM's
> framework for garbage collection:
>
> http://llvm.org/docs/GarbageCollection.html

I had a look at it some time ago, but I prefer to target some LLVM-
independent GC, at least at first.

> Getting all the load/store codegen updated is probably going to be a
> bit painful, since unfortunately this kind of thing hasn't really been
> considered across the codegen code.
>
> grepping for DtoLoad, DtoStore, CreateLoad, CreateStore, LoadInst,
> StoreInst should find all instances though.

Thanks, good to know.

> > Thanks a lot.
>
> Good luck and let us know if there's anything :)

Thanks. This is a little low priority for me now (since is not a
trivial task), but I'll keep you updated if I dive into it.