[go-nuts] Second order allocator explanation

See for example: http://golang.org/src/pkg/regexp/exec.go#L91

-j

--

Thanks

Surely you could do this in almost any GC language though? In what way does
Go make this easier?

My background is mostly C# where it's possible to pass references around,
is this something that's not possible in Java for example?

For example, one cannot at all control where Java allocates a class
instance. In Go, in the previously mentioned example, the instances of
`*regexp.thread` are allocated in `machine.pool` slice and that can
Java do as well. In other cases, or perhaps even in this one, some
other `pool` can hold the entities instances directly, not only the
pointers to them. This way it is possible in Go to explicitly manage,
in reasonable cases, where "allocated" entities are stored. Once
again, with e.g. Java that's not possible.

-j

--

You can do it in any GC language, but in GC languages like Java it most
likely wouldn't deliver reduced memory consumption nor greater execution
speed.

In my opinion, the mentioned example
http://golang.org/src/pkg/regexp/exec.go#L91 is close to what Rob meant in
the article, but it isn't what he meant. He probably meant to allocate a
linear array of structs and let the custom "2nd order" allocator return
pointers to elements in the array. When the code is done with an element,
the element is sent to the custom "2nd order" memory manager (M) which
appends the element to a free list. When M is created it may pre-populate
the free list, but this isn't strictly required.

In C# and Java it is impossible to get a pointer (type: *T) to any element
of an array (type: [N]T or []T).

Like this, http://msdn.microsoft.com/en-us/library/cx9s2sy4%28v=vs.100%29.aspx
?

--

Slightly off-topic, but working in c# and go every day - the languages feel
remarkably similar in that c# contains most of the features of go (GC,
function pointers(delegates/anon funcs), type safety and unsafe,
reflection, interfaces: c# uses a more java-like method than go). Go idioms
are particularly useful in c# most of the time, obviously not relating to
generics or channels.

Sometimes I wonder if Hejlsberg and Pike are in cahoots.