Limitations when sampling [S]

Due to the virtual-machine architecture, it is not possible to sample inside accessors or system primitives. This means that an accessor or system primitive never appears in an execution tree, even though time is spent in these methods.

When sampling, the Stats tool installs an interrupt-service routine that relies on the timely delivery of asynchronous messages from the system timer. Accessors and system primitives do not check for asynchronous messages. As a result, the time spent in accessors and system primitives is recorded in the first timer tick after the accessor or system primitive has exited. The time is charged to the next method that checks for asynchronous messages.

For accessors and very fast system primitives, charging the time incorrectly is not harmful. The time is typically charged to the calling method, provided it checks for asynchronous messages.

A more serious problem occurs when a system primitive takes a long time. The following example demonstrates the problem:

| string |

name := 'primitive+short op'.

string := String new: 1024 * 10.

benchTimer start.

iterations timesRepeat: [

string

replaceFrom: 1

to: string size

with: string

startingAt: 1.

string isMemberOf: String].

benchTimer stop.

When this code fragment is sampled S], the time spent in the system primitive operation replaceFrom:to:with:startingAt: is incorrectly charged to isMemberOf:, because isMemberOf: is the first method that checks for asynchronous messages after the primitive operation.

Note:

If a method that is known to be fast has a large amount of time charged against it (and the method is not called many times), the time could have been incorrectly charged as described above. The time was actually spent in the preceding system primitive.