The major cause of inconsistency here is that reference count does *not* change upon a call to BaseDataVV#getBuffers. However, it *does* change when the method is invoked on a composite vector type. See for instance VariableLengthVV[1] or NullableVV[2].
This is problematic. We should fix this. Filed DRILL-2719 to track this. -Hanifi [1]: https://github.com/apache/drill/blob/master/exec/java-exec/src/main/codegen/templates/VariableLengthVectors.java#L151 [2]: https://github.com/apache/drill/blob/master/exec/java-exec/src/main/codegen/templates/NullableValueVectors.java#L82 On Tue, Apr 7, 2015 at 7:09 PM, Hanifi Gunes <[email protected]> wrote: > The use of clear flag at ValueVector#getBuffers(clear) seems very > inconsistent to me. > > Because the implementation does not truly "clear" the vector when the flag > is set but instead > (i) L74: increments the ref count first > (ii) L79: decrements the ref count and replaces the underlying buffer > later. > > My expectation was a "complete clear" at this point. So what was the > intended use of the flag? Would not it be nicer if we separated returning > buffers from clearing vectors/buffers entirely? > > > [1]: > https://github.com/apache/drill/blob/master/exec/java-exec/src/main/java/org/apache/drill/exec/vector/BaseDataValueVector.java#L67 > > > Thanks. > -Hanifi >
