headers
Ivan Maidanski | 1 Dec 2009 07:32
Picon

Re[2]: time for an alpha release?

Hi!

Hans -

It's unclear to me from your answer whether it would be good if I prepare the alpha release tarball (right
today) or it would be good to wait for the entitled patch, or you prepare the tarball yourself (when back to home).

-----Original Message-----
> The current parallel GC algorithm doesn't interact very well with real incremental collection.  But I
think the collector already backs off to pure generational (collections run to completion, but mark bits
are not reset at every GC) if you try to combine them.  In particular, the threads initialization code sets
GC_time_limit to GC_TIME_UNLIMITED in the PARALLEL_MARK case..  Thus I don't think there's a reason to
prevent the combination in the test code.
> 
> We could probably do better in allowing real incremental and parallel collction to be combined.  There are
some real issues in that it takes a while to start up and shut down a parallel collection.  But I'm sure we
could do better than we are now.
> 
> Hans
> 
> > -----Original Message-----
> > From: Talbot, George [mailto:Gtalbot@...]
> > Sent: Monday, November 30, 2009 5:52 AM
> > To: Boehm, Hans; Ivan Maidanski; gc@...
> > Subject: RE: [Gc] time for an alpha release?
> >
> > Just out of curiousity--I'm on one of those platforms
> > (x86_64) that appears to disable incremental collection with
> > parallel mark turned on.  Why is that again?
> >
(Continue reading)

Permalink | Reply | 2 comments |
headers
Boehm, Hans | 1 Dec 2009 18:11
Picon
Favicon

RE: Re[2]: time for an alpha release?

Sorry.  I think it would be a good idea to get an Alpha release out asap.  If you have time, please do so. 
Otherwise I will do so when I get back.  We can fix test.c afterwards.

By the current numbering scheme, this should be alpha4, and the tree should become alpha5 afterwards.

Thanks.

Hans

> -----Original Message-----
> From: gc-bounces@...
> [mailto:gc-bounces@...] On Behalf Of Ivan Maidanski
> Sent: Monday, November 30, 2009 10:33 PM
> To: gc@...
> Subject: Re[2]: [Gc] time for an alpha release?
>
> Hi!
>
> Hans -
>
> It's unclear to me from your answer whether it would be good
> if I prepare the alpha release tarball (right today) or it
> would be good to wait for the entitled patch, or you prepare
> the tarball yourself (when back to home).
>
> -----Original Message-----
> > The current parallel GC algorithm doesn't interact very
> well with real incremental collection.  But I think the
> collector already backs off to pure generational (collections
> run to completion, but mark bits are not reset at every GC)
(Continue reading)

Permalink | Reply | 1 comment |
headers
Ben Elliston | 1 Dec 2009 19:29
Picon

boehm-gc patch

Hi.

I would like to bring the following patches to your attention, which
were contributed to the version of the Boehm GC in the GCC tree:

  http://gcc.gnu.org/ml/gcc-patches/2009-11/msg01508.html
  http://gcc.gnu.org/ml/gcc-patches/2009-11/msg01636.html

I hope these can be integrated upstream.

Regards, Ben

--

-- 
Ben Elliston <bje@...>
Australia Development Lab, IBM
Permalink | Reply | 8 comments |
headers
Ivan Maidanski | 1 Dec 2009 20:16
Picon

Re: boehm-gc patch

Hi!
Ben Elliston <bje@...> wrote:
> Hi.
> 
> I would like to bring the following patches to your attention, which
> were contributed to the version of the Boehm GC in the GCC tree:
> 
>   http://gcc.gnu.org/ml/gcc-patches/2009-11/msg01508.html

The message is:

	* os_dep.c: Use the POSIX signal API in preference to the BSD API.
	Generate a compilation error if neither the POSIX nor BSD APIs can
	be detected.

Index: os_dep.c
===================================================================
--- os_dep.c	(revision 154694)
+++ os_dep.c	(working copy)
 <at>  <at>  -501,7 +501,13  <at>  <at>  void GC_enable_signals(void)
       && !defined(MACOS) && !defined(DJGPP) && !defined(DOS4GW) \
       && !defined(NOSYS) && !defined(ECOS)

-#   if defined(sigmask) && !defined(UTS4) && !defined(HURD)
+#   if defined(SIG_BLOCK)
+	/* Use POSIX/SYSV interface */
+#	define SIGSET_T sigset_t
+#	define SIG_DEL(set, signal) sigdelset(&(set), (signal))
+#	define SIG_FILL(set) sigfillset(&set)
+#	define SIGSETMASK(old, new) sigprocmask(SIG_SETMASK, &(new), &(old))
(Continue reading)

Permalink | Reply | 7 comments |
headers
Ivan Maidanski | 1 Dec 2009 23:01
Picon

Re[4]: time for an alpha release?

Hi!
"Boehm, Hans" <hans.boehm@...> wrote:
> Sorry.  I think it would be a good idea to get an Alpha release out asap.  If you have time, please do so. 
Otherwise I will do so when I get back.  We can fix test.c afterwards.
>
> By the current numbering scheme, this should be alpha4, and the tree should become alpha5 afterwards.

I sent the tarball to hans.boehm@... (I also prepared a stand-alone tarball
for AO v1.3a1 in case you might wish to update its home page)

I'll set CVS to alpha5 (and AO to 1.3a2) tomorrow.

BTW. I think it would be good for AO to have its version macro (defined in src/atomic_ops.h or in a dedicated
header file) like that for GC in gc_version.h.

>
> Thanks.
>
> Hans
>
> > -----Original Message-----
> > From: gc-bounces@...
> > [mailto:gc-bounces@...] On Behalf Of Ivan Maidanski
> > Sent: Monday, November 30, 2009 10:33 PM
> > To: gc@...
> > Subject: Re[2]: [Gc] time for an alpha release?
> >
> > Hi!
> >
> > Hans -
(Continue reading)

Permalink | Reply | 0 comments |
headers
Christian Gudrian | 2 Dec 2009 14:23

Collecting large memory blocks

Hello!

I am using the most recent CVS version of the collector under Win32
compiled with C++Builder6.

I wrote a simple test program to verify the operation of the collector
under different conditions.  During the tests I constantly monitor the
values of GC_get_heap_size() and GC_get_free_bytes() to judge if certain
memory blocks which became unreachable got collected.  This of course
involves manually calling GC_gcollect() to force a collection cycle.

I discovered that large memory blocks do not get reclaimed once they
become unreachable.  For example:

GC_MALLOC(100000)  -> gets collected during the next cycle
                         (GC_get_free_bytes() increases accordingly)
GC_MALLOC(1000000) -> never gets collected
                         (GC_get_free_bytes() does not increase)

Apart from the amount of memory allocated both calls take place under the
same conditions.

Is this behaviour intended, and if so: why?

Christian Gudrian
Permalink | Reply | 7 comments |
headers
Ivan Maidanski | 2 Dec 2009 16:01
Picon

Re: Collecting large memory blocks

Hi!
"Christian Gudrian" <christian@...> wrote:
> Hello!
>
> I am using the most recent CVS version of the collector under Win32
> compiled with C++Builder6.
>
> I wrote a simple test program to verify the operation of the collector
> under different conditions.  During the tests I constantly monitor the
> values of GC_get_heap_size() and GC_get_free_bytes() to judge if certain
> memory blocks which became unreachable got collected.  This of course
> involves manually calling GC_gcollect() to force a collection cycle.
>
> I discovered that large memory blocks do not get reclaimed once they
> become unreachable.  For example:
>
> GC_MALLOC(100000)  -> gets collected during the next cycle
>                          (GC_get_free_bytes() increases accordingly)
> GC_MALLOC(1000000) -> never gets collected
>                          (GC_get_free_bytes() does not increase)
>
> Apart from the amount of memory allocated both calls take place under the
> same conditions.
>
> Is this behavior intended, and if so: why?
>
> Christian Gudrian

Well, I tried the following simple test (if you're right it should consume 10 GiB):
(Continue reading)

Permalink | Reply | 5 comments |
headers
Christian Gudrian | 2 Dec 2009 18:01

Re: Collecting large memory blocks

Am 02.12.2009, 16:01 Uhr, schrieb Ivan Maidanski <ivmai@...>:

> The test work correctly: it prints something near 1.5 MiB. Does this  
> test runs ok on your side?

Yes.  The heap sizes stays below 2 MiB.

However, if I execute that loop in a Windows application (using Borland's  
VCL), the heap size goes up to more than 30 MiB.

Without ALL_INTERIOR_POINTERS it stays below 10 MiB.

How come the collector haves differently depending on the application type  
(console/Windows)?

Christian
Permalink | Reply | 4 comments |
headers
Ivan Maidanski | 2 Dec 2009 18:59
Picon

Re[2]: Collecting large memory blocks

Hi!
"Christian Gudrian" <christian@...> wrote:
> Am 02.12.2009, 16:01 Uhr, schrieb Ivan Maidanski <ivmai@...>:
>
> > The test work correctly: it prints something near 1.5 MiB. Does this
> > test runs ok on your side?
>
> Yes.  The heap sizes stays below 2 MiB.
>
> However, if I execute that loop in a Windows application (using Borland's
> VCL), the heap size goes up to more than 30 MiB.

> Without ALL_INTERIOR_POINTERS it stays below 10 MiB.

This is the key phrase, I think - the data roots (that are scanned by GC) contain values that look like
pointers the allocated blocks, so the collector can't recycle them.

Tip: if you have no global pointer variables, you can use the following (to prevent GC from scanning static
data roots at all):

int main(void)
{
 GC_set_no_dls(0);
 GC_INIT();
 GC_clear_roots();
 ...
}

If you have a "limited set" of global pointer variables then you can try to inform the collector about them
after GC_clear_roots like:
(Continue reading)

Permalink | Reply | 3 comments |
headers
Boehm, Hans | 3 Dec 2009 02:28
Picon
Favicon

7.2alpha4

With many thanks to Ivan Maidanski, who actually generated the files, in addition to contributing many and
probably most of the fixes, I made available version 7.2alpha4 of the GC in the usual place, i.e. at 

http://www.hpl.hp.com/personal/Hans_Boehm/gc/gc_source/gc-7.2alpha4.tar.gz

I think we all believe this is in pretty good shape, and basically just needs a bit more testing to turn it into 7.2.

Ivan also generated a corresponding standalone libatomic_ops tar file, which I will attempt to put in the
right place, though that may take a while.  It now uses the GC version numbering, i.e. it skipped many
versions from 1.2 to 7.2alpha4.  The same files are included in the GC distribution, so you don't need to
download libatomic_ops separately if you really want the GC.

Hans
Permalink | Reply | 0 comments |

Gmane