Author: njn Date: 2008-01-03 05:01:50 +0000 (Thu, 03 Jan 2008) New Revision: 345
Log: Add a page about development priorities that Julian and I wrote ages ago. Currently not linked to from the front page -- I'm still not sure if we should put it up. Added: trunk/info/priorities.html Added: trunk/info/priorities.html =================================================================== --- trunk/info/priorities.html (rev 0) +++ trunk/info/priorities.html 2008-01-03 05:01:50 UTC (rev 345) @@ -0,0 +1,171 @@ +<h1>Development Priorities</h1> + +<p>The following is a prioritised list of Valgrind design and +development goals. Each one is followed by a rationale written <em>like +this</em>. The aim of this list is to give a general understanding of +what we think is important, but it should not be taken as +inviolable.</p> + +<p>Following the goals and rationales are some background comments on +techniques that have been used to achieve these goals.</p> + +<h2>High Priority</h2> + +<ul> +<li> +<p><strong>Robustness.</strong> Valgrind should be able to correctly run +as many programs as possible on the platforms we support.</p> + +<p><em>Systems which cannot be relied on to handle the vast majority of +presented workloads soon fall out of favour with users.</em></p> +</li> + +<li> +<p><strong>Accuracy of outputs.</strong> Debugging and profiling +information generated by the tools should be sufficiently accurate as to +be both useful to and credible to users. For example, bug detectors +should have minimal false positives.</p> + +<p><em>Tools which produce unreliable or non-credible results soon fall +out of favour with users.</em></p> +</li> + +<li> +<p><strong>Design simplicity.</strong> The design and implementation +should be easy to understand, maintain, test and verify.</p> + +<p><em>Our engineering resources are very limited, so the code base +should be structured to make best use of them. Also, a simple code base +is more accessible to newcomers.</em></p> +</li> + +<li> +<p><strong>Instrumentation capabilities.</strong> Firstly, provide +enough capabilities to keep Memcheck going. Then add capabilities as +required by other tools.</p> + +<p><em>We aim for Valgrind to be an effective framework for building +dynamic analysis tools, so it needs to provide instrumentation +capabilities as required by current and emerging tools.</em></p> +</li> +</ul> + +<h2>Medium Priority</h2> + +<ul> +<li> +<p><strong>Performance (speed and memory usage) of heavyweight +tools.</strong> This covers the speed of both the Valgrind core and the +tool components.</p> + +<p><em>All else being equal, faster and less space hungry tools are able +to handle larger workloads and so are more useful.</em></p> +</li> + +<li> +<p><strong>Usability.</strong> Users should be able to use the tools +without excessive complication or inconvenience.</p> + +<p><em>Tools which are difficult or inconvenient to use soon fall out of +favour with users.</em></p> +</li> + +<li> +<p><strong>New tools.</strong> Encourage development of new tools as +needs and opportunities develop.</p> + +<p><em>The needs of users and the general computing landscape changes +slowly over time, and it is important to remain relevant.</em></p> +</li> + +<li> +<p><strong>Portability.<strong> We want to avoid platform-specific +techniques. + +<p><em>Platform-specific techniques and assumptions are clearly a + hindrance to portablility. We have also found them to sometimes + reduce stability.</em></p> +</li> +</ul> + +<h2>Low Priority</h2> + +<li> +<p><strong>Performance of lightweight tools.<strong></p> + +<p><em>Heavyweight tools are both harder to construct and more valuable +to users than simple ones (eg, instruction counters, memory trace +generators), and other instrumentation frameworks (such as Pin and +DynamoRIO) support lightweight tools well. Where design choices +conflict they have usually been resolved in favour of supporting +heavyweight tools better.</em></p> +</li> + +<li> +<p><strong>New platforms.</strong> Although we want portability, we +don't want to support a lot of platforms, because it's hard work, +especially to do it to a high quality.</p> + +<p><em>As above, our engineering resources are limited and so we should +focus effort on the most widely used platforms.</em> +</li> + +</ul> + + +<h2>Example Techniques</h2> +Here are some techniques that in the past have been used to achieve +the above goals. This list does not claim to be complete. + +<li> +Valgrind's code representation (IR) favours powerful instrumentation +capabilities. This allows heavyweight tools such as Memcheck to be +built and have reasonable performance. However, it gives poor +performance for lightweight tools such as trace collectors. Such +lightweight tools will have better performance if written in other DBI +frameworks such as Pin or DynamoRIO. +</li> + +<li> +Valgrind does not use libc or any other library itself. This used to +not be true, but it caused robustness and portability problems. +</li> + +<li> +Valgrind makes very few assumptions about memory layout. This used to +not be true, but it caused robustness and portability problems. For +example, Memcheck's two-level shadow memory representation means its +shadow memory can be laid out very flexibly, but it is not particularly +fast. A "half-and-half" representation that stores shadow memory can be +faster, but fails on some programs, some Linux kernel configurations, +and is incompatible with other OSes such as Mac OS X. +</li> + +<li> +Valgrind used to use x86 segmentation to prevent a client program from +accidentally clobbering Valgrind data. However, this is not portable to +other platforms, and it was removed once support for other platforms was +added. Having such platform-specific features hinders portability and +makes testing harder. +</li> + +<li> +Valgrind serialises thread execution. For subtle atomicity reasons, +this is necessary for tools (like Memcheck) that use shadow values. It +means they can not use more than one processor at a time on +multiprocessor machines. +</li> + +<li> +Assertions and sanity checks. The code base contains a large number of +assertions. Additionally, many subsystems have sanity check code which +periodically checks important data structures in detail. In some cases +these checkers are permanently enabled, even at the cost of some +performance. These include: the IR intermediate representation, the +address space manager (m_aspacemgr), the translation table manager +(m_transtab), some parts of Memcheck. One side effect is that Valgrind +almost never segfaults - instead if it fails it does so by failing one +of these assertions or sanity checks. +</li> + +</ul> ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Valgrind-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/valgrind-developers
