08 May 2017: Hints for Computer System Design

today's class is going to be a little bit different instead of going over some of the mechanics of operating system design well I guess in one sense we will be doing that but there's going to be at a slightly higher level on this presumably you all at some level taking a look at the research paper that Jeff had asked about operating system design and hints thereof on this this is if you've looked at it already it's a classic paper certainly has like lots of sites way back when and as a result it should give you a bunch of ideas far as number one the fact that it is so old and it's still being cited it probably means these are good ideas that have stood the test of time on this another thing to keep in mind is I'm sure you've read through the examples a lot of them are severely dated the specific applications do not always apply to things that you're dealing with today on the other hand there are certain areas where the author speculates that this might be a good idea to do this and you're thinking good grief I deal with this all the time this is a huge problem well that's because things have changed over the course of the ensuing three decades since this paper was published on this but the point being is you know how Jeff talks about like trends or policies or theories on this well that's kind of what this paper is trying to get at in other words how can we design systems and obviously as far as you guys are concerned operating systems like what are some of the things that you need to kind of take to the bank that this particular general idea works even though the specific applications or problems that they were dealing with back when may not be as important as they are today but again the general principles still very much remain on this so if we're going through this today I'd also like to kind of draw some attention to some of the projects that you've been dealing with I certainly in reading this paper myself got a few laughs more than once in terms of yeah I should have done that in terms of my own research or back when when I was coding up OS 161 on this so this paper is different in a couple other ways too in the sense that it really isn't a research paper per se by definition the author even admits it's not a bunch of de novo fact rather the author is kind of just collecting the wisdom of the ages as of 30 years ago already and the other thing too it's a single author paper on this how many computer science papers for that matter even in stem field our single author it probably means it's a little bit unusual or off the track and it probably again means it's a little bit classic on this so before we actually get dive into that I should say and I did jump over this a second I'll come on come on come on that there we go okay and that is vicarious kudos from Jeff on this you guys are really tearing up the barn in terms of assignment 3.2 3.3 and whatnot and really it is this is quite good I think that class as a whole you need to kind of Pat yourselves on the back even if you haven't submitted complete or gotten complete grades for three two or three three rest assured number one you probably already got Jeff's email you can continue to submit right to the end of the semester on that so that's one thing as far as how much the balance in terms of additional time to put into coding obviously if you're already at 80% or above in terms of point value it's kind of pointless excuse the pun to consider it continue to bang on it right now at least until you get your quizzes out of the way next week but I would say we I've already talked with you a bunch of you on this I know I am as guilty as anyone else over the summer after I took operating systems with Jeff yeah I had been bitten and I continued to toy around with OS 161 well into the summer on this and I think more than a few of you should be targeting something like copy-on-write or who knows multi-threaded processes there's a whole bunch of stuff for you to kind of dig in on that too but anyway like I say again Jeff really is quite pleased with how the class has done so far one other remark from the trenches on this obviously there is going to be the quiz coming up 168 hours from now i think is what 3:30 or so okay so it'll be 169 hours from now so I believe it's it's Monday right I'm I was thinking is that correct okay and I believe it's same time plus one hour and same bat-cave right here so for better or for worse this is where is going to be scheduled on this so you already know the drill out this I would say the test is roughly speaking twice as long in the midterm but you'll have three times the time and that really should address the time crunch issue which I think affected a bunch of people on the midterms I know from proctoring and from taking the final in the past I can tell you that the final does not have the time pressure that the midterm does that said and done it kind of distress --is me sometime to see a lot of people leaving earlier than they necessarily should because I I'm thinking myself I bet that person could continue to pound away and get more points on this so I'm not saying you have to stay the full three hours but please resist the temptation to get out and start frolicking in the spring Sun on this you've got three hours in which to get points and you might as well make use of that I know you've already done the toughest certainly in terms of clock hours that put in in terms of your programming assignments the other thing it does go without saying remember that that final is 30% of your grades and you don't want to drop the ball on that they've already seen one of Jeff's tests firsthand you certainly have plenty of his released exams online take a look through that essentially what you see is what you get it's the midterm plus two additional essay questions on this so and I do mention that again because I think I know Ally and I discussed this at length I do think that the essay is where most people kind of came up short for the midterm I would again guess that's probably because of time pressure but you want to make sure that on the final where essentially the essays are going to be well a good almost 3/4 of your test two-thirds to three-quarters that you do want to spend your time thinking about the answers before you write them down on this so it's not difficult to score well on this test but again we are going to be looking for are you thinking things through it's again the essay questions again Jeff calls I'm like the medium quad there's going to be typically one medium question worth 20 points which is the equivalent of the one essay that you had for the midterm and there's going to be 225 point questions which are a hair longer than that so just make sure that you budget enough time you will have the time on the final unlike the midterm so there won't be time pressure but again sure that you do take advantage of that and away she goes on this certainly Ali and I are going to try tomorrow and Wednesday to start in on a little bit of the mechanics of the test review and we're going to be seeing if we can't go through like an old practice test on that Jeff is going to be having a whole smash bang up ask me anything I believe it's either Wednesday or Friday of this week and the other thing i know i mentioned this for the midterm but once again to reiterate it i know for those of you and again for those of you out there in video land who are not here because again there's lots of orange seats again if you are thinking about hey i'm going to watch the videos whenever now is a time to start doing that because again if you have 15 hours worth of videos again you don't want to leave that to go to let's say thursday or friday it's going to take a lot longer for you actually to go through this and retain it than you might think so pardon the sermon i will I guess descend from my pulpit at this point and I guess just any like last-minute questions or thought about like the end of assignment 3 like general questions about the test without going too far off the deep end before we dive into the paper oh yes the question is what is the coverage over the final exam Jeff's finals are comprehensive so everything from the beginning right up to the end of the semester yes other questions all righty to the mid Gunther to the midterm okay true the paper on this okay so what do people think of this so knee-jerk reactions gut reactions sounds of silence okay one thumb up and everyone else it's the social hour at the Trappist nothing okay well let's actually kind of talk through this again in terms oh come on there we are okay three goals in terms of what is this okay Butler Lampson guys aim in terms of this paper again if you will furnish and consolidate general tips for designing systems on this and this is one thing again I already talked about this in terms of like designing a system is very often difficult on this you've already seen this firsthand with assignment three so how can we actually kind of maybe give future coders a few bit of a few hints if you will to make the process slightly less painful and perhaps avoid some common pitfalls on this but in terms of what's going on here okay there are goals of functionality speed and fault tolerance here well that is if you will he's going to give you hints as to how you can achieve these three goals and then there's going to be some other three things that he talks about in terms of let's say where these actually get applied on this so remember just to review things functionality we're essentially talking about does the system do what we want it to right that it doesn't come up short that it doesn't achieve some subset what have you on this speed again we're talking there again typically about wall clock time but there could be other factors in play in terms of maybe like prioritization of speed so that we don't have let's say one thing gets done quickly but a more important task gets left to starve on this one other thing in terms of speed it's we talked about this already but remember there's a little bit of a balance to between speed and other goals on this like economics how can we achieve something but at what cost on this then fault tolerance for those of you who have taken classes like databases or distributed systems that huge in there not that it's not huge in operating systems but again we want a system that is going to achieve what we want but also not fail miserably on this so let's actually take a look at this the next page here and again this is directly from the PDF so if you do have a laptop or a phone or who knows a crystal ball kind of put this up and we're going to kind of walk through some of these things in order as we see them in the paper itself here so what are we talking about here in terms of into a computer system design go through functionality on this ok Lampson talks about functionality is well we're trying to get a system to do something on this and in particular one of the things that Lampson talks about is this interface thing and why are we kind of making a big issue you can see take a look at all the comments in this middle section here about interface why are we focusing them on that I mean why do we even need to do this as opposed to these general three goals of functionality speed and fault tolerance what is so bleep idli bleep and about an interface on this lots on this you've all used interfaces like what's the big interface you had to deal with on in this course here mm-hmm well sis 161 that's the okay you know what that is an interface okay I never thought about that okay but you're right because that is an interface at what level we're trying to get the operating system working with the interface of its emulator on this what's the interface that you had to code against you had to configure the SIS 161 interface okay but you had to code against another one assignment 2 aka syscalls okay so so what's the whole point of these interfaces on here you can think of it again the paper talks a little bit about is it kind of almost a mini programming language this is the breaking off point where the system you're designing has to work with the user in this case you are designing your operating system OS 161 to work with the user which in this case is a bunch of automated tests but in the real world it's probably going to be some cranky user who is going to import data that has not been sanitized or uncover some stupid corner case or what have you oh and by the way the user will also try to get your system to do something that maybe it's not designed to or what have you so we need to think long and hard about this interface because it's going to expose the functionality that you want to implement or should implement and also almost as important I think it picked up from the paper on this hide functionality that your system doesn't do and that is you want to kind of childproof of thing so that the user can't break your system on this so and I don't just mean simply error checking it could also be something as simple as just not allowing the user to pass in certain types of requests at all right because again remember it's you want don't want to really do anything more than you absolutely have to on this so interface is super important on this now in terms of what's going on after this here take a look at well that's right you know what let me actually just bring up a PD is probably going to be a little bit simpler - ah there we are so page ok and we are ah ok you've already remember just post maybe about two months or so ago about kiss keep it simple stupid on this and this is probably the biggest recurring theme throughout this entire paper on this why what's the whole point with kiss in this are we concerned with oskol Tory indulgences or what what are we trying to avoid with the kiss theory on this if we're trying to keep things simple we don't want complications right okay and how can we get complications how can we if you will make things harder for ourselves I am being asked to design let's say a database or an operating system that has to perform to these specifications XY and Z okay and that's what I have to do in order to keep my job and to keep the culture a company from having its contract terminated how can I make things worse for myself by adding extra okay because if I do that while you I'm making more work for myself but also what I am making the whole system more complicated I'm potentially introducing bugs and I'm potentially having the system trying to do something that it perhaps was not designed to do in the first place on this so once again is design one system or one subsystem to do one thing and only one thing really well on this so that's actually down there do one thing at a time and make sure that you do it well all right if you do let's say you try to do some things too much that's when things get complicated and that's essentially when things go off the tracks on this now a couple of things about this I should say we're talking about systems and there's also subsystems on this you've already designed several subsystems you do assignment three is a memory manager subsystem like assignment two roughly speaking is a process managing subsystem on this and your interface that you're presenting to the user should ideally allow you to access one and only one part of the system on this so think about this in terms of preventing presenting let's say desist call interface to the user I am not letting the user muck around with let's say the internals of my buffer cache or my scheduling algorithm or what have you on this why not if I expose essentially the entire design of the kernel to the user okay hmm security is one thing okay and closely aligned to stability is what else I've got this finely tuned grandfather clock right and it's kind of dependent on all the gears working together and essentially what I've exposed to the user is a couple dials set the hour and set the minutes on this I don't want the user monkeying around with let's say the weight of the weight or but take changing the gears or something else like that because that's going to essentially throw off all my finely tuned handwork on this so I want to expose one subsection to the user in other words what is the current time right now and if there is a need for something else like let's say it's a cuckoo clock and I want to allow the user to have the ability to change let's say the species of bird that comes out and goes chirp chirp well that's going to be a different interface on this so again one interface to do one subsystem to do one thing at a time on this keep your interfaces as simple as possible on this again that's from your standpoint for your own sanity and also from the protection of the users on this now a couple things in I may have to scroll down on this you know come on yes okay now that's a general rule and this talk is going to have a lot of general rules followed by some qualified exceptions on here so we want to keep our interfaces simple and we want to keep if you will what they're interfacing to simple and quick and very efficient but there's going to be some things for example things that are not used as often can be more complex you know it's the old 8020 rule on this that if I need to let's say I need to set the clock to time or let's say in terms of a syscall let's say the Reid Cisco does one thing what I read a file very simple no more no less but you know what user said sitting in a terminal is sometimes going to need to do very complex tasks like you might need to let's say uno to script the backup policy or what have you and that's actually what the author is getting at here in terms of let's say more complicated stuff like interpreting command lines that is something where you can have let's say expose more complicated functionality that may not even be quite as efficient because do you really care if it takes five milliseconds or ten milliseconds to respond to a user's input line that's probably quick enough for that because the processing time beyond that is going to be a lot longer than that as opposed to something like the ability to respond to a read Cisco that it better be lightning quick on that because there's a gazillion of those things going on every second I know that from my own woeful research and how it is completely overflowing the data collection server on this so simple things that are done all the time you need to keep very efficient like a more complex things that are not as frequently accessed that's where you can kind of let the complexity bubble up to the surface on this one other thing that we're keeping in mind in terms of complexity already hit it at this it the user the more we can not guess ourselves and let the user make the complicated choices of this how does the user want the backup script to run I don't care let the user make that decision on this so I'm just going to give the user a bunch of very simple tools and let the user put together built the building blocks so in this case the user presumably assists admin can then use these cysts calls with a bunch of typical unix programs like RM dash RF that definitely get rid of all buggy programs and that in term will allow you to multi accomplish whatever it is that you need to accomplish right so questions on this so far we're talking about general principles we're talking about just keep it simple on this do a few things that are really important well and let complex things well be it corner cases on this so far so good straightforward already moving right along mmm I can ah here we are go come on which paid up okay get it right this goes without saying here but you know what you want you don't want bugs so and by bugs it certainly could be as obvious as like the old petty and bug from what twenty years or so ago but that was in hardware but it could also be something like a performance bug on this too and kind of distilling all of this down here the author brings up the case of an old I believe it's a word processing program from back in the Cretaceous era when I was young and essentially what it has is an O of N squared search algorithm if you need to search for let's say I think it's like a mail merge or something like this so and the author is basically saying guess what production and well yeah basically production code very often has bugs avoid emplace so moving right along okay we're talking about in terms of efficiency keep things simple keep bugs out of it a few corollaries to this again make it fast so again simple fast functions again try to hard to guess like there's a few angles of what what users might want in other words in designing a system okay I know that the user is going to need to read a file so I'll keep it simple what I'm not going to try to do is guess what the user might want to read the file for or the specific circumstances or the exact performance metric or what additional features that the user might add I know it was ages and ages before they even came out with an extension to the read sis call as simple as P read which all that does is it adds on an extra parameter and it kind of combines LC and read together on this but it's kind of a design principle like Linus in particular absolutely hates adding sis calls and adding features to this it's probably a good idea we'll look at some other reasons for that later on right and that is like well but this user might want to let's say do an atomic position and read at the same time all right but then you know what eventually you're going to be serving these requests well guess what I want an atomic position read back scratch and squeeze my pure juice at the same time and it grows its feature itis this is the problem with this so what we're trying to do is keep the simple stuff simple and fast on this and in terms of you know what the user who does want a built-in back scratch subroutine to this great widget you know what who's going to implement that windows well yeah window that's feature itis okay but again I don't want to do it so who does that leave yeah let's punt the complexity to the user remember we were just talking about that in terms of let the admin use these simple tools to put together the complex backup script on this well same thing here too so the upshot is it's difficult to guess what users are going to need or what their specific wants are so let them do the guessing and the configuring on this we want to keep our stuff clean and lean and lightweight on this now a couple other caveats in terms of don't hide power what the author is trying to get at here it's a very specific corner case but you know what if you have let's say your company is contracted with the electrical engineers and you've got this really really great hardware performance optimization like in this case the author is talking about this one computer system has I guess the ability to do like a huge read of an entire cylinders worth of disk data all at once on this you might as well expose something like that to the user because if it was specifically designed for that why that particular functionality on it so no we're not going to try to completely all functionality but this is something that was implemented for us down below it's not like we're trying to implement the additional functionality get the distinction on this so if there is specific power of the system we might as well expose that system but we're not going to try to be cutesy and implement it ourselves that's kind of the distinction that's going on here ready moving right along if I can I we are use procedure arguments a little bit okay this is I'm already beginning to get off my own track of familiar already here but what does the author trying to say here is you know remember back to days of 115 116 and what was it like MapReduce on this essentially what the author is trying to get at here is rather than me trying to implement a system that does let's say ten different variations let's say I'm retrieving data and then implementing ten functions okay back scratch massage we'll have you shampoo and what have you I'm going to instead say you know what I am going to let's say get my piece of data let's say in this case I'll take a customer at a salon and I am going to have a parameter that is if you will okay a procedure argument so in this case let it kind of think of it as like a callback like it let the user implement the specifics to this again I'm just going to provide the basic tools and let the user take care of some of the more specifics and then look at that leave it to the client once again do we see a pattern here people so the more details that we can punt to the user so much the better on this and similarly on this too we already talked about this UNIX system encourages the building of small programs that take one or more character have we seen that okay the real mark of a UNIX wizard you've seen some like Ken Smith scripts that are about like five pages long and they have like all these pipes and they have like was it awk and said and like all this gibberish all right well the thing is that there are a lot of basic tools and the administrator is using at the user level these tool to build something to do rather complicated but we don't care about that again this is a general design principle of Unix and it certainly is something that we have seen bleed over into yes indeed even the windows world on this there certainly aping the idea of let's say more and more scripting on this questions comments over continuity I wish I had a clicker for this PDF but we'll have to bear with us on this year it's constant tension between the desire to improve a design the need for stability oh boy ain't that the truth on this those of you who have taken 341 especially with Christian Lord you remember him railing about what's the whole thing about x86 architecture why do we still have x86 architecture yes but you know what we're also still running programs that have been written last year too in x86 why is that we all agree that x86 is a boneheaded design at this point but we're still producing programs last year in this year in x86 huh how did that come about we get the 1989 thing but what yes right now the thing okay I think you're definitely getting very warm there okay the intel has a lot of clout and arguably a whole bunch of different areas on this but I don't think they're probably holding a shotgun to people's backs but maybe almost close to that though what do users companies still have that they don't want to move away from here yeah because what there was that Dawes program in 1989 which means that when I bought my computer in 1991 I wanted to run that Doss program because I was still very interested in you and by the way now that I bought the computer in 1991 I might as well buy software that runs on that in 1993 do we see okay it's kind of a rollover pattern and finally all of a sudden we are here in 2017 so part of it is we do get into this rut and it's very difficult to get out of on this but you know because of that we do need to support again - Torvalds is absolutely if you want to see him go apoplectic look well I guess a lot of things will set him off well actually many things will set him off but one of the things that he will really really tear a new one with the kernel developers for is if someone tries to be cute and breaks user space that's the big thing on this so it's absolutely important in Linux Linux whatever that you do not break the expectations of user space programs on this so that's what I mean by basic interface is stable here and again take a look at this the interface is divided by programming language their operating systems well that's certainly one of the ones that you dealt with in OS 161 these can go on for years and years and years and decades on this and even beyond that though let's say internally let's say I can guarantee you at a company like Microsoft they had their own internal api's on this well you don't really want to break a project that has taken let's say gazillions of dollars for them to develop internally on this so again try to keep changes to a minimum on this that said and done sometimes okay if you look at the next bullet point here keep a place to stand and that is sometimes we do need to move away change can happen very glacially but it does happen we are now finally using 64-bit machines on this and how does Windows deal with that legacy 32-bit code mm-hmm cry and die mm-hm it runs just fine using what and you remember like wo W 64 I think it's called that whatever Windows on Windows or something like that okay so you know we don't want to break these things but if we do change the interface what we want to do is in some way try to maintain backwards compatibility on this and there's a bunch of different ways on this the author talks about well in the case of Windows on Windows or what not providing let's say an additional layer of support to support deprecated commands for at least a while as you can say like Windows is no longer supporting 16-bit software they've moved away from that but we're still going to support 32-bit software for a while plus the other thing too another great example this when this paper was written in 1983 it was kind of almost a pipe dream but it's here today remember Jeff's lectures on virtualization on this right that is probably the biggest example of supporting deprecated systems on this we're not going to try to support things at the application level we're going to support the entire operating system so if you've got that legacy piece of software what we're going to do here is instead if we're smart at let's say Windows and or let's say at Apple and we're one we want to kind of because we know Windows has the dominant market share we want to kind of make it easy for companies to use our Macintosh is on this so we're going to make sure that our machines can virtualize windows and thereby run that mission-critical app so that if you come over to our side of the fence you know you don't have to throughout your entire business model on this it'll still work so upshot is try to change that keep changes to a minimum but when you do always make sure that you users and out by the way this is I can smell this sort of a thing showing up in a GF sa type question on this so what we'll ask you to do is possibly talk about what are some of the design principles and let's say software architecture and like well how well how would you go about designing a system that does XYZ or let's say the president of the company has told you that she wants XYZ features is this a good idea or a bad idea according to general design principles does the president know what she's talking about explain why something like that alright come on come on come on two point four two point there's 2.5 out handling all the cases at all normal and worst cases on this what we're talking about here is in a system now this is kind of internal up until now I've been yammering on about how we interact with the user if you will now we're talking about how can we make sure that our performance at least is well tolerable on this because you know what in terms of we want normal case remember think about the 80/20 rule maybe we should say like a ninety eight to rule on this we want the normal case to run very quickly but we also need to be able to handle the odd case actually probably a better way of putting it is this is this worst case right here what do we not want this worst case to do mmm-hmm I'm sorry I've been here I'm going to eat Indomie not make progress definitely not make progress and what else do we not want it to do visa V the rest of the system okay in other words if we don't want the worst case to not make progress we can extend that to also say we don't want it to bottle up and essentially make sure that all the normal cases also don't make progress on this and Jeff used an example actually in the past about like the healthcare.gov website remember there was that debacle about maybe a few years back when essentially the entire official government website melted on this and it turned out that there was one piece of software internal to the website that was a problem in certain cases and the patch that they came up with kind of lickety-split was you know we're going to kind of do a quick test of what the user wants initially and for was it like the 90 X percent places of that is the general case we're just going to bypass the one problem piece of software and for the sub case what we're going to do is say you know what thank you for your initial information we're going to get back to you maybe in the day or two and ask for additional help so that person is going to be told you're going to have to wait at least expectations were set but the big thing is we're not holding up everyone because before everyone was being fine funneled through this really really slow piece of software on this so what we're trying to do again is separate these two cases of handling on this how about an OS 161 example on this for those of you who are finishing up with assignment 3.3 do you remember the TLB on this and remember there's kind of a bunch of different ways of handling the TLB namely if you need to evict out a page what's the easiest way to make sure that we never have to worry about let's say messing up the page cache I'm said the translation cache of the victim process do what - the victim process is TLB I'm sorry cleric yeah nougat in other words in every case every time I evict a page nuke all the TLB s on all the processors that will work I know for sure it will work and it is very easy to implement and what does that do to the if you will performance of your system where's the Moab okay there we go okay it is right so in other words it works in processed but then what did you do okay you separated out the two because when do we need when do we absolutely need to clear out that TLB when's the essentially the only case when the victim process is doing what well yes and specifically running so if I can determine okay it's going to be on the longer and more complex code path to go down if the victim process is running I'm going to still have to do a TLB if you will flush out on this or something like that but if the victim process is not the vast majority of cases on this I can keep much simpler I don't even have to do anything with the victim TLB done so again try to separate out weirdo quarter cases that are going to take a long time from other things here speed look at this it again there we go okay and a little bit about this this is kind of weird remember way back to there's two types of parallelism if you will temporal and spatial purism the author is suggesting here if at all possible try to divide up resources such that kind of each program or each user has its own little sandbox and they're not stomping on each other's toes it's kind of interesting because like 30 some odd years ago memory something like that was much more precious than it is today memory is much less of an issue yes we still have swapping that was part of assignment three but it's much less of an issue in general we want to give processes give users essentially all the RAM that they need on this so that's kind of an example of spatially multiplexing things for speed because that way we don't have to constantly port data in for one process and then poured it out before we when we do a context switch we're just going to leave let's say if two processes are running in memory at the same time leave the contents in memory barring an eviction on this with the exception the author does certainly admit that there are some resources that are well a little bit more expensive like CPUs on this and in that case what you need to do the author is trying to say is as a software engineer design decide whether or not a resource is expensive or not in other words memory is relatively cheap so we can give each process as much memory as it wants as opposed to a CPU even today even though there's let's say four or eight CPUs we don't have 500 CPUs we're not at the point where each process can have its own CPU so that's something that is still going to have to be shared again temporal multiplexing on this okay well it-it-it let's go down to dining if I can find it what page are we on l14 dynamic translation something certainly was talked about back then but everyone deals with dynamic translation directly or indirectly today what I mean by dynamic translation like what language in particular is notorious / famous for dynamic translation if the language I love to hate yeah good old Java okay okay all right and this is something well the JVM gets into it and certainly Android was puting around for it for a little while but again what we can do if possible well this is what we do with compiling in the first place we have let's say a human readable easily accessible way of expressing stuff and we have a very efficient way of expressing stuff ie machine code on this we need to translate between the two on this and certainly we can do static translation ie compiling things but sometimes we want to also look at dynamic translation so this is something that the author is suggesting as a programming is running can we kind of peek ahead to see what's going on and Jeff probably mentioned that visa fee the context of virtualization did he talk about that like with full virtualization you're having to translate bytecode on the fly that was done for the state of stability and security but in this case what the author is trying to get is dynamic translation for the purposes of efficiency and performance on this because if you look at something like again the JVM with just-in-time compilation or again Android certainly doing that in other we want to kind of think okay we know we've got this blob of code that we have to execute in the next five or ten seconds can we look ahead and see what blocks of code are getting executed a lot AHA that looks like a loop that we are executing five million times I'm going to pre compile that thing so that when I get to it again it's going to execute a lot faster so this is again another general trend but one that has certainly become much much more important in recent days on this so just in time translation an example of dynamic translation already moving right along as I can't even own the age 50 ah caching answers on this and certainly again the classic amp so an example that the author brings up is caching isn't cached caching again think back to 341 on a hardware level what we're trying to do is what is the answer to byte 1,000 in other words let's read the value of byte 1,000 and rather than fetching it from mainboard memory let's save it in a much more easily accessible place but from a standpoint of software designers your software designers not hardware designers this is a CS class not an EE class the same principle applies very often you're going to be doing computation and that computation is going to take a while if you have to do it repeatedly why not cache the results on this and where are we doing lots of software caching these days examples where do we hear about software caching Jeff talked about one in this class the blank cash file system talk about Josh you guys get into buffer cache this year okay okay so you didn't talk about that okay so in other words this is one example of okay what is the value of a particular file on this well rather than reading it from disk we're going to this the opposite of swapping I'm going to read it into the buffer cache so that I don't have to re get it again and again on this those of you who have taken networks what's an example of caching that's now going on what's all this net neutrality debate okay because of like videos and stuff like that what's one way that you can let's say if people are constantly streaming or torrenting a particular video and let's say the home server is in Tahiti okay the black sands of Tahiti so what are we going to do is an ISP to try to make it go quicker yes prioritize it definitely that will improve it and that's actually an angle that you can talk about in this too so that will make sure that the user experience is better how can we use a cache to sell this I'm repeatedly seeing requests to this video server in Tahiti why should I continue to go to the video server in Tahiti instead what should I do the next time I see requests for video XYZ in Tahiti yeah okay so let's store a cache locally or at least regionally on this so again this is a big area of software engineering that is being implemented at the hardware level the local system level the cluster level whole bunch of different levels on this all right other things to come on ah hint what is a hint well we know what a hint is but like up until now I've been talking about specific policies you need to do X because it will produce Y on this like one example for let's say we talk about giving it kind of like this in OS 161 is remember we're using the past to predict the future we want to pick a good page to event so Jeff talked about clock and LRU on this what is let's say a good page to vit do I know the best page to event now I can only take kind of a guess at that so this is a hit I might actually sometimes pick wrong and I might have to suffer the consequences on this or another one I had some discussions with people here about how many locks should I have for let's say the quorum app you can have one big lock for the quorum app and that's probably what most people do on this but wait a minute Karl cannot optimize this and have a lock on each individual page on this well yeah it turns out you can write and you can get rid of the big quorum app lock on this and it will be a lot more granular on this in other words I want to let's say gain access to let's say entry ten of the core map so okay what do I do I grab a hold of that and I want to see is it free or not okay um well what happens in the interim though let's say because I've scanned the core map without holding a lock and I think you know what I want to grab this free page for my use but in while grabbing it what happens is what someone else might have grabbed it too so I don't know I might have made a bad guess state might have changed on this but that's okay these are simply hints that we can use I can say that this was the last previously free page on this and I can start here I might be wrong in my guess but it will help me avoid the predicament of having to grab a global lock on the core map and iterate the entire thing from front to back each time on this now the other one on the bottom here if I can find it is it oops no to it ah compute in background this is presented is almost a novel concept here when possible try to compute on this you get the feeling that things have changed because today let's face it multi-threading goes on all the time and this is something that certainly you know about this if your app is non-responsive because you're doing some stuff on the GUI thread your user are going to be very very unhappy on this and as a matter of fact this is something that is a big design principle of you know any graphical operating system you're going to have to make sure that the GUI thread is always as responsive as possible and make sure that you don't block responsiveness on this so just about done on this so just general thoughts questions okay the last part I will say very go quickly it's essentially fault tolerance on this and he talks about like end to end principles in other words essentially what you want to make sure is that the end user gets stuff that matters on this if there's a problem in the interim you really don't care about it on this so again in terms of what you're looking for is performance is the system if you will perform it with in time and economic constraints does it work does it do what it wants and lastly is does this system actually not bomb out so questions on this well thanks people I appreciate it Jeff to go a review and take it from there