Class 35: Other Machine-Level issues

Held Wednesday, April 7

Summary

• Due: Exam 2.
• Representing images
• Representing objects
• Run-time issues
  • The stack and the heap
  • Garbage collection
• Possible visitation from prospectives

Contents

Notes

• The exam is due now! (Beginning of class.)
  • An answer key will be ready by Friday.
  • I hope to have exams graded by next Monday.
• Next week is preregistration. I'd like to encourage you to consider other computer science and mathematics courses.
  • If you like algorithms and algorithm analysis, you might enjoy MAT218: Combinatorics (in which you will study more of the mathematics underlying such analysis) and CSC301: Algorithms. MAT218 is a prerequisite for CSC301. MAT218 is offered in the Fall and Spring, CSC301 is only offered in the Fall.
  • If you're enjoying building programs, you might enjoy CSC223: Software Design (offered in the Fall). The course covers a number of issues, from the tools used to build large projects to human factors in computing systems. Importantly, CSC223 involves a large group project.
  • If you want to know more what goes on ``under the hood'' (including more on issues like binary representation), you might enjoy CSC211: Architecture or Physics 220: Electronics. Both are offered in the Fall (CSC211 is offered in alternate years). You might also enjoy CSC213: Operating Systems, which emphasizes the software that supports all that's going on (how do we allow multiple processes to run at the same time?). CSC213 is offered in alternate years, and will next be offered in Fall 2000.
  • The department is introducing a new computer networks course (CSC364) next Spring. For the first offering, we will only have a prerequisite of CSC152.
  • If you want to study some implications of computing technology, you might want to consider CSC105: An Algorithmic and Social Overview of Computer Science. However, the primary audience for that course is not alums of CSC152. CSC105 will be offered in Spring 2000.
• I believe that there's still time to declare a major. In order to declare a CS major, you need to find an advisor (Mr. Walker or Mr. Rebelsky) and prepare a plan for completing the requirements for the major.

Representing Other Things

• So far, we have focused on how we represent the ``primitive'' values: numbers, characters, and such.
• Let us now turn to a few more structured values, such as objects and images.

Representing Images

• How might we store more complex information, such as images?
• As you probably know, most images are broken down into a grid of pixels (small dots).
  • In a black-and-white image, the pixels are black and white.
  • In a greyscale image, the pixels are some shade of grey (usually one of 256 greys).
  • In a color image, the pixels are in color.
• Representing these types of images requires us to consider two separate issues:
  • How do we represent groups of pixels?
  • How do we represent the individual pixel colors?
• The easiest representation is to write the value of each pixel in sequence (along with some notation as to the size of the image).
  • However, this requires a lot of space.
  • Consider how much we might need for a 100x100 image (relatively small).
• Another possibility is to look for sequences of identical pixels and write down the value of one pixel and then the length of the sequence. In many images, this provides significant compression of the image.
• Traditionally, black-and-white images are represented with a single bit per pixel.
• Greyscale images are usually represented with one byte per pixel (all 0's is white, all 1's is black, or vice-versa).
• There are a number of basic strategies for color images.
  • In 24-bit RGB color, one byte is used for each of three colors (red, green, and blue) that then determine the color of the pixel.
  • In indexed color, a color table lists the colors used in the image (usually 256 separate RGB values) and each pixel has a byte that serves as an index into the table.
• You may get an assignment on images.

Representing Video

• How do we represent video? One possibility is to simple store a sequence of images.
  • However, such a sequence can get surprisingly large.
  • And the images in the sequence are often similar.
• Typically, what is stored is a number of key frames (images, usually representing a new shot or whatever), with accompanying changes for intermediate frames.
  • A change might describe particular pixels in the new frame.
  • A change might be a function to create the new frame.
  • ...

Representing Arrays

• How do we represent arrays?
  • Part of an array matches the representation of any object (described below).
  • But the core of an array is simply an area of memory big enough for the appropriate number of elements of the appropriate type.
• For example, if we have an array of 10 ints, we need 40 bytes. (Each int is 4 bytes.)
• We also need to store a length of the array.

  Representing Objects

• Note that the following is intended to help you think about how one might represent objects, and may not be an accurate portrayal of how Java represents objects.
• How do we store objects in memory? Usually, as a grouped collection of the fields in the object plus a reference to the methods.
• Consider a simple Person class:

  public class Person {
    int id;
    String name;
    public Person(String name) { ... }
    public Person(String name, int id) { ... }
    public int getId() { ... }
    public void setId(int newid) { ... }
    ...
  } // class Person
  

• We might draw a few Persons as

  Person0: +-------+ Methods:| *--------------------------+ +-------+ +---+ | name:| *----------->| S | | +-------+ +---+ | id:| 32 | | a | | +-------+ +---+ | | m | | Person1: +---+ v +-------+ +-------+ Methods:| *--------------------->| | equals(Object) +-------+ +-------+ name:| *-------+ | | toString() +-------+ | +-------+ id:| 99 | | | | +-------+ | ... | | | v +-------+ +---+ +----------* | getId() | C | | +-------+ +---+ | | | setId(int) | l | | +-------+ +---+ | | | | i | | ... +---+ | | | | f | | +-------+ +---+ | | | Person(String) v +-------+ Code for getId +------* | Person(String,int) return the | +-------+ value at | offset 8 | v Code for Person(String,int)

• Things to notice:
  • There is a lot of indirection going on.
  • Objects use a reference to an ``array'' of references to methods.
  • All objects in the same class share the same array.
  • Names are references to strings.
  • All the ``cells'' are relatively small: either an integer (4 bytes); a reference (4 bytes, I believe); a character (2 bytes), or some other primitive type.
• Note that inheritance is handled at compile time rather than run time. That is, all the fields in a superclass are included within the object of the subclass (separate objects are not created).
  • The same is true of methods.
• Suppose we created a new subclass, SalariedPerson

  public class SalariedPerson
    extends Person
  {
    float salary;
    public SalariedPerson(String name, float salary) { ... }
    public void giveRaise(float amt) { ... }
  } // class SalariedPerson
  

• An element of the new class might look like

  employee: +-------+ +-------+ Methods:| *--------------------->| | equals(Object) +-------+ +-------+ name:| *-------+ | | toString() +-------+ | +-------+ id:| 99 | | | | +-------+ | ... salary: | 11.99 | | | | +-------+ v +-------+ +---+ +-----------* | getId() | X | | +-------+ +---+ | | | setId(int) | e | | +-------+ +---+ | | | | n | | ... +---+ | | | | a | | +-------+ +---+ | | | super(String) | +-------+ | +------* | super(String,int) v | +-------+ Code for getId | | | giveRaise(float) return the | +-------+ value at | | | SalariedPerson(String,float) offset 8 | +-------+ | | | | ... v Code for Person(String,int)

• Note that the fields and methods inherited from Person are in the same order. That way, a method that expects a person can still take a SalariedPerson and behave in exactly the same way. (getId is one such method.)
• Note also that we made a new array of methods. This is also necessary, since we may overload some methods.

Run-time Issues

• We may also want to consider a number of representation issues that deal with how the computer actually processes Java programs.
• We will deal with three fundamental memory-related issues:
  • The stack (where stack frames go)
  • The heap (where objects go)
  • Garbage collection (how you recover memory)

The Stack and the Heap

• How is memory arranged in the computer while the program is running? Usually into three parts:
  • Static memory
  • The stack
  • The heap
• (This stack and heap are somewhat different from the data structures we will soon learn about.)
• As you might guess, static memory is reserved for things that don't really change, such as program code. Often, the most general variables (e.g., those in main) are also stored in stack memory.
• The stack and the heap provide what is normally called dynamic memory. This is where new objects (and other things) are allocated and deallocated.
• The heap is where most objects are created. It is an unordered "chunk" of memory. When a new object is requested, some part of that chunk is then used for the object. When the object is no longer needed (and either explicitly deallocated or garbage collected by the system), it is freed up for the next object to be allocated.
• The stack is where local variables for procedures (and other information on procedures) normally go. When you call a procedure, a stack frame is created containing the parameters for the procedure as well as any local variables. The stack frame also contains information on the previous stack frame and an indication of where in the previous procedure we were.
• When the procedure terminates, we return to the previous stack frame.

Garbage Collection

• In most modern languages, it is possible to dynamically create new objects (or variables or ...).
• This can lead to problems: what happens when we're done with something we've created? We can't just leave it around, or we'll eventually run out of memory.
• In many languages (C, C++, Pascal, etc.), programmers are responsible for reclaiming the memory allocated to objects they've created.
• This can lead to many problems
  • Some people reclaim memory that's still in use.
  • Some people forget to reclaim memory that's no longer in use. (This leads to memory leaks.)
• I've been told that for professional programmers, between 50% and 90% of debugging time is devoted to problems related to memory allocation.
• To reduce these problems, many modern languages now provide automatic garbage collection. That is, the implementation of the language automatically determines which allocated things are no longer necessary and frees them up.
• There are a number of strategies for garbage collection. They include:
  • Reference count: associate a counter with each object. When a new reference is made to the object, increment the counter. When a reference is moved to another object, decrement the counter. When you reach 0, delete the object.
  • Mark and sweep: mark all the active things, then sweep through memory noting what is now free.
  • Copying: identify all the active objects, copy them elsewhere in memory, and update all the references to them.

History

• Created Monday, January 11, 1999.
• Added short summary on Friday, January 22, 1999.
• Filled in some details on Wednesday, April 7, 1999. Many of these details were taken from outline 36 of CSC152 98S. The pictures and their implications are completely new, as is the discussion of video.