[webkit-reviews] review canceled: [Bug 66363] The executable allocator makes it difficult to free individual chunks of executable memory : [Attachment 106079] the patch - added forgotten files

[bugzilla-daemon at webkit.org]

Filip Pizlo <fpizlo at apple.com> has canceled Filip Pizlo <fpizlo at apple.com>'s
request for review:
Bug 66363: The executable allocator makes it difficult to free individual
chunks of executable memory
https://bugs.webkit.org/show_bug.cgi?id=66363

Attachment 106079: the patch - added forgotten files
https://bugs.webkit.org/attachment.cgi?id=106079&action=review

------- Additional Comments from Filip Pizlo <fpizlo at apple.com>
This replaces the RedBlackTree with one based on PODRedBlackTree.

It shares no code with the one from MIT that the previous patch had, so the
license issues should be entirely side-stepped.

I could not use PODRedBlackTree directly because that tree does things that I
do not want, and lacks features that I need:

- PODRedBlackTree removes nodes by copying one node over another one. 
MetaAllocator needs to be able to hold references to nodes in the tree, and
expects that these pointers remain valid until MetaAllocator deletes those
nodes itself.  Hence, I needed to change the PODRedBlackTree's removal method
to move y into z's position rather than copying the contents of y into z.

- PODRedBlackTree calls virtual methods all over the place to support features
that WebCore needs.  I don't need these features, and I don't want virtual
calls.	The MetaAllocator is designed to be decently fast, and so it avoids
virtual calls inside the hot paths.

- PODRedBlackTree has additional features to support partial ordering.	I don't
need these features at all.

- PODRedBlackTree allocates nodes internally and presents an API that does not
expose nodes.  MetaAllocator wants to be able to allocate nodes itself, and is
carefully written to not allocate (or free) any nodes in the common case - it
simply moves a node from one place to another in the tree.

I thought about combining PODRedBlackTree and my RedBlackTree into a common
implementation, with features to specialize as needed.	This would be doable.

Pro: one less tree in the code base.

Con: the code for the tree becomes more complex, because users of
PODRedBlackTree and MetaAllocator require significantly different functionality
and make different assumptions about the inner workings.

I ultimately decided that the cons of combining the trees into one outweighed
the pros.  Mainly, my thinking is that the tree logic itself is unlikely to be
ever modified - so having two copies does not increase maintenance burden.  But
the interface that the tree presents is likely to be modified - so having two
simple implementations of that interface seems better than having one much more
complex one that mixes the requirements of WebCore and the JSC JIT.