I've opened an issue: https://github.com/golang/go/issues/27180
--
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 email
to golang-nuts+unsubscr...@googlegroups.com.
For more
On Tuesday, August 21, 2018 at 7:31:28 AM UTC+2, Keith Randall wrote:
>
> 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,
>
> Another question: Why does the nil check take two instructions. Can't it
> be done using MOVQ?
>
Scratch that. That was nonsense.
--
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
Forgot the ssa.html
--
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 email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/
Dear all,
I stumbled over a strange performance degradation when using unsafe
pointers. I took a look at the assembly and was surprised to see a number
seemingly redundant nil checks using the LEAQ and TESTB instructions.
A minimal reproducer is the following function:
func getOff(a *uint64, i
>
> From the GC POV, the only interesting thing about an unsafe.Pointer is if
> its value falls anywhere into a GC managed memory block for liveness
> analysis, AFAIK.
>
And then it will check that memory block for stuff that looks like a
pointer (not caring what the actual type being pointed t
>
> The garbage collector does not care about the values of items of a []T
> when T is not a pointer type nor a type containing transitively any
> pointers.
>
Just to make sure I understand you correctly. Are you saying I could hold
an unsafe.Pointer to an array of uint64 and the GC will still
Thanks Axel.
Good to know the first part. I have a couple of comments regarding your
answer to the second part.
In regards to your second question: That would require having an array type
> for every possible size, which isn't really tenable.
>
The idea was to use the same array type (`[(^uint
Mistake in the second struct. The data field should have the type:
*[(^uint(0)) >> 17]uint64
--
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 email
to golang-nuts+unsubscr
Dear all,
I have some questions concerning the implementation details of the garbage
collector regarding slices and arrays.
I'm implementing bit slices. The current approach is to use the following
struct:
type BitSlice {
data []uint64
len int
}
Given that the slices length and capacity are
type T struct {
F struct{ lots, of, fields int }
}
func main() {
var _ T.F
}
https://play.golang.org/p/qjoKIQ0TAG
If T.F just resolved to the underlying type struct{ lots, of, fields int } I
could stop littering my code with helper types.
Does anyone know if this would create problems? I expect
See my previous answer to ohir for a less convoluted and less specific
problem statement. My problem does not seem to be related to being inside
or outside a GOPATH.
> Dependencies are derived from import paths. Import paths are not complete
> paths. They are transformed to complete paths by
Thanks for the suggestions. I may not have explained the setup well enough.
I don't think your suggestions work if you just have your code in a folder
without any additional structure (no src directory).
But your first suggestion prompted my to play around with having the
package in a GOPATH and
Hi everyone,
I never bothered too much with the details of "go get" until the issue
recently came up in a conversation with another developer who was also
annoyed by the clumsiness of the go tool in practice. I often work with
programs that are not in a GOPATH, but import some non-local package
I tried googling this, but couldn't find anything.
A common issue when using the http package and registering handles is the
need to register a handler for "domain.com" that does not catch
"domain.com/otherStuff". Since any pattern ending in a "/" matches paths
prefixed with the pattern, providi
I just want to leave my solution here, since I am sure I am not the last
person to run into this.
The issue (as others have suggested and initially assumed) is indeed that
go expects a pointer where there is none. This only leads to errors when
the GC scans the stack if I interpret my results c
Well, I am pretty sure I was wrong about something. Turning of the garbage
collector results in no error. Any smart ideas for debugging this?
On Sunday, December 18, 2016 at 4:20:25 PM UTC+1, Florian Uekermann wrote:
>
> I may be misdiagnosing the problem, but I think go is doing a problematic
>
I forgot to ask another question.
If solving this is not practical in go, should I bring this up with the
Vulkan people?
I don't really understand why they don't use uint64_t regardless of
architecture.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts"
I may be misdiagnosing the problem, but I think go is doing a problematic
check of the value of C pointer types pointers.
The following runtime error is reproducible, but does not always happen in
a program:
runtime: writebarrierptr *0xc420326a90 = 0x12
fatal error: bad pointer in write barrie
>
> You wrote `*X.Y`; I'm going to assume you meant to write `*X = Y`.
>
*X.Y = value
, where the Y field is a pointer to the C heap. But I suppose that is
pretty much the same.
> This error message is telling you that in the assignment `*X = Y` Y
> has a pointer type, but has the value 1.
I just had a fairly strange not reproducible panic. I have no idea whether
this could be a go bug or if the C library I am using is buggy. In case it
looks like a go bug I should probably post this on the issue tracker. Does
anyone have an idea whether this is useful or if I should just forget a
21 matches
Mail list logo
