Experimental changes to Instruction for line execution count

21 views
Skip to first unread message

Pieter Dirk Soels

unread,
Jul 1, 2021, 7:19:22 AM7/1/21
to JaCoCo and EclEmma Users
Hi all,

For my thesis project, I've been looking into changing JaCoCo to keep track of line execution counts (see GitHub issue and related conversation for context). I know this is not a desirable feature for the primary use-cases of JaCoCo, especially given that it will decrease performance. However, we need to do instrumentation-based profiling to see how often and where classes communicate with each other. We combine the line execution count with static analysis to extract this data, and changing JaCoCo seems the quickest way to achieve that. After my implementation is final, I will be comparing CI builds to see the impact of my performance changes. 

I've been able to get an implementation with reporting working (with some caveats), and it shows the execution counts on lines in HTML and XML reporting. I played around a bit with switch, if and try-catch statements and the values seem correct. However, I am less confident about the changes I made in Instruction.java as I am not as versed at branching in bytecode and would love to hear your input. Given that we do not store data in a BitSet for covered branches but in a Map<Integer, Integer> for the branches' execution counts, what should the behaviour be of instruction propagation, branching, merging and replacement? I placed some verbose comments in the class to argue my decisions and would love to hear if my assumptions and reasoning are somewhat sound.

Thank you in advance,
Pieter Dirk Soels      

Marc Hoffmann

unread,
Jul 1, 2021, 10:03:41 AM7/1/21
to JaCoCo and EclEmma Users
Hi Peter,

the code in this area is indeed quite tricky. That’s why we have lots of unit tests and integration tests (see validation… modules).

I would recommend to execute those to make sure the new implementation is correct.

Cheers,
-marc

--
You received this message because you are subscribed to the Google Groups "JaCoCo and EclEmma Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jacoco+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jacoco/2e0999d7-a66e-412e-8e21-7b018573c0d1n%40googlegroups.com.

Pieter Dirk Soels

unread,
Jul 2, 2021, 7:20:24 AM7/2/21
to JaCoCo and EclEmma Users
Hi Marc,

Thank you for your feedback here and on the PR itself! I've been able to execute all the unit and integration tests successfully. 
Furthermore, some simple manual investigation into the HTML and XML reporting shows what I would expect from my implementation.
In the meantime, I'm setting up a local environment to perform performance testing.

The primary thing that was unclear to me is how this concept of instruction execution count would be mapped to the implementation of merging instructions and replacing branches.
With merging instructions, I would assume that you would want to add the instruction execution count of every branch with the corresponding branch on the other instruction. 
Similar to the current or implementation but, rather than combining bits, adding the integers. 

Replacing branches, however, is vaguer to me where I do not exactly know why and when that happens. I was especially confused that no information is retained about the target
instruction's branches (b.coveredBranches) apart from whether there is at least one that was covered (the resulting bit that is written into a branch for current instruction). 
I was wondering whether my sum implementation would be correct in this context (which I do not understand). 

Many thanks,
Pieter Dirk Soels

Marc Hoffmann

unread,
Jul 2, 2021, 12:28:00 PM7/2/21
to jac...@googlegroups.com
Hi Pieter,

on a higher level the algorithm for boolean probes is documented here:


We need to keep track of covered branches only for filtering. For example for try/finally the code in the finally block is duplicated by the compiler. The respective filter merges the two blocks to make them look the same for the user. Here is when this was introduced:


Regards,
-marc


Reply all
Reply to author
Forward
0 new messages