ABSTRACT Finding Bugs is Easy

合集下载

Abstract

Using Rewriting-Logic Notation for Funcional Verification in Data-Stream Based Reconfigurable ComputingReiner W. Hartenstein1, Ricardo P. Jacobi2 1Fachbereich Informatik Kaiserslautern University of Technology hartenst@rhhk.uni-kl.de2Depto. De Ciência da ComputaçãoUniversidade de Brasíliarjacobi@cic.unb.br Maurício Ayala-Rincón3, Carlos H. Llanos4 3Departamento de Matemáticaayala@mat.unb.br4Departamento de Engenharia Mecânicallanos@unb.brUniversidade de BrasíliaBrasília - BrazilAbstractReconfigurable Systolic Arrays are a generalization of Systolic Arrays where node operations and interconnections can be redefined even at run time. This flexibility increases the range of systolic array’s application, making the choice of the best systolic architecture to a given problem a critical task. In this work we investigate the specification and verification of such architectures using rewriting-logic, which provides a high level design framework for architectural exploration. In particular, we show how to use ELAN rewriting system to specify reconfigurable systems which can perform both arithmetic and symbolic computations.1. IntroductionThe widespread popularization of mobile computing and wireless communication systems fostered the research on new architectures to efficiently deal with communications issues in hardware constrained platforms like PDAs, mobile phones and pagers, for instance. Some tasks such as data compression, encoding and decoding are better implemented through dedicated hardware modules than using standard general purpose processors (GPP). However, the exploding costs of integrated circuit fabrics associated with shorter devices lifetimes makes the design of ASIC (Application Specific Integrated Circuit) a very expensive alternative. The growing capacity of Field Programmable Gate Arrays (FPGA) and the possibility of reconfiguring them to implement different hardware architectures makes it a good solution to this rapid changing wireless market. An FPGA may be configured to implement a cipher algorithm at one moment and can be later reconfigured to implement a data compressing algorithm. This flexibility opens a wide range of architectural alternatives to implement algorithms directly in hardware. In this context, it is very important to provide methods and tools to rapidly model and evaluate different hardware architectures to implement a given algorithm.In this paper we propose the use of rewriting systems to model and evaluate reconfigurable systolic hardware architectures. After the seminal work of Knuth-Bendix about the completion of algebraic equational specifications, which allows for the automatic generation of a rewrite-based theorem prover for the equational reduct of the subjacent treated theories [KnBe70], rewriting has been successfully applied into different areas of research in computer science as an abstract formalism for assisting the simulation, verification and deduction of complex computational objects and processes. In particular, in the context of computer architectures, rewriting theory has been applied as a tool for reasoning about hardware design.To review only a reduced set of different approaches in this direction, we find of great interest the work of Kapur who has used his well-known Rewriting Rule Laboratory - RRL(the first successful prover assistant based on rewriting) for verifying arithmetic circuits [KaSu2000, Ka2000, KaSu1997] as well as Arvind’s group that treated the implementation of processors with simple architectures [ShAr98a,ShAr98b,ArSh99], the rewrite-based description and synthesis of simple logical digital circuits [HoAr99] and the description of cache protocols over memory systems [RuShAr99,ArStSh01]. Also contributions in this field have shown how rewriting theory can be applied for the specification of processors (as Arvind’s group does) as well as for the purely rewrite based simulation and analysis of the specified processors [ANJLH02]. To achieve this rewriting-logic has been applied, that extends the pure rewriting paradigm allowing for a logical control of the application of the rewriting rules bystrategies [Me00,CiKi99]. Important programming environments based on the rewriting-logic paradigm are ELAN [CiKi99,BKKM02], Maude [Me00,Cla02] and Cafe-OBJ [DiFu02]. The impact of rewriting-logic as a successful programming paradigm in computer science as well as of the applicability of the related programming environments is witnessed by [MOMe02]. All our implementations and experiments were done in ELAN, since we consider of great flexibility its easy manipulation of strategies. However, for effects of model checking Maude has been proved to be more adequate.Section 2 provides an introduction to basic concepts in rewriting theory and reconfigurable circuits. Section 3 presents the specification and simulation of reconfigurable systolic arrays. Section 4 discusses use of rewriting-logic for simulating reconfiguration and another approach for data driven systolic arrays and section 5 is the conclusion.2. BackgroundAn example of our typical target environments is mapping applications onto platforms like coarse-grained DPAs (DataPath Arrays) or rDPAs (reconfigurable DPAs). We assume, that such platforms are completely pre-debugged, so that only the related mapping source has to be verified. Using Term Rewriting Systems (s. section 2.1) in such an environment means to specify or verify designs from sources at abstraction levels being higher than that of languages like VHDL or Verilog. Such notations are much more compact and concise than with traditional hardware language source notations in EDA. An example is the input language of ELAN which is a parsable derivative of the math formula space.This paper uses systolic arrays as demo examples (section 2.2). Systolic arrays, however, are special cases of super-systolic platforms like DPAs or rDPAs [HaKrRe95], which are data-stream-based [Ha03] pipe networks. (By the way: such platforms may also be emulated on larger FPGAs.) The only difference between systolic and super-systolic is the mapping method [Ha97]. Algebraic mapping or linear projection methods yield only solutions with linear uniform pipes which is restricted to the special case of applications with strictly regular data dependencies. But using simulated annealing, genetic algorithms or other optimization methods, permits any heterogeneous networks with free form pipes like zigzag, circular, or any much more wild shapes, and may also include forks and joins. The methodology introduced by this paper may be used for all kinds of data-stream-based hardwired or reconfigurable platforms.2.1. Rewriting theoryWe include the minimal needed notions on rewriting theory and rewriting-logic. For a detailed presentation of rewriting see [BaNi98].A Term Rewriting System, TRS for short, is defined as a triple ·R, S, S0 Ò, where S and R are respectively sets of terms and of rewrite rules of the form l ’ r i f p(l)being l and r terms and p a predicate and where S0 is the subset of initial terms of S. l and r are called the left-hand and right-hand sides of the rule and p its condition.In the architectural context of [ShAr98b], terms and rules represent states and state transitions, respectively.A term s can be rewritten or reduced to the term t, denoted by s ’ t, whenever there exists a subterm s' of s that can be transformed according to some rewrite rule into the term s'' such that replacing the occurrence of s' in s with s'' gives t. A term that cannot be rewritten is said to be in normal or canonical form. The relation over S given by the previous rewrite mechanism is called the rewrite relation of R and is denoted by ’. Its inverse is denoted by ¨and its reflexive-transitive closure by ’*and its equivalence closure by ´*.The important notions of terminating property (or Noetherianity) and Church-Rosser property or confluence are defined as usual. These notions correspond to the practical computational aspects as the determinism of processes and their finiteness.•a TRS is said to be terminating if there are no infinite sequences of the form s0’ s1’ ...• a TRS is said to be confluent if for all divergence of the form s ’* t 1, s ’* t 2 there exists a term u such that t 1 ’* u and t 2 ’* u .The use of the subset of initial terms S 0, representing possible initial states in the architectural context (which is not standard in rewriting theory), is simply to define what is a "legal" state according to the set of rewrite rules R ; i.e., t is a legal term (or state) whenever there exists an initial state s Œ S 0 such that s ’* t .Using these notions of rewriting one can model the operational semantics of algebraic operators and functions. Although in the pure rewriting context rules are applied in a truly non deterministic manner in the practice it is necessary to have a control of the ordering in which rules are applied. Thus rewriting theory jointly with logic, that is known as rewriting-logic, has been showed of practical applicability in this context of specification of processors since they may be adapted for representing in the necessary detail many hardware elements involved in processors. Moreover, other important fields of hardware design such as verification and synthesis of logical circuits may be benefited from the simplicity and versatility of this theoretical framework.2.2. Systolic arrays and reconfigurable systemsA systolic array is a mesh-connected pipe network of DPUs (datapath units), using only nearest neighbor (NN) interconnect [Ku78, Ku87]. DPU functional units operate synchronously, processing streams of data that traverse the network. Systolic arrays provide a large amount of parallelism and are well adapted to a restrict set of computational problems, i.e., those which can be efficiently mapped to a regular network of operators.Figure 1 shows a simple systolic example of a matrix-vector multiplication. The vector elements are stored inthe cells and are multiplied by the matrix elements thatare shifted bottom-up. On the first cycle, the first cell(DPU1) computes x 1*a 11, while the second and third cells(DPU2 and DPU3) multiply their values by 0. On thesecond cycle, the first cell computes x 1*a 21, while thesecond cell computes x 1*a 11 + x 2*a 12, where the first termis taken from the first cell and added to the productproduced in second cell. In the third cycle, the third cellproduces the first result : y 1 = x 1*a 11 + x 2*a 12 + x 3*a 13. Inthe following two cycles y 2 and y 3 will be output by thethird cell.There are several alternative configurations of functional cells, each one tailored to a particular class of computing problems. However, one of the main critics to systolic arrays is its restriction to applications with strictly regular data dependencies, as well as its lack of flexibility. Once designed, it is suitable to support only one particular application problem.The limitations of systolic arrays may be circumvented by using reconfigurable circuits, the most representative of them being the FPGAs (Field Programmable Gate Arrays). An FPGA can have its behavior redefined in such a way that it can implement completely different digital systems on the same chip. Fine grain FPGAs may redefine a circuit at the gate level, working with bit wide operators. This kind of architecture provides a lot of flexibility, but takes more time to reconfigure than coarse grain reconfigurable platforms (rDPAs: reconfigurable DPAs). These work with word wide operators that are slightly less flexible but more area efficient and take much less time to reconfigure than the fine grain ones. The design of reconfigurable systolic architectures [HaKrRe95, HHHN00] aims to overcome the restriction of pure systolic circuits while keeping the benefits of a large degree of parallelism. In the reconfigurable approach, the operations performed by each functional unit as well as the interconnection among them may be reconfigured in order to be adapted to different applications. Moreover, it is possible to change the configuration of the circuit during run time, an approach called dynamic reconfiguration, which broadens even more the architectural alternatives to implement applications in hardware.a 21a 31a 12a 22a 32a 13a 23a 330y 1 = a 11x 1+a 12x 2+a 13x 3y 2 = a 21x 1+a 22x 2+a 23x 3y 3 = a 31x 1+a 32x 2+a 33x 3Figure 1: Vector – matrix computation.3. Specification and Simulation of Systolic Arrays via Rewriting-LogicHere we show how rewriting-logic can be applied to specify simple systolic arrays for vector andmatrix multiplication using the ELAN system. In these systems we can consider as the reconfigurablepart the constants in each component (DPU as in Figure 1), here called MAC (Multiplier/Adder).Vector multiplication: ELAN provides a very flexible programming environment where the user defines the syntax and semantics of data types (called sorts) and operations to be used in the program.Figure 2 shows the syntax of the data types in the ELAN program that models the vector multiplication.In the left side of a definition the data is specified using a combination of text and place holders which are represented by an ‘@’ character. For instance, an element of sort Port is defined as port(@, @). Thesort of the parameters as well as the sort of the element itself is defined in the right side of the definition.In this example, the two parameters of port are an integer and a Boolean, and the resulting element port(int, bool) is of sort Port. A MAC data is composed of six elements. The sort of the elements is, respectively, int, for the identifier, two of sort Port and two of sort Reg for the ports and registers andone of sort Const for the respective constant component of the multiplier vector. The processor sort Procconsists of four components: three of sort MAC and one of sort DataStream. The DataStream isdescribed as an object with three components of sort list[Data].operators global@ : ( int ) Const;port(@,@): ( int bool ) Port;reg(@,@): ( int bool ) Reg;'[' @,@,@,@,@,@ ']': ( int Port Port Reg Reg Const ) MAC;'<' @ @ @ @ '>' : ( MAC MAC MAC DataStream ) Proc;( @ @ @ ): ( list[Data] list[Data] list[Data] ) DataStream;@: ( int ) Data;endFigure 2. Sorts of the MAC in ELANThe rule named sole, used to describe the behavior of the processor during each cycle of the execution is given in figure 4. Informally, the rule is fired when the expression being processed matches the left side of the rule. It is replaced by the expression produced at the right side of the rule, which is again matched against the set of rules that define the program. Rules can be named for future reference when defining strategies. The rule name sole appears between square brackets in the beginning of the rule. Observe that after one-step of reduction applying this rule all necessary changes in the specified processor are executed. First, notice that the data d1, d2 and d3 at the top of the DataStream, are removed from the three lists of data and placed in the first ports of the three MACs.Figure 3. MAC Systolic Array ArchitectureThe multiplications between the contents of each first port vpi1 and the corresponding constant c i are placed in the first register of each MAC, for i=1,2 3 and 3 and the additions between the first register vri1 and the second port vpi2 are placed in the second port of each MAC, for i=1,2 and 3. Zeros preceding each operator v i are included to synchronize the two operations executed in each MAC. Finally, observe the data transfer from the second register vri2 of each MAC to the second port of the next component vp(i+1)2for i=1 and 2. All that is simultaneously done by only one application of the rewriting rule sole.With respect to the timing aspects of this example, the model assumes a clocked operation like traditional systolic architectures. There is no handshake between nodes and each application of rule sole corresponds to a single clock cycle. Thus, each node in fig. 3 takes two clock cycles to produce itsoutput. The synchronization between nodes for the first values is achieved introducing pairs of zero values, as illustrated in figure 3, and the Boolean flags used to synchronize nodes could be omitted.Executing all steps with a singe rewriting rule could appear artificial in other contexts of computer science, such as semantics of programming languages and in general theory of computing. Nice but relatively complex theoretical results can be related with the possibility of having a unique rewriting rule which simulates a (universal) Turing machine [Da1989, Da1992]. This nontrivial theoretical development may be better understood when we relate a sole rule with the execution of a "cycle" of a processor.rules for Procd1,d2,d3 : int; // variables for input datal1,l2,l3 : list[Data]; // lists of input datavp11, vp12, vp21, vp22, vp31, vp32 : int; // portsvr11, vr12, vr21, vr22, vr31, vr32 : int; // registersc1, c2, c3 : int; // constantsglobal[sole]<[1,port(vp11,true),port(0,true),reg(vr11,true),reg(vr12,true),c1][2,port(vp21,true),port(vp22,true),reg(vr21,true),reg(vr22,true),c2][3,port(vp31,true),port(vp32,true),reg(vr31,true),reg(vr32,true),c3 ](d1.l1 d2.l2 d3.l3) > =><[1, port(d1,true),port(0,true),reg(vp11*c1,true), reg(0+vr11,true),c1 ][2, port(d2,true),port(vr12,true),reg(vp21*c2,true), reg(vp22+vr21,true),c2 ][3, port(d3,true),port(vr22,true),reg(vp31*c3,true), reg(vp32+vr31,true),c3 ](l1 l2 l3) >endendFigure 4. ELAN Description of the Sole Rule.For our example we will consider as simple mechanism of reconfiguration the possibility of changing the constants in each MAC. Then a computation with our systolic array consists of two stages: a reconfiguration stage, where the constants are set and the subsequent processor execution with the previously defined rule sole.Figure 5 shows one additional rule created for the reconfiguration of a processor called conf. It simply changes the contents of the constant part of each MAC(in our case by the vector (1,0,0)). Observe that with the pure rewriting based paradigm this rule applies infinitely, because the resulting expression will match against the left side of the rule again and again. Thus, for controlling its application, we define a logical strategy, called withconf.withconf simply allows for the execution of one-step of reduction with the rule conf(the first reconfiguration stage) and a subsequent normalization with the rule sole (the second processor execution stage). This normalization is an available ELAN strategy, which applies the rewriting rules given as argument (in our case the rule sole) until a normal form is reached.[conf]< [1,port(vp11,true),port(0,true),reg(vr11,true),reg(vr12,true),c1][2,port(vp21,true),port(vp22,true),reg(vr21,true),reg(vr22,true),c2][3,port(vp31,true),port(vp32,true),reg(vr31,true),reg(vr32,true),c3](d1.l1 d2.l2 d3.l3) > =>< [1,port(vp11,true),port(0,true),reg(vr11,true),reg(vr12,true),1][2,port(vp21,true),port(vp22,true),reg(vr21,true),reg(vr22,true),0][3,port(vp31,true),port(vp32,true),reg(vr31,true),reg(vr32,true),0](d1.l1 d2.l2 d3.l3) >endstrategies for Procimplicit[] withconf => conf; normalise(sole) end[] simple => normalise(sole) endendFigure 5. conf Rule for ReconfigurationMatrix Multiplication:figure 6 shows the matriz multiplication structure and the description of its components is given in figure 7. Using the previous approach (that is, specifying a sole rule) implies the use of an excessive number of variables, which is not directly supported in ELAN. In fact, we would need different variables for the two ports, three registers and the constant belonging to each MAC, whichgives a total of 96 variables; additionally, we would need 16 variables for describing the two 4x data streams. This could be done by enlarging the ELAN capacity for dealing with variables before compiling the system. But a better solution is to split the cycle defining independent rewriting rules to be applied under a reasonable strategy, to simulate the internal process into each MAC component and the propagation of data between each component to their North and East connected MAC s.We define a rule for each of the sixteen components, which propagates the contents into their registers two and three to their North and East connected components, respectively. As a consequence of the form in which data should be transferred in the processor, these sixteen rules should be applied from the right to the left and top-down in order to complete a whole cycle of execution.Figure 6. Systolic Matrix-vector multiplicationoperators global@ : ( int ) Const;p(@) : ( int ) Port;r(@) : ( int ) Reg;'['@,@,@,@,@,@,@']' : ( int Port Port Reg Reg Reg Const ) MAC;'<' @@ @ @ @@ @ @ @@ @ @ @@ @ @ @@ '>: ( DataStringMAC MAC MAC MAC // MACs 13 14 15 16MAC MAC MAC MAC // MACs 09 10 11 11MAC MAC MAC MAC // MACs 05 06 07 08MAC MAC MAC MAC // MACs 01 02 03 04DataString ) Proc;( @ @ @ @ ) : ( list[Data] list[Data] list[Data] list[Data] )DataString;@ : ( int ) Data;endFigure 7. A 4¥4 Systolic array DescriptionAll these rules are very similar and a selected group of them is presented in the Figure 8. The rules for the South (mac01, mac02, mac03, mac04) and West (mac01, mac05, mac09, mac13) MAC s, called boundary components of the processor, load the data (dS and dW) in the head of the corresponding list of the data stream (lS1, lS2, lS3, lS4 and lW1, lW2, lW3 and lW4). Moreover, the rules for MAC s in the North (mac13, mac14, mac15, mac16) and East (mac04, mac08, mac12, mac16) boundaries of the processor only transfer data to the East and North corresponding boundary components; except, of course, for mac16. Consequently, different orderings for applying these rules completing a whole cycle of the processor are possible. For instance, we could take the ordering: mac16, mac12, mac08, mac04, mac15, mac11, mac07, mac03, mac14, mac13, mac10, mac09, mac06, mac05, mac02, mac01.In the Figure 9 we present a possible strategy called onecycle which defines an(other) ordering of application of these rules for completing a sole cycle of the processor. For completing the simulation of execution with this simple processor, one should define a normalization via this strategy: normalise(onecycle). In this rewriting-logical environment, our specification could be easily modified allowing the interpretation of parts of the processors as reconfigurable components.At first glance, one could look at the constants of the 16 MAC s as a reconfigurable component. In this way the processor can be adapted to be either a 4-vector versus 4x4-matrix multiplier or vice-versa and the 4x4-matrix may be modified to represent, for example, either the identity or the matrix F 4 of the Fast Discrete Fourier Transform (FFT).rules for Proc m01,m02,m03,m04,m05,m06,m07,m08: MAC; // 1-8 MACs m09,m10,m11,m12,m13,m14,m15,m16:MAC; //9-16 MACs dW, dS : int; // data East and SouthlW1,lW2,lW3,lW4,lS1,lS2,lS3,lS4:list[Data]; // West andSouthr1,r2, r3,rN1,rN2,rN3 : int; // Central North andrE1,rE2,rE3 : int; // East registers 1,2,3p1,p2,pN1,pN2,pE1,pE2: int; //Central,North and East portsc,cE,cN : int;global[mac16]< (lW1 lW2 lW3 lW4)m13 m14 m15 [16,p(p1),p(p2),r(r1),r(r2),r(r3),c ]m09 m10 m11 m12m05 m06 m07 m08m01 m02 m03 m04(lS1 lS2 lS3 lS4) > =>< (lW1 lW2 lW3 lW4)m13 m14 m15 [16,p(p1),p(p2),r(p1*c),r(r1+p2),r(p1),c ]m09 m10 m11 m12m05 m06 m07 m08m01 m02 m03 m04(lS1 lS2 lS3 lS4) >end ...[mac11]< (lW1 lW2 lW3 lW4)m13 m14 [15,p(pN1),p(pN2),r(rN1),r(rN2),r(rN3),cN ] m16m09 m10 [11,p(p1),p(p2),r(r1),r(r2),r(r3),c ][12,p(pE1),p(pE2),r(rE1),r(rE2),r(rE3),cE ]m05 m06 m07 m08m01 m02 m03 m04(lS1 lS2 lS3 lS4) > =>< (lW1 lW2 lW3 lW4) m13 m14 [15,p(pN1),p(r2),r(rN1),r(rN2),r(rN3),cN ] m16 m09 m10 [11,p(p1),p(p2),r(p1*c),r(r1+p2),r(p1),c ] [12,p(r3),p(pE2),r(rE1),r(rE2),r(rE3),cE ] m05 m06 m07 m08 m01 m02 m03 m04 (lS1 lS2 lS3 lS4) >end ...…… [mac01]< (dW.lW1 lW2 lW3 lW4) m13 m14 m15 m16 m09 m10 m11 m12 [05,p(pN1),p(pN2),r(rN1),r(rN2),r(rN3),cN ] m06 m07 m08 [01,p(p1),p(p2),r(r1),r(r2),r(r3),c ] [02, p(pE1),p(pE2),r(rE1),r(rE2),r(rE3),cE]m03 m04 (dS.IS1) IS2 IS3 IS$) > =>< (IE1 IE2 IE3 IE4) m13 m14 m15 m16 m09 m10 m11 m12 [05, p(pN1),p(r2) r(rN1) r(rN2) r(rN3), cN] m06 m07 m08 [01, p(dW), p(dS),r(p1*c), r((rE2), r(rE3), cE] m03 m04 (IS1 IS2 IS3 IS4)>end end Figure 8. A selected set of rules for matrix-vector multiplipy.Strategies for Procimplicit[] onecycle =>mac16;mac15;mac14;mac13;mac12;mac11;mac10;mac09;mac08;mac07;mac06;mac05;mac04;mac03;mac02;mac01 end end Figure 9. onecycle strategy for rule application.reconfF4 => F4;normalise(mac16;mac15;mac14;mac13; mac12;mac11;mac10;mac09; mac08;mac07;mac06;mac05; mac04;mac03;mac02;mac01)endFigure 10: strategy working over processor.The last is specified by a strategy additional, that is presented at the Figure 11, which before to the simulation of the normalization executes the rewrite rule F 4. F 4 transforms any given state of the processor into another where the reconfigurable constants are replaced with the corresponding powers of a primitive complex 4-root of the unity of F 4 (either i o r -i ) as illustrated in the Figure 11. In this specification the components of each MAC have been divided into the fixed ones and the reconfigurable constant [fxnn cnn]. This simple idea can be directly extended to different kind of MAC s , where other components are considered to be reconfigurable.[F4]< dstreamEast[fx13 c13] [fx14 c14] [fx15 c15] [fx16 c16][fx09 c09] [fx10 c10] [fx11 c11] [fx12 c12][fx05 c05] [fx06 c06] [fx07 c07] [fx08 c08][fx01 c01] [fx02 c02] [fx03 c03] [fx04 c04]dstreamSouth > =>< dstreamEast [fx13 i 0] [fx14 i 3] [fx15 i 6] [fx16 i 9] [fx09 i 0] [fx10 i 2] [fx11 i 4] [fx12 i 6] [fx05 i 0] [fx06 i 1] [fx07 i 2] [fx08 i 3] [fx01 i 0] [fx02 i 0] [fx03 i 0] [fx04 i 0]dstreamSouth >endFigure 11: rule for FFT Transformer4. Alternative Models4.1 Variable Size Systolic ArraysOne limitation of the ELAN models presented aboveis that the rules are defined for a specific systolicarchitecture. A more flexible description will allow thespecification of systolic arrays with an arbitrary numberof functional units. In this case, the rewriting rulesshould be defined independently of the array size ortopology.This is exemplified in this section through the modeling of a simple version of the KressArray architecture [HaKrHe95]. It is defined by a matrix of reconfigurable functional units (rDPUs: reconfigurabledatapath units) where both the operations and the interconnections may be redefined (compare fig. 12 c and d). Figure 12 illustrates a KressArray family design space, which covers a wide variety of reconfigurable connect fabrics: nearest neighbour interconnect (NN) and backbus fabrics (segmented and / or non-segmented). Figure 13 shows a detailed example of NN ports featuring individual path width and individual mode (in, out, or bi-directional).Mapping C expressions to KressArrays is performed by assigning C operators to the nodeswhile keeping the corresponding data dependency among them. One particularity is that a KressArray is a pipe network which implements a dataflow model of computation. Coming along with synthesis tools also supporting non-uniform non-regular pipe networks [HHHN00, Na01] (in contrast to classical systolic array synthesis methods accepting only applications with strictly regular data dependencies) the KressArray family is a generalization of the systolic array. In addition to the generalized NN interconnect the KressArray family also provides abackbus (BB) second level interconnect fabrics with resources like buses and bus segments (for familymember examples see fig. 12 e, f, g).The DPU nodes of both, systolic arrays and rDPAs,may operate in a clocked mode, or asynchronously,where each operation is triggered as soon as data isavailable at the node inputs. (The latter version ofsystolic arrays has been usually called wavefrontarrays). This asynchronous operation is accomplishedby a handshake between interconnected nodes, sinceeach operation may take several clock cycles(multiplication, for instance, is implemented in itstypical serial way, through sums and shifts).Modeling of KressArrays in ELAN takes a different approach. To allow the specification of variable size systolic arrays, the nodes are stored on a list of arbitrary length. The designer provides the interconnections among nodes through signals, implemented with variables that connect the registers at the inputs and outputs of the nodes. Thus, if node n i is connected to node n j , then the same variable is associated to n i output and n j input. The operations of the nodes are dynamically specified along with the data that is to be processed by the array. To illustrate this kind of modeling lets consider a practical example: a KressArray that computes the differential equation loop body, given in figure 14.This array is defined by a list of 12 nodes, numbered from left to right and top to bottom. The first 4nodes are presented in figure 15. Each rDPU node is a kind of rAlu (reconfigurable Arithmetic-Logic Unit). In this simplified version, each rDPU has two registers in the inputs and one register at the output.Each register is defined by the variable it holds, its value and a flag that indicates if the data it holds is valid. The flag models the signal used for handshake in hardware. Rule assign() is used by the designer to provide values to input variables, specified in the form “x=5.y=2…”. Then, rule dpu() is applied to the Figure 12. KressArray family design space:(a, b) NN fabrics examples; (e, f, g) backbus (BB) fabrics examples; rDPU configuration:c) routing only configuration, d) routing and function configuration Figure 13: a KressArray family member example illustrating individual port mode and path width。

任务管理功能模块测试及开发答疑英语

任务管理功能模块测试及开发答疑英语全文共6篇示例，供读者参考篇1Task Management Fun: Testing and TroubleshootingHave you ever felt like you have a million things to do and can't keep track of them all? Well, task management apps are here to help! These nifty little programs allow you to create lists of all your tasks or chores, so you'll never forget what needs to be done. But before we can use them, they need to go through a process called testing to make sure everything works properly. Let me tell you all about it!The Importance of TestingImagine if you got a new toy, but some of the pieces were missing or it didn't work quite right. That would be pretty disappointing, right? Well, the same thing can happen with apps and computer programs if they aren't tested thoroughly. That's why testing is such an important step in creating task management apps.During the testing phase, a team of people called testers will try out every single feature and function of the app. They'll check to see if tasks can be added and removed correctly, if due dates and reminders work as intended, and if the app is easy to use and understand. If they find any issues or bugs (problems with the app), they'll report it to the developers (the people who built the app) so they can fix it before the app is released to everyone.It's like having a group of kids test out a new toy before it hits the shelves – they'll make sure it's fun, safe, and works properly so that when other kids get to play with it, they'll have an awesome experience!The Testing ProcessSo, how does this testing process work? Well, it usually involves several stages:Unit TestingThis is where individual parts or "units" of the app are tested separately. It's like testing each piece of a puzzle to make sure it's cut correctly before trying to put the whole thing together.Integration TestingAfter the individual units have been tested, it's time to see how they work together. This is called integration testing. It'skind of like building a model airplane – you need to make sure all the parts fit together properly before you can take it for a test flight.System TestingNow it's time to test the entire app as a whole system. This is where the testers will try out every single feature and function, just like they would if they were regular users. It's like taking that model airplane out to the park and seeing how it flies!User Acceptance TestingFinally, the app is tested by real users to make sure it meets their needs and expectations. This is called user acceptance testing. It's like letting a group of kids play with that new toy and giving their honest feedback before it's mass-produced.Throughout this process, the testers will document any issues they find, and the developers will work to fix those bugs or make improvements based on the feedback.Q&A Time!Now that you know all about the testing process, let's address some common questions and concerns that might come up:Q: What if the testers find a lot of bugs? Does that mean the app is bad?A: Not necessarily! Finding bugs is actually a good thing because it means the testers are doing their job properly. The more bugs they find during testing, the better the app will be after they're fixed.Q: Why does testing take so long? Can't they just skip it?A: Testing is a crucial step that can't be rushed or skipped. It might seem like it takes a while, but it's better to take the time to make sure everything works perfectly than to release an app with a bunch of issues.Q: What if the app still has some bugs after it's released?A: Even after extensive testing, it's possible for some bugs to slip through unnoticed. That's why app developers often release updates and patches to fix any issues that come up after the initial release.Q: Can I be a tester too?A: Absolutely! While professional testers are trained to find and document bugs, many app developers also invite regular users to participate in beta testing (testing an app before it'sofficially released). This allows them to get feedback from their target audience.Q: What if I have an idea for a new feature?A: That's great! App developers love hearing feedback and suggestions from users. Many task management apps have forums or channels where users can submit ideas for new features or improvements. Who knows, your idea might make it into the next update!Well, there you have it – a behind-the-scenes look at the testing and development process for task management apps. It might seem like a lot of work, but it's all to ensure that these apps are as useful, functional, and bug-free as possible. So the next time you're using a task management app to keep track of your chores or homework assignments, remember all the effort that went into making it a reliable and user-friendly tool!篇2Title: Fun with Task Management and Testing!Hi everyone! Today I want to tell you all about this really cool thing called Task Management. It's a special way to keep track ofall the different things you need to do, kind of like a big to-do list but even better!You see, when you have a lot of tasks or chores or homework assignments, it can get really confusing and messy trying to remember everything. That's where Task Management comes in - it helps you organize all your tasks in one place so you don't forget anything important.There are these awesome computer programs called Task Management apps that make it super easy. You can write down all your tasks, give them names like "Clean my room" or "Do math homework", and even set reminders so the app will notify you when it's time to do that task.But here's the really cool part - before these apps get released to everyone, they have to go through something called testing. Testing is like a big check-up to make sure the app is working properly and doesn't have any bugs or problems.There are special people called testers whose job is to test out these apps and find any issues. They'll try out all the different features, like adding tasks, setting reminders, marking tasks as completed and so on. If they find something that isn't working right, they'll report it to the developers.Developers are like the engineers who build the apps. When the testers report a problem, the developers try to fix it by changing some of the code that makes the app run.Once the developers fix the issues found during testing, the app gets tested again to make sure everything is working smoothly now. This back-and-forth between testing and fixing happens many times until the app is ready for everyone to use!Sometimes, even after an app is released, people might find some problems or have questions about how to use certain features. That's when the developers open a Q&A (Questions and Answers) section.People can ask their questions there, and the developers do their best to answer and explain things clearly. If there are any problems with the app, the developers can work on fixing them based on the feedback from users.Isn't that so cool? All these smart people working together to make great apps that help us all stay organized and on top of our tasks! Testing is really important to catch any bugs before the apps go out to everyone.And having a Q&A section allows the developers to keep making the apps better and better based on what people need.Task management itself is super handy for us kids to use for keeping track of homework, chores, activities and more!Well, that's all I wanted to share about the fun world of task management, testing and development Q&A. Stay organized, test thoroughly, ask lots of questions and most importantly, have fun! Let me know if you have any other questions!篇3Task Management is Super Cool!Hi friends! Today I'm going to tell you all about Task Management and how awesome it is. Task Management helps you keep track of all the things you need to do, like homework, chores, and activities. It's like having your very own personal assistant reminding you of everything so you never forget!But first, what even is Task Management? It's a special feature or program that lets you make lists of tasks or things you need to get done. You can add new tasks, check them off when completed, and even set reminders so you don't miss anything important. Pretty neat, right?Testing the Task Management FeatureBefore any new app, website, or program can be released, it has to go through a lot of testing to make sure everything works perfectly. The developers (those are the people who build and code the programs) have to test the Task Management feature very carefully.They check if you can easily add new tasks, make sure reminders go off at the right times, and test that checking off completed tasks works smoothly. It's kind of like when your teacher checks your homework - they need to make sure you did everything right before giving you a gold star!The testers also have to check that the Task Management feature works great on different devices like phones, tablets, and computers. They try adding tasks on a tiny phone screen and a huge computer monitor to ensure it looks and functions awesomely everywhere.If any bugs or issues are found during testing, the developers have to fix them before the feature can be released. Bugs are like the program having a cold - it doesn't work properly until the bug is squashed! The testers keep testing until everything is perfect.Answering Your Task Management QuestionsEven after Task Management is released, the developers still have to answer questions from users who run into any confusion or problems. Let's go through some common questions:Q: How do I add a new task?A: Usually there is a "Add Task" button or you can type your task into a box and hit enter. Give your task a name like "Do math homework".Q: Can I set a due date or reminder?A: Yes! Most task managers let you pick a due date and set a reminder alert for when that task needs to be done. The reminder might pop up or your phone/computer could ping you.Q: How do I mark a task as completed?A: There is typically a checkbox next to each task that you can click or tap to check it off once that task is finished. Completed tasks usually get crossed out or moved to a "Done" list.Q: Can I organize my tasks into different lists or categories?A: Absolutely! You can usually create multiple lists for things like "School", "Chores", "Sports" etc. This keeps everything nicely organized.Q: What if I accidently delete a task I didn't mean to?A: Don't worry, most task managers have an Undo button or let you retrieve deleted tasks from a bin. As long as you act quickly, your task can be restored!Q: Is there a way to share my tasks with my family or friends?A: Yes, many apps let you share access to your task lists so your family can see what you need to do. This helps Mom and Dad keep track too!Those are just some of the common questions about using Task Management features. If you ever get stuck, ask a grown up for help or check the instructions for your specific app. Managing tasks takes practice but is a super useful skill!I hope this gives you a better understanding of how Task Management works and why it's so important to carefully test it before releasing any new updates or improvements. Staying organized and on top of your tasks helps you get so much more done! Let me know if you have any other questions.篇4Task Management: A Fun Adventure for Young Learners!Hey there, young explorers! Are you ready to embark on an exciting journey into the world of task management? Get ready to learn about this fascinating topic in a way that'll make you feel like you're on the coolest adventure ever!Imagine you're a brave adventurer setting out on a quest to conquer a vast and mysterious land. Just like any great explorer, you need to plan your journey carefully, organize your supplies, and keep track of all the tasks you need to complete along the way. That's where task management comes into play!Task management is like having a trusty map and asuper-cool checklist to guide you through your adventure. It helps you stay organized, focused, and on top of all the things you need to do. Without it, you might end up feeling lost and overwhelmed, kind of like wandering aimlessly through a dense jungle without any idea where you're going!Now, let's talk about testing and development – the secret weapons that help make task management tools even more awesome! Think of it like this: imagine you're an inventor creating a brand-new gadget to help you on your quest. You wouldn't want to set out with a gadget that hasn't been properly tested and fine-tuned, would you? That's where testing comes in!Testing is like putting your gadget through a series of challenges to make sure it works perfectly. It's like taking your invention on a practice run to see if it can handle all the obstacles and challenges you might face on your real adventure. By testing your task management tool, you can make sure it's reliable, user-friendly, and has all the features you need to stay on top of your tasks.But wait, there's more! Development is like having a team of brilliant inventors constantly improving and upgrading your gadget. They listen to your feedback, fix any issues you encounter, and add cool new features to make your task management tool even more powerful and convenient.Imagine having a team of experts working behind the scenes to make sure your task management tool is always up-to-date, easy to use, and packed with the latest and greatest features. It's like having a secret squad of gadget geniuses on your side, making sure you have the best tools for your adventure!Now, you might be wondering, "But how do these experts know what to improve or fix?" That's where the Q&A part comes in! Q&A stands for "Questions and Answers," and it's like having a direct line of communication with the inventors themselves.Whenever you have a question, concern, or suggestion about your task management tool, you can simply ask the experts. They'll listen carefully, answer your questions, and use your feedback to make the tool even better. It's like having a team of advisors who are always ready to help you out and make sure your adventure goes as smoothly as possible.So, what do you think, young adventurers? Are you ready to embrace the power of task management, testing, development, and Q&A? With these amazing tools and resources at your disposal, you'll be unstoppable! Just remember to stay organized, ask questions when you need help, and most importantly, have fun on your quest!篇5Sure! Here's a 1000-word article written in English, using a language suitable for a primary school student:Task Management Feature: Testing and Development Q&AHello, everyone! Today, we are going to talk about the cool new feature called "Task Management" that we have been working on. It's a helpful tool that helps us organize our tasks and get things done in a smart and fun way! In this article, we'llexplore how this feature is tested and developed. Let's get started!Testing the Task Management FeatureBefore we release a new feature, like Task Management, we have to make sure it works perfectly and doesn't have any bugs or problems. That's where testing comes in! Our team of testers carefully checks every little detail to ensure everything is just right.Functionality Testing:First, we check if the basic functions of the Task Management feature are working properly. Can we add tasks? Can we mark them as completed? Can we set deadlines? All these things are tested to make sure they work smoothly.User Interface (UI) Testing:The Task Management feature should be easy to use and understand. So, we test the buttons, icons, and menus to ensure they are clear and user-friendly. We want even the youngest users to be able to use it without any trouble!Compatibility Testing:Our team also tests the feature on different devices, like computers, tablets, and smartphones. We want to make sure it works well on all of them. So, whether you're using a big computer or a tiny phone, the Task Management feature should look great and work perfectly!Error Handling Testing:Sometimes, things can go wrong. So, we intentionally try to make mistakes while using the feature. We check if error messages appear when they should and if the feature can recover from those errors. This way, we make sure the Task Management feature is smart enough to handle any problems that may come up.Development Q&ANow, let's move on to some common questions about the development of the Task Management feature. Here are a few questions you might have:Q: How long did it take to develop the Task Management feature?A: Developing a new feature like Task Management takes time. It involves a lot of planning, designing, and coding. Ourteam of talented developers worked hard for several months to create this feature just for you!Q: Why did you decide to add a Task Management feature?A: We understand that managing tasks can sometimes be tricky, especially for students like you who have lots of things to do. So, we thought it would be great to have a feature that helps you stay organized and complete your tasks easily. We want to make your life a little bit easier and more fun!Q: Can we suggest new features for the Task Management module?A: Absolutely! We love hearing from our users, especially smart and creative students like you. If you have any ideas or suggestions for improving the Task Management feature or any other part of our app, please let us know. Your feedback is important to us!That's all for today, my young friends! We hope you enjoyed learning about the testing and development of the Task Management feature. Remember, staying organized and managing your tasks can make a big difference in your life. So, keep using the Task Management feature and make the most of it. Have a fantastic day!*Note: This article is written in a simplified language suitable for primary school students.篇6Task Management: The Fun Way to Stay Organized!Hey there, kids! Are you always forgetting to do your chores or homework? Do you struggle to keep track of all the things you need to do? Well, worry no more! Today, we're going to talk about a super cool feature called Task Management, which is like having your own personal assistant to help you stay on top of everything.Imagine you have a special notebook where you can write down all the tasks you need to complete. But wait, it gets even better! This notebook is actually a computer program that can remind you when things are due, help you prioritize your tasks, and even let you know when you've completed something. Isn't that amazing?Now, let's talk about how this Task Management feature works and how we can test it to make sure it's working properly. You see, before we can start using it, we need to make sure it doesn't have any bugs or problems. That's where testing comes in!Testing is like playing a game of "catch the mistake." We give the Task Management feature different tasks and scenarios to see how it reacts. If it does everything correctly, we give it a big thumbs up! But if it makes a mistake or behaves weirdly, we have to investigate and fix the problem.For example, we might test what happens when you add a new task to your list. Does it show up correctly? What if you have a task due today? Does the program remind you about it? We also need to check if you can mark a task as completed and if it disappears from your list once you've done it.But testing isn't just about checking for mistakes. It's also about making sure the Task Management feature is easy to use and understand. We want it to be simple enough for even the youngest kids to be able to use it without getting confused.So, we might ask some of you to try using the feature and give us feedback. If you find something confusing or difficult, we'll make changes to make it more user-friendly. After all, the whole point of Task Management is to make your life easier, not harder!Now, you might be wondering, "But what if I have a question or run into a problem while using the Task Management feature?" Well, that's where the Q&A part comes in!Whenever you have a question or need help, you can ask the developers (the people who created the Task Management feature) for assistance. They'll be happy to answer your questions and help you solve any problems you might be having.Maybe you're not sure how to add a recurring task, like "Feed the dog every morning." Or perhaps you want to know if you can set reminders for your tasks. Whatever it is, just ask, and the developers will do their best to help you out.But don't worry; you won't have to wait forever for an answer. The developers are dedicated to responding to your questions as quickly as possible. They know how important it is for you to be able to use the Task Management feature without any hiccups.So, there you have it, kids! The Task Management feature is like having a magical assistant to help you stay organized and on top of all your tasks. And with the testing and Q&A process, you can be sure that it's going to work smoothly and be easy to use.Now, go forth and conquer those to-do lists! With Task Management by your side, you'll never forget a homework assignment or chore again. Happy organizing!。

软件编程英文作文

软件编程英文作文下载温馨提示:该文档是我店铺精心编制而成，希望大家下载以后，能够帮助大家解决实际的问题。

文档下载后可定制随意修改，请根据实际需要进行相应的调整和使用，谢谢!并且，本店铺为大家提供各种各样类型的实用资料，如教育随笔、日记赏析、句子摘抄、古诗大全、经典美文、话题作文、工作总结、词语解析、文案摘录、其他资料等等，如想了解不同资料格式和写法，敬请关注!Download tips: This document is carefully compiled by theeditor. I hope that after you download them,they can help yousolve practical problems. The document can be customized andmodified after downloading,please adjust and use it according toactual needs, thank you!In addition, our shop provides you with various types ofpractical materials,such as educational essays, diaryappreciation,sentence excerpts,ancient poems,classic articles,topic composition,work summary,word parsing,copyexcerpts,other materials and so on,want to know different data formats andwriting methods,please pay attention!Software Programming。

Programming is like solving puzzles. It's a creative process that requires logical thinking and problem-solving skills. When you write code, you're essentially giving instructions to a computer to perform specific tasks. It's like speaking a different language, a language that only computers understand.In the world of programming, there are different languages to choose from. Each language has its own syntax and rules. Some are easier to learn, while others are more complex. But no matter which language you choose, the goal is the same: to create software that is efficient and functional.One of the most important aspects of programming is debugging. Debugging is the process of finding and fixing errors in your code. It can be frustrating at times, butit's also a valuable learning experience. Debugging teaches you to think critically and to be patient. It's like being a detective, searching for clues and solving mysteries.Another important skill in programming is problem-solving. As a programmer, you'll encounter all sorts of problems, from simple bugs to complex algorithms. You'll need to break down the problem into smaller, manageable parts and come up with a solution. It's like solving a puzzle, where each piece fits together to form a complete picture.Programming is not just about writing code. It's also about collaboration and teamwork. In a software development project, you'll often work with a team of programmers, designers, and testers. Communication is key to ensure that everyone is on the same page and working towards the same goal. It's like being part of a well-oiled machine, where each part plays a crucial role in the overall success.Continuous learning is essential in programming. Technology is constantly evolving, and new programminglanguages and frameworks are being developed all the time. To stay relevant, you need to keep up with the latest trends and updates. It's like being a lifelong student, always eager to learn and improve your skills.In conclusion, software programming is a fascinating field that requires creativity, logical thinking, and problem-solving skills. It's like solving puzzles, debugging errors, and collaborating with a team. It's a continuous learning process that challenges you to think critically and adapt to new technologies. So, if you're interested in technology and enjoy solving problems, programming might just be the perfect career for you.。

基于规则过滤的改进静态分析技术

基于规则过滤的改进静态分析技术齐钧;陈灯【摘要】Based on rule-based static analysis tools, an optimized rule-checking algorithm was proposed to improve their performance.This work was based on the observation that a source file generally contains limited types of vulnerabilities.There-fore, performance can be improved by filtering rules according to their characteristic parative experiments were con-ducted against an open source static analysis tool PMD.Experimental results show that the proposed technique outperforms PMD by 28.7%in average.%针对主流的基于规则的静态分析工具，提出了一种快速的规则检查方法。

由于一个代码文件通常只包含有限类型的程序缺陷，根据规则的特征对象对待匹配的规则进行过滤，可以极大地提高静态分析的效率。

在开源静态分析工具PMD上进行了技术实现并开展了相关对比实验，实验结果表明，该方法较PMD方法效率平均提升了28．7％。

【期刊名称】《武汉理工大学学报（信息与管理工程版）》【年(卷),期】2015(000)005【总页数】4页(P585-588)【关键词】静态分析;软件质量;软件验证;性能改进【作者】齐钧;陈灯【作者单位】武汉数字工程研究所，湖北武汉 430205;武汉工程大学智能机器人湖北省重点实验室，湖北武汉 430205【正文语种】中文【中图分类】TP311.5静态分析是一种重要的软件质量保障技术。

高三英语学术研究方法创新思路探讨单选题30题及答案

高三英语学术研究方法创新思路探讨单选题30题及答案1. In academic research, a hypothesis is a(n) _____.A. proven factB. educated guessC. random thoughtD. unimportant idea答案：B。

在学术研究中，假设是有根据的推测。

选项A，假设不是已被证实的事实；选项C，假设不是随机的想法；选项D，假设在学术研究中很重要，不是不重要的想法。

2. A research question in academic studies should be _____.A. broad and vagueB. narrow and specificC. unanswerableD. unrelated to the topic答案：B。

学术研究中的研究问题应该是具体且有针对性的。

选项A，宽泛和模糊的问题不利于深入研究；选项C，无法回答的问题没有研究价值；选项D，与主题无关的问题不符合要求。

3. In academic research, data collection is often done through _____.A. guessingB. imaginationC. observation and surveysD. making assumptions答案：C。

在学术研究中，数据收集通常通过观察和调查进行。

选项A，猜测不能用于数据收集；选项B，想象不能作为数据收集的方法；选项D，做假设不是数据收集的方法。

4. A literature review in academic research is mainly to _____.A. show off one's knowledgeB. find existing research on the topicC. fill up pagesD. repeat what others have said答案：B。

怀疑真理的英语作文

怀疑真理的英语作文Title: Questioning Truth。

In the pursuit of understanding, we often findourselves standing at the crossroads of certainty and doubt, grappling with the elusive nature of truth. The human intellect, insatiable in its quest for knowledge,perpetually questions the validity of what is presented as truth. This perpetual questioning forms the cornerstone of intellectual growth and societal progress.At the heart of skepticism lies the recognition that truth is not a fixed entity but rather a dynamic concept, subject to interpretation and revision. From the philosophical inquiries of ancient thinkers to thescientific revolutions of modern times, humanity has continuously challenged established truths, unearthinglayers of complexity and nuance beneath the surface.One of the fundamental aspects of doubting truth is theacknowledgment of inherent biases and limitations in human perception and cognition. Our understanding of reality is filtered through the lens of our experiences, beliefs, and cultural upbringing, shaping the way we interpretinformation and discern truth from falsehood. This realization compels us to approach knowledge with humility, recognizing that our grasp of truth is always partial and subject to refinement.Furthermore, the very nature of truth itself is multifaceted, comprising subjective, objective, and intersubjective elements. While empirical evidence and logical reasoning provide a foundation for objective truths, subjective truths are deeply personal, influenced by individual perspectives and emotions. Intersubjective truths, on the other hand, emerge from shared experiences and collective agreements within societies.In contemporary society, the proliferation ofinformation through various media platforms has amplified the challenge of discerning truth from misinformation. The rise of fake news, echo chambers, and algorithmic biaseshas fueled skepticism towards the veracity of information presented to us. In such a landscape, critical thinking becomes indispensable, empowering individuals to question, analyze, and verify the information they encounter.Moreover, the quest for truth often entails grappling with paradoxes and ambiguities that defy easy resolution. The realm of metaphysics, ethics, and existential inquiries delves into questions that transcend empirical observation, prompting us to confront the limits of human understanding. It is in these existential quandaries that we find the most profound insights into the nature of truth and reality.Despite the inherent challenges and uncertainties surrounding the concept of truth, the act of questioning serves as a catalyst for intellectual growth and societal progress. By challenging entrenched beliefs and ideologies, we pave the way for innovation, tolerance, and greater social cohesion. Embracing doubt as a precursor to enlightenment, we embark on a perpetual journey towards deeper understanding and wisdom.In conclusion, skepticism towards truth is not a sign of ignorance but rather a testament to the richness of human intellect and curiosity. By questioning the veracity of what is presented as truth, we engage in a dialogue that transcends boundaries and fosters a more nuanced appreciation of reality. In the pursuit of truth, let us remain vigilant, humble, and open-minded, for it is through doubt that we inch closer towards the elusive essence of truth itself.。

威学教育托福听力TPO1-34分类整理及难度汇总

TPO25 L1 biology strategies to help extinct species survive
TPO25 L2 art history a composer's experience and style in his lifetime
TPO25 L3 art history the process to decipher the hieroglyphic writing in ancient Egypt
Hale Waihona Puke TPO30 L3 astronomy discoveries about whether life existed on Mars
TPO30 L4 art history the evolution of electric guitar
TPO31 L1 art history the ancient Greek's attitude towards music
TPO27 L4 art the theory of primary colors
TPO28 L1 philosophy the theory of foundationalism in philosophy
TPO28 L2 biology birds' ability to recognize themselves in the mirror
TPO32 L4 art an architecturer and her style
TPO33 L1 art theories explaining the construction of the Great Pyramid
TPO33 L2 env science water distribution of the Colorado River

A Machine Learning Approach to Finding Bugs

A Machine Learning Approach to Finding BugsFancong ZengDepartment of Computer ScienceRutgers UniversityPiscataway,NJ,08854fzeng@ABSTRACTRecently a number of tools have been developed forﬁnding bugs in programs without executing the programs.While these tools are helpful,they often report too many false alarms,false negatives or both.This paper does not present any new such tools.Rather,it is focused on providing a ma-chine learning approach for integrating existing bugﬁnding tools into a practical and adaptive toolset.1.INTRODUCTIONIt is desirable toﬁnd bugs in large programs without actu-ally executing these programs.Recently diﬀerent research groups have developed a number of bugﬁnding tools using various static analysis techniques such as model checking, theorem proving and dataﬂow analyses.[8]compares some of these tools and reports some initial yet interestingﬁndings.Unlike the methodology used in[8], I examine some bugﬁnding tools in the context of testing and debugging processes.These processes have several im-portant properties.One of these properties is that static bug-ﬁnding tools are expected toﬁnd bugs which are diﬃcult to be caught by traditional test cases,e.g.,security vulnerability and timing-related bugs like deadlocks.Another is that software testers ﬁnd and report bugs using these bugﬁnding tools among others and software developers introduce andﬁx bugs.Yet another is that there are(human resource)costs associated toﬁnding andﬁxing bugs.Thus it is important for testers not to report to developers too many false alarms regarding hard-to-catch bugs.It is also important that the bugﬁnding tools do help shake out some hard-to-catch bugs.To acheive the above two goals,there should be a good way to use the static bug-ﬁnding tools.Suppose each bugﬁnding tool is considered as an expert,the problem of utilizing mul-Proceedings of MASPLAS’05Mid-Atlantic Student Workshop on Programming Languages and Systems University of Delaware,April30,2005tiple tools can be reduced to the problem of“predicting with expert advice”,a well-known machine learning problem[3].In this paper,I formulate a variant of the“predicting with expert advice”problem and devise a practical solution to it, so that software engineers can follow this solution in their everyday bugﬁnding andﬁx activities.Outline The rest of the paper is organized as follows.Sec-tion2introduces some popular bugﬁnding tools via static checking and uses a deadlocked Java program to show the imperfection of these tools.Section3deﬁnes a variant of the “predicting with expert advice”problem with each bugﬁnd-ing tool as an expert.Section4presents a practical solution to the problem.Section5discusses the solution.Section6 consludes the paper.Section7lists the references.2.BACKGROUNDIn this section,I brieﬂy describe three well-known static tools and then use a simple deadlocked Java program to demonstrate the usage and limits of these tools.Deadlocks are a timing-related bug which is diﬃcult to catch and re-peat.2.1Three ToolsESC/Java This tool uses a theorem prover to verify that code matches speciﬁcations.Generally programmers supply speciﬁcations in terms of annotations to the source code.In some cases,programmers do not need to specify annotations and ESC/Java checks some default properties like deadlocks[5].JLint This tool operates on bytecode and exploits inter-procedural dataﬂow analysis and some syntactical checks to ﬁnd bugs and coding pitfalls.In particular,Jlint builds a lock graph and signals deadlock warnings if there is a cycle in the graph[1].FindBugs This tool works at the bytecode level and relies on bug patterns toﬁnd bugs.It favours eﬃcient analyses, so it does not use expensive inter-procedural dataﬂow analy-ses.Consequently,FindBugs does not report deadlocks ef-fectively[7].2.2Deadlock DetectionFigure1shows a simple deadlocked Java program.This program simulates money transfer between accounts.There 4.1import java.util.Random;public class Transfer {public static final int NumberOfAccounts= 20;public static final int InitialFund= 1000;public static final int MaxFund= 1000000;public static final int NumberOfThreads= 10;private static Object[] Accounts= new Object[NumberOfAccounts];private static long[] balance = new long[NumberOfAccounts];public static void main(String[] a) {for (int i=0; i<NumberOfAccounts; i++) {balance[i] = InitialFund; Accounts[i] = new Object(); }for (int i=0; i<NumberOfThreads; i++){TransferThread trans = new TransferThread();new Thread(trans).start(); }}public static boolean doTransfer(int f, int t, int a) {synchronized (Accounts[f]) {synchronized (Accounts[t]) {if (balance[f] < a){System.out.println("Transcation Aborted: insufficient fund.");return false;}if (balance[t] + a > MaxFund){System.out.println("Transcation Aborted: too much fund.");return false; }balance[f] -= a;balance[t] += a;System.out.println("Transcation Completed: transferred "+a+" dollars from "+f+" to "+t);}}return true;}public static class TransferThread implements Runnable{public synchronized void run() {while (true) {int fund = Math.abs(new Random().nextInt()) % InitialFund;int source = Math.abs(new Random().nextInt())% NumberOfAccounts;int dest= 0;do { dest= Math.abs(new Random().nextInt())% NumberOfAccounts; }while (dest== source) ;doTransfer(source, dest, fund);} } } }Figure1:A simple deadlocked Java programare twenty accounts and ten threads.Given any two dif-ferent accounts,a thread is used to transfer money from one account to the other.For the transfer to begin,the thread has to acquire the locks for both accounts.In the program showed in Figure1,deadlock occurs when two or more threads are involved in a cyclic wait for locks. FindBugs does not have expensive analyses to support static deadlock detection,so it cannot detect the deadlock in the program.On the other hand,JLint and ESC/Java report some warnings for this deadlock problem.If the“if(balance[f]<a)”block were moved to the place between the two synchronized statements,there would still be a deadlock problem in the code,but in this case Jlint would not report a warning.This is a false negative example. If the doTransfer method were synchronized,then there would not be any deadlock problem.But in this case,both Jlint and ESC/Java would still report a deadlock warning.This is a false positive example.Actually,without the aid of annotations,ESC/Java oftenproduces too many false positives of deadlocks so that by default it does not report deadlock warnings.For the study,I turned on theﬂag to have ESC/Java report deadlock warn-ings.The above example illustrates that static bug-ﬁnding tools are helpful but they suﬀer from false alarms,false negatives, or both.3.PROBLEMConsequently,there are a lot of question-marks regarding using these tools to helpﬁnd and remove hard-to-catch bugs in practice.Example questions are:suppose a tool reportsa warning about a deadlock in a large program,should thetester report the problem to the developer or not?How should the developer deal with the report?Should the de-veloper spend timeﬁnding the root cause of the reported deadlock which may be just a false positive?Should the tester push the developer to remove the potential deadlock?To address the above questions,Iﬁrst formulate a problem for using these tools.Suppose there are N tools,each of the N tools is considered as an expert.The tester can also be considered as an expert.The problem of using these tools can be formulated as an variant of the“Predicting with Expert Advice”problem.Speciﬁcally,whenever the tester is given a bug type and a code region,he gets each expert to report“yes”or“no”to the question whether the code region contains an instance of this bug type.Suppose at least one expert says“yes”,a predictor uses the N(or N+1if the tester also considershimself an expert)expert outputs to make its own prediction of“yes”or“no.”Then,under some conditions,the tester pushes the developer to debug and to get back to him witha true answer w.r.t.whether the code region contains thebug.To be general,I make no assumption of the independence or the quality of the tools.Thus,it is infeasible to achieve absolute quality in the prediction.Instead,a practical goal that the predictor performs nearly as well as the best tool so far.I use the number of mistakes made so far to compare the performance,and I denote this goal as the Testing Goal.This goal is reasonable because in practice given a collection of tools we generally do not know which tool is the best.Furthermore,it is often the case that diﬀerent tools perform best for diﬀerent bug types.Another practical goal is that the tester pushes the developer to do the debugging work at a reasonable rate,which is called debug rate in the rest of the paper.I denote this goal as the Debugging Goal,and this goal is to strike a good balance between real bugﬁxing and wasted eﬀorts.Note that the Testing Goal and the Debugging Goal are related.In addition to solving the“Predicting with Expert Advice”problem,the next section will examine the relation between the two goals.4.SOLUTIONThere are many algorithms to solve a“Predicting with Ex-pert Advice”problem.For the problem I formulated in the 4.2previous section,I devise a solution inspired by and based on an algorithm described in[4]for the problem.For every bug type,the tester uses an implementation of the following procedure to report warning for bugs of that type and to push the developers to debug.The procedure exploits N tools,uses two parameters:η>0and0≤ ≤1, and initialize the weights of all experts at round1,denoted as W1=(W1,1,...,W N,1),to vector1.For each round t=1,2,...1.Apply the set of N tools to code region C t,and get anoutput I t=(I1,t,I2,t,...,I N,t),where I i,t=“Yes”or “No”.“Yes”means that there is a bug warning for C t.2.if I t does not contain a“yes”,then let W t+1=W t andgo to the next round.Otherwise the predictor outputsI i,t with probability W i,t/NW j,t,i=1,...,N.j=13.Draw a Bernoulli random variableΓt s.t.P[Γt=1]=.4.IfΓt=0,then let W t+1=W t,and go to the nextround.Otherwise push the developer toﬁgure out whether there is a bug in C t and to remove the bug if it does exist.e R t to denote the answer given back by the devel-oper,and assume R t is correct.If R t=I i,t,then set W i,t+1to W i,t,else set W i,t+1to W i,t e−η/ .Go to the next round.One nice property of the above procedure is:Fix n>0,the number of times that not all tools say“no”.√Let =m/n andη=(2lnN/m.The above2claims can be proved by adapting the proof of Theorem1in[4].Furthermore,[6]shows that the optimal result of E[M P,n−√M B,n]isΘ(。

1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。

Finding Bugs is Easy∗David Hovemeyer and William Pugh Dept.of Computer Science,University of Maryland College Park,Maryland20742USA{daveho,pugh}@ABSTRACTMany techniques have been developed over the years to au-tomaticallyﬁnd bugs in software.Often,these techniques rely on formal methods and sophisticated program analysis. While these techniques are valuable,they can be diﬃcult to apply,and they aren’t always eﬀective inﬁnding real bugs. Bug patterns are code idioms that are often errors.We have implemented automatic detectors for a variety of bug patterns found in Java programs.In this paper,we describe how we have used bug pattern detectors toﬁnd serious bugs in several widely used Java applications and libraries.We have found that the eﬀort required to implement a bug pat-tern detector tends to be low,and that even extremely sim-ple detectorsﬁnd bugs in real applications.From our experience applying bug pattern detectors to real programs,we have drawn several interesting conclu-sions.First,we have found that even well tested code writ-ten by experts contains a surprising number of obvious bugs. Second,Java(and similar languages)have many language features and APIs which are prone to misuse.Finally,that simple automatic techniques can be eﬀective at countering the impact of both ordinary mistakes and misunderstood language features.1.INTRODUCTIONFew people who develop or use software will need to be convinced that bugs are a serious problem.Automatic tech-niques and tools forﬁnding bugs oﬀer tremendous promise for improving software quality.In recent years,much re-search has investigated automatic techniques toﬁnd bugs in software(e.g.,[11,24,28,46,6,9,44,29,22]).Some of the techniques proposed in this research require sophisticated program analysis.This research is valuable,and many in-teresting and useful analysis techniques have been proposed as a result.However,these techniques have generally not found their way into widespread use.In our work,we have investigated simple static analysis techniques forﬁnding bugs based on the notion of bug pat-terns.A bug pattern is a code idiom that is likely to be an error.Occurrences of bug patterns are places where code does not follow usual correct practice in the use of a language Supported by NSF grant CCR-0098162and by an IBMEclipse Innovation award.Copyright is held by the author/owner.OOPSLA’04,Oct.24-28,2004,Vancouver,British Columbia,Canada. ACM1-58113-833-4/04/0010.feature or library API.Automatic detectors for many bug patterns can be implemented using relatively simple static analysis techniques.In many ways,using static analysis to ﬁnd occurrences of bug patterns is like an automated code inspection.We have implemented a number of automatic bug pattern detectors in a tool called FindBugs.In this paper,we will describe some of the bug patterns our tool looks for,and present examples of bugs that our tool has found in several widely used applications and libraries. We hope that the obvious and embarrassing nature of these bugs will convince you of the need for wider adoption of au-tomatic bugﬁnding tools.We also present empirical results which classify(for selected bug patterns)the percentage of warnings reported by the tool that indicate real bugs.We will argue that although some of the bug pattern detectors we evaluated produce false warnings,they produce enough genuine examples of bugs to make the tool useful in prac-tice.We have two primary motivations in this work.Theﬁrst is to raise awareness of the large number of easily-detectable bugs that are not caught by traditional quality assurance techniques:we believe that developers who employ rigorous quality assurance practices will be surprised at the number of bugs that elude unit testing and code inspections.The second is to suggest possibilities for future research;specif-ically,that much more work needs to be done onﬁnding ways to integrate automatic bugﬁnding techniques into the development process in a way that best directs developers towards the bugs that are most proﬁtable toﬁx,while not distracting them with irrelevant or inaccurate warnings. The structure of the rest of the paper is as follows.In Section2,we discuss the general problem ofﬁnding bugs in software,and the strengths and weaknesses of various ap-proaches.In Section3,we describe the implementation of FindBugs,our bug checker for Java based on bug patterns. In Section4,we describe some of the bug pattern detectors implemented in FindBugs,and show some examples of bugs they found in several widely used applications and libraries. In Section5,we evaluate the eﬀectiveness of our bug pattern detectors on several real programs.In Section6,we oﬀer observations from our experiences and some of our users’experiences putting bug pattern detection into practice.In Section7we oﬀer some conclusions,and describe possibili-ties for future work.In Section8,we describe related work.2.TECHNIQUES FOR FINDING BUGS There are many possible ways toﬁnd bugs in software. Code inspections can be very eﬀective atﬁnding bugs,buthave the obvious disadvantage of requiring intensive manual eﬀort to apply.In addition,human observers are vulnerable to being inﬂuenced by what a piece of code is intended to do.Automatic techniques have the advantage of relative objectivity.Dynamic techniques,such as testing and assertions,rely on the runtime behavior of a program.This can be both an advantage and a limitation.The advantage is that dynamic techniques,by deﬁnition,do not consider infeasible paths in a program.The disadvantage is that they are generally lim-ited toﬁnding bugs in the program paths that are actually executed.Anyone who has tried to construct a test suite for a program of signiﬁcant complexity knows the diﬃculty of achieving high statement or branch coverage.In addition, the time required to run a full suite of tests can be too great to run frequently.In contrast to dynamic techniques,static techniques can explore abstractions of all possible program behaviors,and thus are not limited by the quality of test cases in order to be eﬀective.Static techniques range in their complexity and their ability to identify or eliminate bugs.The most eﬀec-tive(and complex)static technique for eliminating bugs is a formal proof of correctness.While the existence of a correct-ness proof is perhaps the best guarantee that the program does not contain bugs,the diﬃculty in constructing such a proof is prohibitive for most programs.Partial veriﬁcation techniques have been proposed.These techniques prove that some desired property of a program holds for all possible ex-ecutions.Such techniques may be complete or incomplete; if incomplete,then the analysis may be unable to prove that the desired property holds for some correct programs.Fi-nally,unsound techniques can identify“probable”bugs,but may miss some real bugs and also may emit some inaccurate warnings.2.1Bugs vs.StyleIn discussing the use of automatic tools to check code,it is crucial to distinguish bug checkers from style checkers.A bug checker uses static analysis toﬁnd code that violates a speciﬁc correctness property,and which may cause the pro-gram to misbehave at runtime.A style checker examines code to determine if it contains violations of particular cod-ing style rules.The key value of enforcing coding style rules is that when a consistent style is used throughout a project, it makes it easier for the developers working on the project to understand each other’s code.Some style rules,such as “always put constants on the left hand side of comparisons”, and“don’t use assignment statements in the guard of an if statement”,may help prevent certain kinds of bugs.How-ever,violations of those style guidelines are not particularly likely to be bugs.Another way to think about the distinction between style checkers and bug checkers is that violations of style guide-lines only cause problems for the developers working on the software.Warnings produced by a bug checker may rep-resent bugs that will cause problems for the users of the software.Tools that focus mainly on checking style,such as PMD[38] and CheckStyle[10],are widely used.However,bug check-ers are not nearly as widely used,even though they are more likely to direct developers to speciﬁc real bugs in their code. We believe the reason for this disparity is that more work is required to use the output of bug checkers.Style checkers can be extremely accurate in determining whether or not code adheres to a particular set of style rules.Therefore, little or no judgment is needed to interpret their output, and changing code to adhere to style guidelines has a tan-gible eﬀect on improving the understandability of the code. In contrast,bug checkers,especially ones that use unsound analysis,may produce warnings that are inaccurate or diﬃ-cult to interpret.In addition,ﬁxing bugs reported by a bug checker requires judgment in order to understand the cause of the bug,and toﬁx it without introducing new bugs. Another problem with bug checkers is that the percentage of false warnings tends to increase over time,as the real bugs areﬁxed.Techniques for suppressing false warnings must be used so that developers can concentrate on evaluating and ﬁxing the real problems identiﬁed by the bug checker.We believe that tools based on bug patterns represent a useful sweet spot in the design space for bug checkers, for several reasons.Aside from being easy to implement, they tend to produce output that is easy for programmers to understand.Because they focus onﬁnding deviations from accepted practice,they tend to be very eﬀective atﬁnding real bugs,even though they don’t perform deep analysis. With tuning,they can achieve an acceptably low rate of false warnings.All of these factors contribute to overcoming barriers to wider adoption of bug checkers.3.THE FINDBUGS TOOLIn this section we brieﬂy describe the implementation of the FindBugs tool.FindBugs is open source,and source code,binaries,and documentation may be downloaded from .Currently,FindBugs contains detectors for about50bug patterns.All of the bug pattern detectors are implemented using BCEL[7],an open source bytecode analysis and in-strumentation library.The detectors are implemented using the Visitor design pattern;each detector visits each class of the analyzed library or application.The implementation strategies used by the detectors can be divided into several rough categories:•Class structure and inheritance hierarchy only.Some of the detectors simply look at the structure ofthe analyzed classes without looking at the code.•Linear code scan.These detectors make a linearscan through the bytecode for the methods of analyzedclasses,using the visited instructions to drive a statemachine.These detectors do not make use of completecontrolﬂow information;however,heuristics(such asidentifying the targets of branch instructions)can beeﬀective in approximating controlﬂow.•Control sensitive.These detectors make use of anaccurate controlﬂow graph for analyzed methods.•Dataﬂow.The most complicated detectors use dataﬂow analysis to take both control and dataﬂow into ac-count.An example is the null pointer dereference de-tector.None of the detectors make use of analysis techniques more sophisticated than what might be taught in an under-graduate compiler course.The detectors that use dataﬂow analysis are the most complex;however,we have imple-mented a framework for dataﬂow analysis which moves mostFigure1:Screenshot of FindBugs. of the complexity out of the detectors themselves.The mostcomplex detector has about1000lines of Java source code(including blank lines and comments).Almost half of thedetectors have less than100lines of source code.We have implemented several front ends to FindBugs:•A simple batch application that generates text reports,one line per warning.•A batch application that generates XML reports.•An interactive tool that can be used for browsing warn-ings and associated source code,and annotating the warnings.The interactive tool can read and write the XML reports.A screenshot of the interactive tool is shown in Figure1.We have also developed several tools for manipulating the XML reports.These tools allow us to perform actions such as comparing the diﬀerence in warnings generated on two diﬀerent versions of an application.FindBugs users have contributed two additional front-ends:a plugin that integrates FindBugs into the Eclipse[18] IDE,and a task for running FindBugs from the Apache Ant[2]build tool.4.BUG PATTERN DETECTORSFor space reasons,we will only discuss a handful of the bug pattern detectors implemented in FindBugs.Each bug pattern is identiﬁed by a short“code”,which will be used in the evaluation in Section5.A table summarizing the bug patterns and detectors described in this paper is shown in Figure2.Broadly speaking,each detector falls into one or more of the following categories:•Single-threaded correctness issue•Thread/synchronization correctness issue•Performance issue•Security and vulnerability to malicious untrusted code Code DescriptionCN Cloneable Not Implemented CorrectlyDC Double Checked LockingDE Dropped ExceptionEC Suspicious Equals ComparisonEq Bad Covariant Deﬁnition of EqualsHE Equal Objects Must Have Equal Hashcodes IS2Inconsistent SynchronizationMS Static Field Modiﬁable By Untrusted Code NP Null Pointer DereferenceNS Non-Short-Circuit Boolean OperatorOS Open StreamRCN Redundant Comparison to NullRR Read Return Should Be CheckedRV Return Value Should Be CheckedSe Non-serializable Serializable ClassUR Uninitialized Read In ConstructorUW Unconditional WaitWa Wait Not In LoopFigure2:Summary of selected bug patterns.//jdk1.5.0,build59//javax.sql.rowset.spi,//SyncFactory.java,line325if(syncFactory==null){synchronized(SyncFactory.class){if(syncFactory==null){syncFactory=new SyncFactory();}//end if}//end synchronized block}//end ifFigure3:Example of double checked locking. 4.1Cloneable Not Implemented Correctly(CN) This pattern checks for whether a class implements the Cloneable interface correctly.The most common violation is to not call super.clone(),but rather allocate a new object by invoking a constructor.This means that the class can never be correctly subclassed(and the warning is silenced if the class isﬁnal),since calling clone on a subtype will not return an instance of that subtype1.4.2Double Checked Locking(DC)Double checked locking is a design pattern intended for thread safe lazy initialization[42].An example of double checked locking is shown in Figure3.Unfortunately,the double checked locking pattern assumes a sequentially consistent memory model,which isn’t true in any major programming language.In Figure3it is possible that the writes initializing the SyncFactory object and the write to the syncFactoryﬁeld could be reordered(either by the compiler or the processor).It is now accepted that the double checked locking pattern is broken[39]as originally stated.In Java,it is possible to ﬁx the double checked locking pattern simply by making the checkedﬁeld volatile.4.3Dropped Exception(DE)This detector looks for a try-catch block where the catch block is empty and the exception is slightly discarded.This often indicates a situation where the programmer believes the exception cannot occur.However,if the exception does occur,silently ignoring the exception can create incorrect anomalous behavior that could be very hard to track down.4.4Suspicious Equals Comparison(EC)This detector uses intraprocedural dataﬂow analysis to determine when two objects of types known to be incom-parable are compared using the equals()method.Such comparisons should always return false,and typically arise because the wrong objects are being compared.4.5Bad Covariant Deﬁnition of Equals(Eq) Java classes may override the equals(Object)method to deﬁne a predicate for object equality.This method is used by many of the Java runtime library classes;for example,to implement generic containers.Programmers sometimes mistakenly use the type of their class Foo as the type of the parameter to equals():1Having all clone()methods call super.clone()ensure that they all delegate object creation to Object.clone(), which automatically creates a new object of the correct class.public boolean equals(Foo obj){...}This covariant version of equals()does not override the version in the Object class,which may lead to unexpected behavior at runtime,especially is the class is used with one of the standard collection classes which expect that the stan-dard equals(Object)method is overridden.This kind of bug is insidious because it looks correct,and in circumstances where the class is accessed through refer-ences of the class type(rather than a supertype),it will work correctly.However,theﬁrst time it is used in a container, mysterious behavior will result.For these reasons,this type of bug can elude testing and code inspections.Detecting instances of this bug pattern simply involves examining the method signatures of a class and its super-classes.4.6Equal Objects Must Have Equal Hash-codes(HE)In order for Java objects to be stored in HashMap s and HashSet s,they must implement both the equals(Object) and hashCode()methods.Objects which compare as equal must have the same hashcode.Consider a case where a class overrides equals()but not hashCode().The default implementation of hashCode()in the Object class(which is the ancestor of all Java classes) returns an arbitrary value assigned by the virtual machine. Thus,it is possible for objects of this class to be equal with-out having the same hashcode.Because these objects would likely hash to diﬀerent buckets,it would be possible to have two equal objects in the same hash data structure,which violates the semantics of HashMap and HashSet.As with covariant equals,this kind of bug is hard to spot through inspection.There is nothing to“see”;the mistake lies in what is missing.Because the equals()method is useful independently of hashCode(),it can be diﬃcult for novice Java programmers to understand why they must be deﬁned in a coordinated manner.This illustrates the im-portant role tools can play in educating programmers about subtle language and API semantics issues.Automatically verifying that a given class maintains the invariant that equal objects have equal hashcodes would be very diﬃcult.Our approach is to check for the easy cases, such as•Classes which redeﬁne equals(Object)but inherit the default implementation of hashCode()•Classes which redeﬁne hashCode()but do not redeﬁne equals(Object)Checking for these cases requires simple analysis of method signatures and the class hierarchy.4.7Inconsistent Synchronization(IS2)Many Java classes,both in runtime libraries and appli-cations,are designed to be safe when accessed by multiple threads.The most common way to ensure thread safety is to synchronize on the receiver object(“this”)when accessing or modifying shared state.A common category of mistakes in implementing thread safe objects is to allow access to mutableﬁelds without synchronization.The detector for this bug pattern looks for such errors by analyzing accesses toﬁelds to determine which accesses are made while the object’s lock is held.Fields which are sometimes accessed with the lock held and sometimes without are candidate instances of this bug pat-tern.We use heuristics to reduce the number of false posi-tives:•Publicﬁelds are ignored•Volatileﬁelds are ignored•Fields that are never read without a lock are ignored•Access in methods unlikely to be reached when the object is accessible to multiple threads(e.g.,construc-tors)are ignored•Accesses in nonpublic methods called only from con-texts where the lock is held are treated as lockedWe count the number of reads and writes of aﬁeld per-formed with and without a lock.We report that aﬁeld is inconsistently synchronized if there are some unsynchro-nized accesses to aﬁeld and2(RU+2WU)≤(RL+2WL)and RU+WU≤RL+WLwhere RU and WU are unlocked reads and writes,and RL and WL are locked reads and writes.This formula captures both the idea that most of the accesses should be performed while a lock is held,and that looking at whether a lock is held when a write is performed is often a better indication that the synchronization guarding theﬁeld was intentional rather than incidental.The detector for inconsistent synchronization is one of the more complicated that we have implemented.It uses dataﬂow analysis to determine where locks are held and to determine which objects are locked,since the analysis re-lies on being able to determine when a lock is held on the reference through which aﬁeld is accessed.We perform re-dundant load elimination to determine when a value loaded from aﬁeld is likely to be the same value as that of an ear-lier load of the sameﬁeld;without this analysis,the detector would treat all of the references to x in the following code as diﬀerent objects://x is a fieldsynchronized(x){...=x.f;x.g=...}The detector uses a whole program analysis,sinceﬁelds may be accessed from classes other than the class in which they are deﬁned.The inconsistent synchronization detector is interesting because inferring whether or not a class is intended to be thread-safe in the absence of speciﬁcations is diﬃcult.The detector relies on the fact that synchronizing on the this reference is a common idiom in Java,and uses heuristics to make an educated guess about whether synchronization is intended or incidental.An example of inconsistent synchronization is seen in Fig-ure4.This method is in the Vector class of the GNU Class-path library,version0.08.The Vector class is speciﬁed as being thread safe.Most of the accesses to the class’sﬁelds are protected by synchronizing on the object’s this refer-ence.In the code shown,the elementCountﬁeld is accessed //GNU classpath0.08,//java.util,//Vector.java,line354public int lastIndexOf(Object elem){return lastIndexOf(elem,elementCount-1);}Figure4:Example of inconsistent synchronization. without synchronization.The bug is that because of the lack of synchronization,the element count may not be ac-curate when it is passed to the lastIndexOf(Object,int) method(which is synchronized).This could result in an ArrayIndexOutOfBoundsException.In the development of the FindBugs tool,we have run it regularly on several applications and libraries,tracking new releases of those packages as they are made available.We have noticed that it is fairly common for programmers not to understand the synchronization requirements of classes when they are performing maintenance(toﬁx bugs or add new features),and we have seen a number of synchronization bugs introduced this way.Detectors such as the inconsis-tent synchronization detector can serve as a useful safeguard against the introduction of bugs during code evolution. 4.8Static Field Modiﬁable By Untrusted Code(MS)This problem describes situations where untrusted code is allowed to modify staticﬁelds,thereby modifying the be-havior of the library for all users.There are several possible ways this mutation is allowed:•A static non-ﬁnalﬁeld has public or protected access.•A staticﬁnalﬁeld has public or protected access and references a mutable structure such as an array or Hashtable.•A method returns a reference to a static mutable struc-ture such as an array or Hashtable.For example,Sun’s implementation of java.awt.Cursor has a protected static non-ﬁnalﬁeld predefined that caches references to14predeﬁned cursor types.Untrusted code can extend Cursor and freely modify the contents of this array or even make it point to a diﬀerent array of cursors.This would allow,for example,any applet to change the cursors in a way that would aﬀect all applets displayed by the browser, possibly confusing or misleading the user.Another example is the javax.sql.rowset.spi.SyncProvider class in Sun’s implementation of the core J2SE libraries,which contains 11public static nonﬁnal intﬁelds with names that are all uppercase(which is usually used to denote a staticﬁnal ﬁeld).4.9Null Pointer Dereference(NP),RedundantComparison to Null(RCN)Calling a method or accessing an instanceﬁeld through a null reference results in a NullPointerException at run-time.This detector looks for instructions where a null value might be dereferenced.Our implementation of the detector for this pattern uses a straightforward dataﬂow analysis.The analysis is strictly//Eclipse3.0,//pare,//JavaStructureDiffViewer.java,line131Control c=getControl();if(c==null&&c.isDisposed())return;Figure5:Example of null pointer dereference.//Sun JDK1.5build59,//java.awt,MenuBar.java,line168if(m.parent!=this){add(m);}helpMenu=m;if(m!=null){...Figure6:A redundant null comparison. intraprocedural;it does not try to determine whether pa-rameters to a method could be null,or whether return val-ues of called methods could be null.The detector takes if comparisons into account to make the analysis more precise. For example,in the codeif(foo==null){...}the detector knows that foo is null inside the body of the if statement.Two types of warnings are produced.Null pointer derefer-ences that would be guaranteed to occur given full statement coverage of the method are assigned high priority.Those guaranteed to occur given full branch coverage of the method are assigned medium priority2.An example of a null pointer dereference found by the detector is shown in Figure5.We were surprised toﬁnd that a bug this obvious couldﬁnd its way into a mature, well-tested application.However,this was only one of a signiﬁcant number of similar bugs we found in Eclipse.In addition toﬁnding possible null pointer dereferences, this detector also identiﬁes reference comparisons in which the outcome isﬁxed because either both compared values are null,or one value is null and the other non-null.Although this will not directly result in misbehavior at runtime,it very often indicates confusion on the part of the programmer,and may indicate another error indirectly.(This phenomenon is described in greater detail in[46].)Figure6shows some code from the java.awt.MenuBar class from Sun JDK1.5 build59.Here the code manifests the implicit belief that m is not null,because the parentﬁeld is accessed,and later that it might be null because it is explicitly checked.Be-cause the beliefs contradict,one must be incorrect.In this paper,we only report RCN warnings in which a reference is dereferenced before is it checked for null.4.10Non-Short-Circuit Boolean Operator(NS) Like the equivalent operators in C and C++,the Java &&and||operators have short-circuit evaluation.For this 2Because full branch coverage is often infeasible,some of the medium priority warnings do not indicate real bugs.//Eclipse3.0,//org.eclipse.ui.internal.cheatsheets.views,//CheatSheetPage.java,line83if(cheatSheet!=null&cheatSheet.getTitle()!=null)return cheatSheet.getTitle();Figure7:A non-short-circuit boolean operator bug. reason,they are often used to test a reference value against null,and call a method if the reference is found not to be null.Surprisingly,the non-short-circuiting&and|operators are also deﬁned for boolean values.Programmers may un-intentionally use one of these operators where they intended to use a short-circuiting boolean operator.Because both boolean expressions are evaluated unconditionally,a null pointer exception may result.An example is shown in Fig-ure7;this example would also be caught by the NP pattern, but other cases might result in problems not caught by our existing bug detectors,such as an out of bounds array ref-erence.4.11Open Stream(OS)When a program opens an input or output stream,it is good practice to ensure that the stream is closed when it becomes unreachable.Althoughﬁnalizers ensure that Java I/O streams are automatically closed when they are garbage collected,there is no guarantee that this will happen in a timely manner.There are two reasons why streams should be closed as early as possible.First,operating systemﬁle descriptors are a limited resource,and running out of them may cause the program to misbehave.Another reason is that if a buﬀered output stream is not closed,the data stored in the stream’s buﬀer may never be written to theﬁle(be-cause Javaﬁnalizers are not guaranteed to be run when the program exits).The Open Stream detector looks for input and output stream objects which are created(opened)in a method and are not closed on all paths out of the method.The im-plementation uses dataﬂow analysis to determine all of the instructions reached by the deﬁnitions(creation points)of streams created within methods,and to track the state(nonex-istent,created,open,closed)of those streams.If a stream in the open state reaches the exit block of the controlﬂow graph for a method,we emit a warning.To reduce false positives,we ignore certain kinds of streams. Streams which escape(are passed to a method or assigned to aﬁeld)are ignored.Streams passed into a method or loaded from aﬁeld are ignored,since we assume that other code is responsible for closing those streams.Streams that are known not to correspond to any realﬁle resource,such as byte array streams,are ignored.Finally,any stream tran-sitively constructed from an ignored stream is ignored(since it is common in Java to“wrap”one stream object with an-other).An example of a bug found by this detector is shown in Figure8.The FileReader object is never closed by the method.4.12Read Return Should Be Checked(RR) The java.io.InputStream class has two read()methods which read multiple bytes into a buﬀer.Because the number。