Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Adds an IntArray pool to MacroEvaluator.Session and modifies Session's ExpansionInfo pool to match the pattern. #1038

Open
wants to merge 1 commit into
base: ion-11-encoding-pooled-expressions
Choose a base branch
from

Conversation

tgregg
Copy link
Contributor

@tgregg tgregg commented Jan 19, 2025

Description of changes:
The main idea here is that Session manages all pools relevant to macro evaluation. This works well because Session instances are already reused, so we can just reset its pools in bulk in Session.reset(), rather than worrying about releasing individual items back into their pools. I modified the existing ExpansionInfo pool to match this pattern, as well as adding a new IntArray pool for the array used to track argument end indices. This reduced allocation rate.

Speed: 247 ms/op -> 245 ms /op (-<1%)
Allocation rate: 175 KB/op -> 163 KB/op (-6.9%)

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

@tgregg tgregg requested a review from popematt January 19, 2025 02:50
Copy link
Contributor

@jobarr-amzn jobarr-amzn left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

With this we have by my count 6 pool use cases in ion-java.

Using Pool/Poolable:

  • utf8 string encoder pool
  • utf8 string decoder pool
  • bytebuffer pool

Not using Pool/Poolable:

  • Block allocator pool
  • expression pool
  • expander pool (this)

When do we use Pooled/Poolable, and when not?

Comment on lines 105 to 118
/**
* Gets an [IntArray] from the pool, or allocates a new one if necessary. The returned array is valid until
* [reset] is called.
* */
fun intArrayForSize(size: Int): IntArray {
if (size >= intArrayPools.size) {
// Don't attempt to pool arbitrarily large arrays.
return IntArray(size)
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Arrays smaller than intArrayPools.size are zeroed out when reset() is called, but larger arrays are not. I suppose one could say that the larger vended arrays are still only valid until reset is called?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

reset() doesn't zero any of the arrays in the pool, just the indices that point to the next available array in the pool for a given size. Arrays returned from this method are zeroed if freshly allocated, but not otherwise. I'll add a note that the returned array will not necessarily be zeroed.

@@ -44,19 +44,35 @@ class MacroEvaluator {
* This state pertains to a single "session" of the macro evaluator, and is reset every time [initExpansion] is called.
* For now, this includes managing the pool of [ExpansionInfo] and tracking the expansion step limit.
*/
private class Session(
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If this can't be private, can it at least be internal?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes; I should not have assumed IntelliJ's quick fix would suggest the most restrictive possible access modifier.

@@ -116,7 +151,7 @@ class MacroEvaluator {
*/
// TODO(PERF): It might be possible to optimize this by changing it to an enum without any methods (or even a set of
// integer constants) and converting all their implementations to static methods.
private enum class ExpansionKind {
enum class ExpansionKind {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If not private, then internal?

@@ -692,7 +727,7 @@ class MacroEvaluator {
* Alternately, consider ExpansionOperator to reflect the fact that these are
* like operators in an expression tree.
*/
private class ExpansionInfo(@JvmField val session: Session) {
class ExpansionInfo(@JvmField val session: Session) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should be internal.

@@ -51,4 +51,4 @@ internal inline fun confirm(assumption: Boolean, lazyMessage: () -> String) {
/**
* Marks a branch as unreachable (for human readability).
*/
internal fun unreachable(reason: String? = null): Nothing = throw IllegalStateException(reason)
fun unreachable(reason: String? = null): Nothing = throw IllegalStateException(reason)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should stay internal.

@tgregg
Copy link
Contributor Author

tgregg commented Jan 22, 2025

With this we have by my count 6 pool use cases in ion-java.

Using Pool/Poolable:

* utf8 string encoder pool

* utf8 string decoder pool

* bytebuffer pool

Not using Pool/Poolable:

* Block allocator pool

* expression pool

* expander pool (this)

When do we use Pooled/Poolable, and when not?

Pool/Poolable is a fairly heavy-weight abstraction that is good when the resources are fairly large, infrequently accessed, and accessed/freed individually. The BlockAllocator could be migrated to the Pool/Poolable abstraction if we felt like spending the time to do so.

For expressions and expanders, we need to access chunks of many at a time, and they can all be freed at once. Pooled/Poolable is heavy for this use case.

@tgregg tgregg force-pushed the ion-11-encoding-optimize-initial-expression-array-size-session-pools branch from 8161ef7 to 3c029c3 Compare January 22, 2025 01:31
@tgregg tgregg changed the base branch from ion-11-encoding-optimize-initial-expression-array-size-merge to ion-11-encoding January 28, 2025 00:12
@tgregg tgregg changed the base branch from ion-11-encoding to ion-11-encoding-pooled-expressions January 28, 2025 00:17
@tgregg tgregg force-pushed the ion-11-encoding-optimize-initial-expression-array-size-session-pools branch from 3c029c3 to 4d109cb Compare January 28, 2025 00:32
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants