kfaraz commented on code in PR #12521:
URL: https://github.com/apache/druid/pull/12521#discussion_r873318555
##########
pom.xml:
##########
@@ -1733,7 +1733,7 @@
<!-- set heap size to work around
https://github.com/travis-ci/travis-ci/issues/3396 -->
<argLine>
${jdk.surefire.argLine}
- -Xmx768m -Duser.language=en -Duser.country=US
-Dfile.encoding=UTF-8
+ -Xmx1280m -Duser.language=en -Duser.country=US
-Dfile.encoding=UTF-8
Review Comment:
Is this needed because several tests are now going to use on-heap byte
buffers?
Do those tests fail without this change?
##########
core/src/main/java/org/apache/druid/java/util/common/ByteBufferUtils.java:
##########
@@ -138,6 +144,45 @@ private static MethodHandle
unmapJava9(MethodHandles.Lookup lookup) throws Refle
return unmapper.bindTo(UnsafeUtils.theUnsafe());
}
+ /**
Review Comment:
Could we also include a comment advising when `allocateDirect` should be
used (especially in tests) rather than just using on-heap buffers with
`ByteBuffer.allocate()`?
##########
core/src/main/java/org/apache/druid/java/util/common/ByteBufferUtils.java:
##########
@@ -138,6 +144,45 @@ private static MethodHandle
unmapJava9(MethodHandles.Lookup lookup) throws Refle
return unmapper.bindTo(UnsafeUtils.theUnsafe());
}
+ /**
+ * Same as {@link ByteBuffer#allocateDirect(int)}, but returns a closeable
{@link ResourceHolder} that
+ * frees the buffer upon close.
+ */
+ public static ResourceHolder<ByteBuffer> allocateDirect(final int size)
Review Comment:
Should we also use this utility method in places such as
`LZ4Compressor.allocateInBuffer()` rather than calling `free` directly from
there?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
