Project

General

Profile

Actions

Bug #9584

closed

RGenGC regression in CoW sharing

Added by normalperson (Eric Wong) about 10 years ago. Updated over 9 years ago.

Status:
Closed
Target version:
-
[ruby-core:61164]

Description

I just changed USE_RGENGC in ruby.h (and made r45224)
Using Nari-san's original test for bitmap marking GC:
https://github.com/authorNari/skkzipcode.git

rgengc enabled: (default)
PROCESS_CNT : 5
SHARED_AVE : 81644.0 kb
SHARED_TOTAL: 408220 kb
PRIV_AVE : 87692.0 kb
PRIV_TOTAL : 438460 kb
REQ/SEC : 0.003136

rgengc disabled:
PROCESS_CNT : 5
SHARED_AVE : 117307.2 kb
SHARED_TOTAL: 586536 kb
PRIV_AVE : 44453.6 kb
PRIV_TOTAL : 222268 kb
REQ/SEC : 0.002963

I started using bitmaps, but it seems there are some places where my code
is buggy. I haven't had more time to investigate, yet.
My work-in-progress is attached.


Files

rgengc-bitmap-promoted-wip.diff (9.22 KB) rgengc-bitmap-promoted-wip.diff broken work-in-progress patch normalperson (Eric Wong), 03/01/2014 07:24 AM

Updated by ko1 (Koichi Sasada) about 10 years ago

Does it help for CoW friendly?

Basically, promoted bit is changed only for young objects.
To make young object, pages are marked dirty.

And also, I'm worry about WB performance.

Updated by normalperson (Eric Wong) about 10 years ago

wrote:

Does it help for CoW friendly?

Basically, promoted bit is changed only for young objects.
To make young object, pages are marked dirty.

Yes, but look again at the SHARED_* numbers from nari's test
code. #define USE_RGENGC 0 shares more memory.

And also, I'm worry about WB performance.

I doubt it's much difference.
I haven't been able to fix my bitmap patch to test performance
(can't finish build, even). I suspect it's fake objects, I marked some with
FL_PERMANENT but maybe I missed some. If you have time, can you please
take a look?

Updated by ko1 (Koichi Sasada) about 10 years ago

  • ruby -v changed from ruby 2.2.0dev (2014-02-17 trunk 45028) [x86_64-linux] to -

(2014/03/01 19:01), Eric Wong wrote:

Yes, but look again at the SHARED_* numbers from nari's test
code. #define USE_RGENGC 0 shares more memory.

I doubt it caused from memory layout changing issue. RGenGC introduces
more memory pages for objects. This may prohibit to collect old object
closely.

Anyway, we need more survey about this issue.

And also, I'm worry about WB performance.
I doubt it's much difference.

Ordinally case, it doesn't affect.

I haven't been able to fix my bitmap patch to test performance
(can't finish build, even). I suspect it's fake objects, I marked some with
FL_PERMANENT but maybe I missed some. If you have time, can you please
take a look?

Sure. FL_PERMANENT is tricky :)

--
// SASADA Koichi at atdot dot net

Updated by ko1 (Koichi Sasada) over 9 years ago

  • Status changed from Open to Closed

we need to check it again.

Actions

Also available in: Atom PDF

Like0
Like0Like0Like0Like0