public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Geoff Keating <geoffk@geoffk.org>
To: Zack Weinberg <zack@codesourcery.com>
Cc: Daniel Berlin <dberlin@dberlin.org>, gcc@gcc.gnu.org
Subject: Re: GTY and const
Date: Thu, 23 Dec 2004 03:43:00 -0000	[thread overview]
Message-ID: <596EF94A-5481-11D9-9172-000A95B1F520@geoffk.org> (raw)
In-Reply-To: <87zn06exoi.fsf@codesourcery.com>

[-- Attachment #1: Type: text/plain, Size: 1649 bytes --]


On 22/12/2004, at 3:10 PM, Zack Weinberg wrote:

> Daniel Berlin <dberlin@dberlin.org> writes:
>
>> On Tue, 2004-12-21 at 11:01 -0800, Zack Weinberg wrote:
>>> Geoffrey Keating <geoffk@geoffk.org> writes:
>>>
>>>>>> Would it be better to add a cast around the assignment or to make
>>>>>> the GTY code handle const members?
>>>>>
>>>>> I'd prefer that you improved gengtype.
>>>>
>>>> It's not gengtype, the problem really is that you cannot have const
>>>> GCed memory, for the same underlying reasons that you cannot free() 
>>>> a
>>>> const pointer.
>>>
>>> No, that's just plain not true.  cpplib makes extensive use of 
>>> 'const'
>>> to indicate write-once data structures (they are initialized through 
>>> a
>>> non-const pointer, of course).  Those definitely can be GC memory.
>>
>> Right. There is a significant difference between what we need to walk
>> for marking, and what we really need to GC allocate.
>
> While what you say is true¹, this particular data structure needs to be
> in GC memory not because it can point to other things that are in GC
> memory, but because it's part of a precompiled header.

And, as a consequence of this, these data structures are not truly 
write-once; any pointers contained in them will be changed by saving a 
PCH.

[I think I disagree with Dan's statement, but I'm not sure what he 
means by "GC allocate".  Certainly all roots need to be under control 
of the GC machinery.  Equally certainly, not all roots need to be in 
memory that can be freed, and there are two obvious counterexamples in 
the current compiler, static variables and PCH files.]

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2410 bytes --]

  reply	other threads:[~2004-12-23  1:23 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-12-14  7:00 Matt Kraai
2004-12-14 10:30 ` Steven Bosscher
2004-12-14 18:35 ` Zack Weinberg
2004-12-21 18:26   ` Geoffrey Keating
2004-12-21 19:01     ` Zack Weinberg
2004-12-22 23:11       ` Daniel Berlin
2004-12-22 23:24         ` Zack Weinberg
2004-12-23  3:43           ` Geoff Keating [this message]
2004-12-23  5:15             ` Zack Weinberg
2004-12-23  5:39               ` Daniel Berlin
     [not found] <1103776856.24215.ezmlm@gcc.gnu.org>
2004-12-23 17:09 ` Lucas (a.k.a T-Bird or bsdfan3)
2004-12-23 20:04   ` Robert Dewar
2004-12-24  2:32   ` Marc Espie

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=596EF94A-5481-11D9-9172-000A95B1F520@geoffk.org \
    --to=geoffk@geoffk.org \
    --cc=dberlin@dberlin.org \
    --cc=gcc@gcc.gnu.org \
    --cc=zack@codesourcery.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).