I'm not making any function calls in the assembly, just writing to memory
addresses that represent the elements / len of the slice. I've also tried
using LockOSThread() to see if that made any difference, alas it does not.
On Friday, March 22, 2019 at 4:59:30 AM UTC-7, Robert Engels wrote:
>
>
The assembly should never write to a position / update the len beyond the
backing array (specifically, the assembly is generated from code where the
'max stack depth' has been computed and validated, and the capacity of the
slice is that size).
On Friday, March 22, 2019 at 5:39:36 AM UTC-7,
On Friday, March 22, 2019 at 12:27:37 AM UTC-5, Tom wrote:
>
> The allocation is in go, and assembly never modifies the size of the
> backing array. Assembly only ever modifies len, which is the len of the
> slice and not the backing array.
>
>
Can the assembly ever modify len to a size greater
Are you making any calls modifying the len that would allow GC to occur, or
change stack size? You might need to pin the Go routine so that the operation
you are performing is “atomic” with respect to those.
This also sounds very scary if the Go runtime every had a compacting collector.
> On
The allocation is in go, and assembly never modifies the size of the
backing array. Assembly only ever modifies len, which is the len of the
slice and not the backing array.
On Thursday, 21 March 2019 22:18:29 UTC-7, Tamás Gulácsi wrote:
>
> 2019. március 22., péntek 6:06:06 UTC+1 időpontban
2019. március 22., péntek 6:06:06 UTC+1 időpontban Tom a következőt írta:
>
> Still errors I'm afraid :/
>
> On Thursday, 21 March 2019 21:54:59 UTC-7, Ian Lance Taylor wrote:
>>
>> On Thu, Mar 21, 2019 at 9:39 PM Tom wrote:
>> >
>> > I've been stuck on this for a few days so thought I would
Still errors I'm afraid :/
On Thursday, 21 March 2019 21:54:59 UTC-7, Ian Lance Taylor wrote:
>
> On Thu, Mar 21, 2019 at 9:39 PM Tom >
> wrote:
> >
> > I've been stuck on this for a few days so thought I would ask the brains
> trust.
> >
> > TL;DR: When I have native amd64 instructions
On Thu, Mar 21, 2019 at 9:39 PM Tom wrote:
>
> I've been stuck on this for a few days so thought I would ask the brains
> trust.
>
> TL;DR: When I have native amd64 instructions mutating (updating the len +
> values of a []uint64) a slice, I experience spurious & random memory
> corruption
I've been stuck on this for a few days so thought I would ask the brains
trust.
*TL;DR: *When I have native amd64 instructions mutating (updating the len +
values of a []uint64) a slice, I experience spurious & random memory
corruption when under heavy load (# runnable goroutines > MAXPROCS,
