variant regression: Make sure untyped pointers are scanned by the GC#10929
variant regression: Make sure untyped pointers are scanned by the GC#10929Inkrementator wants to merge 1 commit intodlang:masterfrom
Conversation
To make sure that Variant works with big structs that it has to allocate on the heap which can't be allocated with a simple `new T` due to default constructor being disabled, the allocation strategy used was to just allocate an array of ubytes and cast the region appropriately. But if the GC only knows about this memory region as ubyte[], it won't scan it for pointers. I think there might even be issues with alignment, depending on how the GC works. Using GC.malloc with typeinfo should provide the GC with all the relevant info to recursively scan this region and is preferable to just conservatively marking the whole buffer as a new GC root.
|
Thanks for your pull request and interest in making D better, @Inkrementator! We are looking forward to reviewing it, and you should be hearing from a maintainer soon.
Please see CONTRIBUTING.md for more information. If you have addressed all reviews or aren't sure how to proceed, don't hesitate to ping us with a simple comment. Bugzilla referencesYour PR doesn't reference any Bugzilla issue. If your PR contains non-trivial changes, please reference a Bugzilla issue or create a manual changelog. Testing this PR locallyIf you don't have a local development environment setup, you can use Digger to test this PR: dub run digger -- build "master + phobos#10929" |
|
Someone who knows how the GC works please review this. Be aware that the type of the pointer is cast away again when the pointer is written to an ubyte[] buffer (which is marked as a pointer via being in a union with (void*)) later. |
| { | ||
| // object will be intialized later. Using ubyte buffer in case `this()` is disabled | ||
| A* p = cast(A*) (new ubyte[A.sizeof]).ptr; | ||
| // object will be intialized later. Using malloc in case `this()` is disabled |
There was a problem hiding this comment.
These comments don't appear to make a whole lot of sense given the changes that have taken place.
Please remove all of them.
There was a problem hiding this comment.
I was trying to communicate that I'm using GC.malloc here because the constructor of a type might be disabled, but this would be fine because we don't care about the constructor, only the postblit
If you say this doesn't make sense, is this because I have an error in my logic, written the comment in a confusing way or is it because the comment is self evident and redundant?
3 participants
To make sure that Variant works with big structs that it has to allocate on the heap which can't be allocated with a simple
new Tdue to default constructor being disabled, the allocation strategy used was to just allocate an array of ubytes and cast the region appropriately.But if the GC only knows about this memory region as ubyte[], it won't scan it for pointers. I think there might even be issues with alignment, depending on how the GC works.
Using GC.malloc with typeinfo should provide the GC with all the relevant info to recursively scan this region and is preferable to just conservatively marking the whole buffer as a new GC root.