[Gc] RE: about bitmap marking

lijun lijun at ialab.cs.tsukuba.ac.jp
Fri Feb 10 03:31:44 PST 2012


Thank you for your information.

 

The mark bits in a separate region of memory are stored continuously in a
table?

(In sweep phase, the collector scans mark bits in the table)

There is a bitmap table in each page?

 

Best regards.

 

Li Jun

 

From: Boehm, Hans [mailto:hans.boehm at hp.com] 
Sent: Friday, February 10, 2012 4:09 PM
To: lijun; boehm at acm.org
Cc: gc at linux.hpl.hp.com
Subject: RE: about bitmap marking

 

gc6.8 and all relevant versions always keep mark bits in a separate region
of memory.  There is no way to configure the collector differently.

 

I do not understand your second question.  The collector, including 6.8,
always uses free-lists for small objects.  There is no way to configure that
differently.

 

Hans

 

From: lijun [mailto:lijun at ialab.cs.tsukuba.ac.jp] 
Sent: Thursday, February 09, 2012 6:06 AM
To: Boehm, Hans; boehm at acm.org
Cc: gc at linux.hpl.hp.com
Subject: RE: about bitmap marking

 

I am sorry that i did not ask more clearly.

I just want to know about gc6.8.

 

I don't know whether gc6.8 uses bitmap marking or not if I build the
collector without any options or if I don't set any parameters in my C
program?

(For example, if I build gc6.8 with -DGC_LINUX_THREADS -DPARALLEL_MARK
-DTHREAD_LOCAL_ALLOC, the collector will run the mark phase in parallel.

If I call GC_enable_incremental and set GC_time_limit in my program, the
collector will perform an incremental gc. etc)

 

If yes, I want to know whether mark bits are out of the objects or not in
gc6.8.

 

About freelist, I want to know whether the following is right or wrong in
gc6.8?

C program <- (memory block) <- freelist(list of free memory blocks) 

 

I'm waiting for your reply eagerly.

Best Regards.

 

Li Jun

 

 

From: Boehm, Hans [mailto:hans.boehm at hp.com] 
Sent: Thursday, February 09, 2012 12:57 AM
To: lijun; boehm at acm.org
Cc: gc at linux.hpl.hp.com
Subject: RE: about bitmap marking

 

[Copying response to gc mailing list.]

 

6.8 is old at this point, but this hasn't changed much in 7.2alpha6.

 

The collector always stores mark bits in a map off to the side.  When I last
looked at this ages ago, that seemed to be a clear win.  We need to look up
a page descriptor for the object being marked in any case.  Thus the
overhead is smaller than it would probably be for a non-conservative
collector.  Having the mark bit in the object, or even on the same page,
would mean accessing pages containing pointer-free objects during a GC.  In
my experience, in well-tuned applications, a large fraction of the heap is
pointer-free.  The GC could often touch twice as many pages during a GC with
the mark bits in the objects.

 

An ancient version of the GC stored mark bits at the beginning of each page.
That potentially  causes other cache-related problems.  All mark bits
contend for a small fraction of the cache.

 

The GC allocates memory from a free-list, but free-lists are built only a
page at a time, when needed.  Building the free-list will force memory into
the cache, but the hope is that it will still be there when the object is
allocated by the client.

 

Hans

 

From: lijun [mailto:lijun at ialab.cs.tsukuba.ac.jp] 
Sent: Tuesday, February 07, 2012 7:26 PM
To: Boehm, Hans; boehm at acm.org
Subject: about bitmap marking

 

Dear Boehm:

 

I'm sorry about my poor English.

 

I would like to hear about boehm gc.

 

Boehm gc(gc6.8) uses Bitmap marking as default?

 

In Boehm gc, bitmap marking rules out storing mark-bits in object
headers?(move mark-bits to other area)

 

Does Boehm gc get memory area from a freelist when allocate memory?

 

I'm waiting for your reply eagerly.

 

Best regards.

 

 

Li Jun

Univ. of Tsukuba

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://napali.hpl.hp.com/pipermail/gc/attachments/20120210/59ecdd95/attachment-0001.htm


More information about the Gc mailing list