Browse Prior Art Database

A Method for Initializing Objects

IP.com Disclosure Number: IPCOM000015754D
Original Publication Date: 2002-Jul-20
Included in the Prior Art Database: 2003-Jun-21
Document File: 3 page(s) / 31K

Publishing Venue

IBM

Abstract

Strongly-typed languages, like Java, require objects to be properly initialized before their use, preventing programs from referencing invalid values. The cost of initialization can be high, depending on programs, Disclosed is a method for reducing the cost, involving the compiler and the memory management system.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 51% of the total text.

Page 1 of 3

A Method for Initializing Objects

Strongly-typed languages, like Java, require objects to be properly
initialized before their use, preventing programs from referencing invalid
values. The cost of initialization can be high, depending on programs,
Disclosed is a method for reducing the cost, involving the compiler and the
memory management system.

Objects are implicitly initialized by the allocator, a routine in the runtime
system. When initializing an object, the allocator must be properly
synchronized with the garbage collector. In particular, the collector must not
be invoked when the allocator is initializing an object with a reference.
Otherwise, the collector would cause invalid memory access in tracing the
object.

A separate initialization was previously proposed to reduce the implicit
initialization. It exploits a property of object-oriented
programs. That is, it is common that objects are explicitly initialized in
their constructors. In the separate initialization,
the allocator no longer performs implicit initialization, while the compiler
generates intermediate code for implicit initialization at each allocation
site. It is very likely that the compiler inlines one or more constructors
and optimizes away the generated initialization code in the presence of
explicit initialization code.

However, it has a severely limited application. It cannot handle objects with
references for the above-mentioned synchronization requirement. We propose
two techniques to circumvent the limitation, one for the conservative
collector and the other for the type-accurate collector.

For the conservative collector, we extend conservativeness a little bit so
that the collector now conservatively traces objects if they are being
implicitly initialized. The collector can easily identify such objects since
the stacks contain references to them. That is, the collector conservatively
scans an object's field, if the object is referenced *directly* from the
stack.

For the type-accurate collector, we compute an unsafe region for each
allocation site, and prevent a thread from invoking the collector while some
other thread is executing a unsafe region.

Given an allocation site, the compiler computes the unsafe region in the
following manner. After gene...