Richard L. Hudson RLH Working on Go Language Cambridge Ma. Make Go go.

RLH/hello 1

simple go program set up

RLH/ParallelJavaScript 1

Draft spec language related to Parallel JavaScript

RLH/agendas 0

TC39 meeting agendas

RLH/go-issue-24993 0

Repro for

issue commentgolang/go

runtime: 10ms-26ms latency from GC in go1.14rc1, possibly due to 'GC (idle)' work

The following may be relevant. From func GC

func GC()

GC runs a garbage collection and blocks the caller until the garbage collection is complete. It may also block the entire program.

In the section about the trace line:

If the line ends with "(forced)", this GC was forced by a runtime.GC() call.

The trace contains

gc 15 @432.576s 4%: 0.073+17356+0.021 ms clock, 0.29+0.23/17355/34654+0.084 ms cpu, 8697->8714->8463 MB, 16927 MB goal, 4 P GC forced

at the point indicated as the cause of the issue and the second screenshot looks like a call to runtime.GC is made and the mutator thread is stopped and the GC is run.

I would look into whether runtime.GC is called and if the call is in the dynamic scope of code being timed. If so remove the runtime.GC call and see if that makes any difference.

And kudos for helping out testing the new release candidate.

On Sun, Feb 9, 2020 at 2:03 PM Heschi Kreinick wrote:

I think this is working as expected. At the heart of is a single large map AFAIK the map has to be marked all in one go, which will take a long time. In the execution trace above you can see a MARK ASSIST segment below G21. If you click on that I think you'll find that it spent all of its time marking a single object, presumably the map. Austin and others will know better, of course.

Since a real server would need to lock the map, sharding it would be a good idea, which would also reduce the latency impact of a mark.

(cc @rsc, since I think @cagedmantis made a typo.)

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe .


comment created time in 19 days