OPE User Guide

Relocation


General Information on Relocation

What is relocation?

Relocation is the process of adjusting any virtual memory pointer contained in user data to correspond to the actual memory location of the data to which it points.

When a page is fetched from the Server, the client might relocate it. Relocation might not be necessary, if the data to which pointers exist can be placed in the memory that is used when the data is created.

Which segments are involved in relocation?

OPE shows you information about relocation as counters (pages relocated) in the Client Counters/Ratios diagram and as events in the PageState diagram. To see the counters or events, do the following:

Use the counter pages relocated to find transactions with relocation activity. Use the Storage Counters/Ratios diagram to isolate this activity to the segment level.

What is the reason for relocation?

One or more of the following reasons are possible:

Inbound/outbound relocation of persistent pointers (for a detailed description refer to Inbound and Outbound relocation in ObjectStore Performance).

The C++ virtual function table pointer of a persistent object is adjusted to a process-specific value.

Corresponds to adjustments in support of ObjectStore's architectural heterogeneity support, such as byte swapping.

Corresponds to adjustments for ObjectStore's compiler heterogeneity, such as moving virtual function table pointers.

Corresponds to check_illegal_pointers or null_illegal_pointers mode.

Corresponds to the mode where the application activates access hooks.

Relocation of virtual base pointers.

OPE shows you the reason for a relocation event in the Show Details dialog of the PageState diagram. This dialog also indicates the direction of the relocation (inbound or outbound). To get the dialog directly, click on an event with the right mouse button.

Defining Address Space Reservation

How can you determine address space reservation?

The ObjectStore client reserves parts of virtual memory for use by the persistent data of the application. During a transaction, pages from the user's database are mapped into virtual memory when they are needed.

Address space that is reserved over the course of a transaction is released at the end of each transaction (unless objectstore::retain_persistent_addresses() is in use).

The amount of the address space reserved by the client can be higher than the actual amount of persistent data used by the application. This might cause a situation where the amount of virtual memory available approaches a minimum. For detailed information refer to Pseudoaddresses in ObjectStore Performance.

The unassigned address space graph of the Client Counters/Ratios diagram shows you the amount of address space available.

Note that OPE usually records a single value for unassigned address space at the end of the transaction before commit. OPE can record additional samples by raising one or more generic events during the transaction. For more information on generic events refer to Chapter 8, OPE Retriever.



support@objectstore.net
Copyright © 2004 Progress Software Corporation. All rights reserved.