DOC PREVIEW
A STUDY OF THE ALLOCATION

This preview shows page 1-2-23-24 out of 24 pages.

Save
View full document
View full document
Premium Document
Do you want full access? Go Premium and unlock all 24 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 24 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 24 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 24 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 24 pages.
Access to all documents
Download any document
Ad free experience

Unformatted text preview:

A Study of the Allocation Behavior of theSPECjvm98 Java BenchmarksSylvia Dieckmann and Urs HölzleDepartment of Computer ScienceUniversity of CaliforniaSanta Barbara, CA 93106{sylvie, urs}@cs.ucsb.eduAbstract. We present an analysis of the memory usage for six of the Javaprograms in the SPECjvm98 benchmark suite. Most of the programs are real-world applications with high demands on the memory system. For eachprogram, we measured as much low level data as possible, including age andsize distribution, type distribution, and the overhead of object alignment.Among other things, we found that non-pointer data usually represents morethan 50% of the allocated space for instance objects, that Java objects tend tolive longer than objects in Smalltalk or ML, and that they are fairly small.1 IntroductionJava has brought garbage collection to the mainstream, being the first truly popularlanguage in the C/C++ tradition that requires garbage collection (GC). Since Javadiffers in many respects from other languages requiring GC, such as Smalltalk, ML, orLisp, the GC behavior of Java programs may well differ from that of programs writtenin other languages.To understand the GC performance of a system, one must study the allocationbehavior of the targeted applications. Every GC implementation leaves room for awaggonload of knobs and levers which impact performance, but tuning is difficult sincethe right settings depend on the characteristics of the executed program, which againdepends greatly on language features and implementation style. To better identify andoptimize garbage collectors, implementors need detailed empirical information aboutthe allocation behavior of applications. For that reason, many published studies analyzethe allocation behavior in the context of several languages, including Smalltalk, SML/NJ, Lisp, C, and C++ [Ung86, SM94, HMN97, HH+98, Zor89, ZG92, DDZ94].However, no in-depth analysis of Java programs has been published to date, in partbecause of the lack of a standardized benchmark suite.In this paper, we present the first in-depth analysis of the memory usage of realisticJava programs. Our study is based on the programs of the SPECjvm98 benchmark suiterecently released by the System Performance Evaluation Corporation [SPEC98]. Mostprograms are real-world applications with high demands on the memory system.For each program, we measure as much low-level data as practical. To test thegenerational hypothesis, we measure age distributions. To allow implementors to judgethe impact of segregating objects by type or size, we analyze the heap composition andidentify object groups (e.g., reference-free instance objects) which might benefit froma special treatment. To determine the impact of 8-byte object alignment, we simulate itseffects. Since every system is different and there are so many possible GC variants, wegenerally refrain from making recommendations based on the data. Instead, our objec-tive is to provide the GC community with detailed data that allows researchers to predictthe impact of many GC implementation decisions for Java applications.The remainder of this paper is organized as follows. Section 2 discusses relatedwork and previous studies of allocation behavior, and section 3 describes the bench-marks. Section 4 presents our experimental setup. In section 5 we discuss the resultsincluding our observations on object lifetimes, reference density, heap composition,and others. Section 6 compares our numbers to those reported for other languages wherepossible, and section 7 summarizes our results.2 Related WorkWhen implementing a language with garbage collection, it is essential to understandthe expected allocation behavior. Since allocation patterns not only depend on theexecuted applications but also more generally on language characteristics, researchershave studied this question independently for several programming languages. Most ofthe earlier papers focus on lifetime and survival rates in order to estimate the overheadfor generational GC. Later, after the basic characteristics of GC were understood,researchers became more interested in segregation approaches, special allocation strat-egies and others.Ungar, for example, who first implemented Generation Scavenging [Ung84] inBerkeley Smalltalk (BS), analyzed the dependencies between survival rate and nurserysize for Smalltalk-80 [Wil92]. Baker suggested theoretical models to explain allocationbehavior [Bak94, Bak93]. Hayes analyzed survival rates for long-lived objects inCedar, a Modula-like language, and found that objects that survive a certain age tend todie in clusters [Hay91].Zorn presented statistical numbers on eight large Lisp applications analyzed with anobject-level runtime system simulator [Zor89]. Unlike in most other studies (includingours), Zorn used memory reference counts as a metric for object lifetimes. Morerecently, Zorn et al. have studied large C/C++ programs, often in the context of lifetimeprediction and memory allocation [BZ93, ZS98, GJS96, ZG92, ZG94].Stefanovic and Moss analyze the allocation behavior of SML/NJ [SM94].Gonçalves discusses object age distribution in his study on cache performance [Gon95].We discuss these studies further in section 6.Nettles et al. developed Oscar [MHN97], a language-independent GC testbed thatcan be used to analyze object allocation behavior. Unlike our simulator, Oscar does nottrace heap activity but records frequent heap snapshots. Hicks et al. used Oscar toanalyze both SML/NJ and Java applications [HMN97, HH+98] but mostly focus onexecution time. Except for those studies, Java has not yet been the focus of an in-depthallocation behavior study. To the best of our knowledge, no other analysis of theSPECjvm98 benchmark suite has been published yet.3 BenchmarksAll of our measurements are based on six programs from the SPECjvm98 bench-mark suite [SPEC98], released in August 1998 by the System Performance EvaluationCorporation (SPEC). SPEC is a nonprofit organization of hardware vendors whoseobjective is to establish a standardized set of vendor-neutral, relevant, application-oriented benchmarks applicable to the newest generation of high-performancecomputers. Other popular SPEC benchmarks measure various system aspects such asCPU, NFS, and Web server performance.SPECjvm98 is shipped as a set of Java class files and is intended to measure the effi-ciency of Java Virtual Machine (JVM) implementations, i.e., the combination of JITcompiler, runtime system, OS,


A STUDY OF THE ALLOCATION

Download A STUDY OF THE ALLOCATION
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view A STUDY OF THE ALLOCATION and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view A STUDY OF THE ALLOCATION 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?