Join us at TensorFlow World, Oct 28-31. Use code TF20 for 20% off select passes. Register now

EagerSession.ResourceCleanupStrategy

public static final enum EagerSession.ResourceCleanupStrategy

Controls how TensorFlow resources are cleaned up when they are no longer needed.

All resources allocated during an EagerSession are deleted when the session is closed. To prevent out-of-memory errors, it is also strongly suggest to cleanup those resources during the session. For example, executing n operations in a loop of m iterations will allocate a minimum of n*m resources while in most cases, only resources of the last iteration are still being used.

EagerSession instances can be notified in different ways when TensorFlow objects are no longer being referred, so they can proceed to the cleanup of any resources they owned.

Inherited Methods

Enum Values

public static final EagerSession.ResourceCleanupStrategy IN_BACKGROUND

Monitor and delete unused resources from a new thread running in background.

This is the most reliable approach to cleanup TensorFlow resources, at the cost of starting and running an additional thread dedicated to this task. Each EagerSession instance has its own thread, which is stopped only when the session is closed.

This strategy is used by default.

public static final EagerSession.ResourceCleanupStrategy ON_SAFE_POINTS

Monitor and delete unused resources from existing threads, before or after they complete another task.

Unused resources are released when a call to the TensorFlow library reaches a safe point for cleanup. This is done synchronously and might block for a short period of time the thread who triggered that call.

This strategy should be used only if, for some reasons, no additional thread should be allocated for cleanup. Otherwise, IN_BACKGROUND should be preferred.

public static final EagerSession.ResourceCleanupStrategy ON_SESSION_CLOSE

Only delete resources when the session is closed.

All resources allocated during the session will remained in memory until the session is explicitly closed (or via the traditional `try-with-resource` technique). No extra task for resource cleanup will be attempted.

This strategy can lead up to out-of-memory errors and its usage is not recommended, unless the scope of the session is limited to execute only a small amount of operations.