www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - GC Sentinel

reply dsimcha <dsimcha yahoo.com> writes:
I'm looking at the GC implementation and starting my hacking.  I noticed that
the ends of blocks are already being used in some creative ways in the
sentinel version.  This looks like a debugging feature, though I don't
understand it completely.  Can one of the original implementors (Walter, Sean)
explain to me what the heck version(SENTINEL) in gcx.d does at a high level,
whether it conflicts with storing bit masks for precise heap scanning at the
ends of memory blocks, and whether we still even need it?
Oct 27 2009
next sibling parent reply Leandro Lucarella <llucax gmail.com> writes:
dsimcha, el 27 de octubre a las 23:41 me escribiste:

 I'm looking at the GC implementation and starting my hacking.  I noticed that
 the ends of blocks are already being used in some creative ways in the
 sentinel version.  This looks like a debugging feature, though I don't
 understand it completely.  Can one of the original implementors (Walter, Sean)
 explain to me what the heck version(SENTINEL) in gcx.d does at a high level,
 whether it conflicts with storing bit masks for precise heap scanning at the
 ends of memory blocks, and whether we still even need it?


I think that's used to check for memory corruption, by storing a known
patter before and after the actual object. Then, each time you can, you
check that the unused memory block is intact (meaning nobody wrote to an
invalid memory area).

I think it would be reasonble to keep the SENTINEL version as is (without
precise scanning) since it's a debugging feature. Of course it's nice to
have things unchanged when debugging, but the SENTINEL version is already
changing *a lot* about how objects are stored, so that nice property is
gone already.

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
Don't take life to seriously, you won't get out alive
Oct 27 2009
parent reply bearophile <bearophileHUGS lycos.com> writes:
Leandro Lucarella:


 I think that's used to check for memory corruption, by storing a known
 patter before and after the actual object. Then, each time you can, you
 check that the unused memory block is intact (meaning nobody wrote to an
 invalid memory area).


Such things can be quite useful. Do you need to compile Phobos again to do
that? If that's true then handier (compile-time?) solutions can be found.

Bye,
bearophile
Oct 28 2009
parent reply Leandro Lucarella <llucax gmail.com> writes:
bearophile, el 28 de octubre a las 03:52 me escribiste:

 Leandro Lucarella:
 

 I think that's used to check for memory corruption, by storing a known
 patter before and after the actual object. Then, each time you can, you
 check that the unused memory block is intact (meaning nobody wrote to an
 invalid memory area).


 
 Such things can be quite useful. Do you need to compile Phobos again to do
that?


Yes, it's added through a version statement.


 If that's true then handier (compile-time?) solutions can be found.


What do you mean?

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
Se ha dicho tanto que las apariencias engañan
Por supuesto que engañarán a quien sea tan vulgar como para creerlo
Oct 28 2009
parent reply bearophile <bearophileHUGS lycos.com> writes:
Leandro Lucarella:


 If that's true then handier (compile-time?) solutions can be found.


 
 What do you mean?


For example something run-time that doesn't work with a version(), like
something that can be added to the GC API. If this is seen as too much slow or
hard to do, then just the GC may be compiled, and used as separated dynamic
lib. With LDC other intermediate solutions may be possible. Think of this
problem from the point of view of someone that wants something handy. Debugging
data structures is something I do often.

Bye,
bearophile
Oct 28 2009
parent Leandro Lucarella <llucax gmail.com> writes:
bearophile, el 28 de octubre a las 13:19 me escribiste:

 Leandro Lucarella:
 

 If that's true then handier (compile-time?) solutions can be found.


 
 What do you mean?


 
 For example something run-time that doesn't work with a version(), like
 something that can be added to the GC API. If this is seen as too much
 slow or hard to do, then just the GC may be compiled, and used as
 separated dynamic lib. With LDC other intermediate solutions may be
 possible. Think of this problem from the point of view of someone that
 wants something handy. Debugging data structures is something I do
 often.


You can compile just the GC as a shared object (.so) in Linux and then
preload it to change just the GC implementation at "dynamic-link-time".
Just run:
$ LD_PRELOAD=mygc.so ./myprogram

If your GC with extra checks is compiled as a shared object in mygc.so.

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
Que barbaridad, este país se va cada ves más pa' tras, más pa' tras...
	-- Sidharta Kiwi
Oct 28 2009
prev sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Tue, 27 Oct 2009 19:41:24 -0400, dsimcha <dsimcha yahoo.com> wrote:


 I'm looking at the GC implementation and starting my hacking.  I noticed  
 that
 the ends of blocks are already being used in some creative ways in the
 sentinel version.  This looks like a debugging feature, though I don't
 understand it completely.  Can one of the original implementors (Walter,  
 Sean)
 explain to me what the heck version(SENTINEL) in gcx.d does at a high  
 level,
 whether it conflicts with storing bit masks for precise heap scanning at  
 the
 ends of memory blocks, and whether we still even need it?


IIRC, the sentinel byte is to prevent pointers from leaking into the next  
block.

For example, if you did:

byte[] x = new byte[16]; // GC allocates 16 byte block.
x = x[$..$];

Now, if there is no sentinel byte, the pointer in x points to the *next*  
memory block.

It is an interesting problem, there might be a better solution.

-Steve
Oct 29 2009