Move block info caching into the gc package#17067
Move block info caching into the gc package#17067thewilsonator merged 2 commits intodlang:masterfrom
Conversation
|
Thanks for your pull request, @schveiguy! 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 + dmd#17067" |
thewilsonator
left a comment
thewilsonator
left a comment
There was a problem hiding this comment.
Oh, I see this is mostly a cut & paste. Feel free to do those suggestion in a follow up PR.
If you could split out any changes that are not purely cut & paste, e.g. the IsMarked changes like IsMarked isMarked(void *addr) scope nothrow into a separate commit that would be appreciated.
schveiguy
force-pushed
the
mvblkinfocache
branch
from
aecb232 to
4041885
Compare
I will see if I can figure out how to do this. I agree it would be better. |
schveiguy
force-pushed
the
mvblkinfocache
branch
from
4041885 to
868dba2
Compare
|
@thewilsonator ok, I split into 2 commits. The first commit just moves the code as-is into the blkcache module. The second commit shows the edits I made in that module (and everywhere else). |
schveiguy
force-pushed
the
mvblkinfocache
branch
from
868dba2 to
5c9eca4
Compare
|
Is that stdcheader thing my fault? or is that a commonly failing test? Unsure how my code could make that happen... |
|
I guess so, it seems to have hit one of Walter's PRs #17066 (comment) |
thewilsonator
left a comment
thewilsonator
left a comment
There was a problem hiding this comment.
Apart from that, looks good
| $(IMPDIR)\core\internal\elf\io.d \ | ||
| \ | ||
| $(IMPDIR)\core\internal\gc\bits.d \ | ||
| $(IMPDIR)\core\internal\gc\blkcache.d \ |
There was a problem hiding this comment.
These should be part of the first commit
There was a problem hiding this comment.
These commits were split to aid in review. The first commit is a straight copy/paste of code. In essence, they are not separable -- you can't build with the first commit only, even if I were to make these changes go into the first commit.
I had a hard time doing the split, don't make me do it again...
| $(DOCDIR)\etc_linux_memoryerror.html \ | ||
| \ | ||
| $(DOCDIR)\core_internal_gc_bits.html \ | ||
| $(DOCDIR)\core_internal_gc_blkcache.html \ |
| src\core\internal\elf\io.d \ | ||
| \ | ||
| src\core\internal\gc\bits.d \ | ||
| src\core\internal\gc\blkcache.d \ |
|
Ugh, first hard problem. Need to figure out why sociomantic code is failing. |
|
I would suggest splitting the first commit off into a separate PR (along with the makefile changes) and then also splitting out the formatting changes. |
|
I think I know what the problem is. I have to go back to using malloc instead of the GC for the cache... Detached threads... |
It wouldn't work. The first commit is not buildable. |
|
If its a cut& paste then the only other thing you should need (apart from the makefile changes) would be a public import from where you cut from of where you pasted it, no? |
schveiguy
force-pushed
the
mvblkinfocache
branch
2 times, most recently
from
3a1e92f to
ce660d2
Compare
|
OK, switched back to C malloc. Also take into account case where thread is not attached, just avoid the cache in that case (it's dangerous to use if the GC can't clear out collected memory). |
Abstract tls handling routine in thread to decouple thread from knowing the GC's TLS specific data layout.
schveiguy
force-pushed
the
mvblkinfocache
branch
from
ce660d2 to
542296d
Compare
|
Figured out the failure. I was forgetting to clear the pointer from the ThreadBase when shutting down the thread, and then a GC would use the cache because it wasn't null. Let's hope this is it... |
|
All green except the weird header thing. Do we know what's happening there? |
3 participants
This is step 1 in migrating the array runtime code into the GC. Once all these steps are completed, the new GC will be able to hook to druntime.
This does not really change how the
rt.lifetimearray runtime code works. It's just now using the block info caching fromcore.internal.gc.blkcache.A couple of things I changed when I did this:
I don't know why I didn't do this before (probably inexperience), but instead of using C malloc to allocate the BlkInfo cache, use a GC malloc with NO_SCAN.EDIT: Actually, using a GC block is not OK, in the cases where you have a detached thread which uses the cache. In this case, the cache may get collected, and then using it further is use-after-free.
So we still have to use C malloc.