Change the compiler handle append as the gc compiler does: call a
function to grow the slice, but otherwise assign the new elements
directly to the final slice.
For the current gccgo memory allocator the slice code has to call
runtime_newarray, not mallocgc directly, so that the allocator sets the
TypeInfo_Array bit in the type pointer.
Rename the static function cnew to runtime_docnew, so that the stack
trace ignores it when ignoring runtime functions. This was needed to
fix the runtime/pprof tests on 386.
Reviewed-on: https://go-review.googlesource.com/32218
From-SVN: r241667
I started to copy the Go 1.7 interface code, but the gc and gccgo
representations of interfaces are too different. So instead I rewrote
the gccgo interface code from C to Go. The code is largely the same as
it was, but the names are more like those used in the gc runtime.
I also copied over the string comparison functions, and tweaked the
compiler to use eqstring when comparing strings for equality.
Reviewed-on: https://go-review.googlesource.com/31591
From-SVN: r241384
This replaces mem.go and the C runtime_ReadMemStats function with the Go
1.7 mstats.go.
The GCStats code is commented out for now. The corresponding gccgo code
is in runtime/mgc0.c.
The variables memstats and worldsema are shared between the Go code and
the C code, but are not exported. To make this work, add temporary
accessor functions acquireWorldsema, releaseWorldsema, getMstats (the
latter known as mstats in the C code).
Check the preemptoff field of m when allocating and when considering
whether to start a GC. This works with the new stopTheWorld and
startTheWorld functions in Go, which are essentially the Go 1.7
versions.
Change the compiler to stack allocate closures when compiling the
runtime package. Within the runtime packages closures do not escape.
This is similar to what the gc compiler does, except that the gc
compiler, when compiling the runtime package, gives an error if escape
analysis shows that a closure does escape. I added this here because
the Go version of ReadMemStats calls systemstack with a closure, and
having that allocate memory was causing some tests that measure memory
allocations to fail.
Reviewed-on: https://go-review.googlesource.com/30972
From-SVN: r241124
Remove the old locking code written in C.
Add a shell script mkrsysinfo.sh to generate the runtime_sysinfo.go
file, so that we can get Go copies of the system time structures and
other types.
Tweak the compiler so that when compiling the runtime package the
address operator does not cause local variables to escape. When the gc
compiler compiles the runtime, an escaping local variable is treated as
an error. We should implement that, instead of this change, when escape
analysis is turned on.
Tweak the compiler so that the generated C header does not include names
that start with an underscore followed by a non-upper-case letter,
except for the special cases of _defer and _panic. Otherwise we
translate C types to Go in runtime_sysinfo.go and then generate those Go
types back as C types in runtime.inc, which is useless and painful for
the C code.
Change entersyscall and friends to take a dummy argument, as the gc
versions do, to simplify calls from the shared code.
Reviewed-on: https://go-review.googlesource.com/30079
From-SVN: r240657
This change removes the gccgo-specific hashmap code and replaces it with
the hashmap code from the Go 1.7 runtime. The Go 1.7 hashmap code is
more efficient, does a better job on details like when to update a key,
and provides some support against denial-of-service attacks.
The compiler is changed to call the new hashmap functions instead of the
old ones.
The compiler now tracks which types are reflexive and which require
updating when used as a map key, and records the information in map type
descriptors.
Map_index_expression is simplified. The special case for a map index on
the right hand side of a tuple expression has been unnecessary for some
time, and is removed. The support for specially marking a map index as
an lvalue is removed, in favor of lowering an assignment to a map index
into a function call. The long-obsolete support for a map index of a
pointer to a map is removed.
The __go_new_map_big function (known to the compiler as
Runtime::MAKEMAPBIG) is no longer needed, as the new runtime.makemap
function takes an int64 hint argument.
The old map descriptor type and supporting expression is removed.
The compiler was still supporting the long-obsolete syntax `m[k] = 0,
false` to delete a value from a map. That is now removed, requiring a
change to one of the gccgo-specific tests.
The builtin len function applied to a map or channel p is now compiled
as `p == nil ? 0 : *(*int)(p)`. The __go_chan_len function (known to
the compiler as Runtime::CHAN_LEN) is removed.
Support for a shared zero value for maps to large value types is
introduced, along the lines of the gc compiler. The zero value is
handled as a common variable.
The hash function is changed to take a seed argument, changing the
runtime hash functions and the compiler-generated hash functions.
Unlike the gc compiler, both the hash and equal functions continue to
take the type length.
Types that can not be compared now store nil for the hash and equal
functions, rather than pointing to functions that throw. Interface hash
and comparison functions now check explicitly for nil. This matches the
gc compiler and permits a simple implementation for ismapkey.
The compiler is changed to permit marking struct and array types as
incomparable, meaning that they have no hash or equal function. We use
this for thunk types, removing the existing special code to avoid
generating hash/equal functions for them.
The C runtime code adds memclr, memequal, and memmove functions.
The hashmap code uses go:linkname comments to make the functions
visible, as otherwise the compiler would discard them.
The hashmap code comments out the unused reference to the address of the
first parameter in the race code, as otherwise the compiler thinks that
the parameter escapes and copies it onto the heap. This is probably not
needed when we enable escape analysis.
Several runtime map tests that ere previously skipped for gccgo are now
run.
The Go runtime picks up type kind information and stubs. The type kind
information causes the generated runtime header file to define some
constants, including `empty`, and the C code is adjusted accordingly.
A Go-callable version of runtime.throw, that takes a Go string, is
added to be called from the hashmap code.
Reviewed-on: https://go-review.googlesource.com/29447
* go.go-torture/execute/map-1.go: Replace old map deletion syntax
with call to builtin delete function.
From-SVN: r240334
Use the new -fgo-c-header option to build a header file for the Go
runtime code in libgo/go/runtime, and use the new header file in the C
runtime code in libgo/runtime. This will ensure that the Go code and C
code share the same data structures as we convert the runtime from C to
Go.
The new file libgo/go/runtime/runtime2.go is copied from the Go 1.7
release, and then edited to remove unnecessary data structures and
modify others for use with libgo.
The new file libgo/go/runtime/mcache.go is an initial version of the
same files in the Go 1.7 release, and will be replaced by the Go 1.7
file when we convert to the new memory allocator.
The new file libgo/go/runtime/type.go describes the gccgo version of the
reflection data structures, and replaces the Go 1.7 runtime file which
describes the gc version of those structures.
Using the new header file means changing a number of struct fields to
use Go naming conventions (that is, no underscores) and to rename
constants to have a leading underscore so that they are not exported
from the Go package. These names were updated in the C code.
The C code was also changed to drop the thread-local variable m, as was
done some time ago in the gc sources. Now the m field is always
accessed using g->m, where g is the single remaining thread-local
variable. This in turn required some adjustments to set g->m correctly
in all cases.
Also pass the new -fgo-compiling-runtime option when compiling the
runtime package, although that option doesn't do anything yet.
Reviewed-on: https://go-review.googlesource.com/28051
From-SVN: r239872
When libgo is not optimized the static function profilealloc
in malloc.goc shows up in the stack trace. Rename it to
runtime_profilealloc so that runtime/pprof.printStackRecord
ignores it.
From-SVN: r223006
Change from using __go_set_closure to passing the closure
value in the static chain field. Uses new backend support for
setting the closure chain in a call from C via
__builtin_call_with_static_chain. Uses new support in libffi
for Go closures.
The old architecture specific support for reflect.MakeFunc is
removed, replaced by the libffi support.
All work done by Richard Henderson.
* go-gcc.cc (Gcc_backend::call_expression): Add chain_expr argument.
(Gcc_backend::static_chain_variable): New method.
From-SVN: r219776
This upgrades all of libgo other than the runtime package to
the Go 1.4 release. In Go 1.4 much of the runtime was
rewritten into Go. Merging that code will take more time and
will not change the API, so I'm putting it off for now.
There are a few runtime changes anyhow, to accomodate other
packages that rely on minor modifications to the runtime
support.
The compiler changes slightly to add a one-bit flag to each
type descriptor kind that is stored directly in an interface,
which for gccgo is currently only pointer types. Another
one-bit flag (gcprog) is reserved because it is used by the gc
compiler, but gccgo does not currently use it.
There is another error check in the compiler since I ran
across it during testing.
gotools/:
* Makefile.am (go_cmd_go_files): Sort entries. Add generate.go.
* Makefile.in: Rebuild.
From-SVN: r219627
The Go frontend passes closures through to functions using the
functions __go_set_closure and __go_get_closure. The
expectation is that there are no function calls between
set_closure and get_closure. However, it turns out that there
can be function calls if some of the function arguments
require type conversion to an interface type. Converting to
an interface type can allocate memory, and that can in turn
trigger a garbage collection, and that can in turn call pool
cleanup functions that may call __go_set_closure. So the
called function can see the wrong closure value, which is bad.
This patch fixes the problem in two different ways. First, we
move all type conversions in function arguments into temporary
variables so that they can not appear before the call to
__go_set_closure. (This required shifting the flatten phase
after the simplify_thunk phase, since the latter expects to
work with unconverted argument types.) Second, we fix the
memory allocation function to preserve the closure value
across any possible garbage collection.
A test case is the libgo database/sql check run with the
environment variable GOGC set to 1.
From-SVN: r213932
This revision was committed January 7, 2014. The next
revision deleted runtime/mfinal.c. That will be done in a
subsequent merge.
This merge changes type descriptors to add a zero field,
pointing to a zero value for that type. This is implemented
as a common variable.
* go-gcc.cc (Gcc_backend::implicit_variable): Add is_common and
alignment parameters. Permit init parameter to be NULL.
From-SVN: r211249
Before this, the heap location used on a 64-bit system was not
available to user-space on arm64, so the "32-bit" strategy ended up
being used. So use somewhere that is available, and for bonus points
is far away from where the kernel allocates address space by default.
From-SVN: r207977
The spans array is allocated in runtime_mallocinit. On a
32-bit system the number of entries in the spans array is
MaxArena32 / PageSize, which (2U << 30) / (1 << 12) == (1 << 19).
So we are allocating an array that can hold 19 bits for an
index that can hold 20 bits. According to the comment in the
function, this is intentional: we only allocate enough spans
(and bitmaps) for a 2G arena, because allocating more would
probably be wasteful.
But since the span index is simply the upper 20 bits of the
memory address, this scheme only works if memory addresses are
limited to the low 2G of memory. That would be OK if we were
careful to enforce it, but we're not. What we are careful to
enforce, in functions like runtime_MHeap_SysAlloc, is that we
always return addresses between the heap's arena_start and
arena_start + MaxArena32.
We generally get away with it because we start allocating just
after the program end, so we only run into trouble with
programs that allocate a lot of memory, enough to get past
address 0x80000000.
This changes the code that computes a span index to subtract
arena_start on 32-bit systems just as we currently do on
64-bit systems.
From-SVN: r206501
A function that returns an interface type and returns a value
that requires memory allocation will try to allocate while
appearing to be in a syscall. This patch lets that work.
From-SVN: r201226
This fixes a problem on Solaris, where end is not defined in
the main program but comes from some shared library. This
only matters for 32-bit targets.
From-SVN: r201220
Ian Lance Taylor
Ian Lance Taylor
Richard Henderson
Ian Lance Taylor
Rainer Orth