[webkit-dev] Memory Manager

[Phil Bouchard]

On 12/22/2014 07:05 PM, Filip Pizlo wrote:
>
>> On Dec 22, 2014, at 3:41 PM, Phil Bouchard <philippeb8 at gmail.com
>> <mailto:philippeb8 at gmail.com>> wrote:
>>
>> On 12/22/2014 10:02 AM, Filip Pizlo wrote:
>>
>> (Sorry for the late reply)
>>
>>
>> [...]
>>
>>>> This is a good presentation on how it handles it:
>>>> https://svn.boost.org/svn/boost/sandbox/block_ptr/libs/smart_ptr/doc/BlockPointer.ppt
>>>>
>>>> You basically have "sets" of memory blocks (i.e. container = 1 set).
>>>>  If you merge the sets they become one big set.  When the last
>>>> pointer from the stack is deleted then the entire set is also
>>>> destructed.
>>>
>>> Yup, you reinvented regions.
>>
>> As I read it region based memory manager use contiguous memory blocks
>> which get destroyed as a whole without calling any destructor I can
>> imagine, etc.  The block pointer is much more refined than that.
>
> No, region-based memory management doesn’t mean contiguous regions of
> memory.  It also doesn’t mean not calling destructors.  RTSJ regions
> violate both rules, and that’s just one example.  I’m pretty sure
> Cyclone regions are discontiguous because they are arbitrarily
> resizeable.  (Note that RTSJ uses the term “scope”, but in the
> literature it’s common to view this as a special case of regions.)
>
> Region means that some set of objects enter into a “suicide pact” where
> none of them can die unless all of them die.  Even that definition may
> be too strict because there have been so many variations on this theme
> throughout the history of CS.  More loosely, any grouping of objects
> together either to simplify memory management semantics or accelerate
> reclamation is called “regions”.
>
> One of the most common reasons for using regions is that region-based
> allocation semantics (i.e. that suicide pact) allow the objects to be
> bump-allocated within a contiguous memory region.  But they are also
> often used because even if you do have to call destructors, it’s very
> cheap to identify what needs to be freed.  The reason why they are used
> infrequently despite being very well understood is that they are too
> inflexible - it turns out that you need to be able to kill some objects
> before others.

The order of destruction of a cyclic set in block pointer poses no 
problem because the order of construction of the memory blocks is 
remembered.

[...]

> Let’s be clear, though: we’re unlikely to accept a patch in which all of
> our JS object references are replaced by uses of your block_ptr, unless
> that patch is a significant speed-up on web benchmarks, there aren’t any
> slow-downs, and you can prove that all of the JSC GC’s lifetime
> semantics are preserved (including tricky things like the relationship
> between Executable objects, Structure objects, and CodeBlocks).  So, if
> you want to explore the heap compartment approach, I recommend
> implementing it within our GC rather than adding a GC to your block_ptr.
>
> But if you’re going to go to all of that trouble, you might as well just
> implement a concurrent GC.  Trust me, I’ve implemented both, and the
> concurrent GC approach is much easier.

My ultimate goal is to port it back to the C++ standards so I would 
rather have the GC based on the smart pointer than the other way around. 
  To prove it would require some benchmarking and I would be happy to do 
so when I get some free time.

Thanks for all the information; I was looking for this for some time.


Sincerely yours,
-Phil
www.finitetheory.com