Checked and removed reference for zero-overhead, which was an issue with the reviewers
Changed the story regarding iProbe - added that it was the initial foray into light weight instrumentation, and led us to the development of Parikshan. This has been explained in the thesis introduction, and again in iprobe's introduction and it's summary.
Added a new section in discussions about sources of overhead in parikshan when it's running this was one of the main concerns of the reviewers. - See section 3.3.3
Added end-to-end performance evaluation. This is broadly in two terms - first micro-benchmarks which explain the impact on TCP bandwidth and latency. Secondly real-world on two applications - wikipedia, and mysql. I also show that adding a slow-down in the debug container does not impact the production container. - see section 3.4.3
Changed the divergence checking section. Added explanation for several questions that have been raised - see section 3.2.4
Based on your suggestion, I also introduced a new section, which talks about periodic re-synchronization as an option in Parikshan - see section 3.2.5
Based on our discussions, I also added 3 debugging scenarios from the case-studies in chapter 4. I added these to the last section with the debugging strategies of "execution tracing", "interactive debugging" and "staged record and replay". Hence taking the example of 3 real world cases I have explained how debuggers can use parikshan with these three debugging strategies. - see section 6.4.1, 6.4.3, and 6.4.5
Updated Budget based approximation for workload, instrumentation and buffer size modeling in parikshan - see section 6.5
Checked and removed reference for zero-overhead, which was an issue with the reviewers
Changed the story regarding iProbe - added that it was the initial foray into light weight instrumentation, and led us to the development of Parikshan. This has been explained in the thesis introduction, and again in iprobe's introduction and it's summary.
Added a new section in discussions about sources of overhead in parikshan when it's running this was one of the main concerns of the reviewers. - See section 3.3.3
Added end-to-end performance evaluation. This is broadly in two terms - first micro-benchmarks which explain the impact on TCP bandwidth and latency. Secondly real-world on two applications - wikipedia, and mysql. I also show that adding a slow-down in the debug container does not impact the production container. - see section 3.4.3
Changed the divergence checking section. Added explanation for several questions that have been raised - see section 3.2.4
Based on your suggestion, I also introduced a new section, which talks about periodic re-synchronization as an option in Parikshan - see section 3.2.5
Based on our discussions, I also added 3 debugging scenarios from the case-studies in chapter 4. I added these to the last section with the debugging strategies of "execution tracing", "interactive debugging" and "staged record and replay". Hence taking the example of 3 real world cases I have explained how debuggers can use parikshan with these three debugging strategies. - see section 6.4.1, 6.4.3, and 6.4.5
Updated Budget based approximation for workload, instrumentation and buffer size modeling in parikshan - see section 6.5