Update DEFINE_STATIC_LOCAL to allocate statics in BSS instead of the program heap since these objects never get freed.
Created attachment 93876 [details] Patch
Props to Anders for suggesting this placement new trick of coalescing these static objects in the BSS.
Comment on attachment 93876 [details] Patch Cool idea! r=me
Comment on attachment 93876 [details] Patch I'm not sure if this is sufficiently safe. Nothing guarantees that size of an object matches sizeof - the class may override operator new to allocate a different amount of space. We used to do that with some strings to avoid buffer allocation. Besides, objects that are allocated this way won't work with fastMallocSize, potentially triggering assertion failures. r-, because this at least needs a more detailed risk/benefit analysis. I suspect that downsides outweigh the benefits.
(In reply to comment #4) > (From update of attachment 93876 [details]) > I'm not sure if this is sufficiently safe. Nothing guarantees that size of an object matches sizeof - the class may override operator new to allocate a different amount of space. We used to do that with some strings to avoid buffer allocation. I couldn't find any instances of that (overridden operator new + DEFINE_STATIC_LOCAL) in WebKit, so I believed this was safe. > Besides, objects that are allocated this way won't work with fastMallocSize, potentially triggering assertion failures. But of course, you are completely right about this. Thanks for correcting.
> I couldn't find any instances of that (overridden operator new + DEFINE_STATIC_LOCAL) in WebKit, so I believed this was safe. I do not know of a way to detect this situation to catch it early. WebKit code tends to evolve rapidly. > But of course, you are completely right about this. Thanks for correcting. Anders suggested that to avoid tripping over assertions, we could limit this to release builds. This may be fine in practice, although it does make the platform weaker (fastMallocSize will be unreliable in release builds).
(In reply to comment #6) > > I couldn't find any instances of that (overridden operator new + DEFINE_STATIC_LOCAL) in WebKit, so I believed this was safe. > > I do not know of a way to detect this situation to catch it early. WebKit code tends to evolve rapidly. AFAIK, if "operator new(size_t)" is the only override, then it should be easy to catch since placement new won't compile without "operator new(size_t, void*)".
Pratik is going to see if this patch provides significant benefits. Most statically initialized objects also allocate multiple objects in heap, so storing the "main" object alone in BSS may not have any practical effect.
(In reply to comment #8) > Pratik is going to see if this patch provides significant benefits. Most statically initialized objects also allocate multiple objects in heap, so storing the "main" object alone in BSS may not have any practical effect. I'd like us to be able to enable DEFINE_STATIC_LOCAL to store even more data in BSS, such as the StringImpl, and also store the string data in read-only memory so that it can be shared between processes.
Yes, I'll investigate this some more. I think my big concern now is to see if any of the static objects allocated allocate more memory in their constructors which would end up being on the heap. (In reply to comment #7) > AFAIK, if "operator new(size_t)" is the only override, then it should be easy to catch since placement new won't compile without "operator new(size_t, void*)". Good point! This should eliminate one of Alexey's concerns.(In reply to comment #9) (In reply to comment #9) > I'd like us to be able to enable DEFINE_STATIC_LOCAL to store even more data in BSS, such as the StringImpl, and also store the string data in read-only memory so that it can be shared between processes. Yeah. I can see if this is doable and if it gives us any benefits.
One issue with using more static storage is that you always pay the cost for it, whether a particular feature is used or not. This is because pages are become dirty if only a single variable gets changed.
(In reply to comment #11) > One issue with using more static storage is that you always pay the cost for it, whether a particular feature is used or not. This is because pages are become dirty if only a single variable gets changed. Right. That’s why we should use order files to group them together.
Order files can help with not incurring the cost for unused features (but it's profile based, so only helps if usage scenario matches one used for profiling). But heap allocations are even better in this case - if a feature is unused, there is no allocation and no fragmentation. I think that we should be very careful with the idea of replacing heap fragmentation with DATA fragmentation.