Re: [go-nuts] Re: Go 1.18 Beta 1 is released

2021-12-15 Thread 'Austin Clements' via golang-nuts
Jan, assuming you're running on an AMD CPU, this is go.dev/issue/34988 (if you're not running on an AMD CPU, that would be very interesting to know!) The TL;DR is that this appears to be a kernel bug, and we have a C reproducer, but we do not yet have a fix or a workaround. On Wed, Dec 15, 2021

Re: [go-nuts] Re: Considering dropping GO386=387

2020-07-16 Thread 'Austin Clements' via golang-nuts
Thanks for that data point, Nick. It's a good idea to make the build fail if GO386 is set to 387 if we drop support. It already fails if GO386 is set to any unsupported value, but we could continue to check GO386 even though there would only be one supported value, and perhaps give a nicer error

[go-nuts] Considering dropping GO386=387

2020-07-14 Thread 'Austin Clements' via golang-nuts
Hi everyone. We’re exploring the possibility of dropping 387 floating-point support and requiring SSE2 support for GOARCH=386 in the native gc compiler, potentially in Go 1.16. This would raise the minimum GOARCH=386 requirement to the Intel Pentium 4 (released in 2000) or AMD Opteron/Athlon 64

Re: [go-nuts] Change in virtual memory patterns in Go 1.12

2019-04-16 Thread 'Austin Clements' via golang-nuts
On Tue, Apr 16, 2019 at 1:23 AM Rémy Oudompheng wrote: > Thanks Austin, > > The application workload is a kind of fragmentation torture test as it > involves a mixture of many long-lived small and large (>100 MB) > objects, with regularly allocated short-lived small and large objects. > I have

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

2019-04-09 Thread 'Austin Clements' via golang-nuts
Acquiring a mutex while pinned can cause deadlock because pinning prevents a stop-the-world. For example, the following sequence could result in a deadlock: M1: Acquires mutex l. M2: Pins the M. M2: Attempts to acquire mutex l. M3: Initiates stop-the-world M3: Stops M1 M3: Attempts to stop M2,

Re: [go-nuts] Change in virtual memory patterns in Go 1.12

2019-04-02 Thread 'Austin Clements' via golang-nuts
Hi Rémy. We often fight with vm.max_map_count in the runtime, sadly. Most likely this comes from the way the runtime interacts with Linux's transparent huge page support. When we scavenge (release to the OS) only part of a huge page, we tell the OS not to turn that huge page frame back into a huge

Re: [go-nuts] runtime.GC - documentation

2016-11-30 Thread 'Austin Clements' via golang-nuts
On Tue, Nov 29, 2016 at 6:57 PM, Rick Hudson wrote: > That is correct. ... but not guaranteed. :) -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an