I just looked at the code to set the coverage hash and it seems to
extend the code for the existing trace hook. So I guess this means
that in order to get code coverage,  one needs to do add
VM::InstructionSequence.compile_option = { trace_instruction : true }
just like one does to get line tracing. And currently the default is
off, although that has been up for discussion.

On Wed, Jul 16, 2008 at 11:32 PM, Urabe Shyouhei <shyouhei / ruby-lang.org> wrote:
> It seems to me what you need is not a coverage system but a general hook
> interface.  That can be useful, bot should better be another
> infrastructure than the coverage feature we have now.
>
> Rocky Bernstein wrote:
>> Sorry for not noticing sooner. It occurs to me that the built-in
>> coverage feature that is currently being implemented for the next
>> release is not all that different from a line tracing feature. I
>> wonder if it could be extended so that a method is called instead of
>> updating a hash. In fact one can think of the coverage mechanism as a
>> special kind of trace mechanism that only updates a hash.
>>
>> And it's also true that the instruction replacement for setting a
>> (temporary) breakpoint in 1.9 can also be used in implementing
>> something like rcov.
>>
>> Here you set temporary breakpoints at every known statement boundary.
>> If all you care about is coverage like rcov after the temporary
>> breakpoint is serviced by updating a mark indicating the line was hit,
>> the original opcode can go back and in terms of performance the only
>> penalty is the initial time to put in the temporary breakpoints and
>> the time to update however many counts are actually covered.
>>
>> And one can reliably know what has not been run by scanning the code
>> for trace instructions. Finally, I suppose all of this could be sped
>> up by building initial trace replacement into the compiler.
>>
>> On Tue, Jul 8, 2008 at 8:22 AM, Yusuke ENDOH <mame / tsg.ne.jp> wrote:
>>
>>> Hi,
>>>
>>> 2008/7/8 Yugui (Yuki Sonoda) <yugui / yugui.jp>:
>>>
>>>> Committers and anyone who intend to write patches, let me know your
>>>> plan. What features will be implemented by 25 Sep? What will not?
>>>>
>>> I hope to include built-in coverage measurement feature.
>>>
>>> I have already committed some primitive features that measure
>>> coverage into the core interpreter.  But I haven't implemented
>>> a practical front-end tool which controls measurement and outputs
>>> the measured result.
>>>
>>> As a matter of fact, my goal is to measure coverage of the
>>> standard libraries for maintenance and enhancement of their tests,
>>> not to provide useful coverage measurement tool.  So I'm not in a
>>> hurry to implement a front-end tool.  If it's permitted, let's
>>> just say that it will be implemented by 1.9.5 :-)
>>>
>>> --
>>> Yusuke ENDOH <mame / tsg.ne.jp>
>>>
>>>
>>>
>>
>>
>>
>>
>
>
>