Why is there no dealloc or free? is there any alternative
philip
Why doesn't go language have a free or dealloc? Ok I see there is some
answer in the faq, but GC still has some negative consequences even in
the JVM today.
Sometimes I don't like garbage collection, for example consider a
typical Java server memory profile, its a saw shape. The memory usage
goes up, then the GC kicks in and frees up some memory.
Normally, this causes "some" delay in the system. Most Java programs I
use have some GC delay at some time, and of course I don't get that
with a C program.
So I assume, that there is going to be some delay in the Go Language
GC.
I would like to have the option to be able to free some memory that I
have used to get a more real-time performance if I needed it, rather
than relying on the GC which may have a negative impact on
performance.
Although it shouldn't be encouraged as a good practice to free ram
explicitly, at least, can I have the option to be evil?
If this isn't ever going to be a option, is there some way I can do my
own memory management by allocating a large block of ram and mapping
objects to exist within this block? ie, if I was programming in C, I
could create a large block of ram with a void* and then make my own
malloc and free for this block of ram.
Thanks, Phil
Jessta
> Hi,
>
> Why doesn't go language have a free or dealloc? Ok I see there is some
> answer in the faq, but GC still has some negative consequences even in
> the JVM today.
The GC will get better and a GC offers far more flexibility to
increase performance of
an application in the future, especially when integrating with
external packages.
> I would like to have the option to be able to free some memory that I
> have used to get a more real-time performance if I needed it, rather
> than relying on the GC which may have a negative impact on
> performance.
> Although it shouldn't be encouraged as a good practice to free ram
> explicitly, at least, can I have the option to be evil?
>
> If this isn't ever going to be a option, is there some way I can do my
> own memory management by allocating a large block of ram and mapping
> objects to exist within this block? ie, if I was programming in C, I
> could create a large block of ram with a void* and then make my own
> malloc and free for this block of ram.
https://github.com/mcgoo/coffer might be helpful to you.
The runtime package has Alloc() and Free().
You can also do manual memory management in C and link to it using cgo.
That said, please don't do this in any packages you distribute for wider usage.
Fragmented memory management leads to bugs, decrease in performance
and great difficulty tweaking the way memory is managed application wide.
- jessta
--
=====================
http://jessta.id.au
philip
I've been programming in Java from near the beginning and this is a
long time.
Ok it gets better, but there are still delays in performance when the
GC kicks in.
For example, if I wanted to write a computer game, programming it in
Java has the problem that the GC may degrade performance at some point
in time. Programming it in C means that I can manage my own memory and
be sure of performance.
On Feb 3, 11:41 am, Jessta <jes...@jessta.id.au> wrote:
> > Hi,
>
> > Why doesn't go language have a free or dealloc? Ok I see there is some
> > answer in the faq, but GC still has some negative consequences even in
> > the JVM today.
>
> The GC will get better and a GC offers far more flexibility to
> increase performance of
> an application in the future, especially when integrating with
> external packages.
>
> > I would like to have the option to be able to free some memory that I
> > have used to get a more real-time performance if I needed it, rather
> > than relying on the GC which may have a negative impact on
> > performance.
> > Although it shouldn't be encouraged as a good practice to free ram
> > explicitly, at least, can I have the option to be evil?
>
> > If this isn't ever going to be a option, is there some way I can do my
> > own memory management by allocating a large block of ram and mapping
> > objects to exist within this block? ie, if I was programming in C, I
> > could create a large block of ram with a void* and then make my own
> > malloc and free for this block of ram.
>
Kai Backman
> Sometimes I don't like garbage collection, for example consider a
> typical Java server memory profile, its a saw shape.
I've worked extensively with large scale production Java servers so I
understand your pain. I've written Go code for just a few years but I
haven't really felt a similar pain yet.
1. Go let you control memory layout. A lot of the inefficiencies in
Java are in my experience due to objects being scattered around the
heap. I find this to be the most important difference from Java.
2. You can write a simple pool allocator by allocating a large slice
of things and adding a custom interface to it. This pattern should be
familiar if you have worked with real time or soft real time C++ code.
An alternative is the workspace pattern where you pre-allocate a set
of large workspaces that are re-used across the system.
3. If you really need to control the lifecycle of a set of
heterogenous objects you can use syscall to mmap some memory and
package unsafe to cast it to whatever you need. This is a pretty last
ditch effort but it gives you essentially the same control that C/C++
would give. We haven't actually found a need for it yet.
Kai
--
Kai Backman, programmer
http://tinkercad.com - The unprofessional solid CAD
Paulo Pinto
Java or
other GC enabled languages is bad coding.
Many developers just allocate memory as if it was infinite, without
proper
knowledge of what is happening, and never profile the applications GC
behaviour.
In Java I still see people using Strings in cases where StringBuilder/
StringBuffer
should be used.
Allocating memory inside a loop is also an example of bad GC coding.
--
Paulo
On Feb 3, 8:37 am, Kai Backman <kai.back...@gmail.com> wrote:
Miguel Pignatelli
> I've written Go code for just a few years
M;
Andrew Gerrand
Jeff R. Allen
> of things and adding a custom interface to it. This pattern should be
> familiar if you have worked with real time or soft real time C++ code.
saying, but I can't quite imagine what the code looks like.
It seems like it would be a useful pattern for people to keep in mind.
Another pool allocator pattern can be found in fmt/print.go, where a
buffered channel is used as a cache. What do Go gods say about it as a
pattern?
-jeff
philip
Well, people do bad programming sometimes, especially these days, but
when I started with C, if we wanted to do a string, typically we made
an array of chars.
So in a loop, if we were to use a string, we would define a array of
char and just re-use it through the loop, string ended in 0 (null
terminated string).
Not malloc and dealloc or free in the loop.
Well today we use Unicode strings, so thats not such a good idea, but
the point is that with a clear awareness of the data storage, we
didn't do bad things such as creating immutable Strings which get
thrown away each time through the loop.
What I worry about specifically is the garbage collector kicking in at
some time and slowing down performance at that moment in time, which
is what exactly happens with Java.
Its not a mild problem, its a serious problem - ie "Java garbage
collection bottleneck. The severely limited heap size allowed by the
Java garbage collector (if you don't want to have significant
performance issues) is a problem that has plagued the industry for
years. "
http://java.dzone.com/terracotta-releases-bigmemory
The problem has been there from the beginning and the future never
gets bright for Java garbage collection.
Philip
Ian Lance Taylor
> What I worry about specifically is the garbage collector kicking in at
> some time and slowing down performance at that moment in time, which
> is what exactly happens with Java.
The current Go garbage collector will only kick in if you actually
allocate memory. Also, you can disable the garbage collector by setting
runtime.MemStats.EnableGC to false.
Ultimately, though, it sounds like you want a language which has no
garbage collection, and Go is not that language. Language constructs
will allocate memory in ways that are not immediately obvious, so there
is no reasonable way for a Go program to completely manage its own
memory.
Ian
philip
GC which doesn't cause significant problems).
On Feb 4, 11:42 pm, Ian Lance Taylor <i...@google.com> wrote:
Ian Lance Taylor
> I want a language with (a malloc/free AND a garbage collection) OR (a
> GC which doesn't cause significant problems).
Go falls in the first category. You can use runtime.Alloc and
runtime.Free.
Ian
Rob 'Commander' Pike
in pkg/regexp/regexp.go. Look for 'matchArena'.
-rob
Russ Cox
> runtime.Free.
I've been meaning to remove those. Thanks for the reminder. :-)
To be fair, they do say:
func Alloc(uintptr) *byte
Alloc allocates a block of the given size.
FOR TESTING AND DEBUGGING ONLY.
func Free(*byte)
Free frees the block starting at the given pointer.
FOR TESTING AND DEBUGGING ONLY.
Russ
Quartz
mostly) had the "typical" GC times, around 3% of total processing time
(according to the JVM logs, but who knows...). I'm with Paulo on this
one, if your performance is GC-bound, something is wrong with the
code!
Having said that, XML (ok, string manipulation in general) is a hog
in Java...
siddarth shankar
limiting manual memory management:
http://golang.org/doc/go_faq.html#garbage_collection
if you want a modern language with alloc/free for an rtos/game-
development etc., you could look at D, bitc, clay, rust etc..