DIECKMANN, S., AND H OLZLE, U. A study of the allocation behavior of the SPECjvm98 Java benchmarks. In Proc. of the Thirteenth European Conference on Object-Oriented Programming (1999), R. Guerraoui, Ed., vol. 1628 of Lecture Notes in Computer Science, Springer-Verlag, pp. 92--115.  Home/Search   Document Details and Download   Summary   Related Articles   Check

.... analysis to reduce the size of the generated circuits for compilers that generate hardware implementations of programs written in C or similar programming languages [3, 4, 14, 17, 8] Dieckmann and Holzle have performed an in depth analysis of the memory allocation behavior of Java programs [10]. Although space is not their primary focus, their study does quantify the space overhead associated with the use of a two word header and of 8 byte alignment. In general, our measurements of the memory system behavior of Java programs broadly agree with their measurements. Sweeney and Tip [18] ....

Sylvia Dieckmann and Urs Holzle. A study of the allocation behavior of the SPECjvm98 Java benchmarks. In Proceedings of the 13th European Conference on Object-Oriented Programming, August 1999.

.... analysis to reduce the size of the generated circuits for compilers that generate hardware implementations of programs written in C or similar programming languages [3, 13, 15, 7] Dieckmann and Hoelzle have performed an in depth analysis of the memory allocation behavior of Java programs [9]. Although space is not their primary focus, their study does quantify the space overhead associated the use of a two word header and of 8 byte alignment. In general, our measurements of the memory system behavior of Java programs broadly agree with their measurements. Sweeny and Tip [16] did a ....

S. Dieckmann and U. Hoelzle. A study of the allocation behavior of the SPECjvm98 java benchmarks. In Proceedings of the 13th European Conference on ObjectOriented Programming, August 1999.

.... analysis to reduce the size of the generated circuits for compilers that generate hardware implementations of programs written in C or similar programming languages [4, 5, 17, 19, 10] Dieckmann and Holzle have performed an in depth analysis of the memory allocation behavior of Java programs [12]. Although space is not their primary focus, their study does quantify the space overhead associated with the use of a two word header and of 8 byte alignment. In general, our measurements of the memory system behavior of Java programs broadly agree with their measurements. Sweeney and Tip [21] ....

Sylvia Dieckmann and Urs Holzle. A study of the allocation behavior of the SPECjvm98 Java benchmarks. In Proceedings of the 13th European Conference on Object-Oriented Programming, August 1999.

....We use benchmarks from the SPECjvm98 suite in this experiment. SPECjvm98 programs are designed to measure the performance of entire Java platforms, including Java virtual machines, operating systems, and underlying hardware. A detailed analysis of SPECjvm98 is given by Dieckman and Holzle [11]. The eight benchmark programs we use are: 201 compress, a Java port of the 129.compress benchmark from SPEC CPU95 202 jess, an expert system shell 205 raytrace, a ray tracing program 209 db, which simulates a database system 213 javac, the Sun JDK 1.02 Java compiler, compiling ....

S. Dieckmann and U. Holzle. A study of the allocation behavior of the SPECjvm98 Java benchmarks. In Proceedings of the European Conference on Object-Oriented Programming, June 1999.

....to explain how it works. In this scheme, one of three colors (black, grey, and white) is assigned to each object during garbage collection. Initially, all objects start out white. Garbage collection roots are colored grey. Most programs allocate more than half of their space for nonreferences [27]. 67 During the mark phase, all grey objects are walked and marked black. All white objects that are reachable from a grey object are greyed before the grey object is marked black. This process is repeated until there are no more grey objects. At the end of the mark phase, all black objects are ....

....case, we run each benchmark in its own process. Table 5.2 shows how many write barriers are executed for a single run. Except for jack, these numbers confirm the numbers presented in Table 1 of an independent study by Dieckmann that investigated the allocation behavior of the SPECjvm98 benchmarks [27]. We note that the total number of writes includes not only the benchmark program but also includes writes executed in methods that belong to the runtime libraries. We found that when the implementation of certain runtime classes, such as java.util.Hashtable, changes, the number of writes can ....

[Article contains additional citation context not shown here]

Dieckmann, S., and H olzle, U. A study of the allocation behavior of the SPECjvm98 Java benchmarks. In Proceedings of the European Conference on Object-Oriented Programming (ECOOP'99) (Lisbon, Portugal, June 1999), Lecture Notes in Computer Science 1628, Springer-Verlag, pp. 92--115.

....support for object manipulation, stack processing and method invocation to enhance the execution speed of Java bytecodes based on characterizing some Java applications. In [18] and [17] the authors investigated the predictability of branches in the control flows of Java workloads. In [10] and [24] the memory behavior of Java workloads were characterized. More specifically, the studies in [10] were focused on the heap allocation behaviors and provided useful information for the designing of garbage collectors. In [24] the focus was on the characterization of memory access ....

....speed of Java bytecodes based on characterizing some Java applications. In [18] and [17] the authors investigated the predictability of branches in the control flows of Java workloads. In [10] and [24] the memory behavior of Java workloads were characterized. More specifically, the studies in [10] were focused on the heap allocation behaviors and provided useful information for the designing of garbage collectors. In [24] the focus was on the characterization of memory access behaviors in order to expose opportunities for improving cache and TLB performance. All these studies (except ....

[Article contains additional citation context not shown here]

S. Dieckmann and U. Holzle. A study of the allocation behavior of the SPECjvm98 Java benchmarks. In The European Conference on Object-Oriented Programming (ECOOP'99), 1999.

....of di#erent kinds of connectivity with lifetime. Stefanovic and Moss [35] explore the age distribution of objects. They collect their data by garbage collecting frequently. Unlike our work, Stefanovic and Moss do not empirically relate age behavior to connectivity. Dieckmann and Holzle [14] measure the distribution of object lifetimes, sizes, and types and the reference density (fraction of fields that contain pointers) for the SPECjvm98 benchmarks. They focus on traits inherent in individual objects, whereas we study connectivity between various objects and how it correlates with ....

S. Dieckmann and U. Holzle. A study of allocation behavior of the SPECjvm98 Java benchmarks. In European Conference for Object-Oriented Programming (ECOOP), 1999.

....further as it can invalidate past decisions taken by the optimizer. Both issues must be considered when eliminating redundant lock barriers. Another challenge is posed by the small size of objects, typically between 16 to 42 bytes and by a large number of individual objects accessed by programs [DH99], when compared to a typical database transaction. This requires space efficient lock management that scales well with the number of locks. Locking is traditionally implemented by associating a resource with a data structure that represents the lock protecting that resource. The data structure, ....

....of the memoization cache are used before memoization succeeds (up to 3) Undoing of updates is based on physical logging, i.e. log records hold the value of data items before their modification. Programs written in the Java programming language tend to generate a population of very small objects [DH99]. Their mutable part is often even smaller. This makes the recording of the whole mutable part of an object upon the very first update to it an interesting strategy: it avoids the use of an additional write barrier in the access path to objects. Instead, the existing lock barrier triggers logging ....

Dieckmann, S., and Hzle, U. A Study of the Allocation Behavior of the SPECjvm98 Java Benchmarks. 13 ECOOP, Lisbon, Portugal,1999.

....of Shuf et al. is that they are usually compressing the TIB pointer, while we are usually eliminating the thin lock word. The main disadvantage of their scheme is that if the number of prolific types exceeds 16, performance in both space and time will be adversely affected. Dieckmann and HOlzle [10] performed a detailed study of the allocation behavior of the SPECjvm98 benchmarks. Their measurements were all in terms of an idealized, abstract object model in which each instance object had a class pointer and each array object had a class pointer and a length note that this results in ....

DIECKMANN, S., AND HOLZLE, U. A study of the allocation behavior of the SPECjvm98 Java benchmarks. In Proceedings of the Thirteenth European Conference on ObjectOriented Programming (Lisbon, Portugal, 1999), R. GuelTaoui, Ed., vol. 1628 of Lecture Notes in Computer Science, Springer-Verlag, pp. 9115.

.... characterization of the execution behavior of the SPECjvm98 programs, in interpreted 4 mode and using JIT compilers and obtained similar results to the ones obtained in [10] None of these studies, however, looked at the different components of the JVM though Kim et al. 14] and Dieckman et al. [15] did examine the performance of the garbage collection phase alone in detail. 3. Methodology 3.1 Benchmarks The SPECjvm98 suite of benchmarks [3] is used to obtain the cache performance characteristics of the JVM. This suite contains a number of applications that are either real applications or ....

S.Dieckman and U.Holzle, A study of the allocation behavior of the SPECjvm98 Java benchmarks, ECOOP98, pages 92-115, July 1998.

....Since previous sections show that the worst case live memory L is the dominant factor to determine the garbage collection time, the live memory analysis provides the basis for the worst case garbage collection time analysis. We classify heap objects into global and local objects as suggested in [5]. While local objects are only reachable by the task that has allocated the objects in its context, global objects can be referenced by other tasks. As pointed out in [5] the amount of global live object is relatively stable throughout the program execution because global objects are ....

....for the worst case garbage collection time analysis. We classify heap objects into global and local objects as suggested in [5] While local objects are only reachable by the task that has allocated the objects in its context, global objects can be referenced by other tasks. As pointed out in [5], the amount of global live object is relatively stable throughout the program execution because global objects are significantly longer lived than local objects. On the other hand, the amount of local live objects continues to vary until the time at which the garbage collector is triggered. ....

S. Dieckmann and U. H61zle. A study of the allocation behavior of the specjvm98 java benchmarks. In Proceedings of the 13th European Conference on Object-Oriented Programming, Jun 1999.

....on the same coherence granule with the modi ed slot. Furthermore, the write barrier begins with a check whether the object is not dirty. The synchronization barrier is required only if the check is validated, i.e. the object is not dirty. Cost: As reported in a study of the SPECjvm98 benchmarks [15] and is implied by the results of Chilimbi and Larus [9] most objects are small. For example, the median of the object size runs between 12 to 24 [15] The size of the cache line ranges between 32 to 128 depending on the platform. Furthermore, our measures show that objects tested in the write ....

....barrier is required only if the check is validated, i.e. the object is not dirty. Cost: As reported in a study of the SPECjvm98 benchmarks [15] and is implied by the results of Chilimbi and Larus [9] most objects are small. For example, the median of the object size runs between 12 to 24 [15]. The size of the cache line ranges between 32 to 128 depending on the platform. Furthermore, our measures show that objects tested in the write barrier rarely turn out not dirty. For the javac benchmark this happens less than once in a hundred, and for the SPECjbb benchmark and all the other ....

Sylvia Dieckmann and Urs Holzle. A Study of the Allocation Behavior of the SPECjvm98 Java Benchmarks. Proceedings of the European Conference on Object-Oriented Programming (ECOOP'99), Lecture Notes on Computer Science, Springer Verlag, June

No context found.

DIECKMANN, S., AND H OLZLE, U. A study of the allocation behavior of the SPECjvm98 Java benchmarks. In Proc. of the Thirteenth European Conference on Object-Oriented Programming (1999), R. Guerraoui, Ed., vol. 1628 of Lecture Notes in Computer Science, Springer-Verlag, pp. 92--115.

No context found.

Sylvia Dieckmann and Urs Holzle. A Study of the Allocation Behavior of the SPECjvm98 Java Benchmarks. Proceedings of the European Conference on Object-Oriented Programming (ECOOP'99), Lecture Notes on Computer Science, Springer Verlag, June 1999.

No context found.

Sylvia Dieckmann and Urs Holzle. A study of the allocation behavior of the SPECjvm98 Java benchmarks. In Proceedings of the European Conference on Object-Oriented Programming (ECOOP). Springer Verlag, June 1999.

No context found.

S. Dieckmann and U. Holzle. A Study of the Allocation Behavior of the SPECjvm98 Java Benchmarks. In European Conference on Object-Oriented Programming, pages 92--115, 1999.

No context found.

S. Dieckmann and U. Holzle. A study of the allocation behavior of the specjvm98 Java benchmarks. In ECOOP-13, pages 92--115, June 1999.

No context found.

S. Dieckmann and U. Holzle. A study of the allocation behavior of the specjvm98 java benchmark. In Proceedings of the 13th European Conference on Object-Oriented Programming, pages 92--115, London, UK, 1999. Springer-Verlag.

No context found.

Sylvia Dieckmann and Urs Holzle. A study of allocation behavior of the SPECjvm98 Java benchmarks. In European Conference for Object-Oriented Programming (ECOOP), 1999.

No context found.

S. Dieckmann and U. Holzle. A study of the allocation behavior of the SPECjvm98 Java benchmarks. In Proceedings of the European Conference on Object-Oriented Programming, pages 92--115, June 1999.

No context found.

DIECKMANN, S., AND H OLZLE, U. A study of the allocation behavior of the SPECjvm98 Java benchmarks. In Proc. of the Thirteenth European Conference on Object-Oriented Programming (1999), R. Guerraoui, Ed., vol. 1628 of Lecture Notes in Computer Science, Springer-Verlag, pp. 92--115.

No context found.

Sylvia Dieckmann and Urs Hlzle. A study of the allocation behavior of the SPECjvm98 Java benchmarks. In Proceedings of ECOOP 1999.

No context found.

S. Dieckmann and U. Holzle. A study of the allocation behavior of the SPECjvm98 Java benchmarks. In the 13th European Conference on Object-Oriented Programming (ECOOP'99), Lisbon, Portugal, June 1999.

No context found.

Sylvia Dieckmann and Urs Holzle. A study of the allocation behavior of the SPECjvm98 Java benchmarks. In Proceedings of ECOOP 1999.

No context found.

Sylvia Dieckmann and Urs Holzle. A Study of the Allocation Behavior of the SPECjvm98 Java Benchmarks. Proceedings of the European Conference on Object-Oriented Programming (ECOOP'99), Lecture Notes on Computer Science, Springer Verlag, June 1999.

First 50 documents

Online articles have much greater impact   More about CiteSeer.IST   Add search form to your site   Submit documents   Feedback  

CiteSeer.IST - Copyright Penn State and NEC