November 20, 2006
Miles wrote:
> But looking at the problem, being someone from algorithms, I think it is
> possible and feasible to implement array slicing using malloc
> allocation. An extra field will be needed anyway since you need
> reference count for the array, just put it along with the beginning of
> the array and only a single pointer will be needed for both reference
> count and beginning of array.
> 
> Cyclic references is a problem only when using GC. If the programmer
> wants to use a malloc-based allocation, he knows he should handle cyclic
> references himself. Not a problem.

Both of these comments indicate an assumption that the GC will be using a reference count anyhow, so you may as well explicitly manage a reference count where necessary.

But that's not the case for D's GC. It doesn't use reference counts at all. If I remember correctly, the D garbage collector uses a mark-and-sweep collector. These kinds of collectors are generally more performant and more deterministic than reference-counting collectors. And they have no problem with cycling references.

--benji
November 20, 2006
Miles wrote:
> 
> As for synchronization, I think this is more a problem when GC is used
> than when it is not. Malloc-based allocation needs synchronization, of
> course, but I think GC-based does also.

Theoretically, neither require synchronization so long as they maintain per-thread heaps.  The obvious consequence being a greater amount of unused memory in the application.  GC collection obviously requires synchronization however.

> Deallocation is very atomic and
> can be implemented without synchronization and still be thread-safe.
> GC-based, OTOH, needs to freeze the whole application (not just the
> threads doing allocation) in order to collect.

Yup.  There are GC designs which do not require this, but they don't seem terribly compatible with D.  Instead, the focus is more on minimizing the time that any "stop the world" phase requires.  There are a bunch of different GC designs and refinements to accomplish this, and I expect we will see more of them as D matures.


Sean
November 20, 2006
Don Clugston wrote:
> Walter Bright wrote:
>> Boris Kolar wrote:
>>> I don't understand why a good RIAA is not already a part of D. C++ has it, so
>>> it obviously can be done. The new 'scoped' keyword is insufficient for me,
>>> because I'd like to make all my classes scoped. I can usually develop
>>> 99% of my C++ code without a single 'new' or 'malloc'. Most of my classes
>>> are small (average ~2 fields and ~4 methods) and only used locally, so I'm
>>> really angry when I think about negative performance impact they will have
>>> in D simply because a decent RIAA is missing.
>>
>> Have you considered using structs instead of classes? They are allocated on the stack.
> 
> Can you do RAII with them?

No. But most RAII usage is for managing memory, and Boris didn't say why he needed RAII for the stack allocated objects.
November 20, 2006
Miles wrote:
>> The poster who claimed that conservative gc is somehow incompatible with
>> cryptographic software is misinformed. Even if he were correct, the
>> cryptographic buffers could be allocated with malloc() and would then
>> have no effect whatsoever on the gc.
> 
> Using two allocation methods in the same process address space looks
> really bad, not to say hackish.

I strongly disagree. A complex application has different needs for different structures in the program. Just like OOP isn't the solution for every programming problem, one allocation method isn't either.


> And you don't need cryptographic buffers
> or multimedia data, a single int variable is enough to hold a large
> block of unused data in memory, and the larger the block is, the easier
> it is for this to happen. Even if it was 1/2^32 of chances of this
> happening, it still will happen.

In real, long lived gc applications I've been involved with, this is much more of a theoretical problem than an actual one. I found it surprising how little of a problem it actually was in practice.

The reason for this is not so obvious. It isn't "random" with a 1/2^32 probability, that integers (and other types) contain random values with an even distribution. They don't. The overwhelming majority of ints have values that are between -100 and +100. The most common value is 0. Those values are nowhere near where the gc pools are located.
November 20, 2006
Walter Bright wrote:
> Bill Baxter wrote:
> 
>> Indeed.  The people who really need to be GC-free are a tiny minority. Wasting a lot of manpower creating a non-GC library just people who don't want to convert from C++ will have one less justification for not using D sees like a huge waste of effort to me.
> 
> I translated Empire from C to D. It worked fine, and did not use the gc at all. It didn't require a new runtime library.

Cool! And I guess I'm not the only one who'd never have guessed.

Shouldn't this get a whole lot more exposure than now?

This ought to be the first thing one thinks of anytime somebody takes up the GC "issue".
November 20, 2006
Walter Bright wrote:
> In real, long lived gc applications I've been involved with, this is much more of a theoretical problem than an actual one. I found it surprising how little of a problem it actually was in practice.

If you found it surprising, then we could consider it legitimate and expected that "the C++ crowd" has a hard time believing this.

Maybe we should be more vociferous about it. The quote from Don is a good first step.
November 20, 2006
Sean Kelly wrote:
> Julio César Carrascal Urquijo wrote:
>>
>> Is there a way to tell the garbage collector "don't look for references here" without using malloc and friends?
> 
> Not in its current form, but the modifications to allow this are fairly simple.  The compiler can even set the same flag for dynamic arrays containing elements smaller than pointer size.
> 
> 
> Sean

So as long as I use byte[] or short[] this would be possible in a future implementation of the GC, right? Well that's better, at least for cryptographic data.

Still sound data is often represented as int/long samples witch could pose problems on 32bit or 64bit platforms.

Anyway we still need a better implementation of the GC to address this concerns.
November 20, 2006
Bill Baxter wrote:
> This is the kind of comment that scares me.
> How does one reconcile this with Walter's comment "The GC has been pretty heavily tested. It's 6 years old, and it's stood up extremely well."
>   --(digitalmars.com digitalmars.D:43916)
> 
> --bb

Even if a piece of software is reliable and has been heavily tested doesn't mean it can't be improved. The current GC has it's shortcomings and that has been acknowledged by Walter.

That doesn't mean it is unusable (On the contrary), just that under certain circumstances you should use other implementations and that's why a pluggable architecture is needed for garbage collection in the language.
November 20, 2006
Julio César Carrascal Urquijo wrote:
> Bill Baxter wrote:
>> This is the kind of comment that scares me.
>> How does one reconcile this with Walter's comment "The GC has been pretty heavily tested. It's 6 years old, and it's stood up extremely well."
>>   --(digitalmars.com digitalmars.D:43916)
> 
> Even if a piece of software is reliable and has been heavily tested doesn't mean it can't be improved. The current GC has it's shortcomings and that has been acknowledged by Walter.
> 
> That doesn't mean it is unusable (On the contrary), just that under certain circumstances you should use other implementations and that's why a pluggable architecture is needed for garbage collection in the language.

Agreed.  And for what it's worth, I think this plugging should occur at link-time, not run-time.  Hot-swapping GCs while the app is running just raises too many weird issues.


Sean
November 20, 2006
Georg Wrede wrote:
> Walter Bright wrote:
>> In real, long lived gc applications I've been involved with, this is much more of a theoretical problem than an actual one. I found it surprising how little of a problem it actually was in practice.
> 
> If you found it surprising, then we could consider it legitimate and expected that "the C++ crowd" has a hard time believing this.
> 
> Maybe we should be more vociferous about it. The quote from Don is a good first step.

The problem with this thread is that it is the new guys coming from C++ land pitting their conventional wisdom against our experience.

D is not C++. The conventional wisdom you gleaned, your "gut feeling" about what is The Right Way(tm), does not necessarily apply here. Please leave your bias' at the door, and look at D as what it is, a NEW language, with its own character.