Memory bandwidth limitations of future microprocessors
ISCA '96 Proceedings of the 23rd annual international symposium on Computer architecture
A method for overlapping and erasure of lists
Communications of the ACM
An on-the-fly reference counting garbage collector for Java
OOPSLA '01 Proceedings of the 16th ACM SIGPLAN conference on Object-oriented programming, systems, languages, and applications
A Study of the Allocation Behavior of the SPECjvm98 Java Benchmark
ECOOP '99 Proceedings of the 13th European Conference on Object-Oriented Programming
Concurrent Cycle Collection in Reference Counted Systems
ECOOP '01 Proceedings of the 15th European Conference on Object-Oriented Programming
Ulterior reference counting: fast garbage collection without a long wait
OOPSLA '03 Proceedings of the 18th annual ACM SIGPLAN conference on Object-oriented programing, systems, languages, and applications
Myths and realities: the performance impact of garbage collection
Proceedings of the joint international conference on Measurement and modeling of computer systems
The DaCapo benchmarks: java benchmarking development and analysis
Proceedings of the 21st annual ACM SIGPLAN conference on Object-oriented programming systems, languages, and applications
The java hotspotTM server compiler
JVM'01 Proceedings of the 2001 Symposium on JavaTM Virtual Machine Research and Technology Symposium - Volume 1
Proceedings of the 2008 ACM SIGPLAN conference on Programming language design and implementation
Performance comparison of PHP and JSP as server-side scripting languages
Proceedings of the 9th ACM/IFIP/USENIX International Conference on Middleware
A study of memory management for web-based applications on multicore processors
Proceedings of the 2009 ACM SIGPLAN conference on Programming language design and implementation
Scaling the bandwidth wall: challenges in and avenues for CMP scaling
Proceedings of the 36th annual international symposium on Computer architecture
Allocation wall: a limiting factor of Java applications on emerging multi-core platforms
Proceedings of the 24th ACM SIGPLAN conference on Object oriented programming systems languages and applications
Evaluation of a just-in-time compiler retrofitted for PHP
Proceedings of the 6th ACM SIGPLAN/SIGOPS international conference on Virtual execution environments
Da capo con scala: design and analysis of a scala benchmark suite for the java virtual machine
Proceedings of the 2011 ACM international conference on Object oriented programming systems languages and applications
Down for the count? Getting reference counting back in the ring
Proceedings of the 2012 international symposium on Memory Management
new Scala() instance of Java: a comparison of the memory behaviour of Java and Scala programs
Proceedings of the 2012 international symposium on Memory Management
Taking off the gloves with reference counting Immix
Proceedings of the 2013 ACM SIGPLAN international conference on Object oriented programming systems languages & applications
Hi-index | 0.00 |
Implementing a new programming language system is a daunting task. A common trap is to punt on the design and engineering of exact garbage collection and instead opt for reference counting or conservative garbage collection (GC). For example, AppleScript™, Perl, Python, and PHP implementers chose reference counting (RC) and Ruby chose conservative GC. Although easier to get working, reference counting has terrible performance and conservative GC is inflexible and performs poorly when allocation rates are high. However, high performance GC is central to performance for managed languages and only becoming more critical due to relatively lower memory bandwidth and higher memory latency of modern architectures. Unfortunately, retrofitting support for high performance collectors later is a formidable software engineering task due to their exact nature. Whether they realize it or not, implementers have three routes: (1) forge ahead with reference counting or conservative GC, and worry about the consequences later; (2) build the language on top of an existing managed runtime with exact GC, and tune the GC to scripting language workloads; or (3) engineer exact GC from the ground up and enjoy the correctness and performance benefits sooner rather than later. We explore this conundrum using PHP, the most popular server side scripting language. PHP implements reference counting, mirroring scripting languages before it. Because reference counting is incomplete, the implementors must (a) also implement tracing to detect cyclic garbage, or (b) prohibit cyclic data structures, or (c) never reclaim cyclic garbage. PHP chose (a), AppleScript chose (b), and Perl chose (c). We characterize the memory behavior of five typical PHP programs to determine whether their implementation choice was a good one in light of the growing demand for high performance PHP. The memory behavior of these PHP programs is similar to other managed languages, such as Java™ ---they allocate many short lived objects, a large variety of object sizes, and the average allocated object size is small. These characteristics suggest copying generational GC will attain high performance. Language implementers who are serious about correctness and performance need to understand deferred gratification: paying the software engineering cost of exact GC up front will deliver correctness and memory system performance later.