[#41916] Proposal: Bitmap Marking GC — Narihiro Nakamura <authornari@...>

Hi.

18 messages 2012/01/05

[#41941] [ruby-trunk - Bug #5851][Open] make check fails when compiling with GCC 4.7 - *** longjmp causes uninitialized stack frame *** — Vit Ondruch <v.ondruch@...>

12 messages 2012/01/06

[#41979] [ruby-trunk - Bug #5865][Open] Exception#== should return false if the classes differ — Hiro Asari <asari.ruby@...>

10 messages 2012/01/08

[#42003] [ruby-trunk - Bug #5871][Open] regexp \W matches some word characters when inside a case-insensitive character class — Gareth Adams <gareth@...>

14 messages 2012/01/09

[#42016] [ruby-trunk - Feature #5873][Open] Adopt FFI over DL — Heesob Park <phasis@...>

15 messages 2012/01/10

[#42149] [ruby-trunk - Feature #5899][Open] chaining comparsions. — Ondrej Bilka <neleai@...>

12 messages 2012/01/16

[#42164] [ruby-trunk - Feature #5903][Open] Optimize st_table (take 2) — Yura Sokolov <funny.falcon@...>

18 messages 2012/01/17

[ruby-core:41975] Re: Proposal: Bitmap Marking GC

From: Narihiro Nakamura <authornari@...>
Date: 2012-01-08 04:13:55 UTC
List: ruby-core #41975
2012/1/8 KOSAKI Motohiro <kosaki.motohiro@gmail.com>:
>> Narihiro Nakamura <authornari@gmail.com> wrote:
>>> * A heap block address is aligned by 16KB to find fast a bitmap.
>>
>> Just wondering, why/how did you determine 16K alignment is optimal?
>> Normal page size in Linux is only 4K, so 16K seems large.
>

We defined the heap block size at following commit.
https://github.com/ruby/ruby/commit/4d93af26df1c322515e535d60cd5b0a66dcc222d
I've run benchmarks on different heap block size. Then, I chose 16KB
because it was fastest.
But, I probably should have chosen 4KB as you say.

> Moreover, posix_memalign() and memalign() sound bad choice. It need
> a few header bytes. then, some malloc implementations might allocate
> 32K instead of 16K.
>
> So, why can't we use mmap() directly or use "16K - a few bytes" length?
>

No special reason.
We should choose to use mmap() directly if it's efficient way.

-- 
Narihiro Nakamura (nari)

In This Thread