Re: Re: GTY and const

Re: Re: GTY and const

[Lucas (a.k.a T-Bird or bsdfan3)]

Why can't we use the Boehm's GC for all of GCC?  It's already 
distributed with GCC and we already use it for the Java runtime.
Lucas
Zack Weinberg wrote:

>¹ however, I am still sympathetic to the notion that GC-allocating
>everything would be a good idea if we could just get a non-sucky GC
>algorithm.  Remember that glorious time in the 3.1-3.3 timeframe when
>we never had use-after-free bugs?
>  
>

Re: GTY and const

[Robert Dewar]

Lucas (a.k.a T-Bird or bsdfan3) wrote:
> Why can't we use the Boehm's GC for all of GCC?  It's already 
> distributed with GCC and we already use it for the Java runtime.
> Lucas
> Zack Weinberg wrote:

For the record, you cannot use BGC for the GNAT compiler itself
because it uses virtual origin addressing which is incompatible
with the BGC approach. In terms of the run time library, I think
everything should work except the g-table and g-dyntab units which
also use virtual addressing.

Re: GTY and const

[Marc Espie]

In article <41CAF9EF.2030404@cox.net> you write:
>Why can't we use the Boehm's GC for all of GCC?  It's already 
>distributed with GCC and we already use it for the Java runtime.
>Lucas

The java runtime is one of those things that break on a lot of
platforms. Okay, I'm biased, maybe not a lot. But at least on
OpenBSD i386, I haven't been able to get most java runtime tests
to run: boehm-gc doesn't work with dynamic libraries for us.
I don't know why, and I haven't had time to find out.

boehm-gc needs very specific support for each processor, each OS.
I've read through parts of it, it's really not  simple code, a real
maze of a mess of #ifdef. the current gc used by gcc is, 
comparatively, very easy to work with. And it works on most everything,
as there are degraded versions of it that demand very little where the
OS suppport is concerned.

GTY and const

[Matt Kraai]

Howdy,

One of the warnings that causes PR 18176 is an assignment of a const
cpp_token * to the source member of the val union of the cpp_token
structure, which is not const.  According to the uses I've found, this
member could be const, except that doing so causes warnings in
gtype-desc.c, which does not preserve the const qualifier.

Would it be better to add a cast around the assignment or to make the
GTY code handle const members?

-- 
Matt

Re: GTY and const

[Steven Bosscher]

On Monday 13 December 2004 21:30, Matt Kraai wrote:
> Would it be better to add a cast around the assignment or to make the
> GTY code handle const members?

I'd go for the cast.

Gr.
Steven

Re: GTY and const

[Zack Weinberg]

Matt Kraai <kraai@ftbfs.org> writes:

> Howdy,
>
> One of the warnings that causes PR 18176 is an assignment of a const
> cpp_token * to the source member of the val union of the cpp_token
> structure, which is not const.  According to the uses I've found, this
> member could be const, except that doing so causes warnings in
> gtype-desc.c, which does not preserve the const qualifier.
>
> 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.

zw

Re: GTY and const

[Geoffrey Keating]

Zack Weinberg <zack@codesourcery.com> writes:

> Matt Kraai <kraai@ftbfs.org> writes:
> 
> > Howdy,
> >
> > One of the warnings that causes PR 18176 is an assignment of a const
> > cpp_token * to the source member of the val union of the cpp_token
> > structure, which is not const.  According to the uses I've found, this
> > member could be const, except that doing so causes warnings in
> > gtype-desc.c, which does not preserve the const qualifier.
> >
> > 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.

Re: GTY and const

[Zack Weinberg]

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.

zw

Re: GTY and const

[Daniel Berlin]

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.

Right now we GTY/gc allocate a lot of things just so we can mark some
things they may point to.
The fact that we *have* to do this is *bad*.

Roots are roots, whether they occur in GC memory or not.
The requirement that they be in GC memory is just bogus and an artifact
of the way ggc-page marks.

--Dan

Re: GTY and const

[Zack Weinberg]

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.

zw

¹ however, I am still sympathetic to the notion that GC-allocating
everything would be a good idea if we could just get a non-sucky GC
algorithm.  Remember that glorious time in the 3.1-3.3 timeframe when
we never had use-after-free bugs?

Re: GTY and const

[Geoff Keating]

[-- 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 --]

Re: GTY and const

[Zack Weinberg]

Geoff Keating <geoffk@geoffk.org> writes:

> 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:
>> 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.

Sure; however, that happens behind the back of the code that uses this
data structure.  The 'const' is correctly placed to catch bugs in that
code, which is what I care about.

> [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.]

I think Dan wants to be able to dynamically declare roots which are
somewhere in malloc space, or something like that.

zw

Re: GTY and const

[Daniel Berlin]

On Wed, 2004-12-22 at 21:06 -0800, Zack Weinberg wrote:
> Geoff Keating <geoffk@geoffk.org> writes:
> 
> > 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:
> >> 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.
> 
> Sure; however, that happens behind the back of the code that uses this
> data structure.  The 'const' is correctly placed to catch bugs in that
> code, which is what I care about.
> 
> > [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.]
> 
> I think Dan wants to be able to dynamically declare roots which are
> somewhere in malloc space, or something like that.

Yes.


> 
> zw