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
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
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
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
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,
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
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