We introduce a new family of connectivity-based garbage collectors (Cbgc) that are based on potential objectconnectivity properties. The key feature of these collectors is that the placement of objects into partitions is determined by performing one of several forms of connectivity analyses on the program. This enables partial garbage collections, as in generational collectors, but without the need for any write barrier.

Many garbage-cE6zcc systems use a single garbagecrb lecbag algorithmacrit allapplicRz"FRN It has long been known that thisci pro duc poor performanc onapplic# tions forwhic h thatcatz#E6N is not well suited. In some systems,suc h as those thatexec#6 stand-alonectand-a execd-alone an appropriatecppropri foreac happlic"FER ca be selecz" from a pool of availablecblezqS96 and tuned by using profile information. In a study of 20 benc hmarks and several cz99EOz"FS cz99EO with the Marmot optimizing Java-to-native c#qRO#z" for everycyzq#SFO there was at least one benc hmark that would have been at least 15% faster with a more appropriatecpropriat The czqE69Oz" are acO ying cgz9qFqz" a generationalce yingcgzqq6Oqz whic h is cz bined witheac h of 4 di#erent write barriers, and the null c6NN9z"EF whic h allo cloz but neverczq#qRSz A detailed analysis of storage managementc#Nq shows how they vary by applicEq#9 and cz#q9SFz" 1. INTRODUCTION Automatic storage management eliminates a significz t so...

The Java language is popular because of its platform independence, making it useful in a lot of technologies ranging from embedded devices to high-performance systems. The platform-independent property of Java, which is visible at the Java bytecode level, is only made possible thanks to the availability of a Virtual Machine (VM), which needs to be designed specifically for each underlying hardware platform. More specifically, the same Java bytecode should run properly on a 32-bit or a 64-bit VM. In this paper, we compare the behavioral characteristics of 32-bit and 64-bit VMs using a large set of Java benchmarks. This is done using the Jikes Research VM as well as the IBM JDK 1.4.0 production VM on a PowerPC-based IBM machine. By running the PowerPC machine in both 32-bit and 64-bit mode we are able to compare 32-bit and 64-bit VMs. We conclude that the space an object takes in the heap in 64-bit mode is 39.3% larger on average than in 32-bit mode. We identify three reasons for this: (i) the larger pointer size, (ii) the increased header and (iii) the increased alignment. The minimally required heap size is 51.1 % larger on average in 64-bit than in 32-bit mode. From our experimental setup using hardware performance monitors, we observe that 64-bit computing typically results in a significantly larger number of data cache misses at all levels of the memory hierarchy. In addition, we observe that when a sufficiently large heap is available, the IBM JDK 1.4.0 VM is 1.7 % slower on average in 64-bit mode than in 32-bit mode. Copyright c ○ 2005