Re: [go-nuts] How to check whether a variable is unreachable?

>> >> var b []byte >> >> func f(data interface{}) { >> switch ds := data.(type) { >> case []int32: >> sh := (*reflect.SliceHeader)(unsafe.Pointer()) >> l := len(ds) >> d := sh.Data >> runtime.GC() >> b = unsafe.Slice((*byte)(unsafe.

Re: [go-nuts] How to check whether a variable is unreachable?

rintln(b) } 在2021年9月23日星期四 UTC+8 上午6:11:48 写道： > On Wed, Sep 22, 2021 at 1:22 AM Cholerae Hu wrote: > > > > https://play.golang.org/p/WJTH-lUukeb > > > > Do I need to uncomment line 23? IMHO, variable data and ds will not be > used after line 16, so the

[go-nuts] How to check whether a variable is unreachable?

https://play.golang.org/p/WJTH-lUukeb Do I need to uncomment line 23? IMHO, variable data and ds will not be used after line 16, so they can be collected in runtime.GC. But running it with gccheckmark=1 and clobberfree=1 doesn't show any problems. Are there any documents about the details or

[go-nuts] Is there any document about how to add missing instruments in go compiler?

I find a doc https://golang.org/doc/asm#unsupported_opcodes, it says "One is to update the assembler to support that instruction". But I can't find any further doc about this. I also find a previous CL which add some instruments https://go-review.googlesource.com/c/go/+/183225, but I don't

[go-nuts] Why does race detector only throw out warning rather than fatal error?

Code with data races is invalid code, we shouldn't let it run once we find a data race. Actually, since Go 1.5, when runtime finds concurrent read and write to a map, it does throw a fatal error rather than just warning. Maybe it's not consistent that race detector only print out warning

[go-nuts] Re: Why are escape analysis results of these two programs different?

this is a bug or a feature. 在 2020年6月5日星期五 UTC+8下午6:38:56，Cholerae Hu写道： > > https://play.golang.org/p/PL0FCLCv3qU > > You'll find that x1() and x2() are different. Then I run `go tool compile > -m -m`: > ``` > unsafestr.go:11:11: make([]byte, 12) escapes to heap: > unsaf

[go-nuts] Why are escape analysis results of these two programs different?

https://play.golang.org/p/PL0FCLCv3qU You'll find that x1() and x2() are different. Then I run `go tool compile -m -m`: ``` unsafestr.go:11:11: make([]byte, 12) escapes to heap: unsafestr.go:11:11: flow: b = &{storage for make([]byte, 12)}: unsafestr.go:11:11: from make([]byte, 12) (spill)

Re: [go-nuts] Can we maintain a per P epoll fd to make netpoll scalable?

Thanks for responding. I will dig deeper about kernel contention later. 在 2020年5月10日星期日 UTC+8上午6:54:30，Ian Lance Taylor写道： > > On Sat, May 9, 2020 at 8:32 AM Cholerae Hu > wrote: > > > > I'm maintaining a highly-loaded proxy-like service, which serves huge > amount of

[go-nuts] Can we maintain a per P epoll fd to make netpoll scalable?

I'm maintaining a highly-loaded proxy-like service, which serves huge amount of small rpc requests every day. Yesterday I profiled it, and found that runtime.netpoll took 8.5% cpu(runtime.mcall took 20% cpu). There is only one global epoll fd in runtime, but every P will call netpoll. Inside

Re: [go-nuts] Why do we use xchg rather than lock mov to inplement atomic.StoreX?

reorderings > (does it do that? Not sure.) > > We'd need some indication that changing it would be faster, as well. > > On Tuesday, April 28, 2020 at 4:03:00 AM UTC-7, Cholerae Hu wrote: >> >> But on gcc 9.3, atomic store with seq_cst order, will be compiled to >> mov

Re: [go-nuts] Why do we use xchg rather than lock mov to inplement atomic.StoreX?

But on gcc 9.3, atomic store with seq_cst order, will be compiled to mov+fence rather than xchg, see https://gcc.godbolt.org/z/ucbQt6 . Why do we use xchg rather than mov+fence in Go? 在 2020年4月28日星期二 UTC+8上午7:26:15，Ian Lance Taylor写道： > > On Sun, Apr 26, 2020 at 1:31 AM Cholerae Hu &

[go-nuts] Why do we use xchg rather than lock mov to inplement atomic.StoreX?

Atomic.StoreX doesn't return the old value of the given pointer, so lock mov would work. Why do we use a xchg instead? It there any performance issue? -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop

[go-nuts] Re: checksum mismatch inside docker and outside docker

My host os and docker container os are both linux/amd64, and I've already turned GOSUMDB to 'off'. Also, I've already added this mismatched module into GOPRIVATE. 在 2019年8月7日星期三 UTC+8下午2:51:05，Cholerae Hu写道： > > I'm trying to build an private repo using go1.13beta1 in docker container. &

[go-nuts] checksum mismatch inside docker and outside docker

I'm trying to build an private repo using go1.13beta1 in docker container. But I got an checksum mismatch error. Weirdly, I can successfully build it outside docker , with the same go.sum, same version of go(go 1.13beta1). I've already run `go clean --modcache` both inside and outside docker

[go-nuts] Does this code safe?

package main import ( "sync/atomic" "sync" ) func main() { var n int32 var m sync.Mutex var wg sync.WaitGroup wg.Add(2) go func() { for { atomic.LoadInt32() } wg.Done() }() go func() { for { m.Lock() n = 1 m.Unlock() } wg.Done() }() wg.Wait() } Does it safe to use atomic read an int and write

Re: [go-nuts] Why will it deadlock if a goroutine acquire a mutex while pinned to its P?

be able to finish acquiring the mutex (so > it will never release the pin), which means M3 won't be able to finish > stopping the world (so it will never start M1 back up). > > On Mon, Apr 8, 2019 at 2:31 AM Cholerae Hu > wrote: > >> I'm reading this commit >> http

[go-nuts] Why will it deadlock if a goroutine acquire a mutex while pinned to its P?

I'm reading this commit https://github.com/golang/go/commit/d5fd2dd6a17a816b7dfd99d4df70a85f1bf0de31 . Inside runtime_procPin we only increases the m.lock count, why will it cause deadlock when acquiring a mutex after pin? -- You received this message because you are subscribed to the Google

[go-nuts] Re: Do I need to use runtime.KeepAlive in this case?

I've found this issue https://github.com/golang/go/issues/10303 which can answer my questions. 在 2019年3月21日星期四 UTC+8下午1:56:17，Cholerae Hu写道： > > package main > > // void a(long *p) {} > import "C" > > import ( > "unsafe" > ) > > //go

Re: [go-nuts] Do I need to use runtime.KeepAlive in this case?

mean that sweep phrase cannot be started before the end of that cgo call? 在 2019年3月22日星期五 UTC+8上午2:37:36，Ian Lance Taylor写道： > > On Wed, Mar 20, 2019 at 10:56 PM Cholerae Hu > wrote: > > > > package main > > > > // void a(long *p) {} > > imp

[go-nuts] Do I need to use runtime.KeepAlive in this case?

package main // void a(long *p) {} import "C" import ( "unsafe" ) //go:noinline func b() { x := int64(0) C.a((*C.long)(unsafe.Pointer())) // do something without x } func main() { b() } x should be considered unreachable after C.a . If x is something allocated on heap, do I need to use

[go-nuts] Will a pointer point to C.xxx be garbage collected by Go runtime？

Consider the following code: ``` package main /* struct B { int i; }; struct A { int j; struct B b; }; */ import "C" func NewA() *C.struct_A { return _A{ j: 1, b: C.struct_B{ i: 2, }, } } func main() { a := NewA() } ``` Will 'a' be scanned by go runtime? It is

[go-nuts] How to run some unittest repeatedly without build cache?

Some bugs caused by data race cannot be detected by running unittest only once. Before Go 1.12, I can use GOCACHE=off go test -race . to force it to run without cache, but GOCACHE=on is required as of Go 1.12. So how can I workaround this? -- You received this message because you are

[go-nuts] Re: implementation for GetsockoptLinger() and GetsockoptTimeval()

Done. You can update your local x/sys/unix package to use these functions. 在 2018年3月24日星期六 UTC+8上午6:53:45，Yuxuan Li写道： > > Hi, > > I am using the x/sys/unix package > to get the socket options of a fd. While there are SetsockoptLinger() > and

[go-nuts] Why can't I call a pointer-receiver method on a temperary but addressable struct literal?

package main import ( "fmt" "reflect" ) type Circle struct { radius float64 } func (c *Circle) DummyMethod() { fmt.Println("Type of receiver:", reflect.TypeOf(c)) } func main() { // error: cannot take the address of Circle literal // Circle{radius: 1.0}.DummyMethod()

[go-nuts] Why can't we do timer related works in sysmon rather than another timer goroutine?

Currently if we use timer or something, runtime will start a new goroutine to do timerproc works. Why can't we check timer heap in each iteration of sysmon if any timer exists? This may reduce some context switchs, I think. -- You received this message because you are subscribed to the Google

[go-nuts] Can warnings of race detector be ignored and toleranted?

Some of my colleagues think that, in some cases, such as approximately counting the sum total of requests, we don't need to know the accurate value, so we can let several goroutines to access one variable without lock or atomic operation to get the highest performance, and we can ignore the

[go-nuts] How can I set a larger goroutine initial stack size manually?

We found quite a lot `morestack` call in our system, which cost a lot of time. 4 KB of initial stack seems too small for us, how can I set a larger size of initial stack size? -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from

[go-nuts] Re: Why does these two code behave differently? (swap two elements in a slice)

I test it on golang play. https://play.golang.org/p/trTGZsW6Ai https://play.golang.org/p/NEAavwidJ1 在 2017年3月23日星期四 UTC+8下午1:04:00，Cholerae Hu写道： > > First code: > package main > import ( > "fmt" > ) > > > func main() { > test := []int{2, 1

[go-nuts] Why does these two code behave differently? (swap two elements in a slice)

First code: package main import ( "fmt" ) func main() { test := []int{2, 1, 1} fmt.Println(findDuplicate(test)) } func findDuplicate(nums []int) int { for i := 0; i < len(nums); i++ { if nums[i] != i+1 { if nums[i] == nums[nums[i]-1] {

Re: [go-nuts] Is there any import path limitation when using go:linkname localname importpath.name?

I removed the alias "pri", and it works, thanks! By the way, when go:linkname with runtime, why don't I need to import "runtime" package explicitly? 在 2017年1月20日星期五 UTC+8下午1:34:43，Ian Lance Taylor写道： > > On Wed, Jan 18, 2017 at 6:55 PM, Cholerae Hu <chole...@gmail.co

Re: [go-nuts] Is there any import path limitation when using go:linkname localname importpath.name?

;https://github.com/aristanetworks/goarista/blob/46272bfb1c042fc2825d312fe33d494e9d13dd6b/atime/nanotime.go> doesn't import "runtime" at all, but it can use "runtime.nanotime" in go:linkname. 在 2017年1月20日星期五 UTC+8下午1:34:43，Ian Lance Taylor写道： > > On Wed, Jan 18, 2017

[go-nuts] Is there any import path limitation when using go:linkname localname importpath.name?

I'm trying to play with go:linkname, and I wrote a demo for this. directory structure: [test]$ tree . ├── main.go ├── pri │ └── a.go └── pub ├── issue15006.s └── b.go a.go: package pri import ( "fmt" ) func rua() int64 { fmt.Println("rua in pri") return 1 } b.go:

[go-nuts] Re: In the future, how to keep runtime.KeepAlive from dead code elimination?

I see, thanks. 在 2016年8月25日星期四 UTC+8上午11:42:10，Cholerae Hu写道： > > Hi all, > > I've read the source of package runtime, and found that runtime.KeepAlive > is an empty function. If go compiler can do dead code elimination in the > future, how to protect runtime.KeepAlive fr

Re: [go-nuts] In the future, how to keep runtime.KeepAlive from dead code elimination?

I'm curious that how does compiler recognize runtime.KeepAlive specially? 在 2016年8月26日星期五 UTC+8上午12:04:57，Ian Lance Taylor写道： > > On Thu, Aug 25, 2016 at 12:15 AM, Cholerae Hu <chole...@gmail.com > > wrote: > > Does that mean that only inlined functions will be optimized a

Re: [go-nuts] In the future, how to keep runtime.KeepAlive from dead code elimination?

Does that mean that only inlined functions will be optimized and any functions not inlined will not be optimized ? 在 2016年8月25日星期四 UTC+8上午11:55:12，Ian Lance Taylor写道： > > On Wed, Aug 24, 2016 at 7:06 PM, Cholerae Hu <chole...@gmail.com > > wrote: > > > > I've

[go-nuts] In the future, how to keep runtime.KeepAlive from dead code elimination?

Hi all, I've read the source of package runtime, and found that runtime.KeepAlive is an empty function. If go compiler can do dead code elimination in the future, how to protect runtime.KeepAlive from being optimized? -- You received this message because you are subscribed to the Google