headers
jim marshall | 2 Jun 2007 19:21
Favicon

Faster to not call GC_free?

HI,
 I'm using GC 6.8 in my application, we have designed the application to 
have its memory management be interchangeable (e.g. use GC, dmalloc or 
normal CRT malloc). As such we have designed our application to have our 
own internal allocation routines (mainly macros or inline functions). 
After doing some reading the indication I get is that I maybe better off 
stubbing out our gc_free calls with no-ops or something like

#define intFree(vptr) vptr=NULL

Any thoughts on if this is worth while doing?

Thanks

--

-- 
Jim Marshall
Sr. Staff Engineer
WBEM Solutions, Inc.
978-947-3607
Permalink | Reply | 12 comments |
headers
Hans Boehm | 3 Jun 2007 02:41
Picon
Favicon

Re: Faster to not call GC_free?

I haven't measured this recently.  My guess, based on some older
measurements, is that for small object with threads, stubbing out the
GC_free may be s substantial win.  GC_free always acquires a lock,
which often dominates everything else.  Even in the single-threaded case,
the collector is generally significantly faster at reclaiming small
objects than GC_free.

With very large objects, the opposite is generally true, often by
a large margin.  Calling GC_free on these effectively pushes back the
next garbage collection significantly, and it's a relatively cheap
operation.

So, as usual, the short answer is "it depends".

Hans

On Sat, 2 Jun 2007, jim marshall wrote:

> HI,
>  I'm using GC 6.8 in my application, we have designed the application to
> have its memory management be interchangeable (e.g. use GC, dmalloc or
> normal CRT malloc). As such we have designed our application to have our
> own internal allocation routines (mainly macros or inline functions).
> After doing some reading the indication I get is that I maybe better off
> stubbing out our gc_free calls with no-ops or something like
>
> #define intFree(vptr) vptr=NULL
>
> Any thoughts on if this is worth while doing?
>
(Continue reading)

Permalink | Reply | 1 comment |
headers
Bruce Hoult | 3 Jun 2007 03:23

Re: Faster to not call GC_free?

On 6/3/07, Hans Boehm <Hans.Boehm@...> wrote:
> I haven't measured this recently.  My guess, based on some older
> measurements, is that for small object with threads, stubbing out the
> GC_free may be s substantial win.  GC_free always acquires a lock,
> which often dominates everything else.  Even in the single-threaded case,
> the collector is generally significantly faster at reclaiming small
> objects than GC_free.
>
> With very large objects, the opposite is generally true, often by
> a large margin.  Calling GC_free on these effectively pushes back the
> next garbage collection significantly, and it's a relatively cheap
> operation.
>
> So, as usual, the short answer is "it depends".

It also depends on how much larger you're prepared to let the heap be
than the amount of live data (controlled by GC_DIVISOR).  WIth a tight
heap there will be lots of GCs and very little will be reclaimed each
time and GC_free helps a lot.  With a loose heap there will not be so
many GCs and the percentage of the heap that is reclaimed cheaply will
be large.

Basically, the cost of GC_free vs the cost of the GC itself
discovering that that particular object is not used are not very
different.  The difference comes in GC_free putting off the GC having
to scan all the live data -- possibly forever if you use GC_free
consistently in your inner loop.

But be very careful!  Be very very sure that there is only one pointer
to that object -- that you really do own it.  Using GC_free opens you
(Continue reading)

Permalink | Reply | 0 comments |
headers
Lothar Scholz | 3 Jun 2007 03:56

Re: Faster to not call GC_free?

Hello jim,

Sunday, June 3, 2007, 12:21:04 AM, you wrote:

jm> HI,
jm>  I'm using GC 6.8 in my application, we have designed the application to
jm> have its memory management be interchangeable (e.g. use GC, dmalloc or
jm> normal CRT malloc). As such we have designed our application to have our
jm> own internal allocation routines (mainly macros or inline functions). 
jm> After doing some reading the indication I get is that I maybe better off
jm> stubbing out our gc_free calls with no-ops or something like

jm> #define intFree(vptr) vptr=NULL

jm> Any thoughts on if this is worth while doing?

As others said already, GC_free is very usefull for larger objects
(how large?) but there is something else: false pointer recognition.
If you have very complex datastructures where everything is pointing
to each other it is very usefull to replace the GC_free with a
"memset(ptr,0,size)" and prevent this. This will safe time in the next
sweep phase, so maybe even the mutex lock of the GC_free might be
justified.

Because you have to maintain the free calls anyway for your normal malloc
i would be really interested in some benchmarks on your system.

--

-- 
Best regards,
 Lothar Scholz                mailto:scholz@...
(Continue reading)

Permalink | Reply | 9 comments |
headers
jim marshall | 3 Jun 2007 18:34
Favicon

Re: Faster to not call GC_free?

Lothar Scholz wrote:
> Hello jim,
>
> Sunday, June 3, 2007, 12:21:04 AM, you wrote:
>
> jm> HI,
> jm>  I'm using GC 6.8 in my application, we have designed the application to
> jm> have its memory management be interchangeable (e.g. use GC, dmalloc or
> jm> normal CRT malloc). As such we have designed our application to have our
> jm> own internal allocation routines (mainly macros or inline functions). 
> jm> After doing some reading the indication I get is that I maybe better off
> jm> stubbing out our gc_free calls with no-ops or something like
>
> jm> #define intFree(vptr) vptr=NULL
>
> jm> Any thoughts on if this is worth while doing?
>
> As others said already, GC_free is very usefull for larger objects
> (how large?) but there is something else: false pointer recognition.
>   
This is a good question, what is a "small object"?  Any thoughts on 
that, <5k, <10K, <20K?
> If you have very complex datastructures where everything is pointing
> to each other it is very usefull to replace the GC_free with a
> "memset(ptr,0,size)" and prevent this. This will safe time in the next
> sweep phase, so maybe even the mutex lock of the GC_free might be
> justified.
>
> Because you have to maintain the free calls anyway for your normal malloc
> i would be really interested in some benchmarks on your system.
(Continue reading)

Permalink | Reply | 8 comments |
headers
Hans Boehm | 4 Jun 2007 05:07
Picon
Favicon

Re: Faster to not call GC_free?


On Sun, 3 Jun 2007, jim marshall wrote:

> This is a good question, what is a "small object"?  Any thoughts on
> that, <5k, <10K, <20K?
My rough guess would be on the order of 1K for the threads case, less
without threads.  But that's only a guess.

Hans
>
> --
> Jim Marshall
> Sr. Staff Engineer
> WBEM Solutions, Inc.
> 978-947-3607
>
> _______________________________________________
> Gc mailing list
> Gc@...
> http://www.hpl.hp.com/hosted/linux/mail-archives/gc/
>
Permalink | Reply | 7 comments |
headers
jim marshall | 4 Jun 2007 22:11
Favicon

Re: Faster to not call GC_free?

HI,
 I used Lothar Scholz recommendation of of doing a memset on the memory 
unfortunately this results in "smashed objects" because I am clearing 
the entire object including the GC's data.  Here is what I wrote:

> size_t ptrSize = GC_size(vptr);
>             if (ptrSize <= GC_SMALL_SIZE)
>             {
>                 memset(vptr, 0, ptrSize);
>             } else {
>                 GC_FREE(vptr);
>                 vptr = NULL;
>             }
for example is there a set size of data that the GC will add to the ptr? 
so I can maybe do

memset(cptr, 0, ptrSize - GC_MEM_SIZE)

Thanks
-Jim

Hans Boehm wrote:
> On Sun, 3 Jun 2007, jim marshall wrote:
>
>   
>> This is a good question, what is a "small object"?  Any thoughts on
>> that, <5k, <10K, <20K?
>>     
> My rough guess would be on the order of 1K for the threads case, less
> without threads.  But that's only a guess.
(Continue reading)

Permalink | Reply | 6 comments |
headers
Bruce Hoult | 5 Jun 2007 02:14

Re: Faster to not call GC_free?

On 6/5/07, jim marshall <jim.marshall@...> wrote:
> for example is there a set size of data that the GC will add to the ptr?
> so I can maybe do
>
> memset(cptr, 0, ptrSize - GC_MEM_SIZE)

The GC does not store any data in the objects that it gives you, and
doesn't store any GC data next to them either  It gives you the same
size or slightly larger object than you asked for.  You can write
freely into it.

Of course if you put a C++ object in there then you have to watch out
for VTBL pointers, which could be anywhere (with multiple
inheritance).  But you're doing this after you're sure that you're
never going to reference this object again, right?  So it's fine.

The only thing you can't do is clear the object *after* doing a
GC_FREE() on it.  It does have a link field in it then.
Permalink | Reply | 5 comments |
headers
jim marshall | 5 Jun 2007 02:37
Favicon

Re: Faster to not call GC_free?

Bruce Hoult wrote:
> On 6/5/07, jim marshall <jim.marshall@...> wrote:
>> for example is there a set size of data that the GC will add to the ptr?
>> so I can maybe do
>>
>> memset(cptr, 0, ptrSize - GC_MEM_SIZE)
>
> The GC does not store any data in the objects that it gives you, and
> doesn't store any GC data next to them either  It gives you the same
> size or slightly larger object than you asked for.  You can write
> freely into it.
hmm, strange cause I was asking for 14 bytes and got back 80 bytes 
(that's more then a little bigger IMO), and doing the memset instead of 
GC_FREE caused the GC to think memory was corrupted and to abort. If I 
remove the memset and just do a GC_FREE I do not get corrupted memory. 
This is a program that has been working for over a year and the only 
change I have made is with the GC stuff (using GC_MALLOC_ATOMIC in 
places and then this GC_FREE thing).

>
> Of course if you put a C++ object in there then you have to watch out
> for VTBL pointers, which could be anywhere (with multiple
> inheritance).  But you're doing this after you're sure that you're
> never going to reference this object again, right?  So it's fine.
This is 100% C code, no C++ involved.
>
> The only thing you can't do is clear the object *after* doing a
> GC_FREE() on it.  It does have a link field in it then.
-Jim
> _______________________________________________
(Continue reading)

Permalink | Reply | 0 comments |
headers
Boehm, Hans | 5 Jun 2007 02:38
Picon
Favicon

RE: Faster to not call GC_free?

I expect the issue here is that Jim is using debug allocation, which
does store debug information in the object.  There should really be a
GC_debug_size() and GC_SIZE() that adjust for this.  There currently
isn't.  There is s a private DEBUG_BYTES macro that's used to allocate
the object with the extra space.  Thus the definition of GC_debug_size()
should be fairly trivial.  A patch would be welcome.

Having said that, I suspect that the overhead of GC_size, plus a
variable size memset may be starting to approach that of GC_free.  Thus
I'm not sure this is still a win.

Hans

> -----Original Message-----
> From: gc-bounces@... 
> [mailto:gc-bounces@...] On Behalf Of Bruce Hoult
> Sent: Monday, June 04, 2007 5:14 PM
> To: jim marshall
> Cc: gc@...
> Subject: Re: [Gc] Faster to not call GC_free?
> 
> On 6/5/07, jim marshall <jim.marshall@...> wrote:
> > for example is there a set size of data that the GC will 
> add to the ptr?
> > so I can maybe do
> >
> > memset(cptr, 0, ptrSize - GC_MEM_SIZE)
> 
> The GC does not store any data in the objects that it gives 
> you, and doesn't store any GC data next to them either  It
(Continue reading)

Permalink | Reply | 3 comments |

Gmane