[
https://issues.apache.org/jira/browse/ARROW-7494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17390173#comment-17390173
]
Jacques Nadeau commented on ARROW-7494:
---------------------------------------
bq. Possible approaches: 1..2..3..4
Thanks [~bobtinsman] for looking at this.
I continue to believe that #1 is the best approach. I don't see the changes as
excessively complex or risky. The few places where someone wants something
indexed should be able to create a composite object to achieve that without
messing with the core library. From my pov, ArrowBuf is too fundamental in the
library to have excessive additional methods and we should avoid object state
that is outside the design goals. I was the one who initially built ArrowBuf as
a subclass ByteBuf from Netty. It was a mistake and we should try to clean up
any legacy crufty-ness that caused. The idea with ArrowBuf is to be as close to
a lightweight chunk of memory as possible thus the drive towards a tuple of
[address, length, release object address] being the core data structure. In
general, I also recommend maintaining ArrowBuf as a final class to avoid the
potential of getting into performance impacting-specializations when people
start creating multiple subclasses. Use in this way allows direct references in
the ValueVector classes to keep the indirection to a minimum.
WRT to the index use in buffer management code: this is code that exists for
legacy reasons, primarily due to how Dremio was originally built using Arrow.
It would be good to just clean that stuff up and constraining specialized (read
weird) behavior in those systems as opposed to having it bleed into everyone's
use of the library.
> [Java] Remove reader index and writer index from ArrowBuf
> ---------------------------------------------------------
>
> Key: ARROW-7494
> URL: https://issues.apache.org/jira/browse/ARROW-7494
> Project: Apache Arrow
> Issue Type: Task
> Components: Java
> Reporter: Jacques Nadeau
> Assignee: Ji Liu
> Priority: Critical
> Labels: pull-request-available
> Time Spent: 2h 20m
> Remaining Estimate: 0h
>
> Reader and writer index and functionality doesn't belong on a chunk of memory
> and is due to inheritance from ByteBuf. As part of removing ByteBuf
> inheritance, we should also remove reader and writer indexes from ArrowBuf
> functionality. It wastes heap memory for rare utility. In general, a slice
> can be used instead of a reader/writer index pattern.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
