• asd <asd example.invalid> Jan 24 2010
• BCS <none anon.com> Jan 24 2010

asd <asd example.invalid> writes:

Andrei Alexandrescu Wrote:

 Why would having one chunk of code get checked for calls to the GC and 
 another not be any more complicated than mixing 
 malloc/free+add/removeRoot with normal GC? I'm beginning to wonder if 
 I'm calling for something different than other people are.
 
 What I'm thinking of would have zero effect on the generated code, the 
 only effect it would have is to cause an error when some code would 
 normally attempt to invoke the GC.


 It's much more complicated than that. What if a library returns an 
 object or an array to another library?
 
 Memory allocation strategy is a cross-cutting concern.


Optional GC is in Objective-C already and it works great! 

NB: In this context by GC I mean automatic mark-sweep garbage collection and
*not* refcouting. I'm ignoring here Cocoa's retain/release, because it's not
directly relevant.

There are 3 options:

-no-gc. Like pure C - explicit manual memory management is used exclusively.
Can't talk to GC code at all. (I don't recommend that for D).

-gc-supported. Program's memory is not garbage collected, but the program is
able to talk to GCd OS and libraries. You use manual memory management, but
compiler inserts write barriers and other stuff needed for seamless mixing with
GCd pointers. (I imagine that'd be D's -nogc).

-gc-only. Like D (-gc-supported code looks like C from D's perspective).

BCS <none anon.com> writes:

Hello asd,

 Optional GC is in Objective-C already and it works great!
 
 NB: In this context by GC I mean automatic mark-sweep garbage
 collection and *not* refcouting. I'm ignoring here Cocoa's
 retain/release, because it's not directly relevant.
 
 There are 3 options:
 
 -no-gc. Like pure C - explicit manual memory management is used
 exclusively. Can't talk to GC code at all. (I don't recommend that for
 D).


OK i can tell right there that you are not talking about what I'm talking 
about. The case I'm looking at would never stop one chunk of code from calling 
another.

 
 -gc-supported. Program's memory is not garbage collected, but the
 program is able to talk to GCd OS and libraries. You use manual memory
 management, but compiler inserts write barriers and other stuff needed
 for seamless mixing with GCd pointers. (I imagine that'd be D's
 -nogc).


Two bit's here are different than what I want: 1) the generated code wouldn't 
change, no write barriers nothing. And 2) there would be no difference at 
any level between GCd pointers and non GCd pointers. You could have the same 
pointer contain a reference to GCd data at one point and non GCd data at 
another and the compiler wouldn't even notice.

The reason I'm liking the idea is that it adds some useful abilities and 
*all* of the complexities that it entails already exist in D right now and 
have existed almost from the get go.

----   <IXOYE><