Browse Prior Art Database

An Proactive Scanning Approach to Monitoring Object Lifecycle based on Weak Reference

IP.com Disclosure Number: IPCOM000177798D
Original Publication Date: 2009-Jan-05
Included in the Prior Art Database: 2009-Jan-05
Document File: 6 page(s) / 49K

Publishing Venue

IBM

Abstract

This invention provides a method to enable user monitor object’s lifecycle in Object Oriented languages without any modification to languages' runtime environment or the application itself. Compared with traditional approach, the proposed method uses a totally different way that relies on Byte Code Instrumentation and Object Oriented language support (e.g. weak reference) to monitor object’s lifecycle. The key ideas of our invention are A. Combine object's proactive notification with the agent's proactive scanning together to monitor object's lifecycle and usage information. B. Based on Weak Reference to detect object's recycle time. C. An newly designed data structure (ID tag in each object to reference flat one-one mapping tables) that enable very fast notification and scanning of the detection.

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

Page 1 of 6

An Proactive Scanning Approach to Monitoring Object Lifecycle based on Weak Reference

1. Background

This invention provides a method to enable user monitor object's lifecycle in Object Oriented languages without any modification to languages' runtime environment or the application itself.

The background is that standard object oriented programming practices leads to poor memory usage, which is called software bloat in academic area. For example, in IBM WAS (based on Java, the widely used OO language), there are huge memory usage pressures coming from (1) excessive allocation; (2) allocating objects much sooner than needed; (3) holding objects for too long, memory leaks, which lead to frequent garbage collection. However, bloat and excessive memory use hinder scalability because memory bandwidth is a finite resource in today's hardware system, and long living objects will not only occupy memory space, but also bring pressure to memory recycle, such as GC. We need tools to help user identify bloat.

Bloat includes size bloat and object lifecycle bloat. Lifecycle bloat means the object's living time is much longer than expected. Figure 1 shows the situation. Only the middle part of the object is useful. However, many objects' in OO language such as Java have a lot of objects that have long useless period and leak period.

Object GC

Allocation First use Last use No reference Lag (Useless period) Drag (Leak period)

Solution: lazy load Solution: clear

reference earlier

Figure 1, Object's lifecycle

However, identifying object's lifecycle is always a very difficulty problem, and there are very few practiced methods. Based on our detail survey, known solutions have the following disadvantages
1. Only provide statistics information of Object's lifecycle

Example:

JVMTI interface of Java, most commercial memory lifecycle tools are based on it.

Disadvantages

Only statistics information.

Cannot guide application optimization

Need modify Virtual Machine or need a customized Virtual Machine

Example:

     Ran Shaham , Elliot K. Kolodner , Mooly Sagiv, Heap profiling for space-efficient Java, PLDI 2001

     Jonas Maebe , Dries Buytaert , Lieven Eeckhout , Koen De Bosschere, Javana: a system for building customized Java program analysis tools, OOPSLA 2006

Disdvantages

It's very hard to apply to real production system
3. Large Overhead in speed or memory footprint

Example

DJProf - an Aspect-Oriented Java Profiler

Disadvantages

Large overhead - typically 100x

       Use hashSet to track every object - Both speed and memory footprint, and cannot scale well for multi-thread application (need synchronization)

Bad scalability

       Use PhantomReference to track object's clear time - Interference GC and doesn't scale well

Didn't track each object's usage information

1

No object usage information,

No individual object's info


2.

Page 2 of 6

2. Invention Main Idea

Our approach uses a totally different way that relies on Byte Code Instrumentation...