Compiler Design Spring 2017

Transcription

1 Compiler Design Spring Software design Dr. Zoltán Majó Compiler Group Java HotSpot Virtual Machine Oracle Corporation 1

2 Code quality What is quality? All exams have high quality. Student: Exam asks questions that check material on the handout. Lecturer: Exam shows that students can apply material to new problem(s). Dean (head of studies): The results follow normal distribution. Provost: Successful students are great ambassadors for the college. Teaching assistant: Exam was multiple choice (and therefore could be graded while watching soccer). 3

3 Quality Need to identify dimensions Need to define low and high marks Without clarification vague Near term goal: code reviews By students Of students code Why? Code reviews are common Code reviews highly effective to improve software systems Other techniques exist as well 4

4 Code quality First focus: software system artifact Source code Documents External characteristics of software system Visible/noticeable by user Internal characteristics of software system Primarily of interest to developer Other aspects: process, environment, 5

5 External characteristics Boundary to internal characteristics not always strict Dimensions are not always mutually exclusive Correctness: freedom from faults Faults in specification Faults in design Faults in implementation Faults in execution Robustness: ability to handle invalid input Useful error messages May have to include handling of hardware faults 6

6 External characteristics (cont d) Usability Serves its purpose Adaptability: system can be used w/o modifications in other scenarios Interoperates with other systems as designed/specified Integrity: prohibit unauthorized/improper access Traceability: completeness of access traces and/or logs Accuracy: results acceptable with regard to quantitative input Could be considered a correctness issue Reliability: system performs under stated conditions 7

7 Internal characteristics Flexibility: system can be modified (with little or no effort) to be used for unintended environments Reusability: system can be used in another operating environment Readability: source code can be understood 8

8 Readability Numerous factors influence readability Consistent style (formatting) Use of white space Use of indentation Tools can help Rules for names, naming conventions Rules for comments Use of language features Choice of programming language(s) Use of assertions Coding conventions Size of functions Use of exceptions File (project) organization/directory structure 9

9 Readability à Understandability System structure Reflects high-level design Modularity Coherence and cohesion Number of interaction points with other modules Number of parameters Control flow Use of exceptions Control/data plane 10

10 Understandability Level required to comprehend system Classes (structs, records) Class hierarchies Depth Frameworks Patterns 11

11 Internal characteristics (cont d) Maintainability: source code can be modified to address changing requirements Improve performance Improve usability Address correctness and security problems Correct defects as well as react to environment changes Testability: Can you unit test the system? How easy it is to verify that the system meets requirements 13

12 public void HandleStuff(CORP_DATA inputrec, int crntqtr, EMP_DATA emprec, double estimrevenue, double ytdrevenue, int screenx, int screeny, COLOR_TYPE newcolor, COLOR_TYPE prevcolor, StatusType status, int expensetype) { int i; for (i = 0; i < 100; i++) { inputrec.revenue[i] = 0; inputrec.expense[i] = MASTER.corpExpense [crntqtr][i]; } MASTER.UpdateCorporateDatabase( emprec ); estimrevenue += ytdrevenue * 4.0 / (double) crntqtr; newcolor.color = prevcolor.color; status.result = Result.SUCCESS; if ( expensetype == 1) { for (i = 0; i < 12; i++) MASTER.profit[i] = inputrec.revenue[i] - MASTER.expense.type1[i]; } else if ( expensetype == 2) { MASTER.profit[i] = inputrec.revenue[i] - MASTER.expense.type2[i]; } else if ( expensetype == 3) MASTER.profit[i] = inputrec.revenue[i] - MASTER.expense.type3[i]; } Adapted from S. McConnell, Code Complete (2 nd Edition) 15

13 16

14 Comments Internal/external characteristics may overlap Correlated, not independent Often no fixed rule on good design Example: size of functions/methods Example: number of method arguments Texts to consider Steve McConnell: Code Complete: A Practical Handbook of Software Construction, Microsoft Press, George A. Miller: The Magical Number Seven, Plus or Minus Two: Some Limits on Our Capacity for Processing Information, The Psychological Review, 1956, vol. 63, pp (on the web) 23

15 Software quality Goal: design & implementation of software systems with desirable internal and external characteristics Desirable: depends on context and objectives Combinations of characteristics Steps to ensure software quality Identify quality dimensions Set priorities Allow (and discuss) tradeoffs Establish objectives Establish ways to measure quality 24

16 Objectives Many possible dimensions Development time and cost Code length Memory usage Execution speed 25

17 Quality assurance Implicit and explicit quality assurance steps Focus here on explicit steps Guidelines for software construction Software process Follow process Testing strategy Informal reviews Formal reviews External audits 26

18 Informal reviews Objective: catch errors early Misuse of informal reviews Assign blame Staff evaluation Budget control Informal 27

19 Informal reviews (cont d) Kinds of informal reviews 1. Inspection Reviewers look at code Reviewers meet developers, ask questions (person-person interaction) 2. Walk-through Presentation of system Guide tour by developer(s) 3. Code reading Feedback via comment, review Usually done by co-developer 28

20 Informal reviews Execution of system, test cases may be part of the review Emphasis usually on understanding source code 29

21 Inspections Participants with clearly defined roles Some roles mutually exclusive 30

22 Roles Moderator Keeps review going Must be technical person Neither reviewer nor developer Author Developed software system under review May start out review with an overview May answer factual questions (if asked) Explain parts Does not defend decision Do not argue Key is to listen, code should speak for itself 31

23 Roles (cont d) Reviewer(s) Find problems Identify defects Find good features Find good uses Scribe Takes notes Record defects, problems Not a reviewer May also be moderator 32

24 Roles (cont d) Management: Absent from inspection Inspection is for developers Objective is not review of developer performance Number of participants At least three: author, reviewer, moderator Moderator and scribe are the same person Large groups more difficult to manage than small ones 33

25 Preparation Planning Code or design delivered to moderator Moderator selects reviewer(s) Setup Overview by developer Danger: developer directs reviewers Preparation Reading of code/design documents Inspection meeting Inspection report 34

26 Follow up Reports state problems Moderators assign defects for repair May be manager maps requests to developers/authors Another inspection Depends on number and severity of defects Keep logs, collect data Number of defects Size of software system Length of meetings Number of reviewers 35

27 Code inspection Well-defined process Even though process is informal Homework C : Participate in inspection process Review other students code Have your code reviewed Details later (not today) Process presented here: A possible way to organize reviews Other processes used in practice A case study: The OpenJDK review process 36

28 OpenJDK Open Java Development Kit Free and open-source implementation of the Java Platform Java Platform Java Class Library E.g., packages like java.lang, java.io, java.math (Static) Java compiler javac Translate Java programs bytecode instructions for Java Virtual Machine HotSpot Java Virtual Machine Just-in-time compilers C1 and C2 (translate bytecode native code) Interpreter (template-based) Runtime system Garbage collectors 37

29 Quality assurance for OpenJDK Quality important Millions of OpenJDK users worldwide Software quality assurance challenging Large codebase: 7 millions of lines of code (Java, C, C++, assembly) Contributors all around the world In different time zones Both within Oracle and outside Oracle (volunteers, SAP, RedHat, Intel) Well-defined code review process helps ensure software quality Reviews informal: management is excluded Other quality assurance methods used as well Only review process discussed today 38

30 Workflow for OpenJDK reviews Step 1: Author develops and tests new code Usually results in a patch to the existing system Step 2: Author uploads patch to review server cr.openjdk.java.net Webrev 39

31 Webrev 40

32 Cdiff 41

33 Workflow for OpenJDK reviews Step 1: Author develops and tests new code Usually results in a patch to the existing system Step 2: Author uploads patch to review server cr.openjdk.java.net Webrev Step 3: Author sends out request for review to a mailing list E.g., hotspot-compiler-dev@openjdk.java.net Usually includes link to webrev, description of problem and solution, testing performed Step 4: Reviewers inspect code, give feedback If changes required, author updates and tests code, continue with Step 2 Otherwise continue with Step 5 Step 5: Code ( change set ) pushed Either by author or by a sponsor 42

34 Change sets Code annotated with a well-formed description Example : Assert fails in deoptimization due to original PC at the end of code section Summary: Change assert to accept end of code section as well. Reviewed-by: rbackman, kvn, dlong Author: zmajo First line: Unique issue ID ( ) to identify problem Reviewed-by statement identifies reviewers Give credit to often non-trivial reviewing effort Reviewers are responsible for havoc if author not available 43

35 OpenJDK review process Is it code inspection, walkthrough, or code reading? A combination of all three It takes elements from each Walkthrough: Author describes problem and solution Code reading: Reviewers look at code independently Enforced also by geographic distribution Feedback given in written form (comments) Code inspection: Well-defined roles and steps 44

36 Roles Code inspection (as described earlier) Management not involved Author Reviewer(s) Selected by moderator Scribe Moderator OpenJDK review process Management not involved Author Reviewer(s) Everybody on mailing list Mailing list Log all conversations No moderation 45

37 (Lack of) moderation Everybody registered on mailing list can review All members have a right to veto Though proper justification is always required Depending on mailing list, 10s or 100s of potential reviewers Making all reviewers happy is sometimes difficult And time consuming Up to 80% of time spent on reviewing Especially if reviewers have conflicting expectations More the case with cross-component changes E.g., core libraries and JIT compilers Sometimes (rarely) consensus is not reached Code thrown away 46

38 Other differences Suggestions for improvement allowed during OpenJDK reviews Not only defect detection OpenJDK defines a hierarchy of roles Contributor Signed Oracle Contributor Agreement Author Person with own username Listed on project website Committer Allowed to also push code Can sponsor change sets Reviewer Allowed to decide if code is good enough 47

39 OpenJDK roles Roles allow fine-grained access control Achieving Reviewer status Requires 32 significant change sets (Author: 2 change sets, Committer: 8 change sets) Through nomination and vote by members All members have the right to veto Significant : another vaguely defined word Sometimes: Number of lines of code pushed Compiler engineer: 1-line change can take weeks to develop 48

40 Code reviews Good way to assure software quality Often well-defined process (rules to follow) Helps people in organization operate on similar level of standard Defining/following rules Incurs (some) overhead Keep to minimum Rules should be guided by objectives that matter Use common sense to find balance 50