On 12/22/2014 07:05 PM, Filip Pizlo wrote:
On Dec 22, 2014, at 3:41 PM, Phil Bouchard <[email protected]
<mailto:[email protected]>> 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
_______________________________________________
webkit-dev mailing list
[email protected]
https://lists.webkit.org/mailman/listinfo/webkit-dev
