public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Laurynas Biveinis <laurynas.biveinis@gmail.com>
To: Jeff Law <law@redhat.com>
Cc: Steven Bosscher <stevenb.gcc@gmail.com>,
	gcc-patches@gcc.gnu.org,
		Richard Guenther <richard.guenther@gmail.com>,
	Mike Stump <mikestump@comcast.net>
Subject: Re: [gc-improv] Permanent vs function RTL obstack fix
Date: Tue, 12 Apr 2011 11:46:00 -0000	[thread overview]
Message-ID: <BANLkTikFrcCNTxAThfbPF8YMrZ+-wuTwwg@mail.gmail.com> (raw)
In-Reply-To: <BANLkTinDX5m9vyzC+yKOV-SmuBRuqJSkEg@mail.gmail.com>

[Resending with the correct Mike's address, sorry for the spam]

> So what's the plan for the case where you need to change the lifetime of
> an object?

Copying it. Frankly at the moment I don't how much trouble does deep
copying from scratch to function entails, as mentioned in your other
e-mail. ATM I am working at separating permanent from function. If it
turns out to be unsurmountable, then, well, lesson learned.

> What's the plan for building some kind of consistency
> checking to ensure that we aren't referencing dangling pointers.

I haven't thought them out in detail at this moment, but I had some
ideas, very close to what Steven suggested: poisoning RTL obstacks
instead of freeing/reusing. Walking existing GC memory at RTL function
memory freeing time to see that no pointers point to it. The latter is
virtually free even.

> I ask these questions because they were a serious source of problems in
> the past and any significant revamping of memory management needs to
> have a reasonable story for how to deal with them, else we're taking a
> rather significant step backwards.

I plan to propose merging the branch once such concerns will be
adequately addressed. Personally I believe that it is possible to
address them. In the case it is impossible to address them, I will
propose merging very lite version of the branch that changes RTL
allocation interface, keeps GC behind it, and leaves the rest for
presumably brighter future. Hopefully this will not be the case.

Regarding PCH: so far whenever I touch it, frankly I hate it. In the
current context: the RTL output there was early-generated RTL which
IMHO itself is a sign of a poor IL separation in GCC. So in that
respect I believe my work is a step in a right direction, even if
painful.

Thanks for your feedback,
--
Laurynas

  reply	other threads:[~2011-04-12 11:46 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-04-07  6:17 Laurynas Biveinis
2011-04-07 21:33 ` Steven Bosscher
2011-04-08 13:22   ` Laurynas Biveinis
2011-04-08 14:36     ` Jeff Law
2011-04-08 14:39       ` Richard Guenther
2011-04-08 14:42         ` Jeff Law
2011-04-09 10:34       ` Steven Bosscher
2011-04-10 18:27         ` Laurynas Biveinis
2011-04-10 18:49           ` Basile Starynkevitch
2011-04-11 20:03           ` Jeff Law
2011-04-12  0:22             ` Mike Stump
2011-04-12  2:54               ` Jeff Law
2011-04-12  6:34                 ` Steven Bosscher
2011-04-12  7:01                   ` Jakub Jelinek
2011-04-12  8:45                     ` Steven Bosscher
2011-04-12 10:44                       ` Mike Stump
2011-04-12 10:49                         ` Steven Bosscher
2011-04-12 15:02                       ` Jeff Law
2011-04-12 11:56             ` Bernd Schmidt
2011-04-12 15:31               ` Jeff Law
2011-04-10 18:23       ` Laurynas Biveinis
2011-04-10 22:33         ` Steven Bosscher
2011-04-11 20:08         ` Jeff Law
2011-04-12 11:43           ` Laurynas Biveinis
2011-04-12 11:46             ` Laurynas Biveinis [this message]
2011-04-12 17:25               ` Mike Stump

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=BANLkTikFrcCNTxAThfbPF8YMrZ+-wuTwwg@mail.gmail.com \
    --to=laurynas.biveinis@gmail.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=law@redhat.com \
    --cc=mikestump@comcast.net \
    --cc=richard.guenther@gmail.com \
    --cc=stevenb.gcc@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).