apurtell commented on a change in pull request #2627:
URL: https://github.com/apache/hbase/pull/2627#discussion_r518896781
##########
File path:
hbase-common/src/main/java/org/apache/hadoop/hbase/util/UnsafeAvailChecker.java
##########
@@ -168,20 +174,24 @@ public Boolean run() {
}
}
+ public static void overrideUnsafeAvail(boolean unsafeAvail) {
+ useUnsafe = unsafeAvail;
Review comment:
If this is changed by the application it will trigger de-opt and JIT
method replacement at the converter call sites, but the performance blip will
be temporary, because the new case will also predict the same return in 100% of
cases. (Unless the application keeps flipping it, but that is nonsensical, we
don't need to consider it.)
##########
File path: hbase-common/src/main/java/org/apache/hadoop/hbase/util/Bytes.java
##########
@@ -1367,7 +1363,7 @@ int putShort(byte[] bytes, int offset, short val) {
public UnsafeConverter() {}
static {
- if (UNSAFE_UNALIGNED) {
+ if (UnsafeAvailChecker.unaligned()) {
Review comment:
My expectation here is by the time the code is JITted the JVM will be
able to predict UnsafeAvailChecker.unaligned() is both monomorphic and returns
the same value for every invocation. There will be a bit of extra code to
branch (and de-opt) if the prediction fails, but I believe the branches will
have the right prediction hints. The generated code will have the same
performance characteristics as previous. If this is a concern, a jmh-based
microbenchmark could confirm.
##########
File path: hbase-common/src/main/java/org/apache/hadoop/hbase/util/Bytes.java
##########
@@ -778,7 +775,7 @@ public static long toLong(byte[] bytes, int offset, final
int length) {
if (length != SIZEOF_LONG || offset + length > bytes.length) {
throw explainWrongLengthOrOffset(bytes, offset, length, SIZEOF_LONG);
}
- return ConverterHolder.BEST_CONVERTER.toLong(bytes, offset, length);
+ return ConverterHolder.getBestConverter().toLong(bytes, offset, length);
Review comment:
My expectation here is by the time the code is JITted the JVM will be
able to predict ConverterHolder#getBestConverter() is both monomorphic and
returns the same value for every invocation. There will be a bit of extra code
to typecheck and branch (and de-opt) if the prediction fails, but I believe the
branches will have the right prediction hints. The generated code will have the
same performance characteristics as previous. If this is a concern, a jmh-based
microbenchmark could confirm.
----------------------------------------------------------------
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.
For queries about this service, please contact Infrastructure at:
[email protected]
