www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - D vs. ISRs (interrupt service routines) or Which D language features implictly allocate memory?

reply Forest Ray <disto flying-guillotine.com> writes:
One of D's intended uses is systems level programming.  These tasks include
implementing ISR (interrupt service routines).  Generally speaking it is a very
bad idea to allocate memory within an ISR, unless your memory system is
reentrant.  Many memory managers, especially in the embedded environment, are
not reentrant.  What language features of D implicitly allocate or resize
memory?  I assume dynamic arrays, associative arrays, splicing, and
concatenation will, but what else?  Obviously "new" allocates memory, but that
is an explicit request by the programmer, not an implicit request as a side
effect of a D language feature.  It would be very useful to have the ability to
tag a scope of code as "native" or "pure" or "some_better_keyword" so the D
compiler would issue an error for any expressions or statements within that
scope that implicitly allocate/resized memory.  Thoughts, comments?

Forest
May 04 2007
next sibling parent reply Gregor Richards <Richards codu.org> writes:
Forest Ray wrote:

 One of D's intended uses is systems level programming.  These tasks include
implementing ISR (interrupt service routines).  Generally speaking it is a very
bad idea to allocate memory within an ISR, unless your memory system is
reentrant.  Many memory managers, especially in the embedded environment, are
not reentrant.  What language features of D implicitly allocate or resize
memory?  I assume dynamic arrays, associative arrays, splicing, and
concatenation will, but what else?  Obviously "new" allocates memory, but that
is an explicit request by the programmer, not an implicit request as a side
effect of a D language feature.  It would be very useful to have the ability to
tag a scope of code as "native" or "pure" or "some_better_keyword" so the D
compiler would issue an error for any expressions or statements within that
scope that implicitly allocate/resized memory.  Thoughts, comments?
 
 Forest


'new', concatenation and adding elements to associative arrays allocate 
memory. Those are the only language features that do (AFAIK)

Of the ones you assumed did, notably splicing does not.

  - Gregor Richards
May 04 2007
parent reply "Unknown W. Brackets" <unknown simplemachines.org> writes:
Well, slicing will not.  Splicing will.  Sorry to be pedantic.

-[Unknown]



 Forest Ray wrote:

 One of D's intended uses is systems level programming.  These tasks 
 include implementing ISR (interrupt service routines).  Generally 
 speaking it is a very bad idea to allocate memory within an ISR, 
 unless your memory system is reentrant.  Many memory managers, 
 especially in the embedded environment, are not reentrant.  What 
 language features of D implicitly allocate or resize memory?  I assume 
 dynamic arrays, associative arrays, splicing, and concatenation will, 
 but what else?  Obviously "new" allocates memory, but that is an 
 explicit request by the programmer, not an implicit request as a side 
 effect of a D language feature.  It would be very useful to have the 
 ability to tag a scope of code as "native" or "pure" or 
 "some_better_keyword" so the D compiler would issue an error for any 
 expressions or statements within that scope that implicitly 
 allocate/resized memory.  Thoughts, comments?

 Forest


 
 'new', concatenation and adding elements to associative arrays allocate 
 memory. Those are the only language features that do (AFAIK)
 
 Of the ones you assumed did, notably splicing does not.
 
  - Gregor Richards
May 05 2007
parent Gregor Richards <Richards codu.org> writes:
Unknown W. Brackets wrote:

 Well, slicing will not.  Splicing will.  Sorry to be pedantic.
 
 -[Unknown]
 


I stand corrected.

Nae, defeated.

:'(

  - Gregor Richards

PS: For the confused: Slicing is this: someArray[1..3]. Splicing would 
be, for example: someArray = someArray[0..1] ~ someOtherArray ~ 
someArray[1..$]
May 05 2007
prev sibling next sibling parent Alexander Panek <alexander.panek brainsware.org> writes:
On Sat, 05 May 2007 02:11:08 -0400
Forest Ray <disto flying-guillotine.com> wrote:


 One of D's intended uses is systems level programming.  These tasks
 include implementing ISR (interrupt service routines).  Generally
 speaking it is a very bad idea to allocate memory within an ISR,
 unless your memory system is reentrant.  Many memory managers,
 especially in the embedded environment, are not reentrant.  What
 language features of D implicitly allocate or resize memory?  I
 assume dynamic arrays, associative arrays, splicing, and
 concatenation will, but what else?  Obviously "new" allocates memory,
 but that is an explicit request by the programmer, not an implicit
 request as a side effect of a D language feature.  It would be very
 useful to have the ability to tag a scope of code as "native" or
 "pure" or "some_better_keyword" so the D compiler would issue an
 error for any expressions or statements within that scope that
 implicitly allocate/resized memory.  Thoughts, comments?
 
 Forest


You can use any language features that do not require dynamic memory
allocation, as you said already. 

The things requiring the GC are:
 - dynamic arrays, associative arrays
 - array slicing when you .dup the slice (I think, at least. If you
don't duplicate the slice, it'll only be a from-to-reference to the
original array)
 - array concatination
 - dynamic class instantiation (new)
 - debug features: always use the -release or -frelease switch, as
there are debug functions added you would have to provide yourself if
you don't link with a runtime library. Also, most of 'em require a GC,
IIRC.

Unfortunately some internal stuffies use these kind of features, too,
at times, which means that you have to hack together either a memory
manager + GC that is available at compile time, or try to work around
that by providing functions which are only statically using memory.

Splicing seems to be concatination? If so, this also requires a GC.
Maybe this can be worked around with hacking the internals, too, but
that's not recommended.

Kind regards,
Alex
May 05 2007
prev sibling next sibling parent janderson <askme me.com> writes:
 It would be very useful to have the ability to tag a scope of
 code as "native" or "pure" or "some_better_keyword" so the D compiler
 would issue an error for any expressions or statements within that scope
 that implicitly allocate/resized memory. Thoughts, comments?


I agree, that would be nice.  I think it maybe a bit difficult to do it 
statically with things like functions that are in other libraries.  I 
don't think that it's impossible though.

I've used a run-time variant in the past to speed up rendering (it would 
assert if any memory was allocated during the alloted time.  Perhaps 
tango could provide a debugging option to assert when allocations are 
made, or something like that.

-Joel
May 05 2007
prev sibling parent reply Sean Kelly <sean f4.ca> writes:
As others have said, string concatenation (via ~), the .dup property, 
insertions into AAs (and possibly removals as well), and 'new' calls. 
Those are the only language features I can think of that allocate.  As 
for library calls, Tango almost never allocates internally.  This has 
actually been a source of contention for some, but I think the benefit 
is worthwhile.


Sean
May 05 2007
parent reply Thomas Kuehne <thomas-dloop kuehne.cn> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Sean Kelly schrieb am 2007-05-05:

 As others have said, string concatenation (via ~), the .dup property, 
 insertions into AAs (and possibly removals as well), and 'new' calls. 
 Those are the only language features I can think of that allocate.


Depending on the libary implementation
"foreach(char c; dchar[])" and .sort might heap allocate too.

Thomas

-----BEGIN PGP SIGNATURE-----

iD8DBQFGPRV1LK5blCcjpWoRAjspAJ42LxmQu5sNLU8t/IStgm261U7PsACfdDyJ
klJ8ep2FQsLUfleNxptP9M8=
=ZKOd
-----END PGP SIGNATURE-----
May 05 2007
parent Sean Kelly <sean f4.ca> writes:
Thomas Kuehne wrote:

 -----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
 Sean Kelly schrieb am 2007-05-05:

 As others have said, string concatenation (via ~), the .dup property, 
 insertions into AAs (and possibly removals as well), and 'new' calls. 
 Those are the only language features I can think of that allocate.


 
 Depending on the libary implementation
 "foreach(char c; dchar[])" and .sort might heap allocate too.


Good point.  Though neither of these allocate in Phobos/GPhobos (for the 
record).


Sean
May 06 2007