Tensor Scope and resource management
オープン
まだ誰も着手していません。
- 主要言語
- Java
- スター
- 928
- フォーク
- 227
- PR マージ指標
- 30日以内にマージされた PR はありません
説明
cc @saudet @karllessard @Craigacp
This issue is for TensorScope and tensor resource management more generally, as discussed in #181 and the community call.
I'm envisioning usage like (or with try-with-resources):
TensorScope scope = new TensorScope();
TInt32 input = stuff;
TInt32 result = function(input).detach();
scope.close();
// result is accessible here, input and any tensors created in function() are not
A few issues I'd like comment on:
- NDArrays. As mentioned in https://github.com/tensorflow/java/issues/181#issuecomment-755863642, it's possible to have a NDArray opaquely backed by a tensor. The tensor could be closed by a
TensorScope, making the NDArray inaccessible in a way that probably won't make sense to users. I plan to addisNativeBuffer()andcloseNativeBuffer()to NDArray, and some Javadoc comments about this, so I think it's ok as the default behavior, but I also think it would be a good idea to haveTensorScopehave an option to copy out NDArrays on close (i.e. to a Java buffer). Not sure how it would be implemented yet, but it should be possible. When exactly to do it is more complicated. We don't want to do it for every NDArray, because that would include every TType, but we may want to do it for non-TType NDArrays that use one of those buffers. - Threading: how much do we want to support multithreading? PointerScope uses ThreadLocal, which is necessary for the global scope stacks, but prevents running parts of a model in another thread, if that's even supported in the first place.
PointerScope(@saudet). We discussed implementing this by wrapping PointerScope, but that means that as far as I understand it, the PointerScope would pick up any other pointers, too. It seems better to re-implement the tracking ourselves, which would be necessary for things like copying out NDArrays anyways, and usingTF_Tensor's reference counting.RawTensoralso already usesPointerScopeinternally, so I think that takes care of the reference counting.TF_Tensor's deallocator doesn't implementReferenceCounter, which as far as I can tell will make the reference counting not work. @saudetTF_TensorandTFE_TensorHandle. Do I need to trackTFE_TensorHandleas well?- More broadly, this waits until the end of the scope to do any cleanup, where especially for eager mode we want to remove temporary variables as soon as they are un-live. Am I correct that when using
Operands in eager mode, we don't actually realize the tensors in Java and cleanup is done by TF's native side?
TensorMapper#nativeHandle also probably needs to call retainReference, depending on the semantics we want.
コントリビューションガイド
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
調査の方向性
まず issue #181 と TensorScope に関する議論を読み、次に PointerScope、RawTensor、NDArray、TensorMapper#nativeHandle を調査してください。TF_Tensor と TFE_TensorHandle の参照カウントが現在どのように機能しているかを確認してください。scope、スレッド処理、コピー、cleanup のセマンティクスが決定され、実装されて初めて作業は完了します。
索引モデルが issue の本文から書いたものです。
評価
- 技術スタック
- java
- 領域
- machine-learning
- issue の種類
- 機能追加
- 難易度
- 5/5
- 見積もり時間
- 1週間以上
- 活発さ
- 停滞
- 明瞭さ
- 説明が足りない
- 初心者へのやさしさ
- 20/100