When calling assumeSafeAppend, cache the block info for subsequent calls #1198
Conversation
| @@ -637,7 +637,8 @@ extern(C) void _d_arrayshrinkfit(const TypeInfo ti, void[] arr) /+nothrow+/ | |||
| auto tinext = unqualify(ti.next); | |||
| auto size = tinext.tsize; // array element size | |||
| auto cursize = arr.length * size; | |||
| auto bic = __getBlkInfo(arr.ptr); | |||
| auto isshared = typeid(ti) is typeid(TypeInfo_Shared); | |||
| auto bic = !isshared ? __getBlkInfo(arr.ptr) : null; | |||
There was a problem hiding this comment.
auto bic = isshared ? null : __getBlkInfo(arr.ptr);
|
Updated with suggestions. |
|
Cache on read, makes sense. |
|
Auto-merge toggled on |
When calling assumeSafeAppend, cache the block info for subsequent calls
|
I actually considered last night, why put the cache only for array appending, why not just have a general |
|
Hm... but the cache depends on knowing that the block is unshared. Maybe that wouldn't work in the general case. |
|
We will add thread local caches for the GC soon, and one part of the will be to cache the info, making a separate cache unnecessary. |
|
Yeah, a GC that knows which blocks are shared or not seems like a prerequisite. Looking forward to that! |
|
That's just an optimization to avoid synchronization, but the GC has to deal with that anyhow. |
Library code may conservatively call assumeSafeAppend on an array without knowing if the block will be appended to. However, if the block is not cached in the block info cache, it would not add it to the cache. This meant that code that continually calls assumeSafeAppend is constantly looking up the block info from the heap. This fixes that situation.