Re: blog post about how you can make your gc code faster
On Wednesday, 9 November 2022 at 11:55:28 UTC, Guillaume Piolat wrote: I've been avoiding void[] for this reason (I mean, void[] _could_ contain pointers), but I think I'm cargo-culting this? If I do: ubyte[] arr = new ubyte[100_000_000]; void[] arr2 = cast(void[]) arr; // will this still avoid scanning? Does the GC still know that this area is NO_SCAN? Yes (as per Adam's post). However, it's easy to lose it with operations like concatenation or appending. `a ~ b` will allocate `void[]` (without `NO_SCAN`) if either are `void[]`. This is why I still use `ubyte[]` (or, in ae, `Data` / `DataVec`) for raw data.
Re: blog post about how you can make your gc code faster
On Wednesday, 9 November 2022 at 11:55:28 UTC, Guillaume Piolat wrote: I've been avoiding void[] for this reason (I mean, void[] _could_ contain pointers), but I think I'm cargo-culting this? Yeah, it actually doesn't really matter. It is the allocation type that sets the flag. So If I do: ubyte[] arr = new ubyte[100_000_000]; Since you `new ubyte`, it set NO_SCAN at the allocation. That's attached to the memory block now. void[] arr2 = cast(void[]) arr; // will this still avoid scanning? Meaning this will not scan the block. Where you get in trouble with void is if it was allocated that way to begin with. Then it will be scanned... but I'm pretty sure `new void[]` doesn't work anyway. Other potential trouble with this would be if you allocate as ubyte, then cast to a pointer type and store something in there. That might be freed prematurely since the block flags is set at allocation time, and not changed when you cast the slice. Even the precise collector doesn't really care since the type in a struct being ubyte[] or void[] are both themselves a pointer - the pointer to the array - so it'd count. But the array itself is stored elsewhere so the GC will look that up in its separate metadata. So you are OK using void[] here to hold things wrt gc scans. Just make sure it is allocated as a concrete type.
Re: blog post about how you can make your gc code faster
On Monday, 7 November 2022 at 14:34:38 UTC, Adam D Ruppe wrote: Putting aside new GC implementation tweaks like I discussed last week, and not just switching to other functions, this week I wanted to lecture a bit about how you can reduce your GC pause times in stock D today: http://dpldocs.info/this-week-in-d/Blog.Posted_2022_11_07.html By far, the biggest benefit you can tweak in D's gc is making your bulk allocations be completely pointer-free, since then it is entirely removed from the scan job, saving potentially significant amounts of time. I've been avoiding void[] for this reason (I mean, void[] _could_ contain pointers), but I think I'm cargo-culting this? If I do: ubyte[] arr = new ubyte[100_000_000]; void[] arr2 = cast(void[]) arr; // will this still avoid scanning? Does the GC still know that this area is NO_SCAN?
