Discussions about the Boehm Garbage Collector (Boehm GC).

Boehm, Hans | 8 Feb 16:56

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-E8mQNyieTr9F8jW2Upzce+ga9YzINl48@public.gmane.org]
Sent: Tuesday, February 07, 2012 7:26 PM
To: Boehm, Hans; boehm-HInyCGIudOg@public.gmane.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

_______________________________________________
Gc mailing list
Gc@...
http://www.hpl.hp.com/hosted/linux/mail-archives/gc/

headers

lijun | 9 Feb 15:06

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-VXdhtT5mjnY@public.gmane.org]
Sent: Thursday, February 09, 2012 12:57 AM
To: lijun; boehm-HInyCGIudOg@public.gmane.org
Cc: gc-V9/bV5choksm30D7ZfaTJw@public.gmane.org
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.

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.

Hans

From: lijun [mailto:lijun-E8mQNyieTr9F8jW2Upzce+ga9YzINl48@public.gmane.org]
Sent: Tuesday, February 07, 2012 7:26 PM
To: Boehm, Hans; boehm-HInyCGIudOg@public.gmane.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

_______________________________________________
Gc mailing list
Gc@...
http://www.hpl.hp.com/hosted/linux/mail-archives/gc/

headers

Boehm, Hans | 10 Feb 08:09

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-E8mQNyieTr9F8jW2Upzce+ga9YzINl48@public.gmane.org]
Sent: Thursday, February 09, 2012 6:06 AM
To: Boehm, Hans; boehm-HInyCGIudOg@public.gmane.org
Cc: gc-V9/bV5choksm30D7ZfaTJw@public.gmane.org
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

[Copying response to gc mailing list.]

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

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.

Hans

From: lijun [mailto:lijun-E8mQNyieTr9F8jW2Upzce+ga9YzINl48@public.gmane.org]
Sent: Tuesday, February 07, 2012 7:26 PM
To: Boehm, Hans; boehm-HInyCGIudOg@public.gmane.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

_______________________________________________
Gc mailing list
Gc@...
http://www.hpl.hp.com/hosted/linux/mail-archives/gc/

headers

lijun | 10 Feb 12:31

RE: about bitmap marking

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-VXdhtT5mjnY@public.gmane.org]
Sent: Friday, February 10, 2012 4:09 PM
To: lijun; boehm-HInyCGIudOg@public.gmane.org
Cc: gc-V9/bV5choksm30D7ZfaTJw@public.gmane.org
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

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

[Copying response to gc mailing list.]

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

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.

Hans

From: lijun [mailto:lijun-E8mQNyieTr9F8jW2Upzce+ga9YzINl48@public.gmane.org]
Sent: Tuesday, February 07, 2012 7:26 PM
To: Boehm, Hans; boehm-HInyCGIudOg@public.gmane.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

_______________________________________________
Gc mailing list
Gc@...
http://www.hpl.hp.com/hosted/linux/mail-archives/gc/

headers

Boehm, Hans | 10 Feb 18:30

RE: about bitmap marking

Each page has a separate mark bit table, since the heap is not presumed to be contiguous. The mark bit table is allocated separately from the page itself, but also contains other information about the page. Much of this is outlined in http://www.hpl.hp.com/personal/Hans_Boehm/gc/gcdescr.html .

Hans

From: lijun [mailto:lijun-E8mQNyieTr9F8jW2Upzce+ga9YzINl48@public.gmane.org]
Sent: Friday, February 10, 2012 3:32 AM
To: Boehm, Hans; boehm-HInyCGIudOg@public.gmane.org
Cc: gc-V9/bV5choksm30D7ZfaTJw@public.gmane.org
Subject: RE: about bitmap marking

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-HInyCGIudOg@public.gmane.org
Cc: gc-V9/bV5choksm30D7ZfaTJw@public.gmane.org
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-HInyCGIudOg@public.gmane.org
Cc: gc-V9/bV5choksm30D7ZfaTJw@public.gmane.org
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-HInyCGIudOg@public.gmane.org
Cc: gc-V9/bV5choksm30D7ZfaTJw@public.gmane.org
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.

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.

Hans

From: lijun [mailto:lijun <at> ialab.cs.tsukuba.ac.jp]
Sent: Tuesday, February 07, 2012 7:26 PM
To: Boehm, Hans; boehm-HInyCGIudOg@public.gmane.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

_______________________________________________
Gc mailing list
Gc@...
http://www.hpl.hp.com/hosted/linux/mail-archives/gc/

headers

lijun | 13 Feb 09:08

RE: about bitmap marking

In each mark bit table, the mark bits are stored contiguously?

Best regards.

Li Jun

From: Boehm, Hans [mailto:hans.boehm-VXdhtT5mjnY@public.gmane.org]
Sent: Saturday, February 11, 2012 2:31 AM
To: lijun; boehm-HInyCGIudOg@public.gmane.org
Cc: gc-V9/bV5choksm30D7ZfaTJw@public.gmane.org
Subject: RE: about bitmap marking

Hans

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

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

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

[Copying response to gc mailing list.]

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

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.

Hans

From: lijun [mailto:lijun <at> ialab.cs.tsukuba.ac.jp]
Sent: Tuesday, February 07, 2012 7:26 PM
To: Boehm, Hans; boehm-HInyCGIudOg@public.gmane.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

_______________________________________________
Gc mailing list
Gc@...
http://www.hpl.hp.com/hosted/linux/mail-archives/gc/

headers

Boehm, Hans | 14 Feb 23:05

RE: about bitmap marking

That depends on the collector configuration. It can either use a bit or a byte per logical mark bit, and use one logical mark bit per allocation granule or per object. See MARK_BIT_PER_GRANULE and USE_MARK_BYTES/USE_MARK_BITS.

Hans

From: lijun [mailto:lijun-E8mQNyieTr9F8jW2Upzce+ga9YzINl48@public.gmane.org]
Sent: Monday, February 13, 2012 12:08 AM
To: Boehm, Hans; boehm-HInyCGIudOg@public.gmane.org
Cc: gc-V9/bV5choksm30D7ZfaTJw@public.gmane.org
Subject: RE: about bitmap marking

In each mark bit table, the mark bits are stored contiguously?

Best regards.

Li Jun

Hans

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

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

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

[Copying response to gc mailing list.]

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

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.

Hans

From: lijun [mailto:lijun <at> ialab.cs.tsukuba.ac.jp]
Sent: Tuesday, February 07, 2012 7:26 PM
To: Boehm, Hans; boehm-HInyCGIudOg@public.gmane.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

_______________________________________________
Gc mailing list
Gc@...
http://www.hpl.hp.com/hosted/linux/mail-archives/gc/

headers

lijun | 15 Feb 16:38

RE: about bitmap marking

Because each page has a separate mark bit table, in most cases, there are many mark bit tables in the collector.

If I use the default configuration, the mark bit tables(gc6.8) help to attain a higher locality of reference? (in comparison with not using the mark bit tables)

In sweep phase(gc6.8, default configuration), the collector will run faster because of having mark bit tables?

(scanning/clearing the mark bit tables is faster than scanning/clearing the mark bits in object headers because of putting the mark bits together?)

Best regards

Li Jun

From: Boehm, Hans [mailto:hans.boehm-VXdhtT5mjnY@public.gmane.org]
Sent: Wednesday, February 15, 2012 7:06 AM
To: lijun; boehm-HInyCGIudOg@public.gmane.org
Cc: gc-V9/bV5choksm30D7ZfaTJw@public.gmane.org
Subject: RE: about bitmap marking

Hans

In each mark bit table, the mark bits are stored contiguously?

Best regards.

Li Jun

Hans

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

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

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

[Copying response to gc mailing list.]

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

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.

Hans

From: lijun [mailto:lijun <at> ialab.cs.tsukuba.ac.jp]
Sent: Tuesday, February 07, 2012 7:26 PM
To: Boehm, Hans; boehm-HInyCGIudOg@public.gmane.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

_______________________________________________
Gc mailing list
Gc@...
http://www.hpl.hp.com/hosted/linux/mail-archives/gc/

headers

lijun | 15 Feb 17:51

RE: about bitmap marking

In general, there are three advantages of using mark bit table(bitmap marking).

+ it is friendly to copy-on-write.

+ it helps to attain a higher locality of reference.

+ in sweep phase, scanning/clearing the mark bit table is faster than scanning/clearing the mark bits in object headers because of putting the mark bits together.

(the collector will run faster because of having a mark bit table)

There are several differences between the usual bitmap marking and that of boehm gc

(For example, because each page has a separate mark bit table in boehm gc, in most cases, there are many mark bit tables in the collector.),

So I want to know whether the implememtation of bitmap marking in boehm gc(gc6.8) has the advantages listed above if I use the default configuration(boehm gc 6.8).

Best regards

Li Jun

From: lijun [mailto:lijun-E8mQNyieTr9F8jW2Upzce+ga9YzINl48@public.gmane.org]
Sent: Thursday, February 16, 2012 12:39 AM
To: 'Boehm, Hans'; 'boehm-HInyCGIudOg@public.gmane.org'
Cc: 'gc-V9/bV5choksm30D7ZfaTJw@public.gmane.org'
Subject: RE: about bitmap marking

Because each page has a separate mark bit table, in most cases, there are many mark bit tables in the collector.

If I use the default configuration, the mark bit tables(gc6.8) help to attain a higher locality of reference? (in comparison with not using the mark bit tables)

In sweep phase(gc6.8, default configuration), the collector will run faster because of having mark bit tables?

(scanning/clearing the mark bit tables is faster than scanning/clearing the mark bits in object headers because of putting the mark bits together?)

Best regards

Li Jun

Hans

In each mark bit table, the mark bits are stored contiguously?

Best regards.

Li Jun

Hans

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

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

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

[Copying response to gc mailing list.]

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

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.

Hans

From: lijun [mailto:lijun <at> ialab.cs.tsukuba.ac.jp]
Sent: Tuesday, February 07, 2012 7:26 PM
To: Boehm, Hans; boehm-HInyCGIudOg@public.gmane.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

_______________________________________________
Gc mailing list
Gc@...
http://www.hpl.hp.com/hosted/linux/mail-archives/gc/

headers

lijun | 18 Feb 10:12

RE: about bitmap marking

I sent 2 emails 2 days ago, but I didn’t get an answer.

Can you tell me whether the implememtation of bitmap marking in boehm gc(gc6.8) has the advantages listed in my previous email(February 16, 2012 1:52 AM) if I use the default configuration(boehm gc 6.8).

＞＞In general, there are three advantages of using mark bit table(bitmap marking).

＞＞+ it is friendly to copy-on-write.

＞＞+ it helps to attain a higher locality of reference.

＞＞+ in sweep phase, scanning/clearing the mark bit table is faster than scanning/clearing the mark bits in object headers because of putting the mark bits together.

＞＞(the collector will run faster because of having a mark bit table)

＞＞

＞＞There are several differences between the usual bitmap marking and that of boehm gc

＞＞(For example, because each page has a separate mark bit table in boehm gc, in most cases, there are many mark bit tables in the collector.),

＞＞So I want to know whether the implememtation of bitmap marking in boehm gc(gc6.8) has the advantages listed above if I use the default configuration(boehm gc 6.8).

Best regards

Li Jun

From: lijun [mailto:lijun-E8mQNyieTr9F8jW2Upzce+ga9YzINl48@public.gmane.org]
Sent: Thursday, February 16, 2012 1:52 AM
To: 'Boehm, Hans'; 'boehm-HInyCGIudOg@public.gmane.org'
Cc: 'gc-V9/bV5choksm30D7ZfaTJw@public.gmane.org'
Subject: RE: about bitmap marking

In general, there are three advantages of using mark bit table(bitmap marking).

+ it is friendly to copy-on-write.

+ it helps to attain a higher locality of reference.

+ in sweep phase, scanning/clearing the mark bit table is faster than scanning/clearing the mark bits in object headers because of putting the mark bits together.

(the collector will run faster because of having a mark bit table)

There are several differences between the usual bitmap marking and that of boehm gc

(For example, because each page has a separate mark bit table in boehm gc, in most cases, there are many mark bit tables in the collector.),

So I want to know whether the implememtation of bitmap marking in boehm gc(gc6.8) has the advantages listed above if I use the default configuration(boehm gc 6.8).

Best regards

Li Jun

Because each page has a separate mark bit table, in most cases, there are many mark bit tables in the collector.

If I use the default configuration, the mark bit tables(gc6.8) help to attain a higher locality of reference? (in comparison with not using the mark bit tables)

In sweep phase(gc6.8, default configuration), the collector will run faster because of having mark bit tables?

(scanning/clearing the mark bit tables is faster than scanning/clearing the mark bits in object headers because of putting the mark bits together?)

Best regards

Li Jun

Hans

In each mark bit table, the mark bits are stored contiguously?

Best regards.

Li Jun

Hans

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

_______________________________________________
Gc mailing list
Gc@...
http://www.hpl.hp.com/hosted/linux/mail-archives/gc/