Re: [go-nuts] Okay to use mmap ?

Note though that you can't put pointers to Go heap objects into mmap'd memory, as the garbage collector can't see them. On Monday, February 12, 2018 at 8:37:46 AM UTC-8, Jan Mercl wrote: > > On Mon, Feb 12, 2018 at 5:28 PM Juliusz Chroboczek > wrote: > > > Is it okay to use syscall.Mmap to alloc

Re: [go-nuts] evacuate in hashmap: where to put when migrate data from oldbucket to bucket

On Thursday, March 15, 2018 at 9:46:34 AM UTC-7, Ian Lance Taylor wrote: > > On Thu, Mar 15, 2018 at 1:34 AM, > > wrote: > > > > when evacuate oldbucket, go will migrate the data to a new position. > > > > and i found it used X and Y as two bucket where Xi equal the old index > in > > h.o

[go-nuts] Re: After one goroutine completed, does the thread its binded will be destroyed?

Tamás is right. In the case you show, M1 will pick up G2 and work on it. In general, the M (OS thread) finds another goroutine to run, and if it can't find one it parks itself until more goroutines show up. The code is in src/runtime/proc.go:findrunnable, which calls stopm. We've been contemp

[go-nuts] Re: Help debugging atomic.AddInt64 usage

This is definitely strange. You're using the atomics correctly. Are you on a 32-bit platform by any chance? If so, try replacing 64-bit atomics with 32-bit atomics. The 64-bit atomics should work on 32-bit platforms, but it wouldn't hurt to test that theory. If you can extract a standalone te

Re: [go-nuts] Re: Garbage collector and Slices

There is no conservativeness to unsafe.Pointer. The type information for any object in the heap is recorded at allocation time, and is unrelated to the type of the reference currently held to it (be it unsafe.Pointer, []byte, *int64, or whatever). So for 2.2, the answer is no, you are incorrect.

Re: [go-nuts] Unsafe Pointer rules

Just to add, it is ok to have a pointer (unsafe.Pointer or otherwise) to unreadable memory. For instance, you can use syscall.Mmap and syscall.Mprotect to produce such a state. The GC will not dereference any pointer that points outside the Go heap. Public Service Announcement #1: Don't use sy

[go-nuts] Re: What is the proper way to delete a key which holding a pointer in a map

FYI shrinking maps on delete is issue 20135 . On Monday, August 27, 2018 at 12:13:00 PM UTC-7, Kasun Vithanage wrote: > > thanks this answer will work > > On Monday, August 27, 2018 at 9:56:16 PM UTC+5:30, Jake Montgomery wrote: >> >> Just to be clear, t

[go-nuts] Re: How much performance will be impacted for GC to be conservative by scanning externally allocated memory (mmap mostly desirable) for pointers ?

1. No. Go will never scan objects outside of the Go-allocated heap. That includes mmap'd memory. That means you can't have pointers from such memory into the Go heap. Pointers within the mmap'd area are fine. > that also means no regular Go pointer should be defined into such structs Right. O

Re: [go-nuts] Huge map[string]*Object and GC where *Object is from sync.Pool

Objects returned by Get() are not special in any way. They will be GCd just like an object returned by new(). In fact, they will often be just a new()'d object. There is no association of such an object with the pool. A pool is just a fancy free list. Get might return a previously Put'd object

Re: [go-nuts] Huge map[string]*Object and GC where *Object is from sync.Pool

On Thu, Sep 27, 2018 at 11:26 PM Peter Mogensen wrote: > > > On 09/28/2018 08:17 AM, Peter Mogensen wrote: > > > > > > On 09/28/2018 03:04 AM, keith.rand...@gmail.com wrote: > >> Objects returned by Get() are not special in any way. They will be GCd > >> just like an object returned by new(). In

[go-nuts] Re: Using the CX register on 386 and AMD64 in Go Assembly

Fixed memory location is a global variable. This only applies to 386, not amd64. This applies only to (SB) dereferences, not to any other (SP, FP, or standard register). The text doesn't really say it, but it applies to LEAL as well as loads and stores. On Saturday, March 30, 2019 at 2:40:28 PM

Re: [go-nuts] will the following code always print two 1?

For the second section (the one with locks), the program is guaranteed to print a 1 (if it prints anything). The Go memory model guarantees this. This follows from the facts: x = 1 @29 happens before m.Unlock() @31 m.Unlock() @31 happens before m.Lock() @35 m.

Re: [go-nuts] Re: will the following code always print two 1?

They are the lock count for the given lock. Imagine each lock keeps track of how many times it has been acquired. There is a happens-before edge from an unlock to a lock only if the unlock has a lower count (i.e. was earlier than) than the lock. On Mon, Oct 23, 2017 at 3:43 PM, T L wrote: > Th

Re: [go-nuts] Re: select is still a little unfair if there are more than 4 cases?

On Saturday, October 28, 2017 at 2:59:53 PM UTC-7, John Souvestre wrote: > > Ø I don't think it needs to be uniformly fair. It just needs to prevent > starvation of a channel for infinity. Any proof would have progress covered > if we pick every channel once in a while, even under a heavily unfa

Re: [go-nuts] Re: Can I interpret the Go 1 memroy model as the following described?

On Saturday, October 28, 2017 at 2:18:05 PM UTC-7, T L wrote: > > > > On Saturday, October 28, 2017 at 4:56:42 PM UTC-4, T L wrote: >> >> In my opinion, the memory model article should mention that if event A >> happens event B, >> the the statements shown before event A in source code will be e

Re: [go-nuts] Re: select is still a little unfair if there are more than 4 cases?

On Saturday, October 28, 2017 at 11:11:02 PM UTC-7, John Souvestre wrote: > > Ø Round robin isn't implementable. There's no place to store the state > for an individual select. > > > > Couldn’t a place be allocated? Since it would be local to a goroutine, > put it on the stack. > > > >

[go-nuts] Re: Will a running GC task stop immediately once debug.SetGCPercent(-1) is called?

The runtime will still finish any in-progress garbage collection. debug.SetGCPercent only affects the trigger point (when to start) and the pacing (at what rate to mark the heap). On Monday, November 13, 2017 at 2:40:29 PM UTC-8, T L wrote: > > or runtime will still try to finish the current run

Re: [go-nuts] Understanding panic at addr=0x38 when calling a method on a nil interface

Konstantin, your description is correct. The code is trying to load a function pointer out of an itab, but the pointer to the itab is nil. I think this is actually a bug. If you have an interface with more than pagesize/ptrsize methods in it, this code might not panic when it should. On Monda

Re: [go-nuts] Understanding panic at addr=0x38 when calling a method on a nil interface

Filed issue https://github.com/golang/go/issues/22703 On Monday, November 13, 2017 at 3:50:58 PM UTC-8, Keith Randall wrote: > > Konstantin, your description is correct. The code is trying to load a > function pointer out of an itab, but the pointer to the itab is nil. > I t

Re: [go-nuts] Re: private global un-used variable passing compile - is it intended or a bug?

A private global can be used in assembly. The compiler would not be able to detect that fact. I don't think that's a show-stopper (the compiler has a -complete flag, and the linker might do such detection), but it makes specifying when the toolchain should report an error more complicated. On

[go-nuts] Re: There is definitely a race condition, why it can't be detected by race condition detector?

The race detector has many special cases for packages like sync and runtime, so it can detect synchronization operations. I haven't looked, but I wouldn't be surprised if the race detector ignored package sync's code bodies and just hard coded the semantics of each operation. On Monday, April 2

Re: [go-nuts] If Go is using libc instead of syscalls on macOS now, why is it not shown via otool -L?

I don't have hard numbers on slowdowns. It will depend a lot on the binary in question. At the time I checked the compiler and linker and it did not slow those down (to the accuracy of our benchmarks). The linker particularly is fairly read syscall intensive. We've seen benchmarks that have sig

Re: [go-nuts] Any way to prevent gc emitting AVX256 and AVX512 instructions for amd64?

By the way, these instructions are not generated by the compiler. They are part of the assembly in the stdlib (runtime or internal/bytealg, probably). On Tuesday, May 14, 2019 at 7:37:44 AM UTC-7, Amnon Baron Cohen wrote: > > OK. > Thanks for the explanation and pointers. > > On Tuesday, 14 May 2

[go-nuts] Re: Testing changes to Go SSA?

In addition to the tests you saw, there are a bunch of tests in test/codegen that makes sure specific sequences of instructions are or are not generated. Tests for specific issues that have been fixed are in test/fixedbugs. Generally the whole test suite is one giant compiler test. Run all.bash a

[go-nuts] Re: Testing changes to Go SSA?

In addition to the tests you saw, there are a bunch of tests in test/codegen that makes sure specific sequences of instructions are or are not generated. Tests for specific issues that have been fixed are in test/fixedbugs. Generally the whole test suite is one giant compiler test. Run all.bash a

[go-nuts] Re: Testing changes to Go SSA?

In addition to the tests you saw, there are a bunch of tests in test/codegen that makes sure specific sequences of instructions are or are not generated. Tests for specific issues that have been fixed are in test/fixedbugs. Generally the whole test suite is one giant compiler test. Run all.bash a

Re: [go-nuts] Map of structs vs Array of structs

Note: this issue - assigning to a field of a compound map value - is a proposal at https://github.com/golang/go/issues/3117 > Ian, can you clarify that for me, so the GC tracks interior pointers (to a slice of structs) so that even if there are no references to the outer slice it will not be GC

[go-nuts] Re: Using "map index expressions" as the value for a range loop

I don't think there are any. Because you can do it doesn't mean you should. It's incredibly confusing for readers (hence the confusion in this thread). On Thursday, July 7, 2016 at 8:52:06 AM UTC-7, Kyle Stanly wrote: > > So, what would be the appropriate use-cases for this; I.E, using a map

[go-nuts] Re: escape analysis improvements?

Yes, this is a limitation of the current escape analysis. It doesn't realize that the proto.Buffer can be stack allocated. I suspect this is because b.Marshal is recursive, and escape analysis gives up on recursive things. On Tuesday, March 7, 2017 at 8:22:42 PM UTC-8, apo...@google.com wrote:

Re: [go-nuts] Re: Why copy is much slower than append when clone a slice?

This looks like it is all due to the extra zeroing required for the Copy test. CloneWithAppend does not need to zero the newly allocated slice before copying the contents of x into it. CloneWithCopy does. Benchmark_CloneWithAppend-4 3000480247 ns/op Benchmark_CloneWithCopy-410

Re: [go-nuts] Re: Why copy is much slower than append when clone a slice?

gt; On Tuesday, June 27, 2017 at 8:11:01 PM UTC-7, Keith Randall wrote: >> >> This looks like it is all due to the extra zeroing required for the Copy >> test. CloneWithAppend does not need to zero the newly allocated slice >> before copying the contents of x into it.

Re: [go-nuts] Is the GC recovering storage when full slice expression reduce capacity ?

On Friday, January 10, 2020 at 1:02:22 AM UTC-8, Jan Mercl wrote: > > On Fri, Jan 10, 2020 at 9:52 AM Christophe Meessen > > wrote: > > > > It is possible to reduce the capacity of a slice by using the full slice > expression (https://golang.org/ref/spec#Slice_expressions). > > > > Now cons

Re: [go-nuts] Is the GC recovering storage when full slice expression reduce capacity ?

It can get expensive to do that. Instead of just a mark bit per object, and a queue of pointers to mark, you need a mark bit per word and a queue of ptr+len. You can also end up doing more than constant work per mark. x := [10]*int{ ... 10 pointers ... } a := x[:3:3] b := x[7::] x is now dead, bu

[go-nuts] Re: Proposed additions to maphash documentation

I mailed a small CL for this. It now says "uniform distribution on 64-bit integers". That should imply reduction by masking (or other methods) is fine. https://go-review.googlesource.com/c/go/+/219340 On Sunday, February 9, 2020 at 10:52:22 AM UTC-8, Juliusz Chroboczek wrote: > > It would be hel

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

It looks like the mechanism used by C's std::atomic would not be useful for us. We require release semantics on atomic stores. That is, if one thread does: .. some other writes ... atomic.StoreInt32(p, 1) and another thread does if atomic.LoadInt32(p) == 1 { .. some other reads ... } If t

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

Ah, so I guess we don't need a barrier at all on x86 for the release semantics. Presumably we still need something for Dekker-style algorithms, although I don't think we use those anywhere in the stdlib, at least. I guess it's just a question of which is faster? On Tue, Apr 28, 2020 at 8:24 PM Cho

Re: [go-nuts] Re: Preventing SIGBUS errors when memmove-ing an unsafe.Pointer to multiple destinations

Showing us some code would really help. It's hard to understand what you are doing from this brief description. Also, where does the SIGBUS occur? What pc, and what address? What types are you passing as the first argument to typedmemmove? Where did you get them from? This is a fine question f

Re: [go-nuts] Re: Preventing SIGBUS errors when memmove-ing an unsafe.Pointer to multiple destinations

On Wed, Jun 10, 2020 at 4:15 AM Viktor Kojouharov wrote: > Thanks Ian. Adding to that allocation to cover the element size did the > trick. Out of curiosity, the momery allocated by mallocgc is still tracked > by the gc, right? > A brief look at the code seems to indicate that this is the case,

Re: [go-nuts] [runtime] gostring question

Yes, we can't depend on the data at *p to remain constant. We need to snapshot it at the moment of the gostring call. On Tuesday, June 23, 2020 at 5:52:23 PM UTC-7, Kurtis Rader wrote: > > On Tue, Jun 23, 2020 at 5:32 PM Bill Morgan > wrote: > >> I'm a C programmer so maybe this is a dumb questi

[go-nuts] Re: who is mike?

Mike Burrows https://en.wikipedia.org/wiki/Michael_Burrows On Sunday, June 28, 2020 at 3:51:27 PM UTC-7, Bill Morgan wrote: > > who is mike wrt this commit? > > commit bc0b4f0d2a610059afb95ef0360704714815187d > Author: Ken Thompson > > Date: Thu Nov 13 10:35:44 2008 -0800 > > mike's map code

Re: [go-nuts] [Arm32] float/NaN/int issue (fixed for me, posting for info/discussion/bug report?)

On Wednesday, July 8, 2020 at 4:50:30 PM UTC-7, simon place wrote: > > wait a minute, so this... https://play.golang.org/p/x5SQVgSJsIs > > could return anything! > > I think float -0 should be guaranteed to convert to integer 0. Just like -0.25 and 0.25. The spec says "fraction discarded" but I

[go-nuts] Re: casting arbitrary int to unsafe.Pointer: go test -race (checkptr) complains

Just write a wrapper on the C side (in the import "C" code) that takes a uintptr and casts it to void*. func wrapper(a uintptr, b, c, d, e ...) { op_open_callbacks((void*)a, b, c, d, e) } Then you can call C.wrapper and pass it s.id directly. On Thursday, July 9, 2020 at 4:17:08 PM UTC-7, Hra

Re: [go-nuts] what is walk(fn *Node) for?

In addition to what Jesper said, the walk pass does a variety of lowerings and optimizations on the ast. For example, it rewrites the builtin `new` to a runtime call, rewrites switches to a tree of `if` statements, etc. On Monday, July 20, 2020 at 2:11:08 AM UTC-7 jesper.lou...@gmail.com wrote:

[go-nuts] Re: What's the basic block layout algorithm ?

It's not a fancy algorithm. It tries to layout blocks connected by high-likelihood edges together. It also tries to keep panic paths at the end. I don't know of any documentation for it, other than the code. There's nothing particularly important in the layout pass to help with register allocat

[go-nuts] Re: why the values in ssa block can be unordered?

All the ordering required is explicit in the representation. If x is an argument of y, then x must come before y (in the eventual assembly output). There is no other need for ordering within a basic block. Any order consistent with the argument ordering I mentioned above is ok. On Friday, August

[go-nuts] Re: which pass of SSA will transform a ssa.Value(op=OpPhi) phi operations to a normal(not phi operations)?

The regalloc pass does that. It ensures that all the inputs and the output of a phi are all in the same register (or memory location), so the phi becomes a no-op. The regalloc pass doesn't actually remove the phi, though. Removal is actually in genssa in cmd/compile/internal/gc/ssa.go. Look for

[go-nuts] Re: what is empty block mean in ssa.Block?

Empty here means has-only-dead-values. All the values still in s0 and s1 are known to be dead. On Monday, August 24, 2020 at 8:24:06 AM UTC-7, xie cui wrote: > > > https://github.com/golang/go/blob/master/src/cmd/compile/internal/ssa/fuse.go#L130 > it mention empty block here. in my knowledge, em

Re: [go-nuts] Re: what is empty block mean in ssa.Block?

On Tue, Aug 25, 2020 at 3:10 AM xie cui wrote: > so what's dead value means? in my mind, dead value can be ignore, why we > need to append it to b.Values? > > Dead means no longer used. Their values are ignored. We put them in b.Values so that they get cleaned up properly. See the deadcode pass f

Re: [go-nuts] Heap allocation found in function prolog

That looks like something escaped to the heap. If you pass the -S option to the compiler, the assembly output will have the symbolic name of the type being allocated (at the LEAQ 2 instructions before the call to newobject). If you pass the -m option to the compiler, it will tell you what escaped

[go-nuts] Re: Why gc compiler treat slice and custom type differently in garbage collection?

This ideally shouldn't happen. For some reason the compiler is keeping t.y alive across the printMemStat calls, even when it only needs to keep t.x alive. I've opened an issue https://github.com/golang/go/issues/24263 On Monday, March 5, 2018 at 8:08:59 AM UTC-8, di...@veryhaha.com wrote: > > >

Re: [go-nuts] implementation of sync.atomic primitives

On Monday, March 19, 2018 at 9:30:39 AM UTC-7, thepud...@gmail.com wrote: > > Hi Ian, > > I know you were not giving any type of definitive treatise on how go > treats atomics across different processors... > > but is a related aspect restricting instruction reordering by the compiler > itself?

Re: [go-nuts] Limit goroutine resource usage?

There's no equivalent of the methods you mentioned. You can't limit a goroutine from another goroutine, because (among other reasons) there's no way to name it. A goroutine can limit itself a bit by calling runtime.Gosched, or more forcefully using time.Timer. Andrey's suggestion of limiting ho

Re: [go-nuts] Is conversion between int and uint a no-op i.e. is it free

int<->uint conversions should never generate any machine code. They are free. On Saturday, November 24, 2018 at 10:55:50 AM UTC-8, Andy Balholm wrote: > > There is nothing in the language spec that guarantees anything about > performance. But if logic tells you that it should be a no-op, and >

Re: [go-nuts] Is WASM support planned in go 1.12 ?

To answer the OP, wasm support is in 1.12 and is still experimental. There have been some changes to the wasm support but nothing major. (See the syscall/js section of https://tip.golang.org/doc/go1.12 for details.) On Wednesday, February 6, 2019 at 2:27:53 PM UTC-8, Tharaneedharan Vilwanathan

[go-nuts] Re: Providing more detail after a nil pointer dereference

27605 is more about providing the values that caused the panic, not the source location. It is still the case that even with 27605 multiple indexing operations on the same line are not distinguished (unless knowledge of the application lets you disambiguate using the values). For nil pointer der

[go-nuts] Re: runtime CallerFrames and FuncForPC miss some infomation

FuncForPC misses the test function because it is inlined. Using FuncForPC on the results of Callers does not work correctly in the presence of inlining. That is essentially why CallersFrames was introduced. The function name is missing because you're using the wrong expression for it. You shoul

Re: [go-nuts] sync/atomic and zero-initialization

The garbage collector ensures that after it has zeroed memory, it does proper synchronization to hand off that memory to an allocator. That allocator (and the goroutine on whose behalf it is working) is then guaranteed to see the zeroed memory. That's how heap memory works. Stack memory is a sp

Re: [go-nuts] Re: Accessing *[]uint64 from assembly - strange memory corruption under heavy load - any ideas?

Your assembly looks ok to me. At least, the sections you've shown us. It would help if we could see all of it and/or the whole program. You might want to try putting a len>0 test in the pop and a len > On Fri, Mar 22, 2019 at 10:55 AM Robert Johnstone > > wrote: > > > > I don't see any memory

[go-nuts] Re: Question regarding compiler internals

On Wednesday, September 20, 2017 at 7:51:28 AM UTC-7, Jacob McCollum wrote: > > All, > > This is my first time posting to the golang-nuts mailing list, but I've > hit a wall and I'm not sure where else to reach out for some assistance. > > I'm knee-deep in a research implementation of parameteri

Re: [go-nuts] How to remove a struct value from a struct slice without memory leak?

I see a couple of issues with your code. The code you use for removal of an element is right. You've correctly made sure there is no leak. You never return the clients slice back to the caller. Any length shortening of the clients slice will be lost when the function returns. You might want to

Re: [go-nuts] Can I interpret the Go 1 memroy model as the following described?

I don't think the Go memory model provides any guarantee here. In particular, x==0, y==1 is allowed at the end. There is no happens-before relationship between both of the final reads and either of their writes. So those reads are allowed to observe those writes, or not. The fact that x=1 happ

Re: [go-nuts] corrupt stack?

package main // Convert an *A to a *B, using a data race. // Works for any types A and B. func cast(a *A) *B { var x interface{} go func() { for i := 0; i < 10; i++ { x = a } }() go func() { var b *B for i := 0; i < 10; i++ { x = b } }() for i := 0; i < 10; i++ { b, ok := x.(*B) if o

Re: [go-nuts] GC Internals Questions

Pointers that point from a Go object to somewhere outside the Go heap are perfectly fine. The Go runtime will not try to dereference them. unsafe.Pointer is ok, but so are concrete types, like *byte. One caveat: the pointer must be a real pointer. Don't store a bunch of bitfields in a Go pointer

Re: [go-nuts] Go if else syntax .. suggested replacement

On Wednesday, April 24, 2019 at 2:03:01 PM UTC-7, Kurtis Rader wrote: > > On Wed, Apr 24, 2019 at 1:14 PM andrey mirtchovski > wrote: > >> Here's the lore associated with the subject: Ken wanted ternary, Rob >> and Robert did not. They overruled Ken (remember, early on all three >> had to agree

[go-nuts] Re: Concurrent Routines in WASM

No, it doesn't. Do wasm threads exist yet? When the wasm port was first developed, they didn't exist. If the spec is now complete, we would just need a builder than can test threads, and then we would implement threading support in tip (for 1.14, presumably). Feel free to submit patches. It loo

Re: [go-nuts] Tools for developing Go compiler/ Go code from SSA

On Wed, Jul 3, 2019 at 9:04 PM Ian Lance Taylor wrote: > [ +khr ] > > On Wed, Jul 3, 2019 at 4:46 PM Mohit Verma wrote: > > > > Hi All, > > > > I am trying to change the ssa phase of Go compiler to do extra work > during memory stores. > > For example whenever there is a memory store, I want to

Re: [go-nuts] Tools for developing Go compiler/ Go code from SSA

ntime > seemed inefficient to me, and I thought the Go team might be doing things > differently during their development/debug. > > Thanks! > Mohit > > On Wed, Jul 3, 2019 at 9:24 PM Keith Randall wrote: > >> >> >> On Wed, Jul 3, 2019 at 9:04 PM Ian Lance Taylor wrote

Re: [go-nuts] Tools for developing Go compiler/ Go code from SSA

invoked > during compileSSA() in gc/pgen.go. > > It's inserted by the compiler, I believe. cmd/internal/obj.Flushplist is called from (*Progs).Flush in cmd/compile/internal/gc/gsubr.go > > Thanks a lot! > Mohit > > > On Fri, Jul 5, 2019 at 11:32 AM Keith Randall wrote: >

[go-nuts] Re: SSA-able and canSSA meaning in Go compiler's SSA backend?

On Wednesday, September 18, 2019 at 1:50:27 PM UTC-7, Mohit Verma wrote: > > Hi All, > > I was reading Go compiler's SSA backend code at > cmd/compile/internal/gc/ssa/go > > & > cmd/compile/internal/ssa >

Re: [go-nuts] Clarification on unsafe conversion between string <-> []byte

In the runtime we use structs like these, but with unsafe.Pointer data fields (runtime.stringStruct and runtime.slice). They are much safer to use than reflect's types with uintptr Data fields. Unfortunately we can't change reflect's types because of the Go 1 compatibility guarantee. You can do

[go-nuts] Re: Two Related Questions. (1) Map Concurrency (2) Making Multidimensional Arrays

Tamás's suggestion of using [4]string as the key is a good one. You could use any struct you want as well, if you want to name the parts of the key. How are you using the map? If you're only reading the map, then concurrent access is allowed. Concurrent access is only forbidden if one of the

[go-nuts] Re: Concurrently read map entries into a channel

On Saturday, November 5, 2016 at 7:48:27 AM UTC-7, leob...@gmail.com wrote: > > Hey, > > I have a scenario where I need to iterate over (as many as possible) map > entries and send them into a channel. > The operation on the other end of the channel can take a long time, so > sends on the chann

Re: [go-nuts] CFG for a Go program

You can get the CFG (control flow graph) for a function by setting the environment variable GOSSAFUNC to the function in question when building. It will generate a file named ssa.html in the current directory which you can load into a browser. It doesn't draw the CFG explicitly but the nodes (b

Re: [go-nuts] Re: Eliminating redundant map lookups

Yes, it currently requires two lookups (two hashes, two bucket searches, etc.). This general problem is issue 17133 (https://github.com/golang/go/issues/17133). Your example has the extra complication that the update operation is an append, not just a +=. On Sunday, November 27, 2016 at 7:00

[go-nuts] Re: Simple Go program that doesn't seem to free memory as it should...

I think what is going on is this. y := []*int{&x[0]} compiles to: var z [1]*int // allocate backing array p = &z // take its address p[0] = &x[0] // initialize it y := z[:]// slice it Because z has its address taken, we conservatively assume that z lives

[go-nuts] Re: Another runtime.KeepAlive question

On Friday, December 30, 2016 at 1:26:26 PM UTC-8, Justin Israel wrote: > > Hi, > > Regarding this thread: > https://forum.golangbridge.org/t/curious-about-runtime-keepalive-usage/3530 > > And also the original problem example from Russ: > https://github.com/golang/go/issues/15277#issuecomment-221

[go-nuts] Re: Accessing an slice is too slow than Array

You're not really testing what you think you are testing. When you do "_ = load something", the compiler just throws away the load. You have to use the result somehow to keep the load in the final assembly. What you are actually timing is the speed of the modulo operator (%). For the pointer c

[go-nuts] Re: Efficient ForEach() on a map protected by a mutex

On Friday, January 6, 2017 at 5:12:54 PM UTC-8, tsuna wrote: > > Hi there, > I have a struct that contains an unexported map protected by a mutex, > let’s say something like: > > type Map struct { > mtx sync.Mutex > col map[string]interface{} > } > > I want to implement a ForEach method that wor

Re: [go-nuts] Bitmasks on signed types

I do x & (0x - 1<<32). On Tuesday, June 14, 2016 at 1:44:14 PM UTC-7, Michael Jones wrote: > > I have fought this many times. > > What I almost always do is cast all variables involved as unsigned so that > I can express the logical operations as desired. The exception is right > shift

Re: [go-nuts] Re: [ANN] primegen.go: Sieve of Atkin prime number generator

Looks like something is wrong with immediate loading for the 1 << ... operation. Could you open a bug with repro instructions? I can look at it when 1.8 opens. On Thursday, June 16, 2016 at 5:30:12 PM UTC-7, gordo...@gmail.com wrote: > > > Modern x86 CPUs don't work like that. > > > In genera

Re: [go-nuts] [ANN] primegen.go: Sieve of Atkin prime number generator

On Monday, June 20, 2016 at 6:33:29 AM UTC-7, gordo...@gmail.com wrote: > > Further to the subject of compiler efficiency, the following is the > assembler code output with array bounds checking turned off (-B) the the > inner tight composite culling loop of FasterEratspeed above (generated wit

Re: [go-nuts] Will go compiler do optimization here if "bytes" is a global variable?

This was a concern when we originally implemented the m[string(b)] optimization. If someone is simultaneously modifying b, then weird things happen during the lookup. But it won't crash anything, just maybe not return what you expect. And that's ok in cases of a data race, the spec makes no

Re: [go-nuts] Will go compiler do optimization here if "bytes" is a global variable?

Yes, it is. The optimization occurs for any occurrence of m[string(expression of type []byte)]. Where the byte slice came from (global or otherwise) is irrelevant. On Monday, July 25, 2016 at 8:37:03 AM UTC-7, T L wrote: > > @Randall, thanks for answer. > You mean the answer is yes, right? --

Re: [go-nuts] Re: Is there a reason go doesn't use the small string optomization

I wrote up a proto-proposal for something like this a while ago. https://docs.google.com/a/google.com/document/d/18nu6QTr-ACYr5AiyP6x31SkXvuJZZaZ12lnvPTEQfgQ/pub It has a few numbers worth looking at in it. This proposal was before the fully precise GC we have today. It needs to have special G

Re: [go-nuts] Re: Is there a reason go doesn't use the small string optomization

> > On Wed, Feb 1, 2017 at 5:18 PM, 'Keith Randall' via golang-nuts > wrote: > > I wrote up a proto-proposal for something like this a while ago. > > > > https://docs.google.com/a/google.com/document/d/18nu6QTr- > ACYr5AiyP6x31SkXvuJZZaZ12lnvPTEQfgQ/pu

[go-nuts] Re: Unsafe string/slice conversions

On Thursday, March 23, 2017 at 4:24:40 PM UTC-7, Caleb Spare wrote: > > That's very good to know. Thanks, Ian. > > Unfortunately if I use this KeepAlive-based fix, p escapes and so the > function now allocates. I guess I'll stick with the original version > from my first email. > > Does this

Re: [go-nuts] Questions about assembly and calling conventions

The FP pseudoreg has been dropped from assembly output (on tip). All offsets are from SP. On previous versions the assembly output reported the base register as FP but the offset was from SP. See https://github.com/golang/go/issues/19458 and referents. On Friday, March 24, 2017 at 12:01:06 PM

Re: [go-nuts] Re: Unsafe string/slice conversions

; overwritten by subsequent functions that are pushed on the stack. > > On Thursday, March 23, 2017 at 9:05:48 PM UTC-4, Caleb Spare wrote: >> >> Filed: https://github.com/golang/go/issues/19687 >> >> On Thu, Mar 23, 2017 at 4:41 PM, 'Keith Randall'

[go-nuts] Re: Assembly jump instruction operands

I think you're talking about conditional branches 0x008c 00140 (s.go:7) JLT $0, 55 There is sometimes an optional constant $0 or $1 in addition to the destination. $0 means the branch is considered unlikely. $1 means the branch is considered likely. There's really no reason why the assembly o

[go-nuts] Re: Assembly jump instruction operands

https://github.com/golang/go/issues/19718 On Saturday, March 25, 2017 at 4:42:31 PM UTC-7, Keith Randall wrote: > > I think you're talking about conditional branches > > 0x008c 00140 (s.go:7) JLT $0, 55 > > There is sometimes an optional constant $0 or $1 in addition to

[go-nuts] Re: memclr optimization and structs

The value being zeroed must not have any pointers. This is a change from 1.7 and is part of the requirement for the hybrid write barrier (part of making garbage collection pauses smaller). On Friday, April 14, 2017 at 4:02:24

Re: [go-nuts] Re: memclr optimization and structs

AM UTC-7, T L wrote: > > > > On Saturday, April 15, 2017 at 7:18:51 PM UTC+8, Konstantin Khomoutov > wrote: >> >> On Sat, 15 Apr 2017 01:31:27 -0700 (PDT) >> "'Keith Randall' via golang-nuts" wrote: >> >> > > I'v

[go-nuts] Re: about the []byte -> string comversion optimization, is it some weird?

This is a weird corner case in string concatenation optimization. runtime.concatstrings (what the + in this code gets rewritten to) has an optimization where if all the strings but one that it is concatenating are 0 length, then it returns the remaining one without doing any allocation. Because

[go-nuts] Re: about the []byte -> string comversion optimization, is it some weird?

On Wednesday, April 19, 2017 at 3:56:21 AM UTC-7, T L wrote: > > > > On Wednesday, April 19, 2017 at 3:37:29 AM UTC+8, Keith Randall wrote: >> >> This is a weird corner case in string concatenation optimization. >> >> runtime.concatstrings (what the + in

[go-nuts] Re: Large GC pauses with large map

It is almost never a good idea to call runtime.GC explicitly. It does block until a garbage collection completes. This behavior is sometimes useful in tests, but almost never otherwise. If it weren't for go1 compatibility, we'd rename this function to something that more clearly spells out its

Re: [go-nuts] Re: Will deleting a key from a map in an iteration prevent some keys being iterated in the same iteration?

Yes, all keys present in the map at the start of iteration, that aren't deleted during iteration, will be returned during iteration. On Monday, May 1, 2017 at 4:51:56 AM UTC-4, T L wrote: > > > > On Monday, May 1, 2017 at 3:56:51 PM UTC+8, Paul Jolly wrote: >> >> I think the part of the spec you'

[go-nuts] Re: Unexpected need to use runtime.KeepAlive().

On Sunday, May 7, 2017 at 8:21:38 AM UTC-7, Bruno Albuquerque wrote: > > I have this struct that has an associated method that simply call a C > function that might take a long time to use. It is defined more or less > like this: > > import "C" > > type Indexer struct { > cIndexer *C.Indexer

[go-nuts] Re: [Assembler] How can I call SIMD immediate by FP?

The immediate goes first, like this: SHUFPD $1, X1, X2 Note that SHUFPD takes an immediate for the shuffle - I don't see how you can implement the function you want; it takes a dynamic shuffle argument. Unless you do a switch on all possible values of the immediate. On Tuesday, June 13, 2017 at

[go-nuts] Re: Go's scheduler always “stuck” after certain time when executing the code below

The reason why the other goroutines can't run is garbage collection. Because there is one goroutine that's not responding to the runtime's stop request, the runtime can't finish the garbage collection. That outstanding goroutine might have pointers to otherwise unreachable objects. The runtime

[go-nuts] Re: Attaching a Finalizer to a struct field holding a slice or the slice's underlying array

It should work to just set the finalizer on the first byte of an allocation. i.e.: s := make([]byte, N) runtime.SetFinalizer(&s[0], func(b *byte) { ... }) Note that the spec of runtime.SetFinalizer doesn't actually guarantee that this will work. But I think in the current implementation it will

  1   2   >