• New Feature
  • Status: Open
  • 2 Major
  • Resolution:
  • Byte Code Transform
  • prodmgmt
  • Reporter: teck
  • June 18, 2008
  • 0
  • Watchers: 0
  • October 22, 2010

Description

inspiration: http://forums.terracotta.org/forums/posts/list/1150.page

The basic idea of this feature request to make sure code that uses arrays doesn’t pay any extra instrumentation overhead. Array instrumentation is not particularly fast since we have to check a map to figure if a given array reference is managed or not. Given that arrays naturally lend themselves to tight code loops, the cost of the check really adds up. Code that works with multi-dimensional arrays get taxed even more.

A first optimization would be do to static analysis on methods that contain array instructions to prove that given references on the stack cannot possibly be managed (thus all TC instrumentation need not be added). An example is array reference that is new’d within the scope of the method and is neither assigned to any fields and/or passed to any methods. In this case there is no opportunity for it to become shared.

Another possibility is to discover loops and determine if the “isManaged” check can be done once instead of every time through the loop.

This type of analysis is challenging and tricky for sure, but it is possible

Comments

ROHIT REJA 2008-09-09

Arrays.sort(list) is ~10X slower with Terracotta instrumentation as compared to non-instrumented code. The list in context is not shared with tc.

Tim Eck 2008-09-09

Rohit’s comment is a little confusing. It might be both that are slow, but I can’t discern whether he is talking about java.uitl.Collections.sort(List) or java.util.Arrays.sort(..). The “Arrays” class has many sort() methods for various array types, but it doesn’t have one that deals with List