Goal is to make it more clear which parts of code rely on AddressSpaceView.
Also we this way we can remove some static_asserts which check that
CombinedAllocator instantiated with compatible types. Now
CombinedAllocator controls type by itself.
Differential D57279
NFC: Reduce presence of "template <typename AddressSpaceView>" vitalybuka on Jan 25 2019, 7:50 PM. Authored by
Details
Goal is to make it more clear which parts of code rely on AddressSpaceView. Also we this way we can remove some static_asserts which check that
Diff Detail
Event TimelineComment Actions If we're going to go down this road we really need to land https://reviews.llvm.org/D56964 first. That fixes additional behaviour of the allocators.
Comment Actions Sure, I'd like to land this patch as NFC. I don't mind if D56964 goes either before or after.
Comment Actions @vitalybuka Thanks for working on this. Context for those new to the patch: We are looking at ways of converting a Allocator<LocalAddressSpaceView> into a Allocator<RemoteAddressSpaceView>. With the current design on master it is not safe to do a reinterpret_cast<>() because C++ doesn't guarantee that the two different types have the same data-layout or fields (AFAIK). Over the weekend I investigated your first suggestion for fixing the reinterpret_cast problem for the allocators. I've updated my patch stack to use this new approach. Even though you're trying a different approach in this patch I thought it was important that I investigate other options. The key patches are...
I'd encourage you take a look because I think what we might end up doing may be a hybrid between this patch and what I've done in the patches I listed above. I've made a short pro/con list (from my perspective) for the two approaches. Hopefully this will encourage some discussion that will allow us to converge on a design. This patchThis patch effectively tries to separate data and code. Data in a parent allocator class that is not templated over AddressSpaceView, and then the methods that depend on AddressSpaceView are in the child class. I'm guessing the hope is that recasting a AllocatorView<LocalAddressSpaceView> as a AllocatorView<RemoteAddressSpaceView> should work and be safe because all the data is in the parent class (the data layout doesn't depend on AddressSpaceView). Pros
Cons
My CopyFromTarget(...) patch series.Pros
Cons
ThoughtsI personally prefer my CopyFromTarget(...) patch series. Although I think what @vitalybuka has done in this patch is quite clever (the separation of code and data is quite aesthetically pleasing), I think this patch paints us into a design corner. The restrictions it places on what data structures can be used in allocators and how they can be implemented is a very serious concern of mine. I wanted the AddressSpaceView interface to be as unintrusive as possible but his patch feels like it places very intrusive design restrictions on the allocators. I would rather take the performance hit that CopyFromTarget(...) adds and the minor maintenance burden it adds so that we can continue to allow the Allocators to use whatever data structure they wish. @kcc @eugenis @cryptoad I'd appreciate your input here because this is quite an important design decision. Comment Actions Now you can reinterpret/memcpy at base class level.
I rely hope we will try to avoid such fields with either design. So I don't think we need to optimize for this scenario.
This one can be easily solved making SizeClassAllocator32->SizeClassAllocator32State a pure data structure without methods and class SizeClassAllocator32<AddressSpaceView> { // logic SizeClassAllocator32State state_; } or even better: class SizeClassAllocator32<AddressSpaceView> { // logic SizeClassAllocator32State* state_; } This way remote part will be able to swap state pointers without need to copy/reinterprete anything. Anyway all this hidden in implementation and simplify interface. These consts are "possible" future issues which will likely never bother us. AddressSpaceView noise is current issue.
It adds even more complexity for readers.
Comment Actions Okay. As long as we encapsulate that in a method similar to what I have in https://reviews.llvm.org/D57307 template <typename DstTy, typename SrcTy> const SrcTy *CopyFromTarget(DstTy *dst, const SrcTy *src) then I'm fine with that.
I was going to ask if the performance impact of this indirection matters. However given that Scudo now has its own independent code base I guess this matters a lot less.
Okay. I left this open for a week to see if anyone would respond and it seems that no one else has a differing opinion on this other than me. Given that I am not the code owner the only real way forward is for me to follow the approach in this patch. Comment Actions Looking through my unfinished patches, and noticed this one. Comment Actions
I'm not familiar with AddressSpaceView @vitalybuka but @yln or @kubamracek may have better perspective. Would applying this patch internally to see if we have explicit dependencies be useful? I can certainly do that as a black-box test, otherwise I'd have to dig in a bit to be of much help. Comment Actions Applying the patch can be hard as it's outdated. My question is "can we go further and remove AddressSpaceView completly?" |
This looks wrong. In the out-of-process case where we've copied over a FlatByteMap from the target process map2 is pointing to memory that isn't valid in our local address space. Here it looks like you're actually dereferencing invalid memory (map2[idx % kSize2]) and then taking a reference to it.
Perhaps this is okay. I think it might be the implicit conversion of map2[idx %kSize2] to an rvalue that actually triggers the dereference normally. This might not be happening here (I hope the code isn't taking a reference to a temporary r-value), but I am incredibly suspicious of this code.