Skip to content

Limit memory consumption in test on overflow#17373

Merged
andsel merged 6 commits intoelastic:mainfrom
andsel:fix/limit_heap_consumption_in_test
Mar 26, 2025
Merged

Limit memory consumption in test on overflow#17373
andsel merged 6 commits intoelastic:mainfrom
andsel:fix/limit_heap_consumption_in_test

Conversation

@andsel
Copy link
Copy Markdown
Member

@andsel andsel commented Mar 20, 2025

Release notes

[rn:skip]

What does this PR do?

Updates only test code to be able to run a test that consumes big memory if:

  • the physical memory is bigger than the requested Java heap
  • JDK version is greater than or equal to 21.

The reason to limit the JDK version is that on 16GB machine the G1GC is more efficient than the one on previous JDKs and so let complete the test with 10GB heap, while in JDK 17 it consistently fails with OOM error.

Why is it important/What is the impact to the user?

N/A

Checklist

  • My code follows the style guidelines of this project
  • I have commented my code, particularly in hard-to-understand areas
  • [ ] I have made corresponding changes to the documentation
  • [ ] I have made corresponding change to the default configuration files (and/or docker env variables)
  • I have added tests that prove my fix is effective or that my feature works

Author's Checklist

  • tested on ubuntu 2024 16GB RAM VM with JDK 11, 17 and 21

How to test this PR locally

Related issues

@mergify
Copy link
Copy Markdown
Contributor

mergify bot commented Mar 20, 2025

This pull request does not have a backport label. Could you fix it @andsel? 🙏
To fixup this pull request, you need to add the backport labels for the needed
branches, such as:

  • backport-8./d is the label to automatically backport to the 8./d branch. /d is the digit.
  • backport-8.x is the label to automatically backport to the 8.x branch.
  • If no backport is necessary, please add the backport-skip label

@andsel andsel force-pushed the fix/limit_heap_consumption_in_test branch from 8c7b3f4 to cff2dba Compare March 24, 2025 15:03
@andsel andsel self-assigned this Mar 24, 2025
@andsel andsel marked this pull request as ready for review March 24, 2025 16:31
@andsel
Copy link
Copy Markdown
Member Author

andsel commented Mar 25, 2025

Why the test requires 10GB of JVM heap?

To explain why the test needs 10GB while it just allocate 2GB string it's needed to see all the allocations that are done.

With 4GB the test is not able to allocate space for the RubyString at https://github.com/elastic/logstash/pull/17373/files#diff-6c455e621a523fb4c88050efc394a576e69e0c0ef293b93ced25d8c4b6cadab4R161

Stack trace 4GB
org.logstash.common.BufferedTokenizerExtWithSizeLimitTest > givenTooLongInputExtractDoesntOverflow FAILED
    java.lang.OutOfMemoryError: Java heap space
        at java.base/java.nio.HeapByteBuffer.<init>(HeapByteBuffer.java:71)
        at java.base/java.nio.ByteBuffer.allocate(ByteBuffer.java:391)
        at java.base/java.nio.charset.CharsetEncoder.encode(CharsetEncoder.java:814)
        at java.base/java.nio.charset.Charset.encode(Charset.java:904)
        at org.jruby.RubyEncoding.doEncodeUTF8(RubyEncoding.java:223)
        at org.jruby.RubyString.encodeBytelist(RubyString.java:6820)
        at org.jruby.RubyString.<init>(RubyString.java:403)
        at org.jruby.RubyString.newString(RubyString.java:483)
        at org.jruby.Ruby.newString(Ruby.java:3516)
        at org.logstash.common.BufferedTokenizerExtWithSizeLimitTest.generateString(BufferedTokenizerExtWithSizeLimitTest.java:161)
        at org.logstash.common.BufferedTokenizerExtWithSizeLimitTest.givenTooLongInputExtractDoesntOverflow(BufferedTokenizerExtWithSizeLimitTest.java:147)

With 6GB the extract method is not able to reserve the space to convert the RubyString to Java String (this is a second copy)

Stack trace 6GB
org.logstash.common.BufferedTokenizerExtWithSizeLimitTest > givenTooLongInputExtractDoesntOverflow FAILED
    java.lang.OutOfMemoryError: Java heap space
        at java.base/java.nio.HeapCharBuffer.<init>(HeapCharBuffer.java:71)
        at java.base/java.nio.CharBuffer.allocate(CharBuffer.java:391)
        at java.base/java.nio.charset.CharsetDecoder.decode(CharsetDecoder.java:814)
        at java.base/java.nio.charset.Charset.decode(Charset.java:867)
        at org.jruby.RubyEncoding.decodeUTF8(RubyEncoding.java:308)
        at org.jruby.runtime.Helpers.decodeByteList(Helpers.java:2875)
        at org.jruby.RubyString.decodeString(RubyString.java:830)
        at org.jruby.RubyString.toString(RubyString.java:821)
        at java.base/java.lang.String.valueOf(String.java:4465)
        at java.base/java.lang.StringBuilder.append(StringBuilder.java:173)
        at org.logstash.common.BufferedTokenizerExt.extract(BufferedTokenizerExt.java:137)
        at org.logstash.common.BufferedTokenizerExtWithSizeLimitTest.givenTooLongInputExtractDoesntOverflow(BufferedTokenizerExtWithSizeLimitTest.java:148)

With 8GB the extract method is still not able to reserve the space to convert the RubyString to Java String (this is a second copy) and maybe during the conversion to UTF8 more inner copies are kept.

Stack trace 8GB
org.logstash.common.BufferedTokenizerExtWithSizeLimitTest > givenTooLongInputExtractDoesntOverflow FAILED
    java.lang.OutOfMemoryError: Java heap space
        at java.base/java.lang.StringUTF16.compress(StringUTF16.java:161)
        at java.base/java.lang.String.<init>(String.java:4768)
        at java.base/java.lang.String.<init>(String.java:303)
        at java.base/java.nio.HeapCharBuffer.toString(HeapCharBuffer.java:716)
        at java.base/java.nio.CharBuffer.toString(CharBuffer.java:1900)
        at org.jruby.RubyEncoding.decodeUTF8(RubyEncoding.java:308)
        at org.jruby.runtime.Helpers.decodeByteList(Helpers.java:2875)
        at org.jruby.RubyString.decodeString(RubyString.java:830)
        at org.jruby.RubyString.toString(RubyString.java:821)
        at java.base/java.lang.String.valueOf(String.java:4465)
        at java.base/java.lang.StringBuilder.append(StringBuilder.java:173)
        at org.logstash.common.BufferedTokenizerExt.extract(BufferedTokenizerExt.java:137)
        at org.logstash.common.BufferedTokenizerExtWithSizeLimitTest.givenTooLongInputExtractDoesntOverflow(BufferedTokenizerExtWithSizeLimitTest.java:148)

@elastic-sonarqube
Copy link
Copy Markdown

@elasticmachine
Copy link
Copy Markdown

💚 Build Succeeded

History

cc @andsel

Copy link
Copy Markdown
Contributor

@mashhurs mashhurs left a comment

Choose a reason for hiding this comment

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

lgtm~

@andsel andsel merged commit 075fdb4 into elastic:main Mar 26, 2025
9 checks passed
@andsel andsel added backport-active-9 Automated backport with mergify to all the active 9.[0-9]+ branches backport-active-8 Automated backport with mergify to all the active 8.[0-9]+ branches labels Mar 26, 2025
mergify bot pushed a commit that referenced this pull request Mar 26, 2025
Updates only test code to be able to run a test that consumes big memory if:
- the physical memory is bigger than the requested Java heap
- JDK version is greater than or equal to 21.

The reason to limit the JDK version is that on 16GB machine the G1GC is more efficient than the one on previous JDKs and so let complete the test with 10GB heap, while in JDK 17 it consistently fails with OOM error.

(cherry picked from commit 075fdb4)
mergify bot pushed a commit that referenced this pull request Mar 26, 2025
Updates only test code to be able to run a test that consumes big memory if:
- the physical memory is bigger than the requested Java heap
- JDK version is greater than or equal to 21.

The reason to limit the JDK version is that on 16GB machine the G1GC is more efficient than the one on previous JDKs and so let complete the test with 10GB heap, while in JDK 17 it consistently fails with OOM error.

(cherry picked from commit 075fdb4)
mergify bot pushed a commit that referenced this pull request Mar 26, 2025
Updates only test code to be able to run a test that consumes big memory if:
- the physical memory is bigger than the requested Java heap
- JDK version is greater than or equal to 21.

The reason to limit the JDK version is that on 16GB machine the G1GC is more efficient than the one on previous JDKs and so let complete the test with 10GB heap, while in JDK 17 it consistently fails with OOM error.

(cherry picked from commit 075fdb4)
mergify bot pushed a commit that referenced this pull request Mar 26, 2025
Updates only test code to be able to run a test that consumes big memory if:
- the physical memory is bigger than the requested Java heap
- JDK version is greater than or equal to 21.

The reason to limit the JDK version is that on 16GB machine the G1GC is more efficient than the one on previous JDKs and so let complete the test with 10GB heap, while in JDK 17 it consistently fails with OOM error.

(cherry picked from commit 075fdb4)
mergify bot pushed a commit that referenced this pull request Mar 26, 2025
Updates only test code to be able to run a test that consumes big memory if:
- the physical memory is bigger than the requested Java heap
- JDK version is greater than or equal to 21.

The reason to limit the JDK version is that on 16GB machine the G1GC is more efficient than the one on previous JDKs and so let complete the test with 10GB heap, while in JDK 17 it consistently fails with OOM error.

(cherry picked from commit 075fdb4)
andsel added a commit that referenced this pull request Mar 27, 2025
…17415)

Updates only test code to be able to run a test that consumes big memory if:
- the physical memory is bigger than the requested Java heap
- JDK version is greater than or equal to 21.

The reason to limit the JDK version is that on 16GB machine the G1GC is more efficient than the one on previous JDKs and so let complete the test with 10GB heap, while in JDK 17 it consistently fails with OOM error.

(cherry picked from commit 075fdb4)

Co-authored-by: Andrea Selva <selva.andre@gmail.com>
andsel added a commit that referenced this pull request Mar 27, 2025
…#17414)

Updates only test code to be able to run a test that consumes big memory if:
- the physical memory is bigger than the requested Java heap
- JDK version is greater than or equal to 21.

The reason to limit the JDK version is that on 16GB machine the G1GC is more efficient than the one on previous JDKs and so let complete the test with 10GB heap, while in JDK 17 it consistently fails with OOM error.

(cherry picked from commit 075fdb4)

Co-authored-by: Andrea Selva <selva.andre@gmail.com>
andsel added a commit that referenced this pull request Mar 27, 2025
…#17413)

Updates only test code to be able to run a test that consumes big memory if:
- the physical memory is bigger than the requested Java heap
- JDK version is greater than or equal to 21.

The reason to limit the JDK version is that on 16GB machine the G1GC is more efficient than the one on previous JDKs and so let complete the test with 10GB heap, while in JDK 17 it consistently fails with OOM error.

(cherry picked from commit 075fdb4)

Co-authored-by: Andrea Selva <selva.andre@gmail.com>
andsel added a commit that referenced this pull request Mar 27, 2025
Updates only test code to be able to run a test that consumes big memory if:
- the physical memory is bigger than the requested Java heap
- JDK version is greater than or equal to 21.

The reason to limit the JDK version is that on 16GB machine the G1GC is more efficient than the one on previous JDKs and so let complete the test with 10GB heap, while in JDK 17 it consistently fails with OOM error.

(cherry picked from commit 075fdb4)
andsel added a commit that referenced this pull request Mar 27, 2025
…17411)

Updates only test code to be able to run a test that consumes big memory if:
- the physical memory is bigger than the requested Java heap
- JDK version is greater than or equal to 21.

The reason to limit the JDK version is that on 16GB machine the G1GC is more efficient than the one on previous JDKs and so let complete the test with 10GB heap, while in JDK 17 it consistently fails with OOM error.

(cherry picked from commit 075fdb4)

Co-authored-by: Andrea Selva <selva.andre@gmail.com>
andsel added a commit that referenced this pull request Mar 31, 2025
…#17412)

Updates only test code to be able to run a test that consumes big memory if:
- the physical memory is bigger than the requested Java heap
- JDK version is greater than or equal to 21.

The reason to limit the JDK version is that on 16GB machine the G1GC is more efficient than the one on previous JDKs and so let complete the test with 10GB heap, while in JDK 17 it consistently fails with OOM error.

(cherry picked from commit 075fdb4)

Co-authored-by: Andrea Selva <selva.andre@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

backport-active-8 Automated backport with mergify to all the active 8.[0-9]+ branches backport-active-9 Automated backport with mergify to all the active 9.[0-9]+ branches

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants