Hi Mads, The idea was indeed improved testability.
Some of the tests we have to verify that internal event happens in the runtime are fragile. I have run into this with my current work on unboxed double arrays, but there are plenty of others examples. I would like to be write specific unit tests (not performance tests) to verify edge cases of my logic. But my tests will always pass with the auto-unboxing doesn't kick in at all, making the tests useless. This actually happened yesterday... somebody checked in a change that accidentally disabled the conversion to double arrays, and my code no longer got called, but all of the tests still passed. I could add a forcing function to cause the unboxing to happen, but then I can't actually test the logic which is intended to trigger the transition in the first place. I could write separate performance tests for each edge case, but that smells way too heavyweight and doesn't seem right either. It seems like whitebox-style testing in that case would be more robust and allow me to write simple, clear tests for the edge cases. My suggestion to Yang was that counters seemed to be a good mechanism to provide the needed instrumentation, and I didn't really see a downside, since there seem to be a fair number of counters that have been around for a while. Danno On Wed, Jun 29, 2011 at 5:22 AM, <[email protected]> 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? :-) > > > http://codereview.chromium.**org/7281007/<http://codereview.chromium.org/7281007/> > -- v8-dev mailing list [email protected] http://groups.google.com/group/v8-dev
