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

Add tracking of allocated arrays. #5264

Closed
wants to merge 2 commits into from

Conversation

jpountz
Copy link
Contributor

@jpountz jpountz commented Feb 26, 2014

The BigArrays utility class is useful to generate arrays of various sizes: when
small, arrays will be allocated directly on the heap while larger arrays are
going to be paged and to recycle pages through PageCacheRecycler. We already
have tracking for pages but this is not triggered very often since it only
happens on large amounts of data while our tests work on small amounts of data
in order to be fast.

Tracking arrays directly helps make sure that we never forget to release them.

This pull request also improves testing by:

  • putting random content in the arrays upon release: this makes sure that
    consumers don't use these arrays anymore when they are released as their
    content may be subject to use for another purpose since pages are recycled
  • putting random content in the arrays upon creation and resize when
    clearOnResize is false.

The major difference with master is that the BigArrays class is now
instanciable, injected via Guice and usually available through the
SearchContext. This way, it can be mocked for tests.

@nik9000
Copy link
Member

nik9000 commented Feb 26, 2014

Neat.

@s1monw
Copy link
Contributor

s1monw commented Feb 26, 2014

cool stuff @jpountz

@@ -39,16 +38,17 @@
private final BytesRef spare;

// Constructor with configurable capacity and default maximum load factor.
public BytesRefHash(long capacity, PageCacheRecycler recycler) {
this(capacity, DEFAULT_MAX_LOAD_FACTOR, recycler);
public BytesRefHash(long capacity, BigArrays bigArrays) {
Copy link
Contributor

Choose a reason for hiding this comment

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

I really like this!

Copy link
Member

Choose a reason for hiding this comment

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

Oh, yeah, cool. I can totally use that.

On Wed, Feb 26, 2014 at 3:24 PM, Simon Willnauer
notifications@github.comwrote:

In
src/main/java/org/elasticsearch/search/aggregations/bucket/BytesRefHash.java:

@@ -39,16 +38,17 @@
private final BytesRef spare;

 // Constructor with configurable capacity and default maximum load factor.
  • public BytesRefHash(long capacity, PageCacheRecycler recycler) {
  •    this(capacity, DEFAULT_MAX_LOAD_FACTOR, recycler);
    
  • public BytesRefHash(long capacity, BigArrays bigArrays) {

I really like this!

Reply to this email directly or view it on GitHubhttps://github.com//pull/5264/files#r10097411
.

@s1monw
Copy link
Contributor

s1monw commented Feb 26, 2014

I left some comments but in general this looks awesome

The BigArrays utility class is useful to generate arrays of various sizes: when
small, arrays will be allocated directly on the heap while larger arrays are
going to be paged and to recycle pages through PageCacheRecycler. We already
have tracking for pages but this is not triggered very often since it only
happens on large amounts of data while our tests work on small amounts of data
in order to be fast.

Tracking arrays directly helps make sure that we never forget to release them.

This pull request also improves testing by:

 - putting random content in the arrays upon release: this makes sure that
   consumers don't use these arrays anymore when they are released as their
   content may be subject to use for another purpose since pages are recycled

 - putting random content in the arrays upon creation and resize when
   `clearOnResize` is `false`.

The major difference with `master` is that the `BigArrays` class is now
instanciable, injected via Guice and usually available through the
`SearchContext`. This way, it can be mocked for tests.
@jpountz
Copy link
Contributor Author

jpountz commented Feb 27, 2014

Thanks for the feedback, @s1monw. I rebased in order to get @martijnvg 's changes around p/c field data and added a new commit.

@s1monw
Copy link
Contributor

s1monw commented Feb 27, 2014

LGTM

@jpountz jpountz closed this Feb 27, 2014
@jpountz jpountz deleted the fix/paging_testability branch February 27, 2014 13:10
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants