Oak shared config #196
Oak shared config #196
Conversation
# Conflicts: # core/src/main/java/com/yahoo/oak/BlocksPool.java
* Fix bad assert pattern in tests
| // to compare serilized and object keys | ||
| protected final OakSharedConfig<K, V> config; | ||
|
|
||
| // to compare serialized and object keys |
There was a problem hiding this comment.
Isn't comparator part of the config?
There was a problem hiding this comment.
Each instance holds its own references to the "config items" it needs.
I implemented it that way to avoid another pointer dereference each time we access these elements.
In addition, the config object is stored here to be passed to the child Chunk instance.
| // in split/compact process, represents parent of split (can be null!) | ||
| private final AtomicReference<BasicChunk<K, V>> creator; | ||
| // chunk can be in the following states: normal, frozen or infant(has a creator) | ||
| private final AtomicReference<State> state; | ||
| private final AtomicReference<Rebalancer<K, V>> rebalancer; | ||
| private final AtomicInteger pendingOps; | ||
| private final int maxItems; | ||
| protected final int maxItems; |
There was a problem hiding this comment.
Why not to use getMaxItems()?
There was a problem hiding this comment.
It seems more natural to me to access internal final fields directly. I don't see why we need a function call here.
For the same reason, we access externalSize and statistics directly.
|
|
||
| private final OakSerializer<K> keySerializer; | ||
| private final OakSerializer<V> valueSerializer; | ||
| protected final MemoryManager keysMemoryManager; |
There was a problem hiding this comment.
Why to keep the config and all those fields? In order to avoid de-referencing? I don't believe we will see any performance differences from accessing config.keysMemoryManager... We may try the benchmarks....
There was a problem hiding this comment.
Comparators are accessed frequently. Are you sure?
I think we can have a different PR after this one where we test this hypothesis.
|
Excuse me. I have some questions about the oak shared config. |
|
Could all oakMap created by one OakMapBuilder share the same BlockMempryAllocator? |
|
Hi @fujian-zfj Thanks for your valuable suggestion. Indeed, we currently have one Anyway, in your case, a possible solution can be to decrease the block size. Use Alternatively, if you would like to contribute some code to Oak, we can guide you to make the change yourself. You can get direct and clear instructions what needs to be done, code review and etc. This is also a possibility :) |
fixes #194
I confirm that this contribution is made under the terms of the license found in the root directory of this repository's source tree and that I have the authority necessary to make this contribution on behalf of its copyright owner.