Possible to free memory explicitly?

[Bienlein]

Hello,

is there a way to free memory explicitly in Go? Some languages that also have a GC support this such as Oberon or D. The idea is to be able to help yourself in case some upper memory bounds are reached when using the GC alone.

Thanks, Bienlein

[minux]

On Tue, May 14, 2013 at 5:07 AM, Bienlein <jet...@web.de> wrote:

is there a way to free memory explicitly in Go? Some languages that also have a GC support this such as Oberon or D. The idea is to be able to help yourself in case some upper memory bounds are reached when using the GC alone.

no.

explicit freeing memory in a GC environment is complicated. for example, what should the GC

do if one frees a still referenced memory chunk? should it ignore such request (how could it

verify that)? or should it make the latter reference to dangling pointer panic, or worse, corrupt

unrelated data?

to be precise, we used to have a runtime.Free, but it's unexported before Go 1.0 is released.

(see http://codereview.appspot.com/5675093 for the change.)

[Hotei]

Not to be unduly negative - but this seems a very "un-go" thing to do.  The whole point of giving a language GC is so that you (the programmer) don't have to worry about such things.  That said, the easiest way to free memory is to stop using a variable or exit a goroutine, then invoke the GC manually if need be.  Knowing when to do this can be a challenge.  After getting back some memory (you hope) if you can solve the problem with a different method that takes more time but uses less memory then do that.

Other than that I'd suggest the obvious stuff like adding memory or limiting the problem set to those you can handle in the given memory.   Or add swap space and live with the slowdown :-(

Without knowing your problem domain I don't know if it will help but you may also want to find ways to avoid unnecessary memory allocations in the first place.  This group has had many threads discussing that topic, especially the topics on profiling.  And as always, beware of premature optimization.

[Michael Jones]

...yes. And one step down from that, if it was not a one-time allocation, you can build a pool allocator that allocates when needed and retains old allocations for future reuse. Such a pool can also unlink and GC if it desires when too much buffering has sat unused to too long. The pool/arena scheme is very fast.

On Tue, May 14, 2013 at 1:18 AM, <voidl...@gmail.com> wrote:

If you really need to do this, which you probably don't- allocate a big block of memory (a byte array or use mmap) and write a custom allocator with an alloc and free function using "unsafe" that uses that block as its backing pool....

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--

Michael T. Jones | Chief Technology Advocate  | m...@google.com |  +1 650-335-5765

[John Nagle]

On 5/13/2013 2:07 PM, Bienlein wrote:
> Hello,
>
> is there a way to free memory explicitly in Go?

You can blank out a structure, thus clearing any references
from it, by assigning it from a copy of an empty version of the
structure. Structure types which can reference a lot of data
but may need to be cleared out probably should have a ".clear()"
method.

John Nagle

[Bienlein]

"You can blank out a structure, thus clearing any references from it ..."

Yes, I know. But this doesn't free memory >immediately< as the GC decides on it's own when to run and may decide not to run at a time when it was triggered by the user..

"... then invoke the GC manually if need be ..."

This also doesn't work as triggering the GC will not necessarily invoke it as already mentioned above. In addition running the GC will often cause a much longer stop-the-world time as when manually freeing the piece of memory.

As already said other languages that have a GC allow for manually freeing memory, e.g. this can be done in Oberon. It is the successor language to Pasacal and Modula II and was also designed by Niklaus Wirth. From all successful language designers he is probably one of the very conservatice ones (with regard to typing, f.ex.) and if he allows for manually freeing memory in Oberon, then it's for a reason. On the Ceres workstation Oberon is not only a programming language, but also the operating system. To write an OS you cannot delegate all memory management to the GC. It sometimes won't be fast enough.