What I meant was just how having a less direct control over memory (like you do with c/c++) affects (edit: in a practical way) the efficiency of cache usage. Having less control means being unable to pack things together as much as one would want, but I'm sure sophisticated GC algorithms (relocating/compacting/generational/incremental) directly or indirectly deal with that somehow. As I said, I'm inexperienced with GC and my understanding of them is probably a bit naive.
From what I've read, the real worry with (for example) C++ is not whether you can control packing or memory ordering. The real worry is when you create data structures that are fundamentally cache-unfriendly. The compiler won't reachitect an object into other objects to make it more memory friendly.
Simple example from the slides on optimizing for the PlayStation 3; if your object is large and full of different data, you miss a lot and burn lots of cache space every time you access it because it is so large. If your object is small and just a collection of pointers, you burn little cache space when you load it, and data can be arranged more appropriately.
Just to you are aware, you are presenting a false dichotomy. There are plenty of languages that are both garbage collected and give you quite a bit of control about memory layout (D, Go, Rust, etc).
For example, in Go if I wanted have a slice of Foobar ([]Foobar) but wanted to have them allocated close to one another I could write:
const neededFoobars = 100
backingSlice := make([]Foobar, neededFoobars)
seqfoobarPtrs := make([]*Foobar, neededFoobars)
for i := 0; i < neededFoobars; i++ {
seqfoobarPtrs[i] = &backingSlice[i]
}
It doesn't. There is a type called Gc that may be garbage collected in future, but at the moment it is just a bad reference counted pointer (the Rc type is better if you want reference counting). And it's not even guaranteed that a GC will ever be implemented, Rust provides other abstractions so GC would be rarely used even if it was implemented.
