On 8/23/07, Rui Hu <[EMAIL PROTECTED]> wrote: > > I've shared the customized emma tool and its usage in [1]. > > We can also find the reason why we need customize emma and how to do it. > The > modified source code is also provided. > > Any comment is highly welcomed. > > [1]: http://wiki.apache.org/harmony/coverageEMMA
The existence of kernel list is, as Robert says, because that Emma itself depends on java core classes in its static initialization but unfortunately in order to record testcoverage of these java core classes, in their static initialization, emma will be referenced in order to register some data structure for these java core classes. Thus Emma' initialization depends on java core classes and java core classes' initialization depends on Emma and VM detects a circular dependency and throw out ClassDefNotFound exception. In out current solution, core classes in the kernel list will not register themselves to emma during instrumentation. But during startup, we will explicitly load these core classes and Emma and then manually register core classes afterwards. But what puzzles me is that the kernel list, which is the dependencies of Emma(The classes will be loaded when loading Emma.), is so unstable and is a lot larger than my estimation. I once used JVMTI to record all the classes loaded when loading Emma, and the kernel list generated by this way is much smaller and does not work. So is there a more precise way to calculate which class will be referenced while loading Emma(The com.vladium.emma.rt.RT class)? I believe the dependencies of this class should be more stable than we have met. 2007/8/22, Rui Hu <[EMAIL PROTECTED]>: > > > > I've shared the coverage report in HARMONY-4665. Anyone can download it > to > > see the coverage details. Thanks. > > The customized EMMA and usage will be shared later. > > > > > > 2007/8/21, Tim Ellison < [EMAIL PROTECTED]>: > > > > > > Rui Hu wrote: > > > > I think, it is not easy to automatically generate the coverage > report > > > of our > > > > trunk. :-( > > > > > > > > Because Harmony is not a Java application, it's the JDK, so the > > > original > > > > EMMA can not be use to collect the coverage data of Harmony. We've > > > modified > > > > the source code of EMMA, and realize the coverage collecting for > > > core-java > > > > APIs. In this way, we must notice that: > > > > 1. The coverage of the classes in luni-kernel.jar can not be > > > collected. It's > > > > not a big problem, because there're not many classes in that jar and > > > the > > > > coverage of those classes is considered to be very high (they're > > > usually > > > > used kernel classes). > > > > 2. The customized EMMA needs extra list of booting classes to run, > the > > > class > > > > list can not be too big or too small. If it's too big, the EMMA may > > > not > > > > work. If it's too small, the JDK can not initialize. > > > > 3. The coverage of the classes in the list mentioned in #2 will be > > > always > > > > 100%, (only the class coverage will be 100%, the method/block > coverage > > > will > > > > be correct), it's reasonable for the REAL booting classes, but > > > incorrect for > > > > the unnecessary classes. So, this is another reason why we need not > a > > > > too-big list. > > > > > > > > The problem is from the booting classes list mentioned in #2. > Ideally, > > > this > > > > list includes the classes which is used during initialization of > > > running a > > > > test suite. Unfortunately, we do not have method to get the list > > > > automatically, and it related with the revision of Harmony build, > the > > > > classes we want to collect coverage data for, and the test suite we > > > want to > > > > run. > > > > So we now must try to get the list from cutting down the big-enough > > > list > > > > (usually the all-instrumented-classes-list) every time. If the test > > > crash, > > > > we must modify the booting classes list or remove some "problem test > > > cases". > > > > > > > > The only shortcut is use the current successful list as the start > > > point, but > > > > it can not ensure the test will run successfully, especially we > change > > > the > > > > test suite or expand the instrumented classes list ( for example, > > > instrument > > > > all the classes instead of only public API classes). > > > > > > > > I'd like to share our customized EMMA and the experience of using > it. > > > It is > > > > highly welcomed to share your idea to automatize this process, or > > > simplify > > > > the it, or make the it more stably. > > > > > > It would be great if you would share it, then perhaps other people > will > > > see ways to improve creating the booting classes list -- and it would > be > > > interesting to get reports on the current BTI test coverage. > > > > > > Regards, > > > Tim > > > > > > > > > > > -- > > Robert Hu > > China Software Development Lab, IBM > > > > > > -- > Robert Hu > China Software Development Lab, IBM > -- Leo Li China Software Development Lab, IBM
