Re: mips support broken in gc-7.x

[Resending this one.]

On Thu, 2008-05-29 at 18:58 +0100, Thiemo Seufer wrote:
> I'm not sure what the problem is you see, but Debian has a seperately
> packaged libatomic-ops which carries patches for mips, m68k, powerpc
> and x86 PIC code. Maybe all of those are still not integrated upstream?

Seems so.

> 
> I attach the potentially relevant parts of the Debian patchset to this
> mail.

I applied the MIPS patch to the current CVS, cross-compiled it and ran
it on a Debian Etch box, getting:

$ ./gctest 
Getcontext failed: Use another register retrieval method?
Aborted

Any idea?  Am I missing a patch?

- twisti

Re: mips support broken in gc-7.x

Christian Thalinger wrote:
> [Resending this one.]
> 
> On Thu, 2008-05-29 at 18:58 +0100, Thiemo Seufer wrote:
> > I'm not sure what the problem is you see, but Debian has a seperately
> > packaged libatomic-ops which carries patches for mips, m68k, powerpc
> > and x86 PIC code. Maybe all of those are still not integrated upstream?
> 
> Seems so.
> 
> > 
> > I attach the potentially relevant parts of the Debian patchset to this
> > mail.
> 
> I applied the MIPS patch to the current CVS, cross-compiled it and ran
> it on a Debian Etch box, getting:
> 
> $ ./gctest 
> Getcontext failed: Use another register retrieval method?
> Aborted
> 
> Any idea?  Am I missing a patch?

I can reproduce the problem here (with current Debian/unstable).

Thiemo

Re: mips support broken in gc-7.x

On Mon, 2008-06-02 at 08:55 +0100, Thiemo Seufer wrote:
> > $ ./gctest 
> > Getcontext failed: Use another register retrieval method?
> > Aborted
> > 
> > Any idea?  Am I missing a patch?
> 
> I can reproduce the problem here (with current Debian/unstable).

Do you have time to look into this problem?

- twisti

Re: mips support broken in gc-7.x (and other pending patches)

Boehm, Hans wrote:
> Thanks!  That helps a lot.  A lot of those indeed hadn't made it, but I checked them in now.  (Patch 06 had been
independently half applied.  The PowerPC patch had been applied, as had the x86 PIC patch.)
> 
> I also checked in the pending patch for thread-local allocation with DONT_ADD_BYTE_AT_END.  I think
there was still some dount about whether that patch is complete.  But I can no longer reproduce the problem
with it.

The mips part is still incomplete, it seems. I need the attached three
patches on top of current CVS, one of them addresses the test suite
failures Christian spotted. (The Linux/MIPS glibc has no getcontext
implemented.)

All tests pass on Linux/MIPS with this patchset.

Thiemo

Index: bdwgc/include/private/gcconfig.h
===================================================================
--- bdwgc.orig/include/private/gcconfig.h	2008-05-31 02:10:15.000000000 +0100
+++ bdwgc/include/private/gcconfig.h	2008-05-31 02:10:39.000000000 +0100
 <at>  <at>  -1316,24 +1316,18  <at>  <at> 
 # ifdef MIPS
 #   define MACH_TYPE "MIPS"
 #   ifdef LINUX
-      /* This was developed for a linuxce style platform.  Probably	*/
-      /* needs to be tweaked for workstation class machines.		*/
 #     define OS_TYPE "LINUX"
 #     define DYNAMIC_LOADING

Re: mips support broken in gc-7.x (and other pending patches)

On Mon, 2008-06-02 at 20:04 +0100, Thiemo Seufer wrote:
> The mips part is still incomplete, it seems. I need the attached three
> patches on top of current CVS, one of them addresses the test suite
> failures Christian spotted. (The Linux/MIPS glibc has no getcontext
> implemented.)
> 
> All tests pass on Linux/MIPS with this patchset.

Same for me.  I also linked CACAO against this version and I can start
Eclipse on MIPS.  So it seems to work 

- twisti

New GC Scheduler

Hi,

I'm working on an experimental operating system kernel called
Viengoos.  One feature is that Viengoos exposes the amount of physical
memory available to a resource principal.  I am trying to modify the
the GC scheduler to perform collections when the amount of allocated
memory exceeds some percentage of the available memory.

I've made two changes.  First, in alloc.c, I changed GC_should_collect
to:

  if (GC_adj_bytes_allocd() < min_bytes_allocd())
    return FALSE;

  return GC_get_heap_size() - GC_unmapped_bytes > 7 * available / 8;

Second, because this doesn't actually free any memory and because
collections are relatively infrequent, I change GC_unmap_old in
allchblk.c to unmap all mapped memory on the free lists.

To test my changes, I am using the GCbench program.  I've wrapped it
in a for loop.  Basically, this program allocates trees and then frees
them.

In my current setup, the amount of available memory is constant.  The
collector correctly runs when the allocated memory exceeds the
low-water mark.  95% of the memory is then unmapped.

After some number of collections, a collection that seems perfectly
normal, will result in the triggering GC_NEW returning NULL.  I'm

Re: New GC Scheduler

At Thu, 19 Jun 2008 00:28:16 +0200,
Neal H. Walfield wrote:
> After some number of collections, a collection that seems perfectly
> normal, will result in the triggering GC_NEW returning NULL.  I'm
> still investing this but would like some feedback:

After some more investigation, it seems that it is not GC_malloc that
is failing but something else (quite possibly my run time).  Running
gctest, I also see failures, usually complains that:

  List reversal produced incorrect list - collector is broken

Other times, it simply terminates due to a NULL pointer dereference.
Occasionally, the test passes.  This happens either with or without my
scheduler enabled.  USE_MMAP and USE_MUNMAP are defined.

When I disable USE_MUNMAP, the test runs to completion successfully.
I've observed that no other configuration currently uses USE_MUNMAP.
When enabling USE_MUNMAP and USE_MMAP on GNU/Linux running on an x86
processor, the test passes.  When I enable my scheduler (by fixing the
available parameter), however, it fails:

  Completed 1 tests
  Finalized 2206/2206 objects - finalization is probably ok
  Total number of bytes allocated is 60591488
  Final heap size is 44679168 bytes
  Unexpected heap growth - collector may be broken
  Test failed
  Aborted

Re: New GC Scheduler

At Thu, 19 Jun 2008 13:09:04 +0200,
Neal H. Walfield wrote:
> 
> At Thu, 19 Jun 2008 00:28:16 +0200,
> Neal H. Walfield wrote:
> > After some number of collections, a collection that seems perfectly
> > normal, will result in the triggering GC_NEW returning NULL.  I'm
> > still investing this but would like some feedback:
> 
> After some more investigation, it seems that it is not GC_malloc that
> is failing but something else (quite possibly my run time).  Running
> gctest, I also see failures, usually complains that:
> 
>   List reversal produced incorrect list - collector is broken
> 
> Other times, it simply terminates due to a NULL pointer dereference.
> Occasionally, the test passes.  This happens either with or without my
> scheduler enabled.  USE_MMAP and USE_MUNMAP are defined.
> 
> When I disable USE_MUNMAP, the test runs to completion successfully.

Turns out that it was a bug in my run-time.  For the interested, it
had to do with map splitting, i.e., unmapping part of an mmaped
region.

Dump blocks with debugging information.

I'm trying to dump all active blocks along with the debugging  
information in GC 6.7. Seems a straightforward task, but I can't find  
any routines to do it except GC_FIND_LEAKS which is not what I want.  
I tried to piece together code, but it insist on crapping out near  
the top of dumpblock.

This has to be possible. Is there some way to do so?

#include "private/gc_priv.h"
#include "private/dbg_mlc.h"

static void dumpblock(struct hblk *p, word dummy) {
	register hdr * hhdr = HDR(p);
	register size_t bytes = WORDS_TO_BYTES(hhdr -> hb_sz);

//	craps out near here because p or hhdr are invalid
//	even though this is a straight copy from GC_print_block_list >>  
GC_print_block_descr
//	and the GC_print_block_list works fine

	GC_err_printf3("(%lu:%lu,%lu)", (unsigned long)(hhdr -> hb_obj_kind),
			(unsigned long)bytes,
			(unsigned long)(GC_n_set_marks(hhdr)));
	if (hhdr -> hb_obj_kind == PTRFREE) {
		GC_err_printf0(" atomic object at ");
	} else {
		GC_err_printf0(" composite object at ");
	}
	register oh * ohdr = (oh *)GC_base(p);
	if (GC_HAS_DEBUG_INFO(p)) {

RE: Dump blocks with debugging information.

Is this single-threaded?  Is there a danger of a block being deallocated while this is running?

Does p look reasonable and hhdr just turns out to be null?  Or is something else going on?  (GC_find_header()
can be used to get the header from a debugger.)

I don't immediately see why this shouldn't work, aside from the fact that some of this code is generally
sloppy about locking.  The collector itself should invoke it with the allocation lock held, but it's meant
to be invocable from a debugger.

Hans

> -----Original Message-----
> From: gc-bounces@...
> [mailto:gc-bounces@...] On Behalf Of S M Ryan
> Sent: Sunday, June 29, 2008 2:12 AM
> To: Boehm-gc
> Subject: [Gc] Dump blocks with debugging information.
>
> I'm trying to dump all active blocks along with the debugging
> information in GC 6.7. Seems a straightforward task, but I
> can't find any routines to do it except GC_FIND_LEAKS which
> is not what I want.
> I tried to piece together code, but it insist on crapping out
> near the top of dumpblock.
>
> This has to be possible. Is there some way to do so?
>
> #include "private/gc_priv.h"
> #include "private/dbg_mlc.h"
>