On Friday, June 11, 2021 at 2:00:03 PM UTC-4 Ian Lance Taylor wrote:
> On Fri, Jun 11, 2021 at 9:38 AM tapi...@gmail.com <tapi...@gmail.com>
> wrote:
> >
> > package allocate
> >
> > import "testing"
> > import "os"
> > import "fmt"
> >
> > func init() {
> > fmt.Println("OS page size:", os.Getpagesize())
> > }
> >
> > var r1 []byte
> >
> > func BenchmarkCount1(b *testing.B) {
> > for i := 0; i < b.N; i++ {
> > r1 = make([]byte, 32768+1)
> > }
> > }
> >
> > var r2 []byte
> >
> > func BenchmarkCount2(b *testing.B) {
> > for i := 0; i < b.N; i++ {
> > r2 = make([]byte, 40)
> > }
> > }
> >
> > The output:
> >
> > OS page size: 32768
> > BenchmarkCount1-4 166443 7312 ns/op 40960 B/op 1 allocs/op
> > BenchmarkCount2-4 31465389 36.88 ns/op 48 B/op 1 allocs/op
> >
> > In fact, a memory block with size 36864 is enough to carry the elements
> of a byte slice with size 32768+1. Why to allocate one more page for them?
>
> Memory blocks larger than 32768 bytes flip over to the "large
> allocation" model. See _MaxSmallSize in runtime/sizeclasses.go (a
> generated file). This requires an extra span. I haven't tried to
> work it out in detail, but it probably has something to do with that.
>
> Ian
>
Yes, that is why I chose a size 32768+1.
I understand that the large memory block will be a multiple of page size.
What I haven't get is why one more page is allocated.
I will try to read the source to get the answer.
BTW, sorry, I missed a "more" in the thread title.
--
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/273df47e-9fc7-43de-85c3-751937588e52n%40googlegroups.com.
