Re: [webkit-dev] [Block Pointer] Deterministic Region Based Memory Manager

[Timothy Hatcher]

> On Mar 13, 2016, at 10:06 AM, Phil Bouchard  wrote:
> 
> I just thought you might be interested in this benchmark.


Please stop email this list until you provide benchmark results replacing 
JavaScriptCore’s GC. The benchmarks you are providing are irrelevant to 
JavaScriptCore’s needs. We are not interested.

— Timothy Hatcher



smime.p7s
Description: S/MIME cryptographic signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] [Block Pointer] Deterministic Region Based Memory Manager

[Phil Bouchard]

On 03/11/2016 09:56 PM, Phil Bouchard wrote:

On 03/06/2016 10:57 PM, Phil Bouchard wrote:


True but if block_ptr<> is 10x faster than the Mark & Sweep GC then I
think we got something perhaps worth investigating.



- For the record, now block_ptr<> is 600% times faster than shared_ptr<>
so it's a good start:

new:
auto_ptr:   23174753 ns
shared_ptr: 49726615 ns
block_ptr:   7812659 ns


Sorry for the confusion but the real benchmark of the pointers is:

unique_ptr (new): 47.7686
unique_ptr (make_unique): 46.8545
shared_ptr (new): 77.8261
shared_ptr (make_shared): 50.8072
shared_ptr (make_shared_alloc_noinit): 33.021
block_ptr (new): 69.6554

But block_ptr<> handles cyclic references as well.  I just thought you 
might be interested in this benchmark.



Regards,
-Phil

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] [Block Pointer] Deterministic Region Based Memory Manager

[Phil Bouchard]

On 03/06/2016 10:57 PM, Phil Bouchard wrote:


True but if block_ptr<> is 10x faster than the Mark & Sweep GC then I
think we got something perhaps worth investigating.



- For the record, now block_ptr<> is 600% times faster than shared_ptr<> 
so it's a good start:


new:
auto_ptr:   23174753 ns
shared_ptr: 49726615 ns
block_ptr:   7812659 ns


- I made the proxy explicit.  Now it can be used 3 different ways:

1) Clothesline style:

block_proxy x;
block_ptr v = block_ptr(x, new block(11));
block_ptr w = block_ptr(x, new block(12));


2) Root style:

proxy_ptr u = proxy_ptr(new block());


3) Container style (very easy to write containers now):

struct list : block_proxy {
public:
list() : root(*this) {}
[...]
private:
block_ptr root;
};


- I removed the capacity to unify sets.  Why?  Because it's faster & 
cleaner without it.  But I can add it back.



- Once again all the examples can be found here:
https://github.com/philippeb8/block_ptr/tree/master/example


- And the pointer itself here:
https://github.com/philippeb8/block_ptr/blob/master/include/boost/smart_ptr/block_ptr.hpp


Regards,
-Phil


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] [Block Pointer] Deterministic Region Based Memory Manager

[Phil Bouchard]

On 03/06/2016 10:36 PM, Ryosuke Niwa wrote:


No :(  It's pretty relevant that GC in JavaScriptCore was written for
JavaScriptCore.  In particular, JSC doesn't focus on optimizing binary
size, memory usage, etc... for embeddable devices so I would expect
the performance characteristics to be dramatically different from that
of Duktape or XS6.


True but if block_ptr<> is 10x faster than the Mark & Sweep GC then I 
think we got something perhaps worth investigating.



Analyzing the performance of a computer software is really hard.  I've
been working on WebKit for six and half years and I'm still surprised
by the kind of performance issues we encounter and the difference in
the performance characteristics between different CPU architectures,
the number of cores, and the spec of a particular CPU.


I hear you.  I am the one porting WebKit and all the dependencies on 
different CPUs where I work.


But my point is if I can't get something notable then it is what it is.


-Phil

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] [Block Pointer] Deterministic Region Based Memory Manager

[Ryosuke Niwa]

On Sun, Mar 6, 2016 at 7:28 PM, Phil Bouchard  wrote:
> On 03/06/2016 10:17 PM, Filip Pizlo wrote:
>>
>>
>>> On Mar 6, 2016, at 6:36 PM, Phil Bouchard  wrote:
>>>
>>> That should speed up my benchmarking process.
>>
>>
>> It will also make your benchmarking process inconclusive for the purpose
>> of evaluating a memory manager’s performance relative to our garbage
>> collector.  To put it another way, I don’t care if your memory manager is
>> faster than someone else’s garbage collector.
>
>
> It is very subjective but if we know that:
> - WebKit's GC is 2x faster than the Mark & Sweep GC
> - block_ptr<> is 2x faster than the Mark & Sweep GC
>
> Then that means WebKit's GC == block_ptr<>.

No :(  It's pretty relevant that GC in JavaScriptCore was written for
JavaScriptCore.  In particular, JSC doesn't focus on optimizing binary
size, memory usage, etc... for embeddable devices so I would expect
the performance characteristics to be dramatically different from that
of Duktape or XS6.

Analyzing the performance of a computer software is really hard.  I've
been working on WebKit for six and half years and I'm still surprised
by the kind of performance issues we encounter and the difference in
the performance characteristics between different CPU architectures,
the number of cores, and the spec of a particular CPU.

- R. Niwa
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] [Block Pointer] Deterministic Region Based Memory Manager

[Phil Bouchard]

I know, it wouldn't be worth integrating in that case but at least I 
have a way to compare.


On 03/06/2016 10:30 PM, Filip Pizlo wrote:

Phil,

I think you need to do better than this.

-Filip



On Mar 6, 2016, at 7:28 PM, Phil Bouchard  wrote:

It is very subjective but if we know that:
- WebKit's GC is 2x faster than the Mark & Sweep GC
- block_ptr<> is 2x faster than the Mark & Sweep GC

Then that means WebKit's GC == block_ptr<>.



___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] [Block Pointer] Deterministic Region Based Memory Manager

[Filip Pizlo]

Phil,

I think you need to do better than this.

-Filip


> On Mar 6, 2016, at 7:28 PM, Phil Bouchard  wrote:
> 
> On 03/06/2016 10:17 PM, Filip Pizlo wrote:
>> 
>>> On Mar 6, 2016, at 6:36 PM, Phil Bouchard  wrote:
>>> 
>>> That should speed up my benchmarking process.
>> 
>> It will also make your benchmarking process inconclusive for the purpose of 
>> evaluating a memory manager’s performance relative to our garbage collector. 
>>  To put it another way, I don’t care if your memory manager is faster than 
>> someone else’s garbage collector.
> 
> It is very subjective but if we know that:
> - WebKit's GC is 2x faster than the Mark & Sweep GC
> - block_ptr<> is 2x faster than the Mark & Sweep GC
> 
> Then that means WebKit's GC == block_ptr<>.
> 
> 
> Regards,
> -Phil
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] [Block Pointer] Deterministic Region Based Memory Manager

[Phil Bouchard]

On 03/06/2016 10:17 PM, Filip Pizlo wrote:



On Mar 6, 2016, at 6:36 PM, Phil Bouchard  wrote:

That should speed up my benchmarking process.


It will also make your benchmarking process inconclusive for the purpose of 
evaluating a memory manager’s performance relative to our garbage collector.  
To put it another way, I don’t care if your memory manager is faster than 
someone else’s garbage collector.


It is very subjective but if we know that:
- WebKit's GC is 2x faster than the Mark & Sweep GC
- block_ptr<> is 2x faster than the Mark & Sweep GC

Then that means WebKit's GC == block_ptr<>.


Regards,
-Phil

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] [Block Pointer] Deterministic Region Based Memory Manager

[Filip Pizlo]

> On Mar 6, 2016, at 6:36 PM, Phil Bouchard  wrote:
> 
> On 03/06/2016 12:59 AM, Phil Bouchard wrote:
>> 
>> Anyway I am not sure if I can create a patch within a short period of
>> time but if I happen to have an interesting Javascript benchmark then I
>> will repost it to this mailing list.
> 
> Hmmm... I just want to say there are embeddable JS engines out there:
> http://duktape.org/
> 
> That should speed up my benchmarking process.

It will also make your benchmarking process inconclusive for the purpose of 
evaluating a memory manager’s performance relative to our garbage collector.  
To put it another way, I don’t care if your memory manager is faster than 
someone else’s garbage collector.

-Filip

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] [Block Pointer] Deterministic Region Based Memory Manager

[Phil Bouchard]

On 03/06/2016 09:37 PM, Ryosuke Niwa wrote:

FYI, XS6 is another popular JS engine for embedded devices:
http://kinoma.com

- R. Niwa


Thanks.  It looks like this one is written in Java...

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] [Block Pointer] Deterministic Region Based Memory Manager

[Ryosuke Niwa]

FYI, XS6 is another popular JS engine for embedded devices:
http://kinoma.com

- R. Niwa


On Sun, Mar 6, 2016 at 6:36 PM, Phil Bouchard  wrote:
> On 03/06/2016 12:59 AM, Phil Bouchard wrote:
>>
>>
>> Anyway I am not sure if I can create a patch within a short period of
>> time but if I happen to have an interesting Javascript benchmark then I
>> will repost it to this mailing list.
>
>
> Hmmm... I just want to say there are embeddable JS engines out there:
> http://duktape.org/
>
> That should speed up my benchmarking process.
>
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] [Block Pointer] Deterministic Region Based Memory Manager

[Phil Bouchard]

On 03/06/2016 12:59 AM, Phil Bouchard wrote:


Anyway I am not sure if I can create a patch within a short period of
time but if I happen to have an interesting Javascript benchmark then I
will repost it to this mailing list.


Hmmm... I just want to say there are embeddable JS engines out there:
http://duktape.org/

That should speed up my benchmarking process.

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] [Block Pointer] Deterministic Region Based Memory Manager

[Phil Bouchard]

Thanks for the references, I will take a look.

But about performance, a GC is perhaps faster for a period of time but 
when the collector kicks in we notice a CPU usage spiking for a bit 
followed by a performance slowdown on some Javascript animation, 
specially on a embedded box with 1 or 2 processors only.


With block_ptr<> the animation would go smoothly at the same constant 
speed.


But if you say that would involve a 2x slowdown on the UI thread 
regardless then I am surprised.


Anyway I am not sure if I can create a patch within a short period of 
time but if I happen to have an interesting Javascript benchmark then I 
will repost it to this mailing list.



Regards,
-Phil

On 03/06/2016 12:30 AM, Filip Pizlo wrote:

Phil,

I would expect our GC to be much faster than shared_ptr.  This shouldn’t
really be surprising; it’s the expected behavior according to the GC
literature.  High-level languages avoid the kind of eager reference
counting that shared_ptr does because it’s too expensive.  I would
expect a 2x-5x slow-down if we switched to anything that did reference
counting.

You should take a look at our GC, and maybe read some of the major
papers about GC.  It’s awesome stuff.  Here are a few papers that I
consider good reading:

Some great ideas about high-throughput GC:
http://www.cs.utexas.edu/users/mckinley/papers/mmtk-icse-2004.pdf
Some great ideas about low-latency GC:
http://www.filpizlo.com/papers/pizlo-pldi2010-schism.pdf
Some great ideas about GC roots:
http://www.hpl.hp.com/techreports/Compaq-DEC/WRL-88-2.pdf
A good exploration of the limits of reference counting performance:
http://research.microsoft.com/pubs/70475/tr-2007-104.pdf

Anyway, you can’t ask us to change our code to use your memory manager.
  You can, however, try to get your memory manager to work in WebKit,
and post a patch if you get it working.  If that patch is an improvement
- in the sense that both you and the reviewers can apply the patch and
confirm that it is in fact a progression and doesn’t break anything -
then this would be the kind of thing we would accept.

Having looked at your code a bit, I think that you’ll encounter the
following problems:
- Your code uses std::mutex for synchronization.  std::mutex is quite
slow.  You should look at WTF::Lock, it’s much better (as in, orders of
magnitude better).
- Your code implements lifecycle management that is limited to reference
counting.  This is not adequate to support JS, DOM, and JIT semantics,
which are based on solving arbitrary data flow equations over the
reachability set.
- It’s not clear that your allocator results in fast path code that is
competitive against either of the JSC GC’s allocators.  Both of those
require ~5 instructions in the common case.  That instruction count
includes the oversize object safety checks.
- It’s not clear that your allocator is compatible with JITing and
standard JavaScript performance optimizations, which assume that values
can be passed around as bits without calling into the runtime.  A
reference counter needs to do some kinds of memory operations on
variable assignments.  This is likely to be about a 2x-5x slow-down.  I
would expect a 2x slow-down if you did non-thread-safe reference
counting, and 5x if you made it thread-safe.

-Filip



___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] [Block Pointer] Deterministic Region Based Memory Manager

[Filip Pizlo]

Phil,

I would expect our GC to be much faster than shared_ptr.  This shouldn’t really 
be surprising; it’s the expected behavior according to the GC literature.  
High-level languages avoid the kind of eager reference counting that shared_ptr 
does because it’s too expensive.  I would expect a 2x-5x slow-down if we 
switched to anything that did reference counting.

You should take a look at our GC, and maybe read some of the major papers about 
GC.  It’s awesome stuff.  Here are a few papers that I consider good reading:

Some great ideas about high-throughput GC: 
http://www.cs.utexas.edu/users/mckinley/papers/mmtk-icse-2004.pdf 

Some great ideas about low-latency GC: 
http://www.filpizlo.com/papers/pizlo-pldi2010-schism.pdf 

Some great ideas about GC roots: 
http://www.hpl.hp.com/techreports/Compaq-DEC/WRL-88-2.pdf 

A good exploration of the limits of reference counting performance: 
http://research.microsoft.com/pubs/70475/tr-2007-104.pdf 


Anyway, you can’t ask us to change our code to use your memory manager.  You 
can, however, try to get your memory manager to work in WebKit, and post a 
patch if you get it working.  If that patch is an improvement - in the sense 
that both you and the reviewers can apply the patch and confirm that it is in 
fact a progression and doesn’t break anything - then this would be the kind of 
thing we would accept.

Having looked at your code a bit, I think that you’ll encounter the following 
problems:
- Your code uses std::mutex for synchronization.  std::mutex is quite slow.  
You should look at WTF::Lock, it’s much better (as in, orders of magnitude 
better).
- Your code implements lifecycle management that is limited to reference 
counting.  This is not adequate to support JS, DOM, and JIT semantics, which 
are based on solving arbitrary data flow equations over the reachability set.
- It’s not clear that your allocator results in fast path code that is 
competitive against either of the JSC GC’s allocators.  Both of those require 
~5 instructions in the common case.  That instruction count includes the 
oversize object safety checks.
- It’s not clear that your allocator is compatible with JITing and standard 
JavaScript performance optimizations, which assume that values can be passed 
around as bits without calling into the runtime.  A reference counter needs to 
do some kinds of memory operations on variable assignments.  This is likely to 
be about a 2x-5x slow-down.  I would expect a 2x slow-down if you did 
non-thread-safe reference counting, and 5x if you made it thread-safe.

-Filip


> On Mar 5, 2016, at 8:05 PM, Phil Bouchard  wrote:
> 
> On 03/05/2016 01:02 AM, Phil Bouchard wrote:
>> On 03/05/2016 12:49 AM, Filip Pizlo wrote:
>>> 
>>> If you're right then you've resolved CS problems dating back to the
>>> 50's. Extraordinary claims require extraordinary evidence. You haven't
>>> provided any evidence.
>> 
>> It wasn't easy to implement but it's done now so we can all move forward.
>> 
>>> Replacing our GC with anything else is going to be incredibly difficult.
>>> 
>>> We aren't going to be compelled by a comparison of our GC to something
>>> else if it isn't in the context of web workloads.
>> 
>> So you're saying it's impossible?  Is there a design document I could
>> start reading?
>> 
>> 
>> Regards,
>> -Phil
>> (Sorry if I don't reply... it's late)
> 
> Believe it or not, I made a mistake in the fast_pool_allocator which 
> allocates proxies.  I wasn't using unitary size which was clogging the 
> allocator.  I fixed it and now block_ptr<> is *faster* than shared_ptr<>:
> 
> make:
> auto_ptr:   25637845 ns
> shared_ptr: 26789342 ns
> block_ptr:  50487376 ns
> 
> new:
> auto_ptr:   23139888 ns
> shared_ptr: 48198668 ns
> block_ptr:  39151845 ns
> 
> So the performance comparison reduces to this.  Now it's just a matter of 
> finding out if block_ptr<> leaks in any way.
> 
> 
> Regards,
> -Phil
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org 
> https://lists.webkit.org/mailman/listinfo/webkit-dev 
> 
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] [Block Pointer] Deterministic Region Based Memory Manager

[Phil Bouchard]

On 03/05/2016 01:02 AM, Phil Bouchard wrote:

On 03/05/2016 12:49 AM, Filip Pizlo wrote:


If you're right then you've resolved CS problems dating back to the
50's. Extraordinary claims require extraordinary evidence. You haven't
provided any evidence.


It wasn't easy to implement but it's done now so we can all move forward.


Replacing our GC with anything else is going to be incredibly difficult.

We aren't going to be compelled by a comparison of our GC to something
else if it isn't in the context of web workloads.


So you're saying it's impossible?  Is there a design document I could
start reading?


Regards,
-Phil
(Sorry if I don't reply... it's late)


Believe it or not, I made a mistake in the fast_pool_allocator which 
allocates proxies.  I wasn't using unitary size which was clogging the 
allocator.  I fixed it and now block_ptr<> is *faster* than shared_ptr<>:


make:
auto_ptr:   25637845 ns
shared_ptr: 26789342 ns
block_ptr:  50487376 ns

new:
auto_ptr:   23139888 ns
shared_ptr: 48198668 ns
block_ptr:  39151845 ns

So the performance comparison reduces to this.  Now it's just a matter 
of finding out if block_ptr<> leaks in any way.



Regards,
-Phil

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] [Block Pointer] Deterministic Region Based Memory Manager

[Phil Bouchard]

On 03/05/2016 12:49 AM, Filip Pizlo wrote:


If you're right then you've resolved CS problems dating back to the 50's. 
Extraordinary claims require extraordinary evidence. You haven't provided any 
evidence.


It wasn't easy to implement but it's done now so we can all move forward.


Replacing our GC with anything else is going to be incredibly difficult.

We aren't going to be compelled by a comparison of our GC to something else if 
it isn't in the context of web workloads.


So you're saying it's impossible?  Is there a design document I could 
start reading?



Regards,
-Phil
(Sorry if I don't reply... it's late)

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] [Block Pointer] Deterministic Region Based Memory Manager

[Filip Pizlo]

> On Mar 4, 2016, at 9:33 PM, Phil Bouchard  wrote:
> 
>> On 03/05/2016 12:07 AM, Ryosuke Niwa wrote:
>> Hi Phil,
>> 
>> You made a similar post in December 2014:
>> https://lists.webkit.org/pipermail/webkit-dev/2014-December/027113.html
>> 
>> Are you suggesting you have done or ready to do the following?
> 
> I just completed the implementation of block_ptr<> but I am ready to run 
> benchmarks on my laptop once the code is integrated locally on my computer.
> 
> I work for a smart TV company which uses WebKit so I can ask assistance from 
> their part if I need to but I need to know the interests from the Open Source 
> community first.

If you're right then you've resolved CS problems dating back to the 50's. 
Extraordinary claims require extraordinary evidence. You haven't provided any 
evidence. 

> 
>>> 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).
>> 
>> Otherwise, I don't think we would be adopting your memory management
>> library anytime soon.   I don't think we're interested in
>> experimenting with your library on behalf of you either given
>> implementing a concurrent GC on top of our existing GC would be much
>> lower risk and will address some of the issues you have pointed out in
>> the thread.
> 
> It depends on the complexity of swapping the garbage collector with the 
> block_ptr<> in WebKit.  If that is easy I can do it myself on my laptop.  If 
> not then perhaps I can download the garbage collector and compare it with 
> block_ptr<> but objectively; including the collection cycle.

Replacing our GC with anything else is going to be incredibly difficult. 

We aren't going to be compelled by a comparison of our GC to something else if 
it isn't in the context of web workloads. 

> 
> I wasn't confident in 2014 because my code wasn't solid but now I am.  I just 
> need some minimal guidance.
> 
> 
> Regards,
> -Phil
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] [Block Pointer] Deterministic Region Based Memory Manager

[Phil Bouchard]

On 03/05/2016 12:07 AM, Ryosuke Niwa wrote:

Hi Phil,

You made a similar post in December 2014:
https://lists.webkit.org/pipermail/webkit-dev/2014-December/027113.html

Are you suggesting you have done or ready to do the following?


I just completed the implementation of block_ptr<> but I am ready to run 
benchmarks on my laptop once the code is integrated locally on my computer.


I work for a smart TV company which uses WebKit so I can ask assistance 
from their part if I need to but I need to know the interests from the 
Open Source community first.



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).


Otherwise, I don't think we would be adopting your memory management
library anytime soon.   I don't think we're interested in
experimenting with your library on behalf of you either given
implementing a concurrent GC on top of our existing GC would be much
lower risk and will address some of the issues you have pointed out in
the thread.


It depends on the complexity of swapping the garbage collector with the 
block_ptr<> in WebKit.  If that is easy I can do it myself on my laptop. 
 If not then perhaps I can download the garbage collector and compare 
it with block_ptr<> but objectively; including the collection cycle.


I wasn't confident in 2014 because my code wasn't solid but now I am.  I 
just need some minimal guidance.



Regards,
-Phil

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] [Block Pointer] Deterministic Region Based Memory Manager

[Ryosuke Niwa]

Hi Phil,

You made a similar post in December 2014:
https://lists.webkit.org/pipermail/webkit-dev/2014-December/027113.html

Are you suggesting you have done or ready to do the following?

> 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).

Otherwise, I don't think we would be adopting your memory management
library anytime soon.   I don't think we're interested in
experimenting with your library on behalf of you either given
implementing a concurrent GC on top of our existing GC would be much
lower risk and will address some of the issues you have pointed out in
the thread.

On Fri, Mar 4, 2016 at 8:22 PM, Phil Bouchard  wrote:
> Greetings,
>
> I already posted this a couple of years ago but my code wasn't robust back
> then.  Now my memory manager is pretty robust and I was wondering if there
> is any interests to integrate this into WebKit to replace the current
> garbage collector.  AFAIK the latter doesn't run well on embedded platforms
> hence the need to replace it.
>
> My code can be found here:
> https://github.com/philippeb8/block_ptr/
>
> And a quick overview can be found here:
> http://htmlpreview.github.io/?https://github.com/philippeb8/block_ptr/blob/master/doc/index.html
>
> Finally a very complex example (on Linux x86-64 and Win x86-64) of all sort
> of cyclic reference handling can be found here:
> https://github.com/philippeb8/block_ptr/blob/master/example/block_ptr_test2.cpp
>
>
> Regards,
> -Phil
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev