Demonstration venue · read-only. Every page can be browsed; the buttons that would change it are switched off. Create an account to run TaxoReview on your own data. A simulation from public publication records: the people listed were not invited and did not agree to review.
? Tutorial for this page

Joel Scherpelz

dblp:94/9256 · DBLP profile ↗
← Back
3ranked-venue papers
0as first author
0since 2021 · last 2020
—ORCID · none

Domains — the database's venue-derived domains; a paper can count in several

Software engineering, systems software and programming languages · 2Systems, architecture and hardware · 1Computer networks · 1

Expertise — from the expertise taxonomy: the topics of the expert's papers under the CCF categories. A weight counts papers with recency: 1 for a paper about the topic, 0.3 when the topic is its context, halved every five years.

Computer architecture, parallel and distributed computing, and storage systems
1 paper
Cloud and datacenter computing · 50% Interconnection networks and networks-on-chip · 50%
Software engineering, system software, and programming languages
2 papers
Concurrent programming · 35% Debugging and program repair · 25% Software maintenance and evolution · 20%

Topics — the 7 heaviest of 8, each with the papers that count most for it

TopicWeightPapersLastEvidence papers
Cloud and datacenter computing › multi-tenancy
multi-tenant datacenter
0.412020
1RMA: Re-envisioning Remote Memory Access for Multi-tenant Datacenters · SIGCOMM 2020
Interconnection networks and networks-on-chip
remote direct memory access
0.412020
1RMA: Re-envisioning Remote Memory Access for Multi-tenant Datacenters · SIGCOMM 2020
Program analysis › static analysis
bug detection
0.112012
Understanding and detecting real-world performance bugs · PLDI 2012
Debugging and program repair › performance debugging
performance bug detection
0.112012
Understanding and detecting real-world performance bugs · PLDI 2012
Concurrent programming
concurrency bugs
0.112011
ConSeq: detecting concurrency bugs through sequential errors · ASPLOS 2011
Concurrent programming
concurrency bug detection
0.112011
ConSeq: detecting concurrency bugs through sequential errors · ASPLOS 2011
Debugging and program repair
fault localization
0.012011
ConSeq: detecting concurrency bugs through sequential errors · ASPLOS 2011

Methods — techniques the papers use, named apart from their topics

performance profiling · 0.1sequential error analysis · 0.1
YearPublicationVenuePosition
2020 1RMA: Re-envisioning Remote Memory Access for Multi-tenant Datacenters
abstract
Remote Direct Memory Access (RDMA) plays a key role in supporting performance-hungry datacenter applications. However, existing RDMA technologies are ill-suited to multi-tenant datacenters, where applications run at massive scales, tenants require isolation and security, and the workload mix changes over time. Our experiences seeking to operationalize RDMA at scale indicate that these ills are rooted in standard RDMA's basic design attributes: connectionorientedness and complex policies baked into hardware.
Arjun Singhvi, Aditya Akella, Dan Gibson, Thomas F. Wenisch, Monica Wong-Chan, Sean Clark 0003, Milo M. K. Martin, Moray McLaren, Prashant Chandra, Rob Cauble, Hassan M. G. Wassel, Behnam Montazeri, Simon L. Sabato, Joel Scherpelz, Amin Vahdat
SIGCOMM14
2012 Understanding and detecting real-world performance bugs
abstract
Developers frequently use inefficient code sequences that could be fixed by simple patches. These inefficient code sequences can cause significant performance degradation and resource waste, referred to as performance bugs. Meager increases in single threaded performance in the multi-core era and increasing emphasis on energy efficiency call for more effort in tackling performance bugs.
Guoliang Jin, Linhai Song, Joel Scherpelz, Shan Lu 0001
PLDI4
2011 ConSeq: detecting concurrency bugs through sequential errors
abstract
Concurrency bugs are caused by non-deterministic interleavings between shared memory accesses. Their effects propagate through data and control dependences until they cause software to crash, hang, produce incorrect output, etc. The lifecycle of a bug thus consists of three phases: (1) triggering, (2) propagation, and (3) failure.
Wei Zhang 0022, Junghee Lim, Ramya Olichandran, Joel Scherpelz, Guoliang Jin, Shan Lu 0001, Thomas W. Reps
ASPLOS4