Proceedings of the 11th Workshop on Programming Languages and Operating Systems最新文献

筛选

英文中文

CppSig

Proceedings of the 11th Workshop on Programming Languages and Operating Systems Pub Date : 2021-10-25 DOI: 10.1145/3477113.3487268

C. Dietrich

{"title":"CppSig","authors":"C. Dietrich","doi":"10.1145/3477113.3487268","DOIUrl":"https://doi.org/10.1145/3477113.3487268","url":null,"abstract":"For decades, the C programming language proved to be a cornerstone of system-software ecosystems, leaving us with billion lines of existing source code. From today's perspective of object-oriented and functional languages, C itself seems rather limited in its expressiveness and abstractive power. However, with the C preprocessor (CPP) as its companion, macros, which operate on the raw token stream, allow for abstractions that are impossible to achieve within the language itself. While its flexibility and its ease of use make CPP attractive for programmers, its potential undisciplined usage makes it problematic for static source-code analysis and can slow down the on-boarding of new developers. In this paper, we focus on a disciplined subclass of CPP macros: the statement-like and expression-like macros, which mimic regular C functions, with well-type C expressions as arguments and, in case, a return value. We show how to spot such macros and their arguments in the compiler's abstract syntax tree, whereby it becomes possible to deduct type signatures for individual macro expansions. With our CppSig prototype, implemented as a Clang plugin, we extract macro-type information from Linux 5.12, whereby it becomes easier to understand even deep macro-expansion nests. In the future, these expansion signatures could be used to statically enforce gradually-typed CPP macro definitions.","PeriodicalId":136137,"journal":{"name":"Proceedings of the 11th Workshop on Programming Languages and Operating Systems","volume":"27 6","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2021-10-25","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"133169395","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}

引用次数: 0

Understanding the Overheads of Hardware and Language-Based IPC Mechanisms 理解硬件和基于语言的IPC机制的开销

Proceedings of the 11th Workshop on Programming Languages and Operating Systems Pub Date : 2021-10-25 DOI: 10.1145/3477113.3487275

Zhaofeng Li, Tianjiao Huang, Vikram Narayanan, A. Burtsev

{"title":"Understanding the Overheads of Hardware and Language-Based IPC Mechanisms","authors":"Zhaofeng Li, Tianjiao Huang, Vikram Narayanan, A. Burtsev","doi":"10.1145/3477113.3487275","DOIUrl":"https://doi.org/10.1145/3477113.3487275","url":null,"abstract":"A recent surge of security attacks has triggered a renewed interest in hardware support for isolation. Extended page table switching with VMFUNC, memory protection keys (MPK), and memory tagging extensions (MTE) are just a few of the hardware isolation mechanisms that promise support for low-overhead isolation in recent CPUs. Along with the restored interest in lightweight hardware isolation mechanisms, safe programming languages like Rust has made a leap towards practical, zero-overhead safety implemented without garbage collection. Both lightweight hardware mechanisms and zero-overhead language safety can be leveraged to enforce the isolation of subsystems, e.g., browser plugins, device drivers and kernel extensions, user-defined database and network functions, etc. However, as both technologies are still young, their relative advantages are still unknown. In this work, we study the overheads of hardware and software isolation mechanisms with the goal to understand their relative advantages and disadvantages for fine-grained isolation of subsystems with tight performance budgets. We ask two questions: What is the overhead of hardware isolation in an ideal scenario where the hardware isolation mechanism takes zero cycles? And if the safety of the Rust language can lower the overhead of cross-subsystem invocations, can the language on its own introduce overheads that might outweigh isolation advantages? To answer these questions, we develop and compare two carefully optimized versions of inter-process communication (IPC) mechanisms (one in safe Rust and one in a carefully-optimized assembly), and two identical (to the degree possible) DPDK-based network packet processing frameworks (one in C++ and one in Rust). Our analysis shows that for systems requiring frequent boundary crossings, a safe language is still beneficial even if the overheads of hardware isolation mechanisms drop to zero.","PeriodicalId":136137,"journal":{"name":"Proceedings of the 11th Workshop on Programming Languages and Operating Systems","volume":"16 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2021-10-25","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"129682835","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}

引用次数: 3

Asterope Asterope

Proceedings of the 11th Workshop on Programming Languages and Operating Systems Pub Date : 1922-12-31 DOI: 10.1515/9783111597232-032

Giorgos Kappes, S. Anastasiadis

引用次数: 0

首页上一页