An Idea for better performance GC

[ahme...@hotmail.de]

Hello folks,
I have a good idea how you can improve the performance of Garbage Collector and I want to share my point of view and discuss it:

Due to many programmers have big issues with stopping-the-world phenomena are too long. I thought of how can one fix it.

Some people you should improve the performance of Garbage Collector.

I think it is true. However the problem is, that you can't implement the GC to be optimal for every programmer's requirements.
Because some need a server with response times under 2 ms some, for some it is important, that the GC don't do its job at special moment, etc

True is, that most programmers will not have any problems with GC and I think that most programmers don't want to mind about the GC at anytime.

So what about programmer who to work with the GC, helping it doing its job like:

"Right now, there is low traffic on my server, I want the GC work right now." Or "Hey GC, please delete this!". "GC, I make a break, you can work Until I come back"

These things should be possible, additional to standard GC-routines.

I think it is possible to implement these things and many programmers will appreciate these functions and the other not wanting mind about memory doesn't need to use them.


What do you think, people?

peace

[Dave Cheney]

Please wait for Go 1.5, or even better try the Go1.5beta2 which is
available now. We have many reports that the improvements in the 1.5
GC have reduced latency to the point that it is no longer a concern.

Thanks

Dave

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

[Ian Lance Taylor]

On Sat, Jul 25, 2015 at 8:02 AM, <ahme...@hotmail.de> wrote:
>

> "Right now, there is low traffic on my server, I want the GC work right
> now."

You can do this by calling runtime.GC.

> Or "Hey GC, please delete this!".

This has been considered. However, it means that Go would no longer
be memory safe. Such a statement would only be useful if the memory
were freed without checking whether anything points to it. That means
that calling it might lead to dangling pointers. It would become a
dangerous nuisance.

Programs that need that level of control can implement their own
memory management.

> "GC, I make a break, you can work Until I come back"

With the concurrent GC in the upcoming 1.5 release, this might be
possible. We could have a way for a goroutine to indicate that it is
going to sleep and that the GC should scan the goroutine's stack now
in the expectation that it will remain asleep through the next real
GC. I don't know how much it would help, but it might be worth trying
in some cases.

Ian

[Gautam Dey]

As Dave said you should try out the the latest version of Go to see if your program has issues. But more to you statement about giving hints to the GC as to when it is a good time to run, you can already do this. The runtime package has two methods already that allow you to do this.

runtime.GC() — Tell the GC to run and it can do an eager sweep. 

runtime.Gosched() — allows other go routines to run (including the gs's I would guess)

Gautam.

On Sat, Jul 25, 2015 at 8:02 AM, <ahme...@hotmail.de> wrote:

--

[ahme...@hotmail.de]

Hey folks, thank you very much answering my questions and for the discussion:

I have one Argument and one Question

Argument

"This has been considered.  However, it means that Go would no longer
be memory safe.  Such a statement would only be useful if the memory
were freed without checking whether anything points to it.  That means
that calling it might lead to dangling pointers.  It would become a
dangerous nuisance.
 
Programs that need that level of control can implement their own
memory management. "

Code hier eingeben...


This is a very good point I haven't considered. However is it so wrong to give no-safety-optional features to programmers?
I mean programmers who don't want mind about memory will not care about such features, or?


Question
Does runtime.GC() go as long as the usual go routine?

[Dave Cheney]

This is a deliberate design choice by Go. The programmer does not get
to manage their own memory, because history has shown that while _one_
programmer _may_ be able to manage the memory of their _single_
program, many programmers, working across many codebases over a long
period of time, cannot do this reliably; and Go is built for that
latter audience.

>
>
> Question
> Does runtime.GC() go as long as the usual go routine?

Do you mean, does runtime.GC() take longer, or introduce a higher
latency than the normal gc process that is triggered automatically
when the heap is exhausted ? The answer is, yes, possibly.
http://tip.golang.org/pkg/runtime/#GC

[ahme...@hotmail.de]

On this term I agree and this is why I am talking about a "no-safety-optional feature".

And how about giving the GC just a hint like: "You can probably delete this object." and than he checks this object.

I think you are getting what I mean: The programmer should have possibility to help the GC and of course it should be "safe".

[Dave Cheney]

On Sat, Jul 25, 2015 at 6:39 PM, <ahme...@hotmail.de> wrote:
> On this term I agree and this is why I am talking about a
> "no-safety-optional feature".
>
> And how about giving the GC just a hint like: "You can probably delete this
> object." and than he checks this object.

The gc knows, because the compiler tells it, the exact moment when a
variable in the local scope is unused.

If you want to help the compiler for variables that are shared via the
heap, set them to nil.

[ahme...@hotmail.de]

However the GC will not delete the object immediately, after setting its reference nil.

I think I see how difficult this topic is. GCs are as good as bad they could be...

Thanks for the discussion!

[Dave Cheney]

On Sat, Jul 25, 2015 at 6:54 PM, <ahme...@hotmail.de> wrote:
> However the GC will not delete the object immediately, after setting its
> reference nil.

This isn't possible, because you cannot _know_ who else has a
reference to the thing that variable pointed to. Only the gc knows,
once it has stopped the world and started marking.