Lecture 30

Announcements

Exam 2 was too long. Many students only half-answered some questions.

Too-long tests have too-large standard deviations. This one had 15.7; the normal 100-point grading scale assumes a standard deviation no larger than 10. Thus, we will adjust the grades to fix the standard deviation. The adjustment is visible in Test Grades in collab (but not in TPEGS).

Adjusted mean: 84.0; median: 85.7; standard deviation: 10; high: 100; low: 0

Exam regrade requests may be made through TPEGS until 13 April 2014.

Talking Points

8.10: Garbage collection

We have been using new a lot. Each time we do so, Java reserves some memory for a new object. What keeps the computer from running out of memory? The Garbage Collector.

In the background there is a part of Java that looks through memory and throws out things you aren't using.

What is really being stored?

The code of methods you write is stored somewhere

The static fields are stored somewhere

The activation records (memory of the variables of each method running) is stored somewhere (the stack)

The fields of each object are stored somewhere (the heap)

There is more being stored too…

We'll explore these ideas with a Kitten class and FindAKitten program.

It's all bits

All computer memory stores is bits: high and low voltages in distinct, ordered buckets. We might treat a high voltage as 1 or true; a low voltage as 0 or false.

Keeping several bits together lets of store more things: two bits have 4 options (00, 01, 10, and 11), three bits gives us 8 options, and so on.

The meaning of a particular set of bits depends on their type; for example, 01110111 is 119 if it is an int but it's w if it's a char. The memory looks exactly the same in both cases; Java just interprets it differently.

Next class we'll go outside the textbook to look at how computers store type.