[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Help-smalltalk] Compiler memory leak
From: |
Paolo Bonzini |
Subject: |
Re: [Help-smalltalk] Compiler memory leak |
Date: |
Wed, 17 Jul 2013 09:35:37 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7 |
Il 16/07/2013 21:11, Gwenaël Casaccio ha scritto:
>> To catch more bugs like this, we need to assert that add_literal is
>> called in the outermost incubator context. We can add an
>> inc_context_depth() function (which really can just return
>> INC_SAVE_POINTER()), store the value in _gst_compile_method and compare
>> it in add_literal. Let me try to do a patch.
>
> Yes but you capture only one kind of bugs tracking allocation with a
> "global" incubator is easier.
There is a global incubator, that's _gst_register_oop and
_gst_register_oop_array. INC_SAVE_POINTER/INC_RESTORE_POINTER is
explicitly for stack-based operation. add_literal is at the bottom of
the stack because the objects it incubates are for the outermost object
(the CompiledMethod). So the invariant makes sense, and the fragility
might only be apparent (i.e. it actually helps finding bugs).
That said, I'm glad to evaluate a patch to remove incubator usage from
add_literal, and instead use _gst_register_oop_array.
Paolo