Do we still need ggc-simple

Do we still need ggc-simple

[Steven Bosscher]

Hi,

Why do we still have ggc-simple?  Are there any targets for which ggc-page 
doesn't work?

Gr.
Steven

Re: Do we still need ggc-simple

[Ben Elliston]

Steven Bosscher <s.bosscher@student.tudelft.nl> writes:

> Why do we still have ggc-simple?  Are there any targets for which
> ggc-page doesn't work?

It can still be chosen with the --with-gc configure option and leaving
it there as a simpler GC could be useful for debugging.

Ben

Re: Do we still need ggc-simple

[Nick Burrett]

Steven Bosscher wrote:

> Why do we still have ggc-simple?  Are there any targets for which ggc-page 
> doesn't work?

Yes (arm-riscos-aof), though it is maintained outside of the GCC tree.

Regards,


Nick.

-- 
Nick Burrett
Network Engineer, Designer Servers Ltd.   http://www.dsvr.co.uk

Re: Do we still need ggc-simple

[Steven Bosscher]

On Wednesday 10 December 2003 11:41, Nick Burrett wrote:
> Steven Bosscher wrote:
> > Why do we still have ggc-simple?  Are there any targets for which
> > ggc-page doesn't work?
>
> Yes (arm-riscos-aof), though it is maintained outside of the GCC tree.

OK.  So I like bitching.

Why is arm-riscos-aof not using ggc-page with malloc?

Fact:  Virtually no-one is using ggc-simple.

I know for sure since building GCC with ggc-simple.c has been impossible since 
at least 26 Oct 2003.  On that day the zone collector was commited, and 
anyone who has tried to build gcc with ggc-simple as the collector should 
have seen a link failure because tree_zone is not declared anywhere.  I've 
heard no complaint, and my conclusion has to be that in almost two months 
time, nobody has noticed that ggc-simple.c is currently broken.

Ben suggested that a simpler GC could be useful for debugging.  I don't see 
how.  It's easy enough to tweak the better collectors to make them not 
collect at all, or change it in other ways to make debugging easier.

Besides, we have two collectors, and I find it hard to believe that we'd be 
able to break them both without anyone noticing.  Especially ggc-page, which 
is now effectively in "deep freeze": No serious work on this collector has 
been done over the past year (since the pch branch was merged).  So for 
debugging, you can always switch to the another collector.
(I do have to admit that we need a better way to analyse the performance/
characteristics of the other collectors.  But this has little to do with 
debugging.)

Having three collectors like we do now is very unpleasant.  Every time someone 
tries to add a feature to the GC system, it has to be added to _three_ 
collectors.  Bah.  Especially since ggc-simple is almost unused.  I would 
very much like to see it go away.

Gr.
Steven

Re: Do we still need ggc-simple

[Nick Burrett]

Steven Bosscher wrote:
> On Wednesday 10 December 2003 11:41, Nick Burrett wrote:
> 
>>Steven Bosscher wrote:
>>
>>>Why do we still have ggc-simple?  Are there any targets for which
>>>ggc-page doesn't work?
>>
>>Yes (arm-riscos-aof), though it is maintained outside of the GCC tree.
> 
> 
> OK.  So I like bitching.
> 
> Why is arm-riscos-aof not using ggc-page with malloc?

Sorry.  The last time I looked to make the decision on using ggc-page or 
ggc-simple, I figured that ggc-page was a solely mmap implementation. 
Upon reading the code further, I notice it isn't and therefore I will 
drop my requirement for ggc-simple.

> I know for sure since building GCC with ggc-simple.c has been impossible since 
> at least 26 Oct 2003.  On that day the zone collector was commited, and 
> anyone who has tried to build gcc with ggc-simple as the collector should 
> have seen a link failure because tree_zone is not declared anywhere.  I've 
> heard no complaint, and my conclusion has to be that in almost two months 
> time, nobody has noticed that ggc-simple.c is currently broken.

You are making the assumption that all port maintainers keep their ports 
right up-to-date.  Due to limited resources and the work required, it 
has taken me and a small team of developers over a year to move from 
2.95 to a 3.3 port.  Part of this is due to having to write/maintain a C 
library, an assembler, a linker, a library maker and the ports of 
several other applications.  The other part of the problem is not having 
that much time out of office-hours to work on such stuff.

I would have come across the breakage to ggc-simple.c in about 12 months 
from now, at which point I'd do the necessary work to swap to ggc-page.c 
(if there was any to be done).

> Having three collectors like we do now is very unpleasant.  Every time someone 
> tries to add a feature to the GC system, it has to be added to _three_ 
> collectors.  Bah.  Especially since ggc-simple is almost unused.  I would 
> very much like to see it go away.

I don't disagree.  If you're committing a patch that breaks an interface 
(in this case ggc-simple.c), then either you should have fixed your 
patch to fix the interface, or simply removed ggc-simple.c.

Breaking the ggc-simple.c or removing the file entirely has the same net 
effect -- it isn't going to work in either case.  Then if somebody 
complains, you could either revert it's removal and fix the breakages, 
or help the maintainer to understand why ggc-page.c should be used instead.

Regards,


Nick.

Re: Do we still need ggc-simple

[Mark Mitchell]

On Sun, 2003-12-14 at 02:35, Nick Burrett wrote:
> Steven Bosscher wrote:
> > On Wednesday 10 December 2003 11:41, Nick Burrett wrote:
> > 
> >>Steven Bosscher wrote:
> >>
> >>>Why do we still have ggc-simple?  Are there any targets for which
> >>>ggc-page doesn't work?
> >>
> >>Yes (arm-riscos-aof), though it is maintained outside of the GCC tree.
> > 
> > 
> > OK.  So I like bitching.
> > 
> > Why is arm-riscos-aof not using ggc-page with malloc?
> 
> Sorry.  The last time I looked to make the decision on using ggc-page or 
> ggc-simple, I figured that ggc-page was a solely mmap implementation. 
> Upon reading the code further, I notice it isn't and therefore I will 
> drop my requirement for ggc-simple.

Based on this discussion, I will pre-approve a patch to remove all
traces of ggc-simple.c from the mainline.

-- 
Mark Mitchell <mark@codesourcery.com>
CodeSourcery, LLC

Re: Do we still need ggc-simple

[Steven Bosscher]

On Sunday 28 December 2003 19:33, Mark Mitchell wrote:
> On Sun, 2003-12-14 at 02:35, Nick Burrett wrote:
> > Steven Bosscher wrote:
> > > On Wednesday 10 December 2003 11:41, Nick Burrett wrote:
> > >>Steven Bosscher wrote:
> > >>>Why do we still have ggc-simple?  Are there any targets for which
> > >>>ggc-page doesn't work?
> > >>
> > >>Yes (arm-riscos-aof), though it is maintained outside of the GCC tree.
> > >
> > > OK.  So I like bitching.
> > >
> > > Why is arm-riscos-aof not using ggc-page with malloc?
> >
> > Sorry.  The last time I looked to make the decision on using ggc-page or
> > ggc-simple, I figured that ggc-page was a solely mmap implementation.
> > Upon reading the code further, I notice it isn't and therefore I will
> > drop my requirement for ggc-simple.
>
> Based on this discussion, I will pre-approve a patch to remove all
> traces of ggc-simple.c from the mainline.


Like so.

2003-12-28  Steven Bosscher  <steven@gcc.gnu.org>

	* ggc-simple.c: Remove.
	* Makefile.in: Remove ggc-simple.o.
	* configure.in: Disallow --with-gc=simple.
	* configure: Regenerate.

Index: Makefile.in
===================================================================
RCS file: /cvs/gcc/gcc/gcc/Makefile.in,v
retrieving revision 1.1212
diff -c -3 -p -r1.1212 Makefile.in
*** Makefile.in	24 Dec 2003 00:14:17 -0000	1.1212
--- Makefile.in	28 Dec 2003 19:40:16 -0000
*************** gtype-desc.o: gtype-desc.c $(CONFIG_H) $
*** 1466,1474 ****
  ggc-common.o: ggc-common.c $(CONFIG_H) $(SYSTEM_H) coretypes.h $(GGC_H) \
  	$(HASHTAB_H) toplev.h $(PARAMS_H) hosthooks.h
  
- ggc-simple.o: ggc-simple.c $(CONFIG_H) $(SYSTEM_H) coretypes.h $(TM_H) $(RTL_H) $(TREE_H) \
- 	flags.h $(GGC_H) varray.h $(TIMEVAR_H) $(TM_P_H) $(PARAMS_H)
- 
  ggc-page.o: ggc-page.c $(CONFIG_H) $(SYSTEM_H) coretypes.h $(TM_H) $(RTL_H) $(TREE_H) \
  	flags.h toplev.h $(GGC_H) $(TIMEVAR_H) $(TM_P_H) $(PARAMS_H)
  
--- 1466,1471 ----
Index: configure
===================================================================
RCS file: /cvs/gcc/gcc/gcc/configure,v
retrieving revision 1.787
diff -c -3 -p -r1.787 configure
*** configure	22 Dec 2003 07:42:37 -0000	1.787
--- configure	28 Dec 2003 19:40:19 -0000
*************** ac_help="$ac_help
*** 85,91 ****
                            use KEY instead of GCC version as the last portion
                            of the registry key"
  ac_help="$ac_help
!   --with-gc={simple,page,zone} choose the garbage collection mechanism to use
                            with the compiler"
  ac_help="$ac_help
    --with-system-zlib      use installed libz"
--- 85,91 ----
                            use KEY instead of GCC version as the last portion
                            of the registry key"
  ac_help="$ac_help
!   --with-gc={page,zone} choose the garbage collection mechanism to use
                            with the compiler"
  ac_help="$ac_help
    --with-system-zlib      use installed libz"
*************** fi
*** 7649,7655 ****
  if test "${with_gc+set}" = set; then
    withval="$with_gc"
    case "$withval" in
!   simple | page | zone)
      GGC=ggc-$withval
      ;;
    *)
--- 7649,7655 ----
  if test "${with_gc+set}" = set; then
    withval="$with_gc"
    case "$withval" in
!   page | zone)
      GGC=ggc-$withval
      ;;
    *)
Index: configure.in
===================================================================
RCS file: /cvs/gcc/gcc/gcc/configure.in,v
retrieving revision 1.763
diff -c -3 -p -r1.763 configure.in
*** configure.in	22 Dec 2003 07:42:37 -0000	1.763
--- configure.in	28 Dec 2003 19:40:21 -0000
*************** AC_SUBST(gthread_flags)
*** 2689,2698 ****
  
  # Find out what GC implementation we want, or may, use.
  AC_ARG_WITH(gc,
! [  --with-gc={simple,page,zone} choose the garbage collection mechanism to use
                            with the compiler],
  [case "$withval" in
!   simple | page | zone)
      GGC=ggc-$withval
      ;;
    *)
--- 2689,2698 ----
  
  # Find out what GC implementation we want, or may, use.
  AC_ARG_WITH(gc,
! [  --with-gc={page,zone} choose the garbage collection mechanism to use
                            with the compiler],
  [case "$withval" in
!   page | zone)
      GGC=ggc-$withval
      ;;
    *)