gc uses different comparation operators to compare some thredshold values

[tapi...@gmail.com]

The code: https://github.com/golang/go/blob/cca23a73733ff166722c69359f0bb45e12ccaa2b/src/cmd/compile/internal/escape/escape.go#L2012-L2025

xxx > ir.MaxStackVarSize

xxx >= ir.MaxImplicitStackVarSize

This leads to the elements of a slice with size as ir.MaxImplicitStackVarSize will be allocated on heap, but an array with size as ir.MaxStackVarSize will be allocated on stack.

Is this intended?

[tapi...@gmail.com]

Sorry, a typo in title. It should be "comparison".

[Axel Wagner]

Out of interest, I chased this down a bit using `git blame`. I think the code in its current form (more or less - some constants where introduced later and things where moved around a bit here and there) was introduced here:

https://go-review.googlesource.com/c/go/+/10268/

It seems checks from multiple places where consolidated into one. One of these checks was `n.Type.Width > MaxStackVarSize` another was `!(n.Type.Type.Width < 1<<16`), which then got rewritten into `n.Type.Type.Width >= 1<<16` to avoid the negation, which eventually became the code you looked at.

Before that commit, it's not clear to me where this specific condition was taken from.

So, from what I can tell, it's an artifact of these two things being written by different people and then evolving over a long time into the same place via a sequence of semantics-preserving small refactorings. I don't think there is a technical reason they should be different but I also assume that it's not worth it to make them the same - it doesn't really matter if we move things to the heap one byte earlier or later, only the order of magnitude is important.

But I might be wrong about all of this. I don't really understand the purpose of you diving so deep into the escape analysis behavior and then asking *extremely* detailed questions like this (though I am always curious to see if you could find the answer yourself, which is why I dove into the git history). ISTM if this causes a problem, the best way to address it would be to file a bug. And if it's just curiosity, you can always try and change it and see what breaks. Go has a lot of tests.

--
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...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/d26fec6c-03ba-4ea2-aa03-4e47f0980660n%40googlegroups.com.

[tapi...@gmail.com]

I agree this is not a real problem in practice. It is just an aesthetics problem.

No tests are broken if the consistency is made.

BTW, in the function "walkStringToBytes", there is a comparison "len(sc) <= int(ir.MaxImplicitStackVarSize)",

which is inconsistent with other uses of MaxImplicitStackVarSize.

[Axel Wagner]

Yeah, I noticed that and wondered if it could lead to problems. I don't know enough about how the compiler works to know if it could. Personally, I would think it would likely be better to be consistent either way. But I'll let someone who knows more take this one.

To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/b8490ef4-31f0-4239-8545-9b9f89e0633dn%40googlegroups.com.