Cached internal stack of LuaClosure

[Getaji]

LuaClosure が頻繁に実行されると getNewStack が頻繁に呼び出され大量の stack が生成されメモリを圧迫するのでキャッシュ化。各インスタンスごとに20件まで (see MAX_STACK_CACHE_SIZE) を Stack<LuaValue[]> で管理する。

Stack<> で管理している理由

実行終了前 (stack 解放前) に再帰呼び出しなどによって同じインスタンスが実行される場合、新たな stack が必要になり、単一のキャッシュを使い回すことができない。そのため、実行が完了した際にキャッシュに回し、それをCollectionで複数管理する方針を採用した。

また、 stack のサイズが異なる場合は再生成が必要になるため、 LIFO Stack を使用することで、同じ階層での呼び出しで同じサイズの stack を再利用させることによる再生成の抑制を狙った。

注意点

• 頻繁に実行しなければ不要
• スレッドセーフではない
• キャッシュ化したスタックはLuaClosureインスタンス自体がGCされないとメモリに残り続ける
• Java SE 8以上をサポートし、Java MEでは動作しない

luaj-jse-3.0.2-custom.jar.zip

[Getaji]

再帰呼び出しで壊れたので修正を試みます。

[Getaji]

LuaClosureの実行完了後にスタックを freeStacks に格納し、それをキャッシュとすることで解決。

[Getaji]

Stack の総称型がJava 1.3では使用できなかったのでsource/targetを8に変更。
また、JME (Java ME) が総称型をサポートしておらず、目的の用途にJMEはないためビルドから削除。

[Getaji]

メモ: Stack を ArrayDeque に変更して検証したが、通常呼び出しと再起呼び出し両方で誤差レベルだったので Stack のままにする。サイズ変更による内部的な再割り当てが頻繁に発生するなら ArrayDeque のほうがいいと思われるが、目的の用途では比較的シンプルな関数の頻繁な呼び出しが多数を占めるので、再割り当てが発生しないケースの方が遥かに多い。