| November 18, 2008 11:00 PM PST | |
Avoid performance and security issues associated with memory-coding errors. Memory-coding errors lead directly to security vulnerabilities. Memory-access miscodings appear to be responsible for the majority of breaches that viruses and related security attacks exploit. Moreover, deep security analysis is only possible once basic memory access is sanitized. Any memory-access violations can reduce the effectiveness of other security measures all the way to zero.
Correct memory-access issues by means of 'safer' languages and safer libraries, inspection, and special-purpose memory-testing tools.
Java* is a safer language than C, particularly in terms of memory management, due to its more restricted semantics. At the same time, it is important to understand that these distinctions are relative. Many C-coded programs "leak memory" because of code fragments such as this:
/* If there's no "free(pointer);" here, then the data element which
pointer currently references will probably be "lost" in a programmatic
sense. */
pointer = malloc(sizeof(struct some_struct))
Java is not subject to this kind of memory leak. However, Java-coded programs still can leak memory at the application level. Think, for example, of a Web server coded in Java. It has a cache mechanism. If there is no provision for rotating or bounding the cache, it will eventually fill all available physical memory. While the memory might not have "leaked" in a formal sense, an inadequate design leads to the unsustainable result that the server can make no new computations. This highlights the reality that all programmers, not just those working in C or C++, need to be sensitive to memory models and their proper engineering.
Rather than use low-level languages for the Itanium® processor family, use high-level languages, achieve correct and reliable results, and invest in hardware and algorithm development. Reliance on low-level languages for large-scale development with diffuse performance goals often does not give the application-scale speed that is widely believed typical for "fast" languages. On the other hand, problems with memory access, and especially memory security, are quite typical of coding with low-level languages. If your applications fail to meet performance requirements, address that issue as a specific, local challenge, with the help of experts who specialize in performance achievements. (Membership in the Intel® Software Partner Program provides information and assistance optimizing and porting applications for Intel's latest processors.)
If you are using a language such as C or C++, you can prevent many common memory problems by substitution of higher-level libraries for more primitive memory approaches. "Garbage-collected C" eliminates one entire sector of memory errors. Use of the Standard Template Library (STL) or other powerful C++ class libraries minimizes source-code line count and therefore reduces opportunities for mistakes.
Perhaps the single most effective way to improve the "cleanliness" of memory coding is inspection in a broad sense, including everything from careful "bench testing" during early design stages, through the introspective collaboration Extreme Programming counsels for coding, to source-code engineering review. It is not just that academic research has demonstrated that inspection is actually le abor-intensive than discovery of problems in late-stage quality assurance or customer response. Inspection simultaneously has the potential to give programmers practical experience in improved techniques.
Take Advantage of the Memory Features of 64-Bit Computing
For more complete information about compiler optimizations, see our Optimization Notice.
