Bug 10323 – getAMDcacheinfo needlessly allocates

src/druntime/src/core/cpuid.d line 544: immutable ubyte [] assocmap = [ 0, 1, 2, 0, 4, 0, 8, 0, 16, 0, 32, 48, 64, 96, 128, 0xFF ]; The real problem here is that a array initializer allocates, even if all the data is static, and the compiler should probably be fixed, but in the mean time I think we should go ahead and kill as many allocations as possible from druntime, and this is one of them. In my experimentation, I found just sticking "static" in front of this line solved the immediate problem.

Yeah, for array initializers to *always* allocate seems wrong to me. Is there a bug for it?

Well, they don't *always* allocate - in the variable is static, they don't. But if not they do and that sucks. I'm pretty sure it is a well known issue and this bug seems close: http://d.puremagic.com/issues/show_bug.cgi?id=6421 but is talking about static so not sure. Bugzilla search never works easily for me :( My preferred solution to the array literal question is if the contents are all literal values too (or, ideally, if they can evaluate to literals with CTFE), put the literal into static data like you would with a string literal. Well, maybe not like a string literal, since they are read only and arrays expect to be writable. Maybe put them in the initialized data segment instead, with read/write. Then only do a runtime allocation if the literal isn't all literals, e.g. "int x = 10; auto b = [x, 100];", b would be an ok allocation because x is a runtime value. Nevertheless, in druntime we should be mindful of it and at least mark these arrays static so they work today, pending an answer to the bigger question.

thinking some more about that data segment thing, maybe that won't work either because ~= would try to find gc info, to check capacity, that doesn't exist there. But I'm sure that can be worked around, the literal could perhaps write out a dummy gc info block before the array informing append that it has zero extra capacity.

(In reply to comment #3) > thinking some more about that data segment thing, maybe that won't work either > because ~= would try to find gc info, to check capacity, that doesn't exist > there. But I'm sure that can be worked around, the literal could perhaps write > out a dummy gc info block before the array informing append that it has zero > extra capacity. The runtime can detect when it's not dealing with non-GC memory (think about appending to stack data). Appending would simply allocate a new GC block.

It should be possible to treat immutable arrays just like static immutable ones.

pull # 625 fixed