expose counter in d8

expose counter in d8

TEST=./d8 test/mjsunit/mjsunit.js test/mjsunit/d8-counter.js

[Yang, 2011-06-29 12:02:20]

Hi,

I just implemented a prototype for exposing counters in D8. I did it similar to
the way the OS object is exposed.

Rather than merely a CL, this is also a request for comment.

Currently, there are two methods counter.get(counter_name) and counter.names().
Is that sufficient? Any better interface?

Concerning test case d8-counter.js: the way how the counters for Math.tan and
Math.sin turn out differently is puzzling.

Cheers,

Yang

http://codereview.chromium.org/7281007/diff/1/src/d8.cc
File src/d8.cc (right):

http://codereview.chromium.org/7281007/diff/1/src/d8.cc#newcode601
src/d8.cc:601: 
Add new object "counter".

http://codereview.chromium.org/7281007/diff/1/src/d8.cc#newcode612
src/d8.cc:612: 
counter.get() returns the counter by the name provided.
e.g.
counter.get("c:V8.TotalCompiledCodeSize")

http://codereview.chromium.org/7281007/diff/1/src/d8.cc#newcode628
src/d8.cc:628: 
counter.names() returns counter names as an array of strings.

http://codereview.chromium.org/7281007/diff/1/src/d8.cc#newcode655
src/d8.cc:655: MapCounters(i::FLAG_map_counters);
Init counter in any case (not only upon --dump-counters). This makes unit tests
take less than half a second longer in total, so I think this is acceptable.

http://codereview.chromium.org/7281007/diff/1/test/mjsunit/d8-counter.js
File test/mjsunit/d8-counter.js (right):

http://codereview.chromium.org/7281007/diff/1/test/mjsunit/d8-counter.js#newc...
test/mjsunit/d8-counter.js:62: 
surprisingly, c:V8.MathSin and c:V8.MathCos both receive the value 1, while
c:V8.MathTan ends up with 1000... no caching involved here?

[Mads Ager (chromium), 2011-06-29 12:22:43]

I'm not sure I understand why we would want to expose counters to JavaScript?

Counters is an internal programmer tool that we use to gather statistics for a
while and then delete again. I don't think we should do testing at that level. I
would test behavior in  tests and performance in benchmarks. If we are making a
change that improves performance I think we should create a benchmark that shows
it to stop us from regressing. If we want to make sure that a test hits a
certain state, we should add functionality to force it instead of relying on
counters I think.

There might be compelling use cases that I haven't thought of? :-)

[Yang, 2011-06-29 14:41:34]

I guess the agreement offline is not to it this way.

On 2011/06/29 12:22:43, Mads Ager wrote:
> I'm not sure I understand why we would want to expose counters to JavaScript?
> 
> Counters is an internal programmer tool that we use to gather statistics for a
> while and then delete again. I don't think we should do testing at that level.
I
> would test behavior in  tests and performance in benchmarks. If we are making
a
> change that improves performance I think we should create a benchmark that
shows
> it to stop us from regressing. If we want to make sure that a test hits a
> certain state, we should add functionality to force it instead of relying on
> counters I think.
> 
> There might be compelling use cases that I haven't thought of? :-)