View mode: basic / threaded / horizontal-split · Log in · Help
January 09, 2013
Re: manual memory management
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
Re: manual memory management
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
Re: manual memory management
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
Re: manual memory management
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
Re: manual memory management
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
Re: manual memory management
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
Re: manual memory management
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
Re: manual memory management
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
Re: manual memory management
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
Re: manual memory management
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?
4 5 6 7 8 9 10 11 12
Top | Discussion index | About this forum | D home