Hello,I see that `scoped_refptr<T>` is marked as TRIVIAL_ABI (by the CL here) and Devin notes that we might want to consider marking `raw_ptr<T>` with the same attribute.Q1: Is this something that we might want to do now? Or is it better to wait until this is really needed (according to raw_ptr<T> performance measurements) or until [[trivially_relocatable]] is adopted by the C++ spec.
Q2: How can one test whether TRIVIAL_ABI (or [[trivially_relocatable]]) is really helping?
FWIW, I've (naively, maybe incorrectly) expected that TRIVIAL_ABI would mean that resizing std::vector's capacity could copy the old elements using memcpy (without calling move constructors and without destructing the old raw_ptr objects). OTOH, this is not what I observe in a test (see WIP CL here) - after emplacing ~250 elements into a vector, it seems that raw_ptr's destructor has run multiple times (I would expect that memcpy means that the destructor doesn't run at all until after the vector elements are cleared/removed). I see that an internal document notes that the optimizations might only kick-in when the allocator is std::allocator<T> (not sure if it matters / how PartitionAlloc-Everywhere fits here).Thanks,Lukasz
--
You received this message because you are subscribed to the Google Groups "memory-safety-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to memory-safety-...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/memory-safety-dev/CAA_NCUF2%2B5m3vTQuZ7zMyuMGNgy_cnAOskcYChdx_v5X6tAs%3DQ%40mail.gmail.com.
For more options, visit https://groups.google.com/a/chromium.org/d/optout.
Q1: Is this something that we might want to do now? Or is it better to wait until this is really needed (according to raw_ptr<T> performance measurements) or until [[trivially_relocatable]] is adopted by the C++ spec.
Q2: How can one test whether TRIVIAL_ABI (or [[trivially_relocatable]]) is really helping?
--
You received this message because you are subscribed to the Google Groups "memory-safety-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to memory-safety-...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/memory-safety-dev/CAER1yGYY3g5CqN4DBm86SKE4r%2B1LDY4M-KKURLkcfs05QjW3og%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/memory-safety-dev/CA%2B%2B_KbTMjOPufLCwDGNWHaRMN0fDsDmB%3D-Ca__GTRigc3t6R2w%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/memory-safety-dev/CA%2B%2B_KbTJrdLZZAr8tkJiKryqJeAhYr3%3DmgkPAhSP4p01ma0w_Q%40mail.gmail.com.
Thanks for explaining. I think this should work then.PSCurrently we don't have raw_ptr params, so if there were any issues, we wouldn't see them until people start actively using it in params (against our current recommendations).
On Tue, Nov 30, 2021 at 10:54 PM Bartek Nowierski <bar...@chromium.org> wrote:Thanks for explaining. I think this should work then.PSCurrently we don't have raw_ptr params, so if there were any issues, we wouldn't see them until people start actively using it in params (against our current recommendations).Right - the lack of utility/coverage can be seen as an argument against early adoption of TRIVIAL_ABI. At the same time, TRIVIAL_ABI seems fairly safe - if it is good enough for scoped_refptr<T> (which also cares about balanced destructors/constructors/moves), then it should be good enough for raw_ptr<T>.
BTW: Any reason why we don't apply TRIVIAL_API to base::WeakPtr?
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/memory-safety-dev/CAA_NCUHcnh4hQAR9y8ukQ7eGQnuRwWmDZxWLyTOds6FFU8KXsw%40mail.gmail.com.
On Wed, Dec 1, 2021 at 11:53 AM Łukasz Anforowicz <luk...@chromium.org> wrote:On Tue, Nov 30, 2021 at 10:54 PM Bartek Nowierski <bar...@chromium.org> wrote:Thanks for explaining. I think this should work then.PSCurrently we don't have raw_ptr params, so if there were any issues, we wouldn't see them until people start actively using it in params (against our current recommendations).Right - the lack of utility/coverage can be seen as an argument against early adoption of TRIVIAL_ABI. At the same time, TRIVIAL_ABI seems fairly safe - if it is good enough for scoped_refptr<T> (which also cares about balanced destructors/constructors/moves), then it should be good enough for raw_ptr<T>.Right, no destructor stops happening. It just moves the responsibility of calling the destructor, so that the raw_ptr contents dont have to be visible to the caller afterward.BTW: Any reason why we don't apply TRIVIAL_API to base::WeakPtr?I think we should. Just no one has.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/memory-safety-dev/CA%2B%2B_KbThAZ5mp5FXmbp%2BYpc2J5wqxrXdzQ%2BjhbpRdOiE37_TvA%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/memory-safety-dev/CACs%3DtyJ1mNPoL9OVpNs6sAQ9qhay378vu_JDADaObn3O23i-%2BQ%40mail.gmail.com.