RE: Correction to last message, GC status

["Boehm, Hans" <hans_boehm at hp dot com>]

> From: Tom Tromey [mailto:tromey@redhat.com]
> 
> >>>>> "Hans" == Boehm, Hans <hans_boehm@hp.com> writes:
> 
> How is the 6.0alpha8 import being done?  Are you switching to using
> the gcc tree as the main repository?  If so then we don't need to do
> all the cvs shennanigans (though it might still be nice).  If not we
> should probably do them.  I can point you at some relatively generic
> instructions on how to do this, or I could try to find the time to do
> the import myself...
The gcc tree is not yet the main repository.  I have been applying the
changes to my gcc work area, somewhat manually.  There are unfortunately
some new integration issues, since there is now a Makefile.am, configure.in
etc. in the gc distribution.  It differs from the gcj one mainly in that the
library name is different, it doesn't write out the gc C flags for use
elsewhere, it tries to build a more general configuration, and it's
buildable outside the gcc context.

Is there an advantage to the "cvs shennanigans", as opposed to just checking
in what I have (with either a ChangeLog entry that says 6.0alpha8
integration, or a more detailed one derived from my README.changes)?

Should I check in the standalone configure.in etc under a different name?
Or should we just leave it out until we finish unifying the two?  (The
library name issue seems to make that harder than necessary.  I still wonder
whether a renaming wouldn't be better.)

If someone with configure/Automake experience gets a chance to look at
configure automake stuff in
http://www.hpl.hp.com/personal/Hans_Boehm/gc/gc_source/gc6.0alpha8.tar.gz ,
that would be appreciated.

(Note that this currently violates the rules somewhat, in that there is a
Makefile in the distribution, which is a copy of Makefile.direct, a
descendent of the old Makefile.  Configure overwrites Makefile with
something different.  This was a compromise.  "Make test" works as before.
"configure; make" should also do the right thing, and shouldn't require
playing directly with preprocessor macros.)
> 
> We need ChangeLog entries before these patches can go in.  I can point
> you at the docs for how to write them if you like.
Of course.  I'll take care of that before checking it in.
> 
> Hans> +#if 0
> Hans>        if ((ptr_t) (Obj) >= GC_least_plausible_heap_addr \
> Hans>  	  && (ptr_t) (Obj) <= GC_greatest_plausible_heap_addr) \
> Hans>          PUSH_CONTENTS (Obj, Top, Limit, Source, Exit)
> Hans> +#endif
> 
> Just delete old code.  No point in keeping it around; we can resurrect
> it via cvs if we need to.
Done.  There's a bunch of other "if 0" ed code already in the file (probably
also originally my doing).  I assume it should also disappear?
> 
> Hans>  static void * handle_out_of_memory(size_t)
> Hans>  {
> Hans>    _Jv_ThrowNoMemory();
> Hans> +  /* NOT REACHED */
> Hans> +  return 0;
> Hans>  }
> 
> Do we need this?  I marked _Jv_ThrowNoMemory as `noreturn'; that
> should suffice.  If we do still need it, it is ok.
It looks like we don't need it anymore.  I removed it.
> 
> Hans>  inline void *
> Hans>  _Jv_AllocPtrFreeObj (jsize size, jclass klass)
> Hans>  {
> Hans> [ ... ]
> Hans> +# ifdef THREAD_LOCAL_ALLOC
> Hans> +    void * obj = GC_local_gcj_malloc(size);
> 
> Shouldn't that be `GC_local_gcj_malloc(size, klass->vtable)' ?
Definitely!  Thanks for catching that.
>  
> Hans> +AC_ARG_ENABLE(parallel-mark,
> 
> I wonder if these options are documented anywhere.
Good question ...

Hans