[webkit-dev] Memory Manager

[Filip Pizlo]

> On Dec 22, 2014, at 4:54 PM, Phil Bouchard <philippeb8 at gmail.com> wrote:
> 
> 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.
> 

The order of destruction isn’t interesting.  It’s the timeliness that’s interesting.  Regions usually mean that the destruction of an object is postponed until all of the objects in the region can be destroyed.

> [...]
> 
>> 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
>