headers
Paul Hilfinger | 1 Aug 2008 01:25
Picon
Favicon

Re: GDB to C++ issue: deletion


> > 1. Ahem, which is precisely why I used a new subject, so as not to 
> >    incorporate an incidental side discussion into the same thread!
> 
> Sorry.  You replied to the same thread; most current Unix mailers
> will thread such replies together regardless of subject.  I didn't
> even notice.

How "helpful" of them.  Sorry; I didn't edit my header stringently
enough.  My bad.

> > 2. On the other hand, if someone is going to claim the advantages of 
> >    not having to do delete as an advantage, it is not entirely 
> >    unreasonable to make sure it really works out that way in practice.
> 
> IMO that applies to short lived variables, not the sort of things that
> get obstacked at all.

Actually, I had already concluded that short-lived variables would NOT
be a great problem.  To a first approximation, the effect of using STL's
storage management is to increase allocation costs by some constant
factor, because deallocation cost for an object tends to be limited by
some constant times its allocation cost.  As long as GDB's allocation
costs are not huge (and the constant factors are not huge), we
shouldn't have much pain.  

But that's just an overall argument about total execution time.
Common sources of short-lived variables (say during parsing and
(sub)expression evaluation) don't produce that many variables between
prompts (usually).  What I was more interested in was the possibility
(Continue reading)

Permalink | Reply | 1 comment |
headers
Daniel Jacobowitz | 1 Aug 2008 01:34

Re: GDB to C++ issue: deletion

On Thu, Jul 31, 2008 at 04:25:18PM -0700, Paul Hilfinger wrote:
> But that's just an overall argument about total execution time.
> Common sources of short-lived variables (say during parsing and
> (sub)expression evaluation) don't produce that many variables between
> prompts (usually).  What I was more interested in was the possibility
> of noticeably large changes in pause times for expensive operations
> (such as re-reading a symbol table) on large executables.  I can think
> of approaches, certainly, but have no actual experience with how well
> they integrate with STL classes in practice.

Yes, those are exactly the sort of allocations that we wouldn't
quickly convert...

I imagine you could make STL containers use obstacks through the
allocator interface, but it would depend on QoI how much extra
allocation was done.  Anyway, I don't know much about it so I will be
quiet now.

--

-- 
Daniel Jacobowitz
CodeSourcery
Permalink | Reply | 0 comments |
headers
Ian Lance Taylor | 1 Aug 2008 07:38
Gravatar

Re: GDB to C++ issue: deletion

Paul Hilfinger <hilfingr <at> EECS.Berkeley.EDU> writes:

> This reminded me of an issue that I'd be curious to see discussed.
> The STL container classes are certainly convenient for decreasing
> memory leaks with little fuss, but they do so internally with
> individual frees of allocated items.  GDB currently does much of its
> allocation using a region-based style (in the form of obstacks).  This
> reduces leakage at some expense in safety (although I have not seen
> many dangling-pointer problems triggered premature obstack releases in
> GDB).  Allegedly, GDB's use of obstacks significantly speeds up
> allocation and (of course) deletion.  I have certainly seen programs
> in which the need to free data structures individually adds
> significant cost*.  The STL container classes provide for allocators,
> but I have no experience in how well they could be made to work in
> duplicating GDB's current performance in this area.

It's fairly easy to use a custom allocator for an STL object which
allocates from a memory pool.  libstdc++ has one.  The free function
simply adds the pointer to a free list.  You wouldn't want to use that
specific allocator, since it loses performance by being multi-thread
safe.  But it would be easy to simplify it.

Lots of code which uses obstacks doesn't actually free anything at
all.  It wouldn't really work to duplicate the semantics of
obstack_free in an allocator (free the specified object and all
objects allocated after it).  But it would be easy to simply ignore
calls to free--just make the allocator's deallocate function do
nothing.  In that case the memory would not go away until the
allocator itself is destroyed--or, if you prefer, the allocator could
be written to simply never release the memory at all.
(Continue reading)

Permalink | Reply | 0 comments |
headers
André Pönitz | 1 Aug 2008 10:54

Re: GDB to C++ issue: deletion

On Friday 01 August 2008 00:04:19 Paul Hilfinger wrote:
> Alpar wrote:
> 
> > A good example for that was the debate on xfree vs. delete. One of the
> > goals of STL standard containers is that using them the programmer will
> > almost never has to use 'delete'.
> 
> This reminded me of an issue that I'd be curious to see discussed.
> The STL container classes are certainly convenient for decreasing
> memory leaks with little fuss, but they do so internally with
> individual frees of allocated items.  GDB currently does much of its
> allocation using a region-based style (in the form of obstacks).  This
> reduces leakage at some expense in safety (although I have not seen
> many dangling-pointer problems triggered premature obstack releases in
> GDB).  Allegedly, GDB's use of obstacks significantly speeds up
> allocation and (of course) deletion.  I have certainly seen programs
> in which the need to free data structures individually adds
> significant cost*.  The STL container classes provide for allocators,
> but I have no experience in how well they could be made to work in
> duplicating GDB's current performance in this area.
> 
> I'd be interested in hearing the thoughts of the C++ lobby.

0. It's the wrong question ;-) It should not be "How to I translate the 
code in lines 30 through 42 from C to C++?" but "The C code in lines
30 through 42 solves problem X. How would I solve X in C++?"
(yes, custom allocators might be a solution to certain generic
allocation performance problems, but the solution more often is
something different.)
(Continue reading)

Permalink | Reply | 7 comments |
headers
Eli Zaretskii | 1 Aug 2008 11:53
Picon

Re: GDB to C++ issue: deletion

> From: =?iso-8859-1?q?Andr=E9_P=F6nitz?= <apoenitz <at> trolltech.com>
> Date: Fri, 1 Aug 2008 10:54:20 +0200
> 
> [1] Of course, every now and then a Guru level coder shows up, replaces
> one central trouble maker with something very cool, more efficient,
> even more hand-crafted, that happens to work well without being
> understood by aynone else. Then the Guru leaves, and the code becomes
> a "no go" area for mere mortals...

Which is why we should request that every such guru documents her
code, both in the sources and in gdbint.texinfo, to the level where
mere mortals can hack on it later.  Unfortunately, not all of them
comply.

Still, I think that it is a misrepresentation to say that GDB code
cannot be understood by "mere mortals".  Most problems, as far as I
remember from questions posted here, are about the high-level
architectural aspects, asked by those who want to add support for some
novel or unusual platform.  People who need to fix a bug in existing
code normally don't have much trouble understanding it.
Permalink | Reply | 6 comments |
headers
Daniel Jacobowitz | 1 Aug 2008 14:56

Re: GDB to C++ issue: deletion

Sorry, I replied to the wrong list.

On Fri, Aug 01, 2008 at 12:53:24PM +0300, Eli Zaretskii wrote:
> Still, I think that it is a misrepresentation to say that GDB code
> cannot be understood by "mere mortals".  Most problems, as far as I
> remember from questions posted here, are about the high-level
> architectural aspects, asked by those who want to add support for some
> novel or unusual platform.  People who need to fix a bug in existing
> code normally don't have much trouble understanding it.

For what it's worth, that's not my experience at all.  Contributors
have a lot of trouble with the GDB code.  One of the biggest problems
is cleanups, which is one reason I'm listening with interest to this
conversation.

--

-- 
Daniel Jacobowitz
CodeSourcery
Permalink | Reply | 2 comments |
headers
Daniel Jacobowitz | 1 Aug 2008 15:13

Re: Move GDB to C++ ?

On Thu, Jul 31, 2008 at 09:42:28PM +0300, Eli Zaretskii wrote:
> > From:  Vladimir Prus <vladimir <at> codesourcery.com>
> > Date:  Thu, 31 Jul 2008 10:10:37 +0400
> > 
> > I think this discussion went a bit wrong way -- trying to convince folks that
> > *investing effort* in converting to C++ is justified. However, I don't think
> > the proposal is about making folks not interested in C++ doing any work -- the
> > proposal is about allowing folks who do some specific work, and want to make
> > use of additional features C++ provides, to use those features, while not imposing
> > significant problems on the rest of contributors.
> 
> Your being busy refactoring does impose a significant problem on me.
> We are members of the same team, so how you use your time while on the
> team is important to me.

Could you please expand on this idea?

Certainly the event of refactoring will have a big impact on all
contributors.  That's at the moment of commit, and not before.  So if
you think it's actively harmful, that's a different issue from the
one Vladimir is talking about here.

GDB is a GNU project, driven by volunteers and sponsored contributors.
And the sponsored contributors are volunteers from the perspective of
anyone outside the sponsoring organization.  I don't understand the
objection to other people choosing to invest effort on something, even
if you think it's unimportant.  Volunteer projects go where their
volunteers want to take them!

And I think one of the bit structural issues in GDB is that it's hard
(Continue reading)

Permalink | Reply | 19 comments |
headers
Eli Zaretskii | 1 Aug 2008 15:46
Picon

Re: Move GDB to C++ ?

> Date: Fri, 1 Aug 2008 09:13:12 -0400
> From: Daniel Jacobowitz <drow <at> false.org>
> Cc: Vladimir Prus <vladimir <at> codesourcery.com>, gdb <at> sources.redhat.com
> 
> On Thu, Jul 31, 2008 at 09:42:28PM +0300, Eli Zaretskii wrote:
> > > From:  Vladimir Prus <vladimir <at> codesourcery.com>
> > > Date:  Thu, 31 Jul 2008 10:10:37 +0400
> > > 
> > > I think this discussion went a bit wrong way -- trying to convince folks that
> > > *investing effort* in converting to C++ is justified. However, I don't think
> > > the proposal is about making folks not interested in C++ doing any work -- the
> > > proposal is about allowing folks who do some specific work, and want to make
> > > use of additional features C++ provides, to use those features, while not imposing
> > > significant problems on the rest of contributors.
> > 
> > Your being busy refactoring does impose a significant problem on me.
> > We are members of the same team, so how you use your time while on the
> > team is important to me.
> 
> Could you please expand on this idea?

The idea is that a maintainer cannot behave with the code as he
pleases, claiming that it's his time and therefore his, and only his,
business.

The idea is also that GDB is a collective effort, so arguments saying
"I will do this because I like it, and you shouldn't care" are not
something I'm willing to accept.

> GDB is a GNU project, driven by volunteers and sponsored contributors.
(Continue reading)

Permalink | Reply | 13 comments |
headers
André Pönitz | 1 Aug 2008 15:53

Re: GDB to C++ issue: deletion

On Friday 01 August 2008 11:53:24 Eli Zaretskii wrote:
> > From: =?iso-8859-1?q?Andr=E9_P=F6nitz?= <apoenitz <at> trolltech.com>
> > Date: Fri, 1 Aug 2008 10:54:20 +0200
> > 
> > [1] Of course, every now and then a Guru level coder shows up, replaces
> > one central trouble maker with something very cool, more efficient,
> > even more hand-crafted, that happens to work well without being
> > understood by aynone else. Then the Guru leaves, and the code becomes
> > a "no go" area for mere mortals...
> 
> Which is why we should request that every such guru documents her
> code, both in the sources and in gdbint.texinfo, to the level where
> mere mortals can hack on it later.  Unfortunately, not all of them
> comply.

Part of the need to document code vanishes if the code is
straight to the point and not blurred by "maintanance operations".

Let me give an example. There is e.g (random pick):

    /* .... The new continuation will be added at
       the front.  */
    void
    add_intermediate_continuation (void (*continuation_hook)
                                   (struct continuation_arg *),
                                   struct continuation_arg *arg_list)
    {
      struct continuation *continuation_ptr;

      continuation_ptr =
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mark Kettenis | 1 Aug 2008 15:52
Picon
Picon
Favicon

Re: Move GDB to C++ ?

> X-Spam-Check-By: sourceware.org
> Date: Fri, 1 Aug 2008 09:13:12 -0400
> From: Daniel Jacobowitz <drow <at> false.org>
> 
> On Thu, Jul 31, 2008 at 09:42:28PM +0300, Eli Zaretskii wrote:
> > > From:  Vladimir Prus <vladimir <at> codesourcery.com>
> > > Date:  Thu, 31 Jul 2008 10:10:37 +0400
> > > 
> > > I think this discussion went a bit wrong way -- trying to convince folks that
> > > *investing effort* in converting to C++ is justified. However, I don't think
> > > the proposal is about making folks not interested in C++ doing any work -- the
> > > proposal is about allowing folks who do some specific work, and want to make
> > > use of additional features C++ provides, to use those features, while not imposing
> > > significant problems on the rest of contributors.
> > 
> > Your being busy refactoring does impose a significant problem on me.
> > We are members of the same team, so how you use your time while on the
> > team is important to me.
> 
> Could you please expand on this idea?
> 
> Certainly the event of refactoring will have a big impact on all
> contributors.  That's at the moment of commit, and not before.  So if
> you think it's actively harmful, that's a different issue from the
> one Vladimir is talking about here.
> 
> GDB is a GNU project, driven by volunteers and sponsored contributors.
> And the sponsored contributors are volunteers from the perspective of
> anyone outside the sponsoring organization.  I don't understand the
> objection to other people choosing to invest effort on something, even
(Continue reading)

Permalink | Reply | 4 comments |

Gmane