Greetings, As some of you might know I work full time on WebKit which in turn uses a garbage collector for its Javascript interface and quite honestly a garbage collector is not ready for a commercial release unless you have a lot of CPU juice. So a garbage collector is unacceptable. On the other hand I code completed the deterministic block_ptr in 2011 and I am wondering if there is anything I am missing to get it through the review process because this is one of the most important subject in computer science: https://svn.boost.org/svn/boost/sandbox/block_ptr/libs/smart_ptr/doc/index.h... Please let me know if you are interested for me to present it and answer questions live. Sincerely, -Phil www.unifiedfieldtheoryfinite.com
On 02/03/2016 09:02 PM, Phil Bouchard wrote:
Greetings,
As some of you might know I work full time on WebKit which in turn uses a garbage collector for its Javascript interface and quite honestly a garbage collector is not ready for a commercial release unless you have a lot of CPU juice. So a garbage collector is unacceptable.
On the other hand I code completed the deterministic block_ptr in 2011 and I am wondering if there is anything I am missing to get it through the review process because this is one of the most important subject in computer science: https://svn.boost.org/svn/boost/sandbox/block_ptr/libs/smart_ptr/doc/index.h...
Please let me know if you are interested for me to present it and answer questions live.
AFAIK this is no rocket science.
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Phil Bouchard Sent: 05 February 2016 04:29 To: boost@lists.boost.org Subject: Re: [boost] [block_ptr] Request for a review manager
On 02/03/2016 09:02 PM, Phil Bouchard wrote:
Greetings,
As some of you might know I work full time on WebKit which in turn uses a garbage collector for its Javascript interface and quite honestly a garbage collector is not ready for a commercial release unless you have a lot of CPU juice. So a garbage collector is unacceptable.
On the other hand I code completed the deterministic block_ptr in 2011 and I am wondering if there is anything I am missing to get it through the review process because this is one of the most important subject in computer science: https://svn.boost.org/svn/boost/sandbox/block_ptr/libs/smart_ptr/doc/i ndex.html
Please let me know if you are interested for me to present it and answer questions live.
I know little of this subject (apart from a belief that garbage collection should not be necessary for C++ ;-) but having glanced at your documentation, I'm sure it has some uses. But to become a Boost library it needs to have the right structure of files in Github https://svn.boost.org/trac/boost/wiki/StartModDev so that it can be viewed and tried out by potentially interested persons. http://www.boost.org/development/submissions.html is helpful. Tests are essential and in the right format to run with the Boost.Build bjam/b2 toolchain so that your library can be tested on various platforms. You also have some examples available and users also need to be able to run these using bjam/b2. The documentation appears to have the right content but looks a little clunky and could easily be rejigged into the Quickbook style. Since you already have Doxygen syntax comments, these could be added along with an automatically generated index. http://www.boost.org/doc/libs/1_60_0/doc/html/circular_buffer.html is a typical example of a small library. I can assist with refactoring if you get further down the review process. Finally you need to find a review manager and preferably some real-life users who can review knowledgably. Good luck. Paul --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830
On 02/05/2016 07:34 AM, Paul A. Bristow wrote:
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Phil Bouchard Sent: 05 February 2016 04:29 To: boost@lists.boost.org Subject: Re: [boost] [block_ptr] Request for a review manager
On 02/03/2016 09:02 PM, Phil Bouchard wrote:
Greetings,
As some of you might know I work full time on WebKit which in turn uses a garbage collector for its Javascript interface and quite honestly a garbage collector is not ready for a commercial release unless you have a lot of CPU juice. So a garbage collector is unacceptable.
On the other hand I code completed the deterministic block_ptr in 2011 and I am wondering if there is anything I am missing to get it through the review process because this is one of the most important subject in computer science: https://svn.boost.org/svn/boost/sandbox/block_ptr/libs/smart_ptr/doc/i ndex.html
Please let me know if you are interested for me to present it and answer questions live.
I know little of this subject (apart from a belief that garbage collection should not be necessary for C++ ;-) but having glanced at your documentation, I'm sure it has some uses.
But to become a Boost library it needs to have the right structure of files in Github https://svn.boost.org/trac/boost/wiki/StartModDev so that it can be viewed and tried out by potentially interested persons. http://www.boost.org/development/submissions.html is helpful.
Tests are essential and in the right format to run with the Boost.Build bjam/b2 toolchain so that your library can be tested on various platforms. You also have some examples available and users also need to be able to run these using bjam/b2.
The documentation appears to have the right content but looks a little clunky and could easily be rejigged into the Quickbook style. Since you already have Doxygen syntax comments, these could be added along with an automatically generated index. http://www.boost.org/doc/libs/1_60_0/doc/html/circular_buffer.html is a typical example of a small library. I can assist with refactoring if you get further down the review process.
Finally you need to find a review manager and preferably some real-life users who can review knowledgably.
Thanks for the clarifications. There are real-life users in the WebKit world but this world isn't interested into cutting-edge C++. I'll see what I can do. Regards, -Phil
On 02/05/2016 07:34 AM, Paul A. Bristow wrote:
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Phil Bouchard Sent: 05 February 2016 04:29 To: boost@lists.boost.org Subject: Re: [boost] [block_ptr] Request for a review manager
On 02/03/2016 09:02 PM, Phil Bouchard wrote:
Greetings,
As some of you might know I work full time on WebKit which in turn uses a garbage collector for its Javascript interface and quite honestly a garbage collector is not ready for a commercial release unless you have a lot of CPU juice. So a garbage collector is unacceptable.
On the other hand I code completed the deterministic block_ptr in 2011 and I am wondering if there is anything I am missing to get it through the review process because this is one of the most important subject in computer science: https://svn.boost.org/svn/boost/sandbox/block_ptr/libs/smart_ptr/doc/i ndex.html
Please let me know if you are interested for me to present it and answer questions live.
I know little of this subject (apart from a belief that garbage collection should not be necessary for C++ ;-) but having glanced at your documentation, I'm sure it has some uses.
But to become a Boost library it needs to have the right structure of files in Github https://svn.boost.org/trac/boost/wiki/StartModDev so that it can be viewed and tried out by potentially interested persons. http://www.boost.org/development/submissions.html is helpful.
I added the new repository with the right folder structure: https://github.com/philippeb8/block_ptr
Tests are essential and in the right format to run with the Boost.Build bjam/b2 toolchain so that your library can be tested on various platforms. You also have some examples available and users also need to be able to run these using bjam/b2.
The tests and the examples are all there as well.
The documentation appears to have the right content but looks a little clunky and could easily be rejigged into the Quickbook style. Since you already have Doxygen syntax comments, these could be added along with an automatically generated index. http://www.boost.org/doc/libs/1_60_0/doc/html/circular_buffer.html is a typical example of a small library. I can assist with refactoring if you get further down the review process.
Finally you need to find a review manager and preferably some real-life users who can review knowledgably.
I cannot imagine there is no real-life user here because WebKit is the ultimate link between C++ and Javascript and a memory manager is the bottom line here. Even QML would need a memory management makeover. I can tell everyone right now: a garbage collector has no place in the commercial industry as most of you might know. If there is no memory leak then there's going to be high CPU usage running in the background and the side effect will be a lagging user interface.
On 8/02/2016 08:35, Phil Bouchard wrote:
But to become a Boost library it needs to have the right structure of files in Github https://svn.boost.org/trac/boost/wiki/StartModDev so that it can be viewed and tried out by potentially interested persons. http://www.boost.org/development/submissions.html is helpful.
I added the new repository with the right folder structure: https://github.com/philippeb8/block_ptr
One thing you perhaps might want to consider is whether you intend this to be a library in its own right or as an addition to the existing smart_ptr library -- each case requires different structures and discussing things with different people.
I can tell everyone right now: a garbage collector has no place in the commercial industry as most of you might know. If there is no memory leak then there's going to be high CPU usage running in the background and the side effect will be a lagging user interface.
Given that I prefer writing UI in C#, we might have a difference of opinion there. :) What is obvious truth in one domain may not be so in another. Getting back on topic, one of the things that bothers me about block_ptr (from looking at the docs only) is that it appears to be incompatible with async methodologies, where memory is constructed and then pushed into a queue somewhere for later action (and sometimes that queue is in application code, sometimes in Boost.Asio or a similar reactor, and sometimes in the OS itself, and often all three at different times). From what I can tell, these would be treated as orphaned pointers and be subject to destruction mid-operation. Or am I missing something?
On 02/08/2016 07:25 PM, Gavin Lambert wrote:
On 8/02/2016 08:35, Phil Bouchard wrote:
But to become a Boost library it needs to have the right structure of files in Github https://svn.boost.org/trac/boost/wiki/StartModDev so that it can be viewed and tried out by potentially interested persons. http://www.boost.org/development/submissions.html is helpful.
I added the new repository with the right folder structure: https://github.com/philippeb8/block_ptr
One thing you perhaps might want to consider is whether you intend this to be a library in its own right or as an addition to the existing smart_ptr library -- each case requires different structures and discussing things with different people.
It really is a layer on top of smart pointers. I think block_ptr_base<> could eventually be part of smart_ptr but not block_ptr<>.
I can tell everyone right now: a garbage collector has no place in the commercial industry as most of you might know. If there is no memory leak then there's going to be high CPU usage running in the background and the side effect will be a lagging user interface.
Given that I prefer writing UI in C#, we might have a difference of opinion there. :) What is obvious truth in one domain may not be so in another.
... or Java ;)
Getting back on topic, one of the things that bothers me about block_ptr (from looking at the docs only) is that it appears to be incompatible with async methodologies, where memory is constructed and then pushed into a queue somewhere for later action (and sometimes that queue is in application code, sometimes in Boost.Asio or a similar reactor, and sometimes in the OS itself, and often all three at different times). From what I can tell, these would be treated as orphaned pointers and be subject to destruction mid-operation. Or am I missing something?
I would need some code example to look into this specific use case.
On 9/02/2016 16:14, Phil Bouchard wrote:
Getting back on topic, one of the things that bothers me about block_ptr (from looking at the docs only) is that it appears to be incompatible with async methodologies, where memory is constructed and then pushed into a queue somewhere for later action (and sometimes that queue is in application code, sometimes in Boost.Asio or a similar reactor, and sometimes in the OS itself, and often all three at different times). From what I can tell, these would be treated as orphaned pointers and be subject to destruction mid-operation. Or am I missing something?
I would need some code example to look into this specific use case.
This is probably not the best example of the case, but it's at least one that's convenient to hand. Consider http://www.boost.org/doc/libs/1_60_0/doc/html/boost_asio/example/cpp11/http/.... While the read/write operations are "in flight", the "self" variable is a shared_ptr that's stored in some arbitrary location (most likely heap-based, since the caller stack will be destroyed) that's defined by a combination of the compiler's lambda generation and Asio's callback handler management. Now, this implementation assumes that only one operation (either read or write, but not both) can be in flight at once, and so it also uses member fields for the buffers. Imagine similar code where that doesn't hold, and (ignoring performance considerations for the moment), imagine that the start of the operation allocated the buffer locally and then passed ownership of it to the "operation", to finally be released inside the handler. I don't see how any of these pointers could be block_ptrs without breaking things, unless its definition of "being on the stack" includes being in a deferred lambda. Perhaps this isn't an intended use, but the docs seem a bit light on examples of real-world use and where you should use one of these rather than some other pointer type.
On 02/08/2016 10:52 PM, Gavin Lambert wrote:
On 9/02/2016 16:14, Phil Bouchard wrote:
Getting back on topic, one of the things that bothers me about block_ptr (from looking at the docs only) is that it appears to be incompatible with async methodologies, where memory is constructed and then pushed into a queue somewhere for later action (and sometimes that queue is in application code, sometimes in Boost.Asio or a similar reactor, and sometimes in the OS itself, and often all three at different times). From what I can tell, these would be treated as orphaned pointers and be subject to destruction mid-operation. Or am I missing something?
I would need some code example to look into this specific use case.
This is probably not the best example of the case, but it's at least one that's convenient to hand.
Consider http://www.boost.org/doc/libs/1_60_0/doc/html/boost_asio/example/cpp11/http/....
While the read/write operations are "in flight", the "self" variable is a shared_ptr that's stored in some arbitrary location (most likely heap-based, since the caller stack will be destroyed) that's defined by a combination of the compiler's lambda generation and Asio's callback handler management.
Now, this implementation assumes that only one operation (either read or write, but not both) can be in flight at once, and so it also uses member fields for the buffers.
Imagine similar code where that doesn't hold, and (ignoring performance considerations for the moment), imagine that the start of the operation allocated the buffer locally and then passed ownership of it to the "operation", to finally be released inside the handler.
I don't see how any of these pointers could be block_ptrs without breaking things, unless its definition of "being on the stack" includes being in a deferred lambda.
Perhaps this isn't an intended use, but the docs seem a bit light on examples of real-world use and where you should use one of these rather than some other pointer type.
I had to remove the rust behind my C++ skills to answer that question. Anything that is not allocated from a pool is "on the stack" so I don't see why the generation of lamdba should be any different because this is just another function pointer.
Gavin Lambert wrote:
This is probably not the best example of the case, but it's at least one that's convenient to hand.
Consider http://www.boost.org/doc/libs/1_60_0/doc/html/boost_asio/example/cpp11/http/....
Reading rationale.html, it says "If it is found to be living on the heap then a more complicated mechanism is involved to track the last memory block that was allocated in the same thread, find its address and stack up the set it will be part of until the first block_ptr<T> found on the stack is or data segment is initialized, where the new set counter will be shared with all of the newly allocated blocks of memory referencing each other." so it looks like other, simpler examples, could also pose problems. Something like vector<block_ptr<X>> v; v.reserve( 5 ); // do something that allocates from the heap v.emplace_back( new X ); The last line constructs a block_ptr<X> inside the vector's allocated memory, which is on the heap. So the block_ptr goes looking for a previous heap allocation and finds some random one.
// do something that allocates from the heap
v.emplace_back( new X );
The last line constructs a block_ptr<X> inside the vector's allocated memory, which is on the heap. So the block_ptr goes looking for a previous heap allocation and finds some random one.
Ah wait, the last allocation is "new X" here. Hmm.
On Tue, Feb 9, 2016 at 5:02 PM, Peter Dimov <lists@pdimov.com> wrote:
// do something that allocates from the heap
v.emplace_back( new X );
The last line constructs a block_ptr<X> inside the vector's allocated memory, which is on the heap. So the block_ptr goes looking for a previous heap allocation and finds some random one.
Ah wait, the last allocation is "new X" here. Hmm.
You can't tell that without seeing X's constructor. It may well be another allocation that is performed in X().
Phil Bouchard wrote:
I added the new repository with the right folder structure: https://github.com/philippeb8/block_ptr
You should update this to work with the latest Boost, because currently block_base is abstract as it doesn't implement virtual void * get_untyped_deleter() = 0;
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Phil Bouchard Sent: 07 February 2016 19:35 To: boost@lists.boost.org Subject: Re: [boost] [block_ptr] Request for a review manager
On 02/05/2016 07:34 AM, Paul A. Bristow wrote:
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Phil Bouchard Sent: 05 February 2016 04:29 To: boost@lists.boost.org Subject: Re: [boost] [block_ptr] Request for a review manager
On 02/03/2016 09:02 PM, Phil Bouchard wrote:
Greetings,
As some of you might know I work full time on WebKit which in turn uses a garbage collector for its Javascript interface and quite honestly a garbage collector is not ready for a commercial release unless you have a lot of CPU juice. So a garbage collector is unacceptable.
On the other hand I code completed the deterministic block_ptr in 2011 and I am wondering if there is anything I am missing to get it through the review process because this is one of the most important subject in computer science: https://svn.boost.org/svn/boost/sandbox/block_ptr/libs/smart_ptr/doc/i ndex.html
Please let me know if you are interested for me to present it and answer questions live.
I know little of this subject (apart from a belief that garbage collection should not be necessary for C++ ;-) but having glanced at your documentation, I'm sure it has some uses.
But to become a Boost library it needs to have the right structure of files in Github https://svn.boost.org/trac/boost/wiki/StartModDev so that it can be viewed and tried out by potentially interested persons. http://www.boost.org/development/submissions.html is helpful.
I added the new repository with the right folder structure: https://github.com/philippeb8/block_ptr
Tests are essential and in the right format to run with the Boost.Build bjam/b2 toolchain so that your library can be tested on various platforms. You also have some examples available and users also need to be able to run these using bjam/b2.
The tests and the examples are all there as well.
OK - look promising.
Finally you need to find a review manager and preferably some real-life users who can review knowledgably.
I cannot imagine there is no real-life user here because WebKit is the ultimate link between C++ and Javascript and a memory manager is the bottom line here. Even QML would need a memory management makeover.
I meant Boost/readers/users who can contribute to a review.
I can tell everyone right now: a garbage collector has no place in the commercial industry as most of you might know. If there is no memory leak then there's going to be high CPU usage running in the background and the side effect will be a lagging user interface.
And perhaps more important, a sagging battery? Is battery life not the more important reason to avoid garbage collection for portables? Paul --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830
I can tell everyone right now: a garbage collector has no place in the commercial industry as most of you might know. If there is no memory leak then there's going to be high CPU usage running in the background and the side effect will be a lagging user interface.
And perhaps more important, a sagging battery?
Is battery life not the more important reason to avoid garbage collection for portables?
And, electricity costs "at-scale". ;-) And, most especially data center cooling costs. ;-) And, the opportunity costs of lower processing throughput for increasingly large data sets. ;-) And, the less scalability for concurrent and parallel systems. ;-) And, the shortened component lifespan due to increased loads. ;-) And, the poor engineering design incentives they encourage. ;-) And, the confusion/sloppiness and non-determinism present in the resulting systems. ;-) And, ... <snip, karmic discussions> ;-) --charley
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of charleyb123 . Sent: 09 February 2016 14:54 To: boost@lists.boost.org Subject: Re: [boost] [block_ptr] Request for a review manager
I can tell everyone right now: a garbage collector has no place in the commercial industry as most of you might know. If there is no memory leak then there's going to be high CPU usage running in the background and the side effect will be a lagging user interface.
And perhaps more important, a sagging battery?
Is battery life not the more important reason to avoid garbage collection for portables?
And, electricity costs "at-scale". ;-)
And, most especially data center cooling costs. ;-)
And, the opportunity costs of lower processing throughput for increasingly large data sets. ;-)
And, the less scalability for concurrent and parallel systems. ;-)
And, the shortened component lifespan due to increased loads. ;-)
And, the poor engineering design incentives they encourage. ;-)
And, the confusion/sloppiness and non-determinism present in the resulting systems. ;-)
And, ... <snip, karmic discussions> ;-)
I think that you are preaching to the converted? ;-) Paul
<snip, garbage collectors bad-for-your-health> Paul commented:
I think that you are preaching to the converted? ;-)
Yes, of course: This was my personal therapy (thanks for humoring me). I just get nervous that some C++ opinion leaders seem to still think that's a good direction, by apparently looking with "jealous eyes" to other popular languages. ;-)) --charley
On 02/09/2016 09:45 AM, Paul A. Bristow wrote:
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Phil Bouchard Sent: 07 February 2016 19:35 To: boost@lists.boost.org Subject: Re: [boost] [block_ptr] Request for a review manager
On 02/05/2016 07:34 AM, Paul A. Bristow wrote:
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Phil Bouchard Sent: 05 February 2016 04:29 To: boost@lists.boost.org Subject: Re: [boost] [block_ptr] Request for a review manager
On 02/03/2016 09:02 PM, Phil Bouchard wrote:
Greetings,
As some of you might know I work full time on WebKit which in turn uses a garbage collector for its Javascript interface and quite honestly a garbage collector is not ready for a commercial release unless you have a lot of CPU juice. So a garbage collector is unacceptable.
On the other hand I code completed the deterministic block_ptr in 2011 and I am wondering if there is anything I am missing to get it through the review process because this is one of the most important subject in computer science: https://svn.boost.org/svn/boost/sandbox/block_ptr/libs/smart_ptr/doc/i ndex.html
Please let me know if you are interested for me to present it and answer questions live.
I know little of this subject (apart from a belief that garbage collection should not be necessary for C++ ;-) but having glanced at your documentation, I'm sure it has some uses.
But to become a Boost library it needs to have the right structure of files in Github https://svn.boost.org/trac/boost/wiki/StartModDev so that it can be viewed and tried out by potentially interested persons. http://www.boost.org/development/submissions.html is helpful.
I added the new repository with the right folder structure: https://github.com/philippeb8/block_ptr
Tests are essential and in the right format to run with the Boost.Build bjam/b2 toolchain so that your library can be tested on various platforms. You also have some examples available and users also need to be able to run these using bjam/b2.
The tests and the examples are all there as well.
OK - look promising.
Finally you need to find a review manager and preferably some real-life users who can review knowledgably.
I cannot imagine there is no real-life user here because WebKit is the ultimate link between C++ and Javascript and a memory manager is the bottom line here. Even QML would need a memory management makeover.
I meant Boost/readers/users who can contribute to a review.
I can tell everyone right now: a garbage collector has no place in the commercial industry as most of you might know. If there is no memory leak then there's going to be high CPU usage running in the background and the side effect will be a lagging user interface.
And perhaps more important, a sagging battery?
Is battery life not the more important reason to avoid garbage collection for portables?
Lol... I agree
participants (6)
-
Andrey Semashev -
charleyb123 . -
Gavin Lambert -
Paul A. Bristow -
Peter Dimov -
Phil Bouchard