is this code ever executed?

4 views
Skip to first unread message

nari

unread,
Oct 9, 2009, 10:01:30 AM10/9/09
to rubinius-dev
Hi.

I had one question for GC.

--- start ---
/vm/gc/baker.cpp

32: Object* BakerGC::saw_object(Object* obj) {
...
50: if(unlikely(obj->age++ >= lifetime)) {
51: copy = object_memory->promote_object(obj);
52:
53: promoted_push(copy);
54: } else if(likely(next->enough_space_p(
obj->size_in_bytes(object_memory->state))))
{
55: copy = next->copy_object(object_memory->state, obj);
56: total_objects++;
57: } else {
58: copy = object_memory->promote_object(obj);
59: promoted_push(copy);
60: }
---

is this code 58,59 lines ever executed?

I think this code 58,59 lines never executed because "From heap size =
To heap size".

thanks.

Evan Phoenix

unread,
Oct 9, 2009, 11:59:48 AM10/9/09
to rubini...@googlegroups.com
Hello nari!
You're right, that code is almost never run. It's simply a boundary
case, in case everything else fails we can still move the object out
of the current space.

So, when might this happen? Well, it used to happen more because
earlier on, when the current space filled up, the GC would start
allocating directly into the next until the GC had the chance to run.
That would mean that there were times where live_objects_in_current >
space_left_in_next. We don't spill allocations to next anymore, so
this case should not occur anymore.

The code got left in when we changed how spilling works. It doesn't
really hurt anything to stay there, in case something else changes and
it starts being used. There would be 2 ways to remove it:

1) Remove the condition in the 'else if', so that we always allocate
to next "unprotected". Doing that could easily introduce some subtle
bug.

2) Replace the next with an assert. This would show us that something
else is being weird in the GC, and cause everything to halt.

Given those 2 options, leaving the code in seems the best way to
handle it.

- Evan

>
> thanks.
> >
>

Eero Saynatkari

unread,
Oct 9, 2009, 12:26:11 PM10/9/09
to rubinius-dev
Excerpts from rue's Private Feed: evanphx's message of Fri Oct 09 18:59:48 +0300 2009:

> 1) Remove the condition in the 'else if', so that we always allocate
> to next "unprotected". Doing that could easily introduce some subtle
> bug.
>
> 2) Replace the next with an assert. This would show us that something
> else is being weird in the GC, and cause everything to halt.
>
> Given those 2 options, leaving the code in seems the best way to
> handle it.

I would go with the assertion.


--
Magic is insufficiently advanced technology.

Narihiro Nakamura

unread,
Oct 10, 2009, 7:44:59 PM10/10/09
to rubini...@googlegroups.com
Hi Evan!

2009/10/10 Evan Phoenix <ev...@fallingsnow.net>:

Ahh! OK!. thanks.

> The code got left in when we changed how spilling works. It doesn't
> really hurt anything to stay there, in case something else changes and
> it starts being used. There would be 2 ways to remove it:
>
> 1) Remove the condition in the 'else if', so that we always allocate
> to next "unprotected". Doing that could easily introduce some subtle
> bug.
>
> 2) Replace the next with an assert. This would show us that something
> else is being weird in the GC, and cause everything to halt.
>
> Given those 2 options, leaving the code in seems the best way to
> handle it.
>
>  - Evan
>

I like (2) is the best.

--
Narihiro Nakamura
blog : http://d.hatena.ne.jp/authorNari/
twitter : http://twitter.com/nari3

Reply all
Reply to author
Forward
0 new messages