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
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
M;
> 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
> 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
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