Browse Prior Art Database

Object instance specific tracing using reflection and re-casting to a "forgery" class

IP.com Disclosure Number: IPCOM000235465D
Publication Date: 2014-Mar-03
Document File: 2 page(s) / 39K

Publishing Venue

The IP.com Prior Art Database

Abstract

The use of tracing and/or instrumentation of source code with simple print statements is probably the most common form of debugging a software application. It is however limited in that every invocation of the traced/instrumented method or function results in the trace code being executed even if that particular execution of the code is not of interest. The usual approach to this is to wrap the trace generation with a simple check so that the majority of the trace code is only executed for the "interesting execution". However that still introduces an overhead for every execution of the method. A means that reduces that overhead further using reflection to identify objects for instrumentation, and an approach that instruments the object by re-casting it to a "forgery" class that mimics the behaviour of the original class but that includes the additional instrumentation, is therefore valuable.

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

Page 01 of 2

Object instance specific tracing using reflection and re-casting to a "forgery" class

The use of tracing and/or instrumentation of source code with simple print statements is probably the most common form of debugging a software application. It is however limited in that every invocation of the traced/instrumented method or function results in the trace code being executed even if that particular execution of the code is not of interest. The usual approach to this is to wrap the trace generation

with a simple check so that the majority of the trace code is only executed for the

"interesting execution".

    The overhead of checking and executing trace code for "uninteresting" calls of the code is particularly apparent in object orientated languages where the same code is used for completely different objects. An example of this would be to detect a memory leak relating to an instance of java.util.HashMap - there may be 1000s of instances of java.util.HashMap in use, but only one instance needs to be traced/instrumented in order to determine what code is responsible for adding objects to the HashMap and not subsequently removing it.

    The usual approach here to minimise the overhead would be to check in every HashMap.put() call whether this instance of HashMap is interesting either by a direct check against the object, or using a lookup table of interesting HashMaps. This however has an overhead for every HashMap.put() call.

    This problem is more apparent in the area of multi-tenancy. Here it would be desirable to be able to add tracing to objects associated with one tenant, but not

with another, or indeed for each tenant to having different tracing/instrumentation for the same class.

    There is therefore value to a mechanism for object orientated languages to allow tracing and instrumentation to be carried out on an object specific instance specific basis that minimises or removes the overhead when executing the method again uninteresting objects.

    The cost of tracing/instrumenting uninteresting instances of the object type can be achieved by using a reflection based mechanism to determine if there are any "interesting" object instances of that type, and if interesting objects are found re-casting those objects at the Java Virtual Machine (JVM)level to a "forgery" version of the class: one that looks and acts identically (isInstance() and cast checks equate to the same) but that can have modified method implementations.

    When the methods of the "forgery" class are executed...