rocksdb/java/rocksjni/filter.cc

47 lines
1.5 KiB
C++
Raw Normal View History

// Copyright (c) 2011-present, Facebook, Inc. All rights reserved.
// This source code is licensed under both the GPLv2 (found in the
// COPYING file in the root directory) and Apache 2.0 License
// (found in the LICENSE.Apache file in the root directory).
2014-04-22 08:56:19 +02:00
//
2014-04-22 09:09:40 +02:00
// This file implements the "bridge" between Java and C++ for
// ROCKSDB_NAMESPACE::FilterPolicy.
2014-04-22 08:56:19 +02:00
#include <jni.h>
2014-04-22 08:56:19 +02:00
#include <stdio.h>
#include <stdlib.h>
2014-04-22 08:56:19 +02:00
#include <string>
2014-04-22 17:58:43 +02:00
#include "include/org_rocksdb_BloomFilter.h"
#include "include/org_rocksdb_Filter.h"
2014-04-22 08:56:19 +02:00
#include "rocksdb/filter_policy.h"
#include "rocksjni/cplusplus_to_java_convert.h"
#include "rocksjni/portal.h"
2014-04-22 08:56:19 +02:00
/*
2014-04-22 17:58:43 +02:00
* Class: org_rocksdb_BloomFilter
* Method: createBloomFilter
Allow fractional bits/key in BloomFilterPolicy (#6092) Summary: There's no technological impediment to allowing the Bloom filter bits/key to be non-integer (fractional/decimal) values, and it provides finer control over the memory vs. accuracy trade-off. This is especially handy in using the format_version=5 Bloom filter in place of the old one, because bits_per_key=9.55 provides the same accuracy as the old bits_per_key=10. This change not only requires refining the logic for choosing the best num_probes for a given bits/key setting, it revealed a flaw in that logic. As bits/key gets higher, the best num_probes for a cache-local Bloom filter is closer to bpk / 2 than to bpk * 0.69, the best choice for a standard Bloom filter. For example, at 16 bits per key, the best num_probes is 9 (FP rate = 0.0843%) not 11 (FP rate = 0.0884%). This change fixes and refines that logic (for the format_version=5 Bloom filter only, just in case) based on empirical tests to find accuracy inflection points between each num_probes. Although bits_per_key is now specified as a double, the new Bloom filter converts/rounds this to "millibits / key" for predictable/precise internal computations. Just in case of unforeseen compatibility issues, we round to the nearest whole number bits / key for the legacy Bloom filter, so as not to unlock new behaviors for it. Pull Request resolved: https://github.com/facebook/rocksdb/pull/6092 Test Plan: unit tests included Differential Revision: D18711313 Pulled By: pdillinger fbshipit-source-id: 1aa73295f152a995328cb846ef9157ae8a05522a
2019-11-27 00:49:16 +01:00
* Signature: (DZ)J
2014-04-22 08:56:19 +02:00
*/
jlong Java_org_rocksdb_BloomFilter_createNewBloomFilter(JNIEnv* /*env*/,
jclass /*jcls*/,
jdouble bits_per_key) {
auto* sptr_filter =
new std::shared_ptr<const ROCKSDB_NAMESPACE::FilterPolicy>(
ROCKSDB_NAMESPACE::NewBloomFilterPolicy(bits_per_key));
return GET_CPLUSPLUS_POINTER(sptr_filter);
2014-04-22 08:56:19 +02:00
}
/*
* Class: org_rocksdb_Filter
* Method: disposeInternal
2014-04-22 08:56:19 +02:00
* Signature: (J)V
*/
void Java_org_rocksdb_Filter_disposeInternal(JNIEnv* /*env*/, jobject /*jobj*/,
jlong jhandle) {
auto* handle =
reinterpret_cast<std::shared_ptr<const ROCKSDB_NAMESPACE::FilterPolicy>*>(
jhandle);
delete handle; // delete std::shared_ptr
2014-04-22 09:04:56 +02:00
}