CSC 213 – Large Scale Programming. Today’s Goals  Consider what new does & how Java works  What are traditional means of managing memory?  Why did.

CSC 213 – Large Scale Programming

Today’s Goals  Consider what new does & how Java works  What are traditional means of managing memory?  Why did they change how this was done for Java?  What are the benefits & costs of these changes?  Examine real-world use of graphs & its benefits  How do all of those graph algorithms get used?  Can we take advantage of this knowledge somehow?  What occurs in real-world we have not covered?  And why is beer ALWAYS answer to life’s problems

Explicit Memory Management  Traditional form of memory management  Used a lot, but fallen out of favor  malloc / new  Commands used to allocate space for an object  free / delete  Return memory to system using these command  Simple to use

Explicit Memory Management  Traditional form of memory management  Used a lot, but fallen out of favor  malloc / new  Commands used to allocate space for an object  free / delete  Return memory to system using these command  Simple to use, but tricky to get right memory leak  Forget to free  memory leak dangling pointer  free too soon  dangling pointer

Dangling Pointers Node x = new Node(“happy”);

Dangling Pointers Node x = new Node(“happy”); Node ptr = x; Node x = new Node(“happy”); Node ptr = x;

Dangling Pointers Node x = new Node(“happy”); Node ptr = x; delete x; // But I’m not dead yet! Node x = new Node(“happy”); Node ptr = x; delete x; // But I’m not dead yet!

Dangling Pointers Node x = new Node(“happy”); Node ptr = x; delete x; // But I’m not dead yet! Node y = new Node(“sad”); Node x = new Node(“happy”); Node ptr = x; delete x; // But I’m not dead yet! Node y = new Node(“sad”);

Dangling Pointers Node x = new Node(“happy”); Node ptr = x; delete x; // But I’m not dead yet! Node y = new Node(“sad”); cout << ptr.data << endl; // sad  Node x = new Node(“happy”); Node ptr = x; delete x; // But I’m not dead yet! Node y = new Node(“sad”); cout << ptr.data << endl; // sad 

Solution: Garbage Collection  Allocate objects into program’s heap  No relation to heap implementing a priority queue  This heap is simply a “pile of memory”  Garbage collector scans objects on heap  Starts at references in program stack & static fields  Finds objects reachable from those program roots  We consider the unreachable objects “garbage”  Cannot be used again, so safe to remove from heap  Need to include free command is eliminated

No More Dangling Pointers Node x = new Node(“happy”);

No More Dangling Pointers Node x = new Node(“happy”); Node ptr = x; Node x = new Node(“happy”); Node ptr = x;

No More Dangling Pointers Node x = new Node(“happy”); Node ptr = x; // x reachable through ptr so cannot reclaim! Node x = new Node(“happy”); Node ptr = x; // x reachable through ptr so cannot reclaim!

No More Dangling Pointers Node x = new Node(“happy”); Node ptr = x; // x reachable through ptr so cannot reclaim! Node y = new Node(“sad”); Node x = new Node(“happy”); Node ptr = x; // x reachable through ptr so cannot reclaim! Node y = new Node(“sad”);

No More Dangling Pointers Node x = new Node(“happy”); Node ptr = x; // x reachable through ptr so cannot reclaim! Node y = new Node(“sad”); cout << ptr.data << endl; // happy! Node x = new Node(“happy”); Node ptr = x; // x reachable through ptr so cannot reclaim! Node y = new Node(“sad”); cout << ptr.data << endl; // happy!

 Static & locals are called root references  Must compute objects in their transitive closure Garbage Collection HEAP

Garbage Collection HEAP  Remove unmarked objects from the heap

Garbage Collection HEAP  Remove unmarked objects from the heap  New objects allocated into empty spaces

Why Not Always Use GC?  Garbage collection has obvious benefits  Eliminates some errors that often occurs  Added benefit: also makes programming easier

Why Not Always Use GC?  GC also has several drawbacks couldwill  Reachable objects could, not will, be used again  More memory needed to hold the extra objects  It takes time to compute reachable objects unreachable livedead reachable

Why Not Always Use GC?  GC also has several drawbacks couldwill  Reachable objects could, not will, be used again  More memory needed to hold the extra objects  It takes time to compute reachable objects unreachable livedead reachable obj = new Object(); free(obj)

Why Not Always Use GC?  GC also has several drawbacks couldwill  Reachable objects could, not will, be used again  More memory needed to hold the extra objects  It takes time to compute reachable objects unreachable livedead reachable free(obj) obj = new Object(); can be explicitly freed

Why Not Always Use GC?  GC also has several drawbacks couldwill  Reachable objects could, not will, be used again  More memory needed to hold the extra objects  It takes time to compute reachable objects unreachable livedead reachable can be garbage collected free(??)

Cost of Accessing Memory  How long memory access takes is also important  Will make a major difference in time program takes  Imaginary scenario used to consider this effect:

Cost of Accessing Memory  How long memory access takes is also important  Will make a major difference in time program takes  Imaginary scenario used to consider this effect: I want a beer

Registers and Caches  Inside the CPU, find first levels of memory  At the lowest level, are processor’s registers

Registers and Caches  Inside the CPU, find first levels of memory  At the lowest level, are processor’s registers  Very, very fast but…  … number of beers held is limited

Registers and Caches  Inside the CPU, find first levels of memory  At the lowest level, are processor’s registers  Use caches at next level for dearest memory

Registers and Caches  Inside the CPU, find first levels of memory  At the lowest level, are processor’s registers  Use caches at next level for dearest memory  More space than registers, but…  … not as fast (walk across room)  Will need more beer if party is good

Horrors!  Processor does its best to keep memory local  Caches organized to hold memory needed soon  Makes guesses, since this requires predicting future  Will eventually drink all beer in house

Horrors!  Processor does its best to keep memory local  Caches organized to hold memory needed soon  Makes guesses, since this requires predicting future  Will eventually drink all beer in house  12MB is largest cache size at the moment  Many programs need more than this  What do we do?

When the House Runs Dry…  What do you normally do when all beer gone?  Must go to store to get more…  … but do not want a DUI so we must walk to store  Processor uses RAM to store data that cannot fit  RAM sizes are much, much larger than caches  100 x slower to access, however

When Store Is Out Of Beer...

Ein Glass Bier, Bitte  Get SCUBA gear ready for WALK to Germany  Should find enough beer to handle any situation  But buzz destroyed by the very long wait per glass  If Germany runs out, you're drinking too much

Non-Beer Example of Hierarchy but only 3 can fit in RAM Program takes 4 pages, but only 3 can fit in RAM RAM Hard Disk

GC follows references from object to object Non-Beer Example of Hierarchy RAM Hard Disk

Bringing memory into RAM when references require it Non-Beer Example of Hierarchy RAM Hard Disk

But we don't have space, Non-Beer Example of Hierarchy RAM Hard Disk

But we don't have space, so another page is evicted Non-Beer Example of Hierarchy RAM Hard Disk

Now GC can continue Non-Beer Example of Hierarchy RAM Hard Disk

Which requires walking to Germany again Non-Beer Example of Hierarchy RAM Hard Disk

Before GC continues to find the reachable objects Non-Beer Example of Hierarchy RAM Hard Disk

And we find that we again walk to Germany Non-Beer Example of Hierarchy RAM Hard Disk

Walking To Germany Is Slow…

What Does This Mean?  Large data sets require more thought & care  Start with, but do not end at, big-Oh notation  Consider memory costs and how to limit them  Most data structures do not grow this large  S TACK, Q UEUE, S EQUENCE rarely get above 1GB  Using very, very large G RAPH is not typical  Databases are largest data sets anywhere  Which data structures & implementations affected?

For Next Lecture  Remember, design for your program #3 due  Does it make sense? Think before submitting  Reading on memory hierarchy for Wednesday  How can we use experience of wanting a beer?  Useful ways to see what happens & take advantage

CSC 213 – Large Scale Programming. Today’s Goals  Consider what new does & how Java works  What are traditional means of managing memory?  Why did.

Similar presentations

Presentation on theme: "CSC 213 – Large Scale Programming. Today’s Goals  Consider what new does & how Java works  What are traditional means of managing memory?  Why did."— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

CSC 213 – Large Scale Programming. Today’s Goals  Consider what new does & how Java works  What are traditional means of managing memory?  Why did.

Similar presentations

Presentation on theme: "CSC 213 – Large Scale Programming. Today’s Goals  Consider what new does & how Java works  What are traditional means of managing memory?  Why did."— Presentation transcript:

Similar presentations

About project

Feedback