Virtual Machine Support for Many-Core Architectures: Decoupling Abstract from Concrete Concurrency Models
- 1. Virtual Machine Support for Many-Core ArchitecturesDecoupling Abstract from Concrete Concurrency ModelsStefan MarrVrijeUniversiteitBrusselPLACES Workshop, 22nd March 2009, York, UK
- 2. AgendaMotivationConcurrency Support for VM Instruction SetsMethodologyCombining Different ModelsInvestigate TradeoffsResearch Platform3/21/092VM Support forMany-CoreArchitectures
- 3. The Free Lunch Is OverMany Core ≠ Many CoreHomogeneous vs. heterogeneous designsDifferent memory and cache patterns/partitionsDifferent concrete concurrency models3/21/0931. MotivationCell Broadband Engine - 1 PPE, 8 SPE - bus interconnectIntel Larrabee - up to 48 cores (IA32) - bus interconnect, virtual shared memoryTilera TILE64 - 64 cores (MIPS) - up to 866 MHz - virtual shared memory
- 4. Abstract Concurrency ModelsBroad range of programming modelsShared memory with locking is error-prone/hardSTM and actors still not mainstreamCombinations and new approaches expected3/21/0941. Motivation
- 5. Virtual Machines as Abstraction Layer3/21/0951. MotivationC#Prolog, …JVM/CLR/…Today, concurrency support is very limited!
- 6. Concurrency Support for VM Instruction Sets3/21/096
- 7. MethodologyTo develop instruction set with concurrency supportCombination of concurrency modelsGuidelines for design decision, tradeoffsInstruction set design Application areaGeneral purpose/multi-langVMs like JVM/CLRSpecial purpose VMs like DalvikVM3/21/097
- 8. Combining Different Models3/21/0982. Concurrency Support for VM Instruction SetsConsider abstract models separately
- 10. Analyze design space for ISA
- 12. Based on existing ideasTradeoffs to be ConsideredModel combinationsDifferent types/approaches of integrationInstruction set sizeDesign space with respect to #instructionsInstruction set typeOpcode vs. higher level representation…?3/21/0992. Concurrency Support for VM Instruction Sets
- 13. Research PlatformRequirements for an appropriate VMPortable, support for Linux and MIPSAvailable STM and Actors languages/librariesUnused instructions in bytecode/opcode setEasy to adapt just-in-time compiler3/21/0910
- 14. Tilera TILE64™3/21/09113. Research Platform64 cores, up to 866 MHz
- 15. MIPS derived 32-bit VLIW ISA
- 16. L1 cache/core: 8KB instructions, 8KB data
- 18. 4 DDR2 RAM controllerChoosing a VM as Research Platform3/21/09123. Research Platform
- 19. Discussion3/21/0913VM Support forMany-CoreArchitecturesMethodologyTradeoffsConcurrency Model IntegrationResearch PlatformInstruction Set Design
Editor's Notes
- #3: Talk presents the idea and goal of my PhD researchPoints to try discussion:Evaluation work, better to use JVM or LuaOther stuff to be evaluated?Targeted research platform: TILE6430min -> 20min slides + 10min discussion
- #6: What we see with JVM and CLR:Run on various platforms (especially JVM)Are platform for wide range of different languages (hundreds, maybe even thousands)Let me explain this statementCommon VMs support threading exclusivelyLanguages: no direct support for other models extra effortsVM: implementation on many-core systems cannot benefit from higherlevel constructs similarities
- #13: Additional VMs which could be suitable?
- #14: I would like to discussion following thingsSuitability of chosen VMsValid reasons to chose JVM over something else? I.e. reasons to not use Lua?-Other platforms then TILE64 or CellBE, which might be interesting?Tradeoffs which should be investigatedThe final goal for my PhD is to cover the concurrency part of ISA/VM design as a cornerstone for multi-paradigm VMs