You could change the limit by editing src/pkg/runtime/malloc.goc
Look for '16LL<<30'.
Russ
What is the downside of increasing this? (Why not set it to 16e15 or 2^63?)
Is there a system limit to how much virtual space can be reserved?
Is there a reason the allocator has to use a contiguous block?
John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk5BORYACgkQJdeBCYSNAAM6TQCgvXizp4dSQz8DA+UAZfP9NATr
XF8AnRa6hzwvo7lBinj2XADf9ydG+SuI
=UFRT
-----END PGP SIGNATURE-----
It takes the address space away from other things,
like C code running in the same address space due to cgo.
> Is there a system limit to how much virtual space can be reserved?
Yes. 64-bit chips have 47-bit user address spaces.
> Is there a reason the allocator has to use a contiguous block?
It makes address calculations much easier.
In addition to the 16 GB of memory there is a
1 GB block below that is essentially a big bitmap
tracking properties of the 16 GB. Having it all
contiguous makes mapping from one to the other
very simple arithmetic.
Russ
Is there any plan (or consideration) for a more dynamic approach to
reservation? - either compiler option/environment variable during build
or an equivalent to the environment variable GOMAXPROCS for setting this
limit during runtime (or other approaches).
thanks
Dan
I'd rather do the right thing automatically.
One possibility is to try to grow the space
every 16 GB. As long as nothing else has
taken it, we could then keep going.
Russ
I created issue 2142.
Dan
> Why not start with, let's say, 64MB, and they grow as 128MB, 256MB...?
It's only address space, not real memory, so there's no specific need
to conserve it. However, if we started out small and grew, then the OS
could allocate nearby pieces to other things (e.g. cgo-run code), and
so to increase our address space we'd need to get a non-contiguous
lump. That makes the address computations harder (we'd need lookup
tables, etc.), so we would want to minimise how much we need to do
that.
Dave.
I deal with dynamic verification tools that reserve 16TB on a routine basis
thanks
Dan