[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Go - deadlocked processes causing memory leaks

This thread is very interesting! I remember how the failing channel communication API was very important when we once shipped transputer products. Many of them still run on some ships! And how memory never overflowed. (I have bought an XMOS startKIT and am learning XC these days, for a small private project (aquarium!-))

Ãyvind TEIG 
+47 959 615 06
(iPhone)

Den 30. mar. 2015 kl. 11.46 skrev Kerridge, Jon <J.Kerridge@xxxxxxxxxxxx>:

That is my experience!!

I shall now try the latest 1.4 release of the language to see if there have been any changes to the run time to get rid of the problem I found.

I will let you know

Jon



Professor Jon Kerridge
School of Computing
Edinburgh Napier University
Merchiston Campus
Edinburgh EH10 5DT
 
0131 455 2777
 
From: occam-com-request@xxxxxxxxxx [occam-com-request@xxxxxxxxxx] on behalf of Roger Shepherd [rog@xxxxxxxx]
Sent: 30 March 2015 09:35
To: Jim Whitehead II
Cc: Rick Beton; Occam Family
Subject: Re: Go - deadlocked processes causing memory leaks

So the memory leak is, arguably, correct behaviour then?

Roger
--
Roger Shepherd




On 29 Mar 2015, at 22:01, Jim Whitehead II <jnwhiteh@xxxxxxxxx> wrote:

There is no such thing as a goroutine going out of scope, there's no process hierarchy. It's spawned in a flat tree and will continue to block indefinitely. Yes it would be possible for the garbage collector to determine that a channel send could never succeed on that channel but the semantics of what to do after that are very difficult to specify.

- Jim

On Sun, 29 Mar 2015 at 22:19 Roger Shepherd <rog@xxxxxxxx> wrote:

On 29 Mar 2015, at 17:35, Rick Beton <rick.beton@xxxxxxxxx> wrote:

Hi Roger,

see notes inserted below...

On 29 March 2015 at 17:01, Roger Shepherd <rog@xxxxxxxx> wrote:

I think I understand the explanation in Stack Overflow. Essentially this says that if a one-buffered channel is used, the sending process wonât block even if the receiver is dead, and the process and channel will be garbage collected. Presumably in the implementation, a processâs memory is reclaimed only when it terminates, whereas dangling channels are garbage collected.


That is a reasonable interpretation. Go has quite straightforward memory model, using the stack as much as possible and the garbage-collected heap otherwise. Anything that goes out of scope is reclaimed either by being on the stack (and the stack pointer is moved), or by having no more references to it. This applies to both the channel and the goroutine in the specific example.

 


In the example, isn't it the case that with the zero-buffered channel the channel and the grouting go out of scope and should be garbage collected? So there is a bug, as the Stack Overflow post suggests.

Roger
--
Roger Shepherd
rog@xxxxxxxx