Re: [go-nuts] Create a 1GB ballast but it takes up RSS and pages are Dirty?

Hi, guys, I know what happened. When we write `ballast := make([]byte, 1<<30)`, it will call makeslice to create a new slice. It's a large object. The memory will be allocated directly via allocLarge() function from heap. Actually, after allocating a mspan for it, it will check the address

Re: [go-nuts] Generics: Using runtime.FuncForPC() to get method name doesn't *seem* to work

Note for posterity: Other methods of method equality fall in the same problem, such as detailed in: https://stackoverflow.com/questions/9643205/how-do-i-compare-two-functions-for-pointer-equality-in-the-latest-go-weekly Proof: https://go.dev/play/p/aeeRKfderY2 On Monday, November 7, 2022 at

[go-nuts] Goroutine to thread mapping

Hello, A goroutine needs ultimately to be assigned to an OS thread. If a goroutine calls an assembly function F, can the thread assignment change during the execution of F? In other words, is F guaranteed to return on the same thread it was called? Best regards, Piotr -- You received

Re: [go-nuts] Generics: Using runtime.FuncForPC() to get method name doesn't *seem* to work

On Mon, Nov 7, 2022 at 9:24 AM John wrote: > > Or maybe I'm just doing something wrong. > > I have a struct implementing generics where methods return the next method to > execute. > > For tests, I wanted to make sure the returned method was the one expected, so > I was using this: > >

Re: [go-nuts] Occasional hard lockup w/ 100% CPU usage in go applications

FWIW - I opened a bug with the go core team and after some discussion one of them suggested I build the program specifying "GOARM=7". It appears to have resolved the issue - I've been running the full stack of programs on two different units (Pi 4 Model B, CM4) for the past week without any

Re: [go-nuts] Goroutine to thread mapping

Go makes no guarantees about the affinity between goroutines and threads, and the mapping does typically jump around a lot during the execution of a program. On Monday, 7 November 2022 at 17:46:42 UTC ren...@ix.netcom.com wrote: > Do you mean Go assembly or an assembly function called via

[go-nuts] Generics: Using runtime.FuncForPC() to get method name doesn't *seem* to work

Or maybe I'm just doing something wrong. I have a struct implementing generics where methods return the next method to execute. For tests, I wanted to make sure the returned method was the one expected, so I was using this: nextStageName :=

Re: [go-nuts] Goroutine to thread mapping

Do you mean Go assembly or an assembly function called via CGo? > On Nov 7, 2022, at 11:28 AM, Piotr Wyderski wrote: > >  > Hello, > > A goroutine needs ultimately to be assigned to an OS thread. If a goroutine > calls an assembly function F, can the thread assignment change during the >

Re: [go-nuts] Generics: Using runtime.FuncForPC() to get method name doesn't *seem* to work

Thanks Ian for being generous with your time in answering this. I'll see if I can drum up another way to make that check work. Cheers and have a good rest of your day. On Monday, November 7, 2022 at 10:02:28 AM UTC-8 Ian Lance Taylor wrote: > On Mon, Nov 7, 2022 at 9:24 AM John wrote: > > >

Re: [go-nuts] Goroutine to thread mapping

You can use runtime.LockOSThread() to control this. > On Nov 7, 2022, at 12:01 PM, Amnon wrote: > > Go makes no guarantees about the affinity between goroutines and threads, > and the mapping does typically jump around a lot during the execution of a > program. > >> On Monday, 7 November

Re: [go-nuts] Occasional hard lockup w/ 100% CPU usage in go applications

All sounds probable reasonable. https://wiki.archlinux.org/title/Core_dump has additional options that may help generate the core dump. Still, if the process is stuck in the kernel, the only option should be a kill signal. If the other signals can