no-pointer areas

Alexander Panek a.panek at brainsware.org
Mon Oct 23 15:39:59 PDT 2006


I agree - a good idea.

Though, what about an explicit function that allocates memory for *data
only*? Theoretically, every kind of data and arrays without references
would then use this function, whereas every reference types use the
normal allocation methods.

Please correct me, if I understood something wrong there. :)

Alex

On Mon, 2006-10-23 at 16:59 -0500, Craig Black wrote:
> Overall a very, very good idea.
> However, why does the bytes allocated per element have to be the 
> qualification?
> This seems a bit convoluted to me. Why not just add a parameter with a 
> default value?
> 
> void *malloc(size_t size, int hasPtr = 1);
> 
> -Craig
> 
> "Thomas Kuehne" <thomas-dloop at kuehne.cn> wrote in message 
> news:slrnejqe00.7a5.thomas-dloop at birke.kuehne.cn...
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > With all that Phobos talk going on ... here is a small task:
> >
> > Implement GC areas that are guaranteed to contain no pointers
> > and are subsequently not searched for pointers during GC-collections.
> >
> > Basic Idea:
> >
> > void *malloc(size_t size);
> > void *calloc(size_t nmemb, size_t size);
> >
> > If less than sizeof(size_t) bytes are allocated per element, the
> > allocated memory is guaranteed to contain no pointers.
> >
> > There are three implementation levels:
> >
> > 1) Basic (dmd/src/phobos/internal/gc/gcx.d)
> >
> > Implement the basic idea(malloc, calloc, realloc, ...) and provide
> > the functions malloc_no_ptr, calloc_no_ptr, realloc_no_ptr.
> >
> > 2) Complete (dmd/src/phobos/internal/gc/gc.d)
> >
> > Update the code to take advantage of gcx.d's *_no_ptr.
> >
> > 3) Extended (compiler and dmd/src/phobos/internal/gc/gc.d)
> >
> > By adding compiler support, elements with sizes larger than or
> > equal to sizeof(size_t) that contain no pointers (e.g. the data
> > portion of float arrays and some structs)can use the no-ptr pools.
> >
> > As a result, the GC for applications using lots of data arrays should
> > be noticeably faster while other applications shouldn't experience any
> > measurable speed decreases.
> >
> > Thomas
> >
> >
> > -----BEGIN PGP SIGNATURE-----
> >
> > iD8DBQFFPTf+LK5blCcjpWoRAkZKAJ4r05W8qpr9ZwXMewKZdHLOoE23vQCbB8ll
> > Zu2I/IkMgSbW+CO81Ljk/jI=
> > =RvEo
> > -----END PGP SIGNATURE----- 
> 
> 




More information about the Digitalmars-d mailing list