From: Eric Wong <normalperson@...>
Date: 2018-01-17T23:31:49+00:00
Subject: [ruby-core:84910] Re: [Ruby trunk Feature#14370] Directly mark instruction operands and avoid mark_ary usage on rb_iseq_constant_body

tenderlove@ruby-lang.org wrote:
> I was concerned that this patch might impact GC time, but
> `make gcbench-rdoc` didn't seem to show any significant
> difference in GC time between trunk and this patch.  If it
> turns out there is a performance impact, I think I could
> improve the time while still keeping memory usage low by
> generating a bitmap during iseq compilation.

I like this patch so far.  This improves data locality (at the
cost of extra branches), so I'm all for the space reduction.

Also, iseq aren't marked frequently anymore since RGenGC;
so I don't believe a bitmap index would be worth the extra code
and space; this is probably why GC time isn't as noticeable.

> +static int
> +iseq_extract_values(const VALUE *code, size_t pos, iseq_value_itr_t * func, void *data)

Did you try without using function pointers?   It may be
possible to eek out a few more cycles by calling rb_gc_mark
directly.

> +void
> +rb_iseq_each_value(const rb_iseq_t *iseq, iseq_value_itr_t * func, void *data)

Shouldn't this be static? (or do you have other changes planned?)

> +static void
> +each_insn_value(void *ctx, VALUE obj)
> +{
> +    return rb_gc_mark(obj);
> +}

Needless "return" statement.  I remember some compilers/options
complain about the "return" despite rb_gc_mark also being void,
even.

Thanks!

Unsubscribe: <mailto:ruby-core-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>