RESOLVED FIXED 156123
Migrate BidiRunList and BidiRun to automatic memory management
https://bugs.webkit.org/show_bug.cgi?id=156123
Summary Migrate BidiRunList and BidiRun to automatic memory management
Myles C. Maxfield
Reported 2016-04-01 17:53:30 PDT
Migrate BidiRunList and BidiRun to automatic memory management
Attachments
Patch (20.01 KB, patch)
2016-04-01 17:55 PDT, Myles C. Maxfield
no flags
Patch (20.61 KB, patch)
2016-04-01 18:13 PDT, Myles C. Maxfield
no flags
Patch (20.60 KB, patch)
2016-04-01 18:19 PDT, Myles C. Maxfield
simon.fraser: review+
Addressing Darin's comments (1.38 KB, patch)
2016-04-04 11:22 PDT, Myles C. Maxfield
no flags
Myles C. Maxfield
Comment 1 2016-04-01 17:55:00 PDT
Myles C. Maxfield
Comment 2 2016-04-01 18:06:09 PDT
This is fixing a problem that has been around since r3627 (February 2003)!!!
Myles C. Maxfield
Comment 3 2016-04-01 18:13:08 PDT
Myles C. Maxfield
Comment 4 2016-04-01 18:19:47 PDT
Simon Fraser (smfr)
Comment 5 2016-04-01 20:39:55 PDT
Comment on attachment 275453 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=275453&action=review > Source/WebCore/platform/text/BidiResolver.h:160 > + , m_override(context->override()) Why isn't m_level initialized here? > Source/WebCore/platform/text/BidiResolver.h:197 > - // Do not add anything apart from bitfields until after m_next. See https://bugs.webkit.org/show_bug.cgi?id=100173 > - bool m_override : 1; > - bool m_hasHyphen : 1; // Used by BidiRun subclass which is a layering violation but enables us to save 8 bytes per object on 64-bit. > - unsigned char m_level; > - BidiCharacterRun* m_next; > +private: > + std::unique_ptr<BidiCharacterRun> m_next; > + > +public: > int m_start; > int m_stop; > + unsigned char m_level; > + bool m_override : 1; > + bool m_hasHyphen : 1; // Used by BidiRun subclass which is a layering violation but enables us to save 8 bytes per object on 64-bit. What is the size change after these changes? > Source/WebCore/platform/text/BidiRunList.h:67 > Run* m_lastRun; > Run* m_logicallyLastRun; Would be nice to have comments saying who owns these raw pointers.
Myles C. Maxfield
Comment 6 2016-04-01 23:23:27 PDT
Comment on attachment 275453 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=275453&action=review >> Source/WebCore/platform/text/BidiResolver.h:160 >> + , m_override(context->override()) > > Why isn't m_level initialized here? It is initialized on line 166 / 165 below. >> Source/WebCore/platform/text/BidiResolver.h:197 >> + bool m_hasHyphen : 1; // Used by BidiRun subclass which is a layering violation but enables us to save 8 bytes per object on 64-bit. > > What is the size change after these changes? It stays 24 bytes.
Myles C. Maxfield
Comment 7 2016-04-02 00:01:41 PDT
Darin Adler
Comment 8 2016-04-02 20:34:01 PDT
Comment on attachment 275453 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=275453&action=review > Source/WebCore/platform/text/BidiRunList.h:182 > + m_firstRun = nullptr; There’s one significant difference from the old algorithm for deleting the linked list and the new one. This new algorithm uses recursion to delete the linked list, using stack proportional to the length of the list. The old algorithm used iteration instead. I don’t think that change is an improvement. This can be fixed in a couple ways. One way is to add this implementation of ~BidiCharacterRun instead of letting the compiler generate the default implementation: ~BidiCharacterRun() { // Delete the linked list in a loop to prevent destructor recursion. auto next = WTFMove(m_next); while (next) next = WTFMove(next->m_next); } On the other hand, it’s possible that the recursive algorithm is acceptable, or even that the compiler is clever enough to turn this into tail recursion and optimize that to not use stack.
Myles C. Maxfield
Comment 9 2016-04-04 11:22:10 PDT
Reopening to attach new patch.
Myles C. Maxfield
Comment 10 2016-04-04 11:22:13 PDT
Created attachment 275561 [details] Addressing Darin's comments
Myles C. Maxfield
Comment 11 2016-04-04 12:41:25 PDT
Note You need to log in before you can comment on or make changes to this bug.