[block_ptr] & Java
Hello everyone, In a quest to speed up my Android applications and knowing Java is written in C++, I decided to discuss with the OS community openjdk.java.net to try to introduce them block_ptr. But the conversation was dead in the water probably due to the lack of developers. So I just have questions: - Does anybody know if Java uses Boost? - block_ptr hasn't been reviewed yet but memory management is an important subject. Are there unanswered questions about it? Sincerely, -Phil Experiment proposal to refute Special Relativity for the interested: http://finitetheory.com/files/experiment.pdf
On Tue, Aug 27, 2013 at 5:34 PM, Phil Bouchard <philippe@fornux.com> wrote:
- block_ptr hasn't been reviewed yet but memory management is an important subject. Are there unanswered questions about it?
My current understanding is that it is not clear at all to most of us (me included) what block_ptr is. Joel Lamotte
On 8/27/2013 11:58 AM, Klaim - Joël Lamotte wrote:
On Tue, Aug 27, 2013 at 5:34 PM, Phil Bouchard <philippe@fornux.com> wrote:
- block_ptr hasn't been reviewed yet but memory management is an important subject. Are there unanswered questions about it?
My current understanding is that it is not clear at all to most of us (me included) what block_ptr is.
Well it's a memory manager but I am not sure where I fail to document its design. -Phil
On 8/27/2013 12:08 PM, Phil Bouchard wrote:
On 8/27/2013 11:58 AM, Klaim - Joël Lamotte wrote:
On Tue, Aug 27, 2013 at 5:34 PM, Phil Bouchard <philippe@fornux.com> wrote:
- block_ptr hasn't been reviewed yet but memory management is an important subject. Are there unanswered questions about it?
My current understanding is that it is not clear at all to most of us (me included) what block_ptr is.
Well it's a memory manager but I am not sure where I fail to document its design.
Maybe I can do a presentation at some point. -Phil
On 8/27/2013 12:22 PM, Klaim - Joël Lamotte wrote:
On Tue, Aug 27, 2013 at 6:08 PM, Phil Bouchard <philippe@fornux.com> wrote:
Well it's a memory manager but I am not sure where I fail to document its design.
"Memory manager" is very vague.
Well it's a deterministic memory manager because the time of the destruction of the objects is predictable. If it was ported to Java there would be no need for the "finally" clause anymore.
On 8/27/2013 1:07 PM, Phil Bouchard wrote:
On 8/27/2013 12:22 PM, Klaim - Joël Lamotte wrote:
"Memory manager" is very vague.
Well it's a deterministic memory manager because the time of the destruction of the objects is predictable.
If it was ported to Java there would be no need for the "finally" clause anymore.
I am not sure what else to tell you. -Phil
Gesendet: Freitag, 30. August 2013 um 22:31 Uhr Von: "Phil Bouchard" <philippe@fornux.com> An: boost@lists.boost.org Betreff: Re: [boost] [block_ptr] & Java
On 8/27/2013 1:07 PM, Phil Bouchard wrote:
On 8/27/2013 12:22 PM, Klaim - Joël Lamotte wrote:
"Memory manager" is very vague.
Well it's a deterministic memory manager because the time of the destruction of the objects is predictable.
If it was ported to Java there would be no need for the "finally" clause anymore.
I am not sure what else to tell you.
I'll just ask about the elephant in the room: What does your block_ptr do differently then the for years known smartpointer implementation in boost? Why is there a need for reinventing the wheel? kind regards, Jens Weller
On 8/30/2013 4:43 PM, Jens Weller wrote:
I'll just ask about the elephant in the room: What does your block_ptr do differently then the for years known smartpointer implementation in boost? Why is there a need for reinventing the wheel?
Because cyclic pointers need to be handled explicitly with smart pointers whereas with mine it's done implicitly. That's why it can be ported to Java so easily. I have my take on smart pointers because I am working on Webkit which uses its own similar smart pointers to Boost's. I haven't been promoting block_ptr much in the last 2 years simply because I was working on my astrophysics project. -Phil
on Fri Aug 30 2013, Phil Bouchard <philippe-AT-fornux.com> wrote:
On 8/30/2013 4:43 PM, Jens Weller wrote:
I'll just ask about the elephant in the room: What does your block_ptr do differently then the for years known smartpointer implementation in boost? Why is there a need for reinventing the wheel?
Because cyclic pointers need to be handled explicitly with smart pointers whereas with mine it's done implicitly.
There's no one correct destruction order for objects participating in a cycle. That's one reason most C++ garbage collectors collect memory but don't run destructors. How does your system deal with this? -- Dave Abrahams
There's no one correct destruction order for objects participating in a cycle. That's one reason most C++ garbage collectors collect memory but don't run destructors. How does your system deal with this?
I can think of another reason: The whole point of garbage collection is to simulate unbounded memory by recycling memory that is no longer reachable. If you run destructors on objects that are collect as garbage, the simulation is no longer a simulation.
On Sat, Aug 31, 2013 at 12:44 PM, Andrew Koenig <ark-mlist@att.net> wrote:
There's no one correct destruction order for objects participating in a cycle. That's one reason most C++ garbage collectors collect memory but don't run destructors. How does your system deal with this?
I can think of another reason: The whole point of garbage collection is to simulate unbounded memory by recycling memory that is no longer reachable. If you run destructors on objects that are collect as garbage, the simulation is no longer a simulation.
Hi Andrew I think Cpp shouldn't have any gc (smart pointer might be an exception). The most compelling feature of cpp is precise memory layout management. GC can't reach that goal. If we do need gc, why not use other languages? Regards gelin yan
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
2013/8/31 Dave Abrahams <dave@boostpro.com>
on Fri Aug 30 2013, Phil Bouchard <philippe-AT-fornux.com> wrote:
On 8/30/2013 4:43 PM, Jens Weller wrote:
I'll just ask about the elephant in the room: What does your block_ptr do differently then the for years known
smartpointer implementation in boost?
Why is there a need for reinventing the wheel?
Because cyclic pointers need to be handled explicitly with smart pointers whereas with mine it's done implicitly.
There's no one correct destruction order for objects participating in a cycle. That's one reason most C++ garbage collectors collect memory but don't run destructors. How does your system deal with this?
It still can be usable for types with trivial destructor. (However it is hard to imagine any smart ptr with trivial destructor, so making a cycle of trivial types with smart pointers seems impossible.). Can we see the implementation of block pointer? -- Best regards, Antony Polukhin
Le 31/08/13 07:48, Antony Polukhin a écrit :
It still can be usable for types with trivial destructor. (However it is hard to imagine any smart ptr with trivial destructor, so making a cycle of trivial types with smart pointers seems impossible.). Can we see the implementation of block pointer?
Hi, block_ptr in on the review schedule since a long time. See https://svn.boost.org/svn/boost/sandbox/block_ptr/ Best, Vice,te
2013/8/31 Vicente J. Botet Escriba <vicente.botet@wanadoo.fr>
Le 31/08/13 07:48, Antony Polukhin a écrit :
It still can be usable for types with trivial destructor. (However it is
hard to imagine any smart ptr with trivial destructor, so making a cycle of trivial types with smart pointers seems impossible.). Can we see the implementation of block pointer?
Hi, block_ptr in on the review schedule since a long time. See https://svn.boost.org/svn/boost/sandbox/block_ptr/
Looks promising and inteesting. But not 100% ready. For example this singleton is not thread safe in C++98/C++03: static mutex & static_mutex() /**< Main global mutex used for thread safety */ { static mutex mutex_; return mutex_; } Also use BOOST_NOEXCEPT_OR_NOTHROW instead of throw(), BOOST_NOEXCEPT instead of /* newer throws*/. Mark noexcept destructors, copy, move constructors, assignment operators with BOOST_NOEXCEPT where appropriate, Please add notes about the issue mentioned by Dave (correct destruction order for objects participating in a cycle) If nobody minds, I can become the release manager for this library. However I'll have enough time for this only at the beginning of this winter. -- Best regards, Antony Polukhin
On 8/31/2013 4:14 AM, Antony Polukhin wrote:
Looks promising and inteesting. But not 100% ready. For example this singleton is not thread safe in C++98/C++03:
static mutex & static_mutex() /**< Main global mutex used for thread safety */ { static mutex mutex_;
return mutex_; }
Also use BOOST_NOEXCEPT_OR_NOTHROW instead of throw(), BOOST_NOEXCEPT instead of /* newer throws*/. Mark noexcept destructors, copy, move constructors, assignment operators with BOOST_NOEXCEPT where appropriate,
Please add notes about the issue mentioned by Dave (correct destruction order for objects participating in a cycle)
If nobody minds, I can become the release manager for this library. However I'll have enough time for this only at the beginning of this winter.
Thanks. But I must also say the object allocator could be speed up because at the time I wrote this there was no way to allocate consecutive bytes from a pool in constant complexity. I am still using fast_pool_allocator<block_header>: https://svn.boost.org/svn/boost/sandbox/block_ptr/boost/block_ptr.hpp That's one more improvement that can be done and it'll be perfect. -Phil
On 8/31/2013 11:24 AM, Phil Bouchard wrote:
Thanks. But I must also say the object allocator could be speed up because at the time I wrote this there was no way to allocate consecutive bytes from a pool in constant complexity. I am still using fast_pool_allocator<block_header>: https://svn.boost.org/svn/boost/sandbox/block_ptr/boost/block_ptr.hpp
That's one more improvement that can be done and it'll be perfect.
Sorry I didn't mean this allocator but boost::singleton_pool<pool, sizeof(char)>: https://svn.boost.org/svn/boost/sandbox/block_ptr/boost/detail/block_base.hp... -Phil
On 8/31/2013 1:06 PM, Phil Bouchard wrote:
Sorry I didn't mean this allocator but boost::singleton_pool<pool, sizeof(char)>: https://svn.boost.org/svn/boost/sandbox/block_ptr/boost/detail/block_base.hp...
May I ask what is the level of understanding of block_ptr in percentage? Thanks, -Phil
On Tue, Sep 3, 2013 at 10:39 PM, Phil Bouchard <philippe@fornux.com> wrote:
May I ask what is the level of understanding of block_ptr in percentage?
I don't know how "percentage" could be applied here but the following is how I understand it: 1. from the interface and behaviour expectations point of view, it's exactly like shared_ptr. (is there a weak_ptr too?) 2. however the implementation is made so that cycles are not a problem, they are destroyed in a deterministic way; All the rest is confuse to me so far, but then I have a quesiton: Can block_ptr be considered as a specific implementation of shared_ptr which allows cycles? If yes, what are the costs for the user, compared to shared_ptr? Joel Lamotte
On 9/3/2013 5:16 PM, Klaim - Joël Lamotte wrote:
All the rest is confuse to me so far, but then I have a quesiton: Can block_ptr be considered as a specific implementation of shared_ptr which allows cycles? If yes, what are the costs for the user, compared to shared_ptr?
It uses some base classes from shared_ptr but it is distinct from shared_ptr (you can't cast a shared_ptr to a block_ptr and vice-versa). block_ptr is a cycle manager on top of a shared_ptr but the sizeof(block_ptr) remains == to sizeof(shared_ptr). -Phil
On 9/3/2013 5:33 PM, Phil Bouchard wrote:
block_ptr is a cycle manager on top of a shared_ptr but the sizeof(block_ptr) remains == to sizeof(shared_ptr).
Sorry: block_ptr is a cycle manager on top of reference counting but the sizeof(block_ptr) remains == to sizeof(shared_ptr). -Phil
On 8/31/2013 1:06 PM, Phil Bouchard wrote:
On 8/31/2013 11:24 AM, Phil Bouchard wrote:
Thanks. But I must also say the object allocator could be speed up because at the time I wrote this there was no way to allocate consecutive bytes from a pool in constant complexity. I am still using fast_pool_allocator<block_header>: https://svn.boost.org/svn/boost/sandbox/block_ptr/boost/block_ptr.hpp
That's one more improvement that can be done and it'll be perfect.
Sorry I didn't mean this allocator but boost::singleton_pool<pool, sizeof(char)>: https://svn.boost.org/svn/boost/sandbox/block_ptr/boost/detail/block_base.hp...
One more improvement that could also be done would be to make the global mutex static_mutex() "set" oriented: https://svn.boost.org/svn/boost/sandbox/block_ptr/boost/block_ptr.hpp This way modifications to a "set" could be made per thread; i.e. a "set" would be thread independent from each other. But this is not trivial unless we work together on this. -Phil
On 8/31/2013 12:01 AM, Dave Abrahams wrote:
There's no one correct destruction order for objects participating in a cycle. That's one reason most C++ garbage collectors collect memory but don't run destructors. How does your system deal with this?
It keeps track of the order of construction and so their are deleted in the order of construction so that their members are deleted first. It also blocks before an attempt to delete a heap object that is already being marked for deletion as you can see in ~block_ptr(): https://svn.boost.org/svn/boost/sandbox/block_ptr/boost/block_ptr.hpp -Phil
On 8/31/2013 11:14 AM, Phil Bouchard wrote:
It keeps track of the order of construction and so their are deleted in the order of construction so that their members are deleted first. It also blocks before an attempt to delete a heap object that is already being marked for deletion as you can see in ~block_ptr(): https://svn.boost.org/svn/boost/sandbox/block_ptr/boost/block_ptr.hpp
*It keeps track of the order of construction and so they are deleted...
On 8/31/2013 11:48 AM, Phil Bouchard wrote:
On 8/31/2013 11:14 AM, Phil Bouchard wrote:
It keeps track of the order of construction and so their are deleted in the order of construction so that their members are deleted first. It also blocks before an attempt to delete a heap object that is already being marked for deletion as you can see in ~block_ptr(): https://svn.boost.org/svn/boost/sandbox/block_ptr/boost/block_ptr.hpp
*It keeps track of the order of construction and so they are deleted...
So if you have a cyclic list, it will be deleted in the correct order. -Phil
On 8/31/2013 1:13 PM, Mathieu Champlon wrote:
On 31/08/2013 17:14, Phil Bouchard wrote:
It keeps track of the order of construction and so their are deleted in the order of construction so that their members are deleted first.
Did you mean deleted in the reverse order of construction ?
So you have a cyclic list: +-> 1 -> 2 -> 3 -+ | | +----------------+ 1 will be called for destruction first but the pointer to 2 and then 3 will deleted beforehand because they are their members. The pointer of 3 to 1 will be ineffective. -Phil
On 8/31/2013 1:22 PM, Phil Bouchard wrote:
So you have a cyclic list:
+-> 1 -> 2 -> 3 -+ | | +----------------+
1 will be called for destruction first but the pointer to 2 and then 3 will deleted beforehand because they are their members. The pointer of 3 to 1 will be ineffective.
And if you have: +-> 1 -+ +-> 2 -+ | | | | +------+ +------+ 1 will be deleted then 2. -Phil
On 8/31/2013 1:26 PM, Phil Bouchard wrote:
And if you have:
+-> 1 -+ +-> 2 -+ | | | | +------+ +------+
1 will be deleted then 2.
Note that in order to end up with the aforementioned case we need to start with: +-> 1 -------> 2 -+ | | +-----------------+ +-> 1 -+ +-> 2 -+ | | | | +------+ +------+ -Phil
On 8/31/2013 2:15 PM, Phil Bouchard wrote:
Note that in order to end up with the aforementioned case we need to start with:
+-> 1 -------> 2 -+ | | +-----------------+
+-> 1 -+ +-> 2 -+ | | | | +------+ +------+
Remember that it works by sets so this example is a set that gets split up. -Phil
On 8/31/2013 6:02 PM, Phil Bouchard wrote:
On 8/31/2013 2:15 PM, Phil Bouchard wrote:
Note that in order to end up with the aforementioned case we need to start with:
+-> 1 -------> 2 -+ | | +-----------------+
+-> 1 -+ +-> 2 -+ | | | | +------+ +------+
Remember that it works by sets so this example is a set that gets split up.
It's all explained here: https://svn.boost.org/svn/boost/sandbox/block_ptr/libs/smart_ptr/doc/BlockPo... -Phil
+-> 1 -------> 2 -+ | | +-----------------+
+-> 1 -+ +-> 2 -+ | | | | +------+ +------+
have a container to hold smart pointer to every object , and let them use weak pointer to each other. thus cyclic avoided. cyclic means wrong "owner". if 2 is not owned by 1, how can you use shared pointers?
On 9/2/2013 6:22 AM, microcai wrote:
have a container to hold smart pointer to every object , and let them use weak pointer to each other. thus cyclic avoided. cyclic means wrong "owner". if 2 is not owned by 1, how can you use shared pointers?
Is there an interest I write a book on this and I will cover all cases? -Phil
On 8/31/2013 1:22 PM, Phil Bouchard wrote:
So you have a cyclic list:
+-> 1 -> 2 -> 3 -+ | | +----------------+
1 will be called for destruction first but the pointer to 2 and then 3 will deleted beforehand because they are their members. The pointer of 3 to 1 will be ineffective.
The pointer of 3 to 1 will be ineffective because 1 is marked for deletion. -Phil
On 27 August 2013 17:08, Phil Bouchard wrote:
On 8/27/2013 11:58 AM, Klaim - Joël Lamotte wrote:
On Tue, Aug 27, 2013 at 5:34 PM, Phil Bouchard <philippe@fornux.com> wrote:
- block_ptr hasn't been reviewed yet but memory management is an important subject. Are there unanswered questions about it?
My current understanding is that it is not clear at all to most of us (me included) what block_ptr is.
Well it's a memory manager but I am not sure where I fail to document its design.
Why is <boost/block_ptr.hpp> in the top-level directory? Why does <boost/block_ptr.hpp> include <iostream>?
On 8/27/2013 11:34 AM, Phil Bouchard wrote:
Hello everyone,
In a quest to speed up my Android applications and knowing Java is written in C++, I decided to discuss with the OS community openjdk.java.net to try to introduce them block_ptr. But the conversation was dead in the water probably due to the lack of developers.
For those who are interested in the subject, the memory manager of the Android is located here: https://android.googlesource.com/platform/dalvik/+/master/vm/alloc It should be reasonably trivial to swap. Thanks, -Phil
participants (11)
-
Andrew Koenig -
Antony Polukhin -
Dave Abrahams -
Gelin Yan -
Jens Weller -
Jonathan Wakely -
Klaim - Joël Lamotte -
Mathieu Champlon -
microcai -
Phil Bouchard -
Vicente J. Botet Escriba