January 09, 2013
09-Jan-2013 12:54, Mehrdad пишет:
> On Wednesday, 9 January 2013 at 08:51:47 UTC, Paulo Pinto wrote:
>> On Wednesday, 9 January 2013 at 08:28:44 UTC, Mehrdad wrote:
>>> On Wednesday, 9 January 2013 at 08:14:35 UTC, Walter Bright wrote:
>>>> On 1/8/2013 11:42 PM, Mehrdad wrote:
>>>>> (True, it wouldn't give you the power of a systems language, but
>>>>> that's quite
>>>>> obviouly not my point -- the point is that it's a _perfectly possible_
>>>>> memory-safe language which we made, so I don't understand Walter's
>>>>> comment about
>>>>> a GC being "required" for a memory-safe language.)
>>>>
>>>>
>>>> The misunderstanding is you are not considering reference counting
>>>> as a form of GC. It is.
>>>
>>> So you would say that C++ code (which uses reference counting) uses
>>> garbage collection?
>>
>> Yes.
>
> You (or Walter I guess) are the first person I've seen who calls C++
> garbage collected.
>

That's a stretch - IMHO I'd call the language garbage collected iff it is the default way language-wise (e.g. if C++ new was ref-counted I'd call C++ garbage collected).

This way D is garbage collected language because the language default is GC.


-- 
Dmitry Olshansky
January 09, 2013
On Wednesday, 9 January 2013 at 09:08:40 UTC, Brad Roberts wrote:
> On 1/9/2013 1:00 AM, Jonathan M Davis wrote:
>> On Wednesday, January 09, 2013 09:54:10 Mehrdad wrote:
>>> You (or Walter I guess) are the first person I've seen who calls
>>> C++ garbage collected.
>> 
>> I sure wouldn't call that garbage collection - not when there's no garbage collector. But Walter has certainly called it that from time to time.
>
> There's a collector, it's in the refcount decrement (a little simplified):
>
> if (refcount == 0)
>    free(obj);
>
> Granted, it's terribly simple, but it's there.

Sure, it's there.

The problem I have with it is that this line of reasoning makes no sense of what Walter said, which was:

"A GC is *required* if you want to have a language that guarantees memory safety."




No matter how he defines the word GC, I _STILL_ don't see how this is true.


I can perfectly well imagine a language which allows you to use integers as _handles_ to objects (perfectly _manual_ management of _everything_), and which gives you access to their fields via external functions.

The language need not give you any direct access to memory, making everything perfectly safe.

I really don't think Walter's statement made any sense whatsoever.
January 09, 2013
On Wednesday, 9 January 2013 at 07:33:24 UTC, Rob T wrote:
> On Wednesday, 9 January 2013 at 07:23:57 UTC, Mehrdad wrote:
>> On Wednesday, 9 January 2013 at 07:22:51 UTC, deadalnix wrote:
>>> Well, you CAN indeed, create a dumbed down language that is memory safe and don't require a GC.
>>
>>
>> Yeah, that's 1 of my 2 points.
>>
>>
>> The other one you still ignored: the GC doesn't bring much to the table. (Re C# Java etc.)
>
> There is a point being made here that is perfectly valid. There is a form of memory leak that a GC can never catch, such as when when memory is allocated and simply never deallocated by mistake due to a persistent "in use" pointer that should have been nulled but wasn't.
>

As long as you have the pointer around, the memory leak is not GC's.

> In addition, the GC itself may fail to deallocated freed memory or even free live memory by mistake. I've seen bugs described to that effect. There simply is no panacea to the memory leak problem. What a GC does do, is free the programmer from a ton of tedium, and even allow for constructs that would normally not be practical to implement, but it can never guarantee anything more than that.
>

False pointer are mostly solved by using 64bits pointers. See : http://www.deadalnix.me/2012/03/05/impact-of-64bits-vs-32bits-when-using-non-precise-gc/
January 09, 2013
On Wednesday, 9 January 2013 at 07:42:39 UTC, Mehrdad wrote:
> Also might mention, we implemented a compiler for a subdialect of Python (including full closures) for our compilers course, which the compiler subsequently translated to C++.
>
> GC wasn't required (we were allowed to never deallocate), but since I didn't feel like doing that I added reference counting using a lot of shared_ptr's and intrusive_ptr's.
>
> I also added a GC just for the sake of catching cyclic references, but it was just that -- everything was reference counted, so if you never had cyclic references, the GC _never_ kicked in, period.
>

This is a very valid way to manage things in D as well, remember that you have GC.free available.
January 09, 2013
On Wednesday, 9 January 2013 at 09:30:41 UTC, deadalnix wrote:
> On Wednesday, 9 January 2013 at 07:33:24 UTC, Rob T wrote:
>> On Wednesday, 9 January 2013 at 07:23:57 UTC, Mehrdad wrote:
>>> On Wednesday, 9 January 2013 at 07:22:51 UTC, deadalnix wrote:
>>>> Well, you CAN indeed, create a dumbed down language that is memory safe and don't require a GC.
>>>
>>>
>>> Yeah, that's 1 of my 2 points.
>>>
>>>
>>> The other one you still ignored: the GC doesn't bring much to the table. (Re C# Java etc.)
>>
>> There is a point being made here that is perfectly valid. There is a form of memory leak that a GC can never catch, such as when when memory is allocated and simply never deallocated by mistake due to a persistent "in use" pointer that should have been nulled but wasn't.
>>
>
> As long as you have the pointer around, the memory leak is not GC's.



"The _leak_ is not GC'd"?



>> In addition, the GC itself may fail to deallocated freed memory or even free live memory by mistake. I've seen bugs described to that effect. There simply is no panacea to the memory leak problem. What a GC does do, is free the programmer from a ton of tedium, and even allow for constructs that would normally not be practical to implement, but it can never guarantee anything more than that.
>>
>
> False pointer are mostly solved by using 64bits pointers. See : http://www.deadalnix.me/2012/03/05/impact-of-64bits-vs-32bits-when-using-non-precise-gc/


Re-read what he wrote, you completely missed what we're saying.
January 09, 2013
On Wednesday, 9 January 2013 at 08:46:20 UTC, Paulo Pinto wrote:
> You can write plugins without dynamic loading, they just are a bit more cumbersome to write.
>
> Like I used to do back in the late 90's, by making use of UNIX's IPC.
>
> The IPC to use (shared memory, pipes, mailbox, sockets) depends on what is required from the plugin. With shared memory being the closest to what dynamic loading achieves.
>
> Of course this raises another set of issues like:
>
> - Take care what happens when a plugin dies
> - Too many loaded plugins can stress the scheduler
> - You might have synchronization issues when using shared memory
> - It is a bit more painful to code for
>
> This is the school of thought of the Plan9/Go guys and most operating system micro-kernel architectures.
>

Such a solution cause the same kind of issue for the runtime. For instance, how to handle the garbage collection of the shared memory ? What do happen if I get the typeid of an object of a type that only exists in the plugin in the core app ?

It quite don't solve problems we have.
January 09, 2013
On Wednesday, 9 January 2013 at 09:01:46 UTC, Jonathan M Davis wrote:
> On Wednesday, January 09, 2013 09:54:10 Mehrdad wrote:
>> You (or Walter I guess) are the first person I've seen who calls
>> C++ garbage collected.
>
> I sure wouldn't call that garbage collection - not when there's no garbage
> collector. But Walter has certainly called it that from time to time.
>
> I think that the other term that Paulo just used - automatic memory management
> - is far more accurate.
>
> - Jonathan M Davis

I used to think that. But I was convinced otherwise when considering carefully the cost and benefit involved. I so no interest in make the difference anymore.

The technical solution you choose for GC imply some tradeoff, and it amazing to see how the fact that you refcount or trace don't matter that much. If you want a tracing collector to behave more like reference counting, you'll need to add barriers, so you ends up with the same cost to get the same benefit. Same goes for variations around reference counting, or any mix of both.
January 09, 2013
On Wednesday, 9 January 2013 at 09:43:01 UTC, deadalnix wrote:
> The technical solution you choose for GC imply some tradeoff, and it amazing to see how the fact that you refcount or trace don't matter that much. If you want a tracing collector to behave more like reference counting, you'll need to add barriers, so you ends up with the same cost to get the same benefit.



A single 100-ms pause is not equivalent to 10,000  0.1-ms pauses for all apps.

Just because they have the "same cost" doesn't necessarily imply they're equal.
January 09, 2013
On Wednesday, 9 January 2013 at 09:50:25 UTC, Mehrdad wrote:
> A single 100-ms pause is not equivalent to 10,000  0.1-ms pauses for all apps.
>
> Just because they have the "same cost" doesn't necessarily imply they're equal.

You can have pauseless tracing GC, at the price of barrier + more floating garbage.

Reference counting tend to create big pauses when deallocating as objects tends to dies in group. You can solve that issue by delaying cascading deallocation, which cause more floating garbage.
January 09, 2013
On Wednesday, 9 January 2013 at 10:07:42 UTC, deadalnix wrote:
> Reference counting tend to create big pauses when deallocating as objects tends to dies in group.




I don't get it... it's slower to deallocate a bunch of objects together with refcounting than to deallocate all of them individually over a longer period of time?