Demystifying Magic High-Level Low-Level ProgrammingThe ProblemThe GoalRevolutionWhyWhy NotWhy (1975)Slide 8Why Not (1972)Why The 70s Shift to C?Revolution II ?A New Revolution?DiscussionSolutions?Our (Small) Battle for the RevolutionOur ApproachOur FrameworkJava Version“Magic” in JikesRVMBoth VersionsSummaryDo You Buy It?Questions?Our “Battleground”A Concrete ExampleSlide 26Slide 27Slide 28Slide 29Slide 30Slide 31IntrinsicsSlide 33Slide 34Semantic RegimesObjectReference Overhead?Type System ExtensionObjectReference AbstractionSlide 39AbstractionSlide 41Issues Still Relevant?Spot The Bug…Extending: Long HistoryPower of AbstractionSlide 46Slide 47ConsiderationsDefining TermsRoadmapDemystifying MagicHigh-Level Low-Level ProgrammingDaniel Frampton, Steve Blackburn, Perry Cheng, Robin Garner, David Grove, Eliot Moss, Sergey Salishev1From Frampton et al.'s VEE'09 TalkJennifer SartorThe Problem•Systems programmers:–strive for reliability, security, maintainability–depend on performance and transparent access to low-level primitives•Abstraction:–Enables the former–Typically obstructs the latterFrom Frampton et al.'s VEE'09 Talk 2The GoalAbstraction without guilt.From Frampton et al.'s VEE'09 Talk 3[Ken Kennedy]RevolutionFrom Frampton et al.'s VEE'09 Talk 4Why“In order to manage the complexity of software systems, I find it necessary to partition my concerns, and deal with them separately. A major set of concerns is the efficient allocation of a whole variety of resources, but I don’t worry about all resources all the time. Efficient allocation of registers is important, but quite separable from memory management, … file management, etc. While I am programming any one of these I would like to take the others for granted.”“In order to manage the complexity of software systems, I find it necessary to partition my concerns, and deal with them separately. A major set of concerns is the efficient allocation of a whole variety of resources, but I don’t worry about all resources all the time. Efficient allocation of registers is important, but quite separable from memory management, … file management, etc. While I am programming any one of these I would like to take the others for granted.”From Frampton et al.'s VEE'09 Talk 5Why Not“A person designing and implementing an operating system, … is trying to make a given collection of processors, storage media, and i/o devices work together reliably, efficiently, and conveniently. The operation of these devices is his problem. It is unclear to us why he would ever want to obscure the exact nature of this hardware behind the constructs of a higher-level language.”“A person designing and implementing an operating system, … is trying to make a given collection of processors, storage media, and i/o devices work together reliably, efficiently, and conveniently. The operation of these devices is his problem. It is unclear to us why he would ever want to obscure the exact nature of this hardware behind the constructs of a higher-level language.”From Frampton et al.'s VEE'09 Talk 6Why (1975)From Frampton et al.'s VEE'09 Talk 7James J. Horning, Yes! High level languages should be used to write systems software. ACM Annual Conference/Annual MeetingProceedings of the 1975 Annual Conference.Why (1975)From Frampton et al.'s VEE'09 Talk 8James J. Horning, Yes! High level languages should be used to write systems software. ACM Annual Conference/Annual MeetingProceedings of the 1975 Annual Conference.Why Not (1972)From Frampton et al.'s VEE'09 Talk 9J.G. Fletcher, On the appropriate language for system programming. ACM SIGPLAN Notices, Volume 7, Number 7, 1972Why The 70s Shift to C?•Better language design•Better language implementation•More complex software•More complex hardware•More hardware (portability)From Frampton et al.'s VEE'09 Talk 10Charles Landau, On high-level languages for system programmingACM SIGPLAN Notices, Volume 11, Issue 1,1976Revolution II ?From Frampton et al.'s VEE'09 Talk 11A New Revolution?•Change continues–heterogeneous multi-core?–more complex software•Higher-level languages–type safe–memory safe–strong abstractions over hardwareFrom Frampton et al.'s VEE'09 Talk 12Discussion•Should we do low-level programming in high-level languages?–Pros?–Cons?–Layers of abstraction13•Performance? •High-level – easier for synchronization?, memory manageSolutions?1. Fortify low-level languages (C/C++)–Memory safety (e.g., cons. GC, talloc)–Idioms (e.g., restrictive use of types)–Tools (e.g., Valgrind’s memcheck)2. Use a Systems PL–BLISS, Modula-3, Cyclone3. Use two languages–FFI’s such as JNI & PInvoke4. Extend a high-level language–Jikes RVM extends JavaFrom Frampton et al.'s VEE'09 Talk 14Our (Small) Battle for the RevolutionFrom Frampton et al.'s VEE'09 Talk 15Our Approach•Key Principle: Containment–Minimize exposure to low-level coding•Extensibility–Requirements change quickly–Languages change slowly•Encapsulation–Contained low-level semantics•Fine-grained lowering of semantics–Minimize impedance–Separation of concernsFrom Frampton et al.'s VEE'09 Talk 16Our Framework•Extend semantics–Intrinsic methods•Controlling semantics–Scoped semantic changes•Extend types–box/unbox, ref/value, arch. sizes, etc•Prefer to retain syntax (pragmatism)–Existing front-end tools useableFrom Frampton et al.'s VEE'09 Talk 17Ex: cache prefetch, invalidateEx: new(), suspend GC yieldJava Versionvoid prefetchObjects( ?!? buffer) { for(int i=0;i<buffer.length;i++) { ?!? current = buffer[i]; ?!? }}From Frampton et al.'s VEE'09 Talk 18void prefetchObjects( OOP *buffer, int size) { for(int i=0;i < size;i++){ OOP o = buffer[i]; asm volatile( "prefetchnta (%0)" :: "r" (o)); }}“Magic” in JikesRVM•Raw access to memory?•Use int and “magic” (peek & poke)•Use ADDRESS macro (as int or long)•Use magical Address type (~= void*)•Use ObjectReference magic type–More strongly typed–Abstracts over mechanism (handle/pointer)From Frampton et al.'s VEE'09 Talk 19Both Versions@NoBoundsCheckvoid prefetchObjects( ObjectReference[] buffer) { for(int i=0;i<buffer.length;i++) { ObjectReference current = buffer[i]; current.prefetch(); }}From Frampton et al.'s VEE'09 Talk 20void prefetchObjects( OOP *buffer, int size) { for(int i=0;i < size;i++){ OOP o = buffer[i]; asm volatile(
View Full Document
Unlocking...