Catálogo de publicaciones - libros

Compartir en
redes sociales


ECOOP 2006: Object-Oriented Programming: 20th European Conference, Nantes, France, July 3-7, 2006, Proceedings

Dave Thomas (eds.)

En conferencia: 20º European Conference on Object-Oriented Programming (ECOOP) . Nantes, France . July 3, 2006 - July 7, 2006

Resumen/Descripción – provisto por la editorial

No disponible.

Palabras clave – provistas por la editorial

No disponibles.

Disponibilidad
Institución detectada Año de publicación Navegá Descargá Solicitá
No detectada 2006 SpringerLink

Información

Tipo de recurso:

libros

ISBN impreso

978-3-540-35726-1

ISBN electrónico

978-3-540-35727-8

Editor responsable

Springer Nature

País de edición

Reino Unido

Fecha de publicación

Información sobre derechos de publicación

© Springer-Verlag Berlin Heidelberg 2006

Tabla de contenidos

Design Patterns – 15 Years Later

Erich Gamma

Design patterns are now a 15 year old thought experiment. And, today, for many, software design patterns have become part of the standard development lexicon. The reason is simple: rather than constantly redis-covering solutions to recurring design problems developers can refer to a body of literature that captures the best practices of system design. This talks looks back to the origins of design patterns, shows design patterns in action, and provides an overview of where patterns are today.

- Keynote | Pp. 1-1

Scalable Source Code Queries with Datalog

Elnar Hajiyev; Mathieu Verbaere; Oege de Moor

Source code querying tools allow programmers to explore relations between different parts of the code base. This paper describes such a tool, named It combines two previous proposals, namely the use of logic programming and database systems.

As the query language we use , which was originally introduced in the theory of databases. That provides just the right level of expressiveness; in particular recursion is indispensable for source code queries. Safe Datalog is like Prolog, but all queries are guaranteed to terminate, and there is no need for extra-logical annotations.

Our implementation of Datalog maps queries to a relational database system. We are thus able to capitalise on the query optimiser provided by such a system. For recursive queries we implement our own optimisations in the translation from Datalog to SQL. Experiments confirm that this strategy yields an efficient, scalable code querying system.

- Program Query and Persistence | Pp. 2-27

Efficient Object Querying for Java

Darren Willis; David J. Pearce; James Noble

Modern programming languages have little or no support for querying objects and collections. Programmers are forced to hand code such queries using nested loops, which is both cumbersome and inefficient. We demonstrate that first-class queries over objects and collections improve program readability, provide good performance and are applicable to a large number of common programming problems. We have developed a prototype extension to Java which tracks all objects in a program using AspectJ and allows first-class queries over them in the program. Our experimental findings indicate that such queries can be significantly faster than common programming idioms and within reach of hand optimised queries.

- Program Query and Persistence | Pp. 28-49

Automatic Prefetching by Traversal Profiling in Object Persistence Architectures

Ali Ibrahim; William R. Cook

Object persistence architectures support transparent access to persistent objects. For efficiency, many of these architectures support queries that can associated objects as part of the query result. While specifying prefetch manually in a query can significantly improve performance, correct prefetch specifications are difficult to determine and maintain, especially in modular programs. Incorrect prefetching is difficult to detect, because prefetch is only an optimization hint. This paper presents , a technique for automatically generating prefetch specifications using traversal profiling in object persistence architectures. generates prefetch specifications based on previous executions of similar queries. In contrast to previous work, can fetch arbitrary traversal patterns and can execute the optimal number of queries. has been implemented as an extension of Hibernate. We demonstrate that improves performance of traversals in the OO7 benchmark and can automatically predict prefetches that are equivalent to hand-coded queries, while supporting more modular program designs.

- Program Query and Persistence | Pp. 50-73

The Runtime Structure of Object Ownership

Nick Mitchell

Object-oriented programs often require large heaps to run properly or meet performance goals. They use high-overhead collections, bulky data models, and large caches. Discovering this is quite challenging. Manual browsing and flat summaries do not scale to complex graphs with 20 million objects. Context is crucial to understanding responsibility and inefficient object connectivity.

We summarize memory footprint with help from the dominator relation. Each dominator tree captures unique ownership. Edges between trees capture responsibility. We introduce a set of , and quantify their abundance. We aggregate these structures, and use thresholds to identify important aggregates. We introduce the to summarize responsibility, and to aggregate patterns within trees. Our implementation quickly generates concise summaries. In two minutes, it generates a 14-node ownership graph from 29 million objects. Backbone equivalence identifies a handful of patterns that account for 80% of a tree’s footprint.

- Ownership and Concurrency | Pp. 74-98

On Ownership and Accessibility

Yi Lu; John Potter

Ownership types support information hiding by providing statically enforceable object encapsulation based on an ownership tree. However ownership type systems impose fixed ownership and an inflexible access policy. This paper proposes a novel type system which generalizes ownership types by separating object accessibility and reference capability. With the ability to hide owners, it provides a more flexible and useful model of object ownership.

- Ownership and Concurrency | Pp. 99-123

Scoped Types and Aspects for Real-Time Java

Chris Andreae; Yvonne Coady; Celina Gibbs; James Noble; Jan Vitek; Tian Zhao

Real-time systems are notoriously difficult to design and implement, and, as many real-time problems are safety-critical, their solutions must be reliable as well as efficient and correct. While higher-level programming models (such as the Real-Time Specification for Java) permit real-time programmers to use language features that most programmers take for granted (objects, type checking, dynamic dispatch, and memory safety) the compromises required for real-time execution, especially concerning memory allocation, can create as many problems as they solve. This paper presents Scoped Types and Aspects for Real-Time Systems (STARS) a novel programming model for real-time systems. Scoped Types give programmers a clear model of their programs’ memory use, and, being statically checkable, prevent the run-time memory errors that bedevil models such as RTSJ. Our Aspects build on Scoped Types guarantees so that Real-Time concerns can be completely separated from applications’ base code. Adopting the integrated Scoped Types and Aspects approach can significantly improve both the quality and performance of a real-time Java systems, resulting in simpler systems that are reliable, efficient, and correct.

- Ownership and Concurrency | Pp. 124-147

Transparently Reconciling Transactions with Locking for Java Synchronization

Adam Welc; Antony L. Hosking; Suresh Jagannathan

Concurrent data accesses in high-level languages like Java and C# are typically mediated using mutual-exclusion locks. Threads use locks to the operations performed while the lock is held, so that the lock’s guarded operations can never be interleaved with operations of other threads that are guarded by the same lock. This way both and properties of a thread’s guarded operations are enforced. Recent proposals recognize that these properties can also be enforced by concurrency control protocols that avoid well-known problems associated with locking, by transplanting notions of found in database systems to a programming language context. While higher-level than locks, software transactions incur significant implementation overhead. This overhead cannot be easily masked when there is little contention on the operations being guarded.

We show how mutual-exclusion locks and transactions can be reconciled transparently within Java’s monitor abstraction. We have implemented monitors for Java that execute using locks when contention is low and switch over to transactions when concurrent attempts to enter the monitor are detected. We formally argue the correctness of our solution with respect to Java’s execution semantics and provide a detailed performance evaluation for different workloads and varying levels of contention. We demonstrate that our implementation has low overheads in the uncontended case (7% on average) and that significant performance improvements (up to 3×) can be achieved from running contended monitors transactionally.

- Ownership and Concurrency | Pp. 148-173

Object Technology – A Grand Narrative?

Steve Cook

This brief article sets out some personal observations about the development of object technology from its emergence until today, and suggests how it will develop in the future.

- Special 20th Anniversary Session | Pp. 174-179

Peak Objects

William R. Cook

I was aware of a need for object-oriented programming long before I learned that it existed. I felt the need because I was using C and Lisp to build medium-sized systems, including a widely-used text editor, CASE and VLSI tools. Stated simply, I wanted flexible connections between providers and consumers of behavior in my systems. For example, in the text editor anything could produce text (files, in-memory buffers, selections, output of formatters, etc) and be connected to any consumer of text. Object-oriented programming solved this problem, and many others; it also provided a clearer way to the problems. For me, this thinking was very pragmatic: object solved practical programming problems cleanly.

- Special 20th Anniversary Session | Pp. 180-185