Compact Strings and APIs for fast decoding of string data

[Paul Sandoz]

> On 10 Feb 2016, at 14:16, Chris Vest <mr.chrisvest at gmail.com> wrote:
> 
> It’d be a shame to loose the no-zeroing optimisation, so if that requires a constructor, then lets find a constructor.
> 
> To recap, I have possibly multiple buffers and I only want to use parts of each. So with the composed buffer I’d have to first extract view buffers and then compose those, so I end up with 3 levels of buffers. Not ideal. A value type as a tuple of a buffer reference, an offset and a length would be better. We could make an array of those and pass that in. It could also find uses elsewhere in JDK where the buffer+offset+length pattern occurs. The array, a long with an encoding, could be passed up front to a String constructor (or a static method – I don’t care) and my use case would be equally satisfied.
> 

Perhaps not necessarily 3, since ByteBuffer.slice does not wrap (IIRC wider views do, but that is an implementation detail to share code for heap and direct AFAICT [*]). An absolute slice(int pos, int limit) method might be useful.

IMO the more we can simplify the consumer the better with regards to dealing with a sequence of regions.


> If I’ve understood correctly, there’s a plan (or at least a great desire) to turn Optional into a value type once they become available.

Yes, there is certainly a strong desire. The risk of course is we have no way of enforcing it be used under constraints of being value-based (or as if a value type).


> These “buffer slice” objects could follow a similar path, and thus be made available independently of value types. Even if they can’t, the overhead they add would be small, I imagine.
> 

Project Panama will most likely require some form of memory region type, on or off-heap, and that would certainly be a value type (or value-based in the interim). So something may emerge, just not in the short term. Thus i think it would be premature to introduce something specific in Java 9.


> I’m slightly more worried about their array and what it implies, though. This API requires of me that I’m able to present all of the relevant buffers up front. In my case, these buffers are shared between multiple threads, so they are guarded by locks. I must take all the locks for all the buffers and hold them for the duration of the copy. _Maybe_ I have to do that anyway, but if there’s a way for me to only lock one buffer at a time, I’d like to be able to exploit this. The builder approach holds this door open for me.
> 

That’s true. Interesting requirements, thanks for sharing.

Paul.

[*] which i suspect could be made more efficient if we unified heap/direct access