www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Garbage collection book

reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
http://www.amazon.com/Garbage-Collection-Handbook-Management-Algorithms/dp/1420082795/ref=sr_1_1?s=books&ie=UTF8&qid=1317790242&sr=1-1

I heard it's good.

Andrei
Oct 04 2011
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 10/4/2011 11:06 PM, Andrei Alexandrescu wrote:

 http://www.amazon.com/Garbage-Collection-Handbook-Management-Algorithms/dp/1420082795/ref=sr_1_1?s=books&ie=UTF8&qid=1317790242&sr=1-1

 I heard it's good.



I have the older version:


http://www.amazon.com/exec/obidos/ASIN/0471941484/classicempire

Yes, it's good.
Oct 04 2011
next sibling parent reply Sean Kelly <sean invisibleduck.org> writes:
On Oct 4, 2011, at 11:14 PM, Walter Bright wrote:


 On 10/4/2011 11:06 PM, Andrei Alexandrescu wrote:

 =




http://www.amazon.com/Garbage-Collection-Handbook-Management-Algorithms/dp=
/1420082795/ref=3Dsr_1_1?s=3Dbooks&ie=3DUTF8&qid=3D1317790242&sr=3D1-1

=20
 I heard it's good.


=20
 I have the older version:
=20
 http://www.amazon.com/exec/obidos/ASIN/0471941484/classicempire
=20
 Yes, it's good.


The books have different authors.  I don't suppose someone has both and =
can comment on the differences?  I have the older version as well, but =
wouldn't mind picking up this new one if it brings enough new stuff to =
the table.=
Oct 05 2011
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 10/5/2011 11:46 AM, Sean Kelly wrote:

 On Oct 4, 2011, at 11:14 PM, Walter Bright wrote:


 On 10/4/2011 11:06 PM, Andrei Alexandrescu wrote:

 http://www.amazon.com/Garbage-Collection-Handbook-Management-Algorithms/dp/1420082795/ref=sr_1_1?s=books&ie=UTF8&qid=1317790242&sr=1-1






I heard it's good.

 I have the older version:

 http://www.amazon.com/exec/obidos/ASIN/0471941484/classicempire

 Yes, it's good.


 The books have different authors.


Richard Jones is listed first for both, the follow on authors are different.


 I don't suppose someone has both and can
 comment on the differences?  I have the older version as well, but wouldn't
 mind picking up this new one if it brings enough new stuff to the table.


It's more like one cannot afford not to if one is spending many hours dealing 
with GC's, even if the improvements are minor.
Oct 05 2011
parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Wednesday, October 05, 2011 12:21:53 Walter Bright wrote:

 On 10/5/2011 11:46 AM, Sean Kelly wrote:

 On Oct 4, 2011, at 11:14 PM, Walter Bright wrote:

 On 10/4/2011 11:06 PM, Andrei Alexandrescu wrote:

 http://www.amazon.com/Garbage-Collection-Handbook-Management-Algorit
 hms/dp/1420082795/ref=sr_1_1?s=books&ie=UTF8&qid=1317790242&sr=1-1






 I heard it's good.
 

 I have the older version:
 
 http://www.amazon.com/exec/obidos/ASIN/0471941484/classicempire
 
 Yes, it's good.


 
 The books have different authors.


 
 Richard Jones is listed first for both, the follow on authors are different.

 I don't suppose someone has both and can
 comment on the differences?  I have the older version as well, but
 wouldn't mind picking up this new one if it brings enough new stuff to
 the table.


 It's more like one cannot afford not to if one is spending many hours
 dealing with GC's, even if the improvements are minor.


And D's GC can use all of the help that it can get.

- Jonathan M Davis
Oct 05 2011
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 10/5/2011 12:31 PM, Jonathan M Davis wrote:

 And D's GC can use all of the help that it can get.


It's not that bad. For one thing, it's reliable.
Oct 05 2011
next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Wednesday, October 05, 2011 13:39 Walter Bright wrote:

 On 10/5/2011 12:31 PM, Jonathan M Davis wrote:

 And D's GC can use all of the help that it can get.


 
 It's not that bad. For one thing, it's reliable.


Regardless of how good or bad it is, it needs all the help that it can get. 
The GC is critical to performance, and every bit of performance that we can 
eke out of it is valuable.

- Jonathan M Davis
Oct 05 2011
prev sibling parent reply "Martin Nowak" <dawg dawgfoto.de> writes:
On Thu, 06 Oct 2011 00:08:08 +0200, Jonathan M Davis <jmdavisProg gmx.com>  
wrote:


 On Wednesday, October 05, 2011 13:39 Walter Bright wrote:

 On 10/5/2011 12:31 PM, Jonathan M Davis wrote:

 And D's GC can use all of the help that it can get.


 It's not that bad. For one thing, it's reliable.


 Regardless of how good or bad it is, it needs all the help that it can  
 get.
 The GC is critical to performance, and every bit of performance that we  
 can
 eke out of it is valuable.

 - Jonathan M Davis


For a real approach to GC.
http://www.artima.com/lejava/articles/azul_pauseless_gc.html
http://www.managedruntime.org/
You probably have to subtract some marketing promises.

More realistically, are there any rough ideas how to support moving  
collectors?
Oct 06 2011
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 10/6/2011 3:28 PM, Martin Nowak wrote:

 More realistically, are there any rough ideas how to support moving collectors?


The idea I used long ago was to move objects for which the only references to 
them are unambiguous, which means those unambiguous refs can be updated to
point 
to the new location.

Ambiguous refs (i.e. might or might not be an actual pointer) had the effect of 
"pinning" the object so it couldn't be moved.

Doing a moving collector requires type info emitted by the compiler that gives 
the offsets of the pointers embedded in every allocated type.
Oct 06 2011
parent reply "Martin Nowak" <dawg dawgfoto.de> writes:
On Fri, 07 Oct 2011 00:44:10 +0200, Walter Bright  
<newshound2 digitalmars.com> wrote:


 On 10/6/2011 3:28 PM, Martin Nowak wrote:

 More realistically, are there any rough ideas how to support moving  
 collectors?


 The idea I used long ago was to move objects for which the only  
 references to them are unambiguous, which means those unambiguous refs  
 can be updated to point to the new location.

 Ambiguous refs (i.e. might or might not be an actual pointer) had the  
 effect of "pinning" the object so it couldn't be moved.

 Doing a moving collector requires type info emitted by the compiler that  
 gives the offsets of the pointers embedded in every allocated type.


Which isn't wanted because of the binary size, right?
As this is also a requirement for precise scanning and runtime type  
information
couldn't a heavily compressed format be found for it.
Something not so weird as DWARF but using a mixture of source encoding
and tables to lower redundancy.
Oct 06 2011
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 10/6/2011 4:48 PM, Martin Nowak wrote:

 Which isn't wanted because of the binary size, right?


It is a substantial size problem. There's also a performance issue - the gc has 
to read those tables and iterate in a non-trivial way. For example, if a struct 
has an embedded static array of pointers in it, you'll need a way to embed a 
loop in the gc scanner.



 As this is also a requirement for precise scanning and runtime type information
 couldn't a heavily compressed format be found for it.
 Something not so weird as DWARF but using a mixture of source encoding
 and tables to lower redundancy.


Compression has its own problem - performance.
Oct 06 2011
next sibling parent "Martin Nowak" <dawg dawgfoto.de> writes:
On Fri, 07 Oct 2011 03:32:13 +0200, Walter Bright  
<newshound2 digitalmars.com> wrote:


 On 10/6/2011 4:48 PM, Martin Nowak wrote:

 Which isn't wanted because of the binary size, right?


 It is a substantial size problem. There's also a performance issue - the  
 gc has to read those tables and iterate in a non-trivial way. For  
 example, if a struct has an embedded static array of pointers in it,  
 you'll need a way to embed a loop in the gc scanner.


Sounds like an interpreter :), with the garbage collector interpreting  
type infos as bytecode.


 As this is also a requirement for precise scanning and runtime type  
 information
 couldn't a heavily compressed format be found for it.
 Something not so weird as DWARF but using a mixture of source encoding
 and tables to lower redundancy.


 Compression has its own problem - performance.
Oct 06 2011
prev sibling parent reply Caligo <iteronvexor gmail.com> writes:
I'm just wondering, does Glasgow Haskell Compile (GHC) have the most
advanced GC?  I remember reading where it said that GHC is like 10 years
ahead of all the other compilers, or something to that effect.
Oct 07 2011
parent reply bearophile <bearophileHUGS lycos.com> writes:
Caligo:


 I'm just wondering, does Glasgow Haskell Compile (GHC) have the most advanced
GC?
 I remember reading where it said that GHC is like 10 years ahead of all the
other compilers,
 or something to that effect.


If you want to find an advanced GC that is years ahead of all other ones, take
a look at the garbage collectors inside the Oracle JavaVM.
Haskell is almost purely functional, and its GC has to do a work different from
a Java or D GC. A D GC has to do a work different from a Java GC, and more

is a larger percentage of pinned down data). Even if it is not perfectly fit, I

with some tuning.
Unfortunately, despite being both Mono and D open source projects, there is a
furiously intense "not invented here" syndrome in the whole planetary effort of
Open Source. Every open source language seems to implement its own GC If you
look at this situation from 15000 feet above it looks like an incredibly dumb
situation. In practice once you get closer, you see incompatible open source
licenses, and differences in the language semantics that make GC transplants
hard or not so useful. Devil is in the details.

Bye,
bearophile
Oct 07 2011
parent reply =?UTF-8?Q?Tr=E1=BB=8Bnh_Quang_Anh?= <codemasta92 gmail.com> writes:
IMO it's hard to apply a single GC design to many different languages, as
each language has it's distinct properties that require the GC to work in s
different manner.

2011/10/8 bearophile <bearophileHUGS lycos.com>


 Caligo:


 I'm just wondering, does Glasgow Haskell Compile (GHC) have the most


 advanced GC?

 I remember reading where it said that GHC is like 10 years ahead of all


 the other compilers,

 or something to that effect.


 If you want to find an advanced GC that is years ahead of all other ones,
 take a look at the garbage collectors inside the Oracle JavaVM.
 Haskell is almost purely functional, and its GC has to do a work different
 from a Java or D GC. A D GC has to do a work different from a Java GC, and

 there is a larger percentage of pinned down data). Even if it is not

 enough for D, maybe with some tuning.
 Unfortunately, despite being both Mono and D open source projects, there is
 a furiously intense "not invented here" syndrome in the whole planetary
 effort of Open Source. Every open source language seems to implement its own
 GC If you look at this situation from 15000 feet above it looks like an
 incredibly dumb situation. In practice once you get closer, you see
 incompatible open source licenses, and differences in the language semantics
 that make GC transplants hard or not so useful. Devil is in the details.

 Bye,
 bearophile
Oct 08 2011
parent Johannes Totz <johannes jo-t.de> writes:
On 08/10/2011 08:45, Trịnh Quang Anh wrote:

 IMO it's hard to apply a single GC design to many different languages, as
 each language has it's distinct properties that require the GC to work in s
 different manner.


Out of curiosity, did anybody try to stick a recent (conservative)
bdwgc* in and see how D's gc compares to it?
It allows to embed some basic type-info regarding what should be
considered pointer or not**.

*:  https://github.com/ivmai/bdwgc/
**: https://github.com/ivmai/bdwgc/blob/master/include/gc_typed.h


 
 2011/10/8 bearophile <bearophileHUGS lycos.com>
 

 Caligo:


 I'm just wondering, does Glasgow Haskell Compile (GHC) have the most


 advanced GC?

 I remember reading where it said that GHC is like 10 years ahead of all


 the other compilers,

 or something to that effect.


 If you want to find an advanced GC that is years ahead of all other ones,
 take a look at the garbage collectors inside the Oracle JavaVM.
 Haskell is almost purely functional, and its GC has to do a work different
 from a Java or D GC. A D GC has to do a work different from a Java GC, and

 there is a larger percentage of pinned down data). Even if it is not

 enough for D, maybe with some tuning.
 Unfortunately, despite being both Mono and D open source projects, there is
 a furiously intense "not invented here" syndrome in the whole planetary
 effort of Open Source. Every open source language seems to implement its own
 GC If you look at this situation from 15000 feet above it looks like an
 incredibly dumb situation. In practice once you get closer, you see
 incompatible open source licenses, and differences in the language semantics
 that make GC transplants hard or not so useful. Devil is in the details.

 Bye,
 bearophile
Oct 10 2011
prev sibling parent d coder <dlang.coder gmail.com> writes:
 The books have different authors.  I don't suppose someone has both and can
 comment on the differences?  I have the older version as well, but wouldn't
 mind picking up this new one if it brings enough new stuff to the table.



Perhaps you can take a look at the ToC here
http://www.amazon.co.uk/gp/product/toc/1420082795/ref=dp_toc?ie=UTF8&n=266239
Oct 10 2011
prev sibling parent "Masahiro Nakagawa" <repeatedly gmail.com> writes:
On Wed, 05 Oct 2011 15:06:35 +0900, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:


 http://www.amazon.com/Garbage-Collection-Handbook-Management-Algorithms/dp/1420082795/ref=sr_1_1?s=books&ie=UTF8&qid=1317790242&sr=1-1

 I heard it's good.


Narihiro Nakamura (a.k.a author of japanese GC book) said "This is great  
book!".

I want to read this book if time permits.


Masahiro
Oct 05 2011