| c375a9cfd6ca0f557a4343a14f6c4115a1f20207 |
|
29-Mar-2013 |
Joel Dice <joel.dice@gmail.com> |
Use long instead of int for address in DirectByteBuffer constructor
This allows the code to be used on 64-bit platforms.
(cherry picked from commit 9ce6a2533b50ffcd24b8b10bae7f234042768819)
Change-Id: Icc5248d8ea276a451b32ecc91b47aeb977e8f21c
|
| 9ce6a2533b50ffcd24b8b10bae7f234042768819 |
|
29-Mar-2013 |
Joel Dice <joel.dice@gmail.com> |
Use long instead of int for address in DirectByteBuffer constructor
This allows the code to be used on 64-bit platforms.
Change-Id: I1c42d48696296f74135cd209b3042b8973779e40
|
| fe5da19e0e366286cd4d95f7628fe9442b9062c8 |
|
27-Mar-2013 |
Elliott Hughes <enh@google.com> |
Simplify the nio Buffer implementations, and fix MappedByteBuffer.
* Fix the reported bug caused by delegation in the MappedByteBuffer
implementation.
* Collapse the three classes (ReadOnly*, ReadWrite*, and *) used
to implement most buffer types into one class each.
* Rename HeapByteBuffer to ByteArrayBuffer to match its companions.
* Remove BaseByteBuffer.
* Give the classes used to implement asXBuffer sane names (their
existing names were backwards).
Bug: https://code.google.com/p/android/issues/detail?id=53637
Change-Id: I2a7ff4f1d502564389615384324afadabccb04f9
|
| 385c6f4303341beb9b091b6d252811b7ca3b9f42 |
|
20-Dec-2012 |
Nick Kralevich <nnk@google.com> |
FileChannelImpl: Ignore ftruncate failures on non-regular files
Truncate only works on regular files. On other files, such as
UNIX character devices, truncate returns EINVAL, which
causes an IOException to be thrown.
With this change, we now have support for creating a MappedByteBuffer
on UNIX character devices such as /dev/zero, if the underlying
device node supports mmap().
Change-Id: I094371d821b187abe3da32edc411ff76a81b047e
|
| 86f5f3e0e2bd808e4c85b0563ae50f17b7d48309 |
|
30-Jul-2012 |
Elliott Hughes <enh@google.com> |
Repair the damage I did removing "useless" checkIndex calls from the asXBuffer adapter classes.
The checkIndex calls were unnecessary as far as throwing the right Exception
subclass goes, but they're necessary if you want the detail message to use
the units of the wrapping buffer rather than the wrapped buffer. And we want
that. An IndexOutOfBoundsException that says "offset=0, limit=1" is only
going to confuse developers.
(Fixes bug introduced by 26841c0bb838d54fea2e1a06390e413fab561e27.)
Bug: 6085292
Change-Id: I9a1a5991ad383b7712642e40bced9af91440bed2
|
| 26841c0bb838d54fea2e1a06390e413fab561e27 |
|
26-Jul-2012 |
Elliott Hughes <enh@google.com> |
Remove useless checkIndex calls from the asXBuffer adapter classes.
Also add tests that we throw the expected exceptions.
Bug: 6085292
Change-Id: Ibcc44bdb546cba5365cdf557847e068fea77e1ca
|
| bdd17cde8cf675f5d5703aad4dfb565932fb4c50 |
|
08-Feb-2012 |
Elliott Hughes <enh@google.com> |
Fix an ICS regression with hasArray on a JNI-allocated DirectByteBuffer.
Bug: http://code.google.com/p/android/issues/detail?id=24327
Change-Id: Ib31b60fe01e3d0b5a1ed7125ddf047e09fd64056
|
| 20b0416aa49b46b586ecf3d0b33016217d2dca63 |
|
29-Apr-2011 |
Elliott Hughes <enh@google.com> |
Fix the byte order of non-ByteBuffer duplicate and slice results.
ByteBuffer.duplicate and ByteBuffer.slice always return big-endian buffers.
Any other kind of buffer returns a buffer with the same endian as itself.
We didn't have tests for the latter, and broke this in Honeycomb.
Bug: http://code.google.com/p/android/issues/detail?id=16434
Bug: 4361578
git cherry-pick 87c354d8d6faa77dee1820df2f0ad2666b9f0331
Change-Id: Idf8dc6f47ffdbfe82b83e9ce1186f1717ec0ef8f
|
| 42d75577588240e7d79fe52e635f0c1df070672e |
|
06-May-2011 |
Elliott Hughes <enh@google.com> |
Add a test for a publicly-reported bug I already fixed.
Another casualty of the honeycomb asXBuffer byte order bug.
Bug: http://code.google.com/p/android/issues/detail?id=16598
Change-Id: I885d9f1651238a5d2aadf3fef7d119775f742fdf
|
| a47f80079c7147f6edc83ae812435326bd82dd40 |
|
07-Apr-2011 |
Elliott Hughes <enh@google.com> |
Fix asReadOnlyBuffer to conserve the byte order (on everything except ByteBuffer).
And add tests to exercise another wart of non-uniformity on this heinous API.
Bug: http://code.google.com/p/android/issues/detail?id=15994
Bug: 4361578
git cherry-pick 54298028777ffe4d5ec02e7908b333400d4f23a6
Change-Id: Id95256efe98edc0b350351e416e67c8f01ac64b7
|
| eebf863ca5c8a7497f92602fe9ea3d1282c8bded |
|
29-Apr-2011 |
Elliott Hughes <enh@google.com> |
Fix the byte order of non-ByteBuffer duplicate and slice results.
ByteBuffer.duplicate and ByteBuffer.slice always return big-endian buffers.
Any other kind of buffer returns a buffer with the same endian as itself.
We didn't have tests for the latter, and broke this in Honeycomb.
Bug: http://code.google.com/p/android/issues/detail?id=16434
git cherry-pick 87c354d8d6faa77dee1820df2f0ad2666b9f0331
Change-Id: I344cccab9a1a5ac4a6d6a70bb09c7da5808929bc
|
| 0c0934430f2cdd830b54eacf518355057f3567f3 |
|
07-Apr-2011 |
Elliott Hughes <enh@google.com> |
Fix asReadOnlyBuffer to conserve the byte order (on everything except ByteBuffer).
And add tests to exercise another wart of non-uniformity on this heinous API.
Bug: http://code.google.com/p/android/issues/detail?id=15994
git cherry-pick 54298028777ffe4d5ec02e7908b333400d4f23a6
Change-Id: I3e1443b4f82b98d71c90b18631d0fbad3e5ae9f8
|
| 87c354d8d6faa77dee1820df2f0ad2666b9f0331 |
|
29-Apr-2011 |
Elliott Hughes <enh@google.com> |
Fix the byte order of non-ByteBuffer duplicate and slice results.
ByteBuffer.duplicate and ByteBuffer.slice always return big-endian buffers.
Any other kind of buffer returns a buffer with the same endian as itself.
We didn't have tests for the latter, and broke this in Honeycomb.
Bug: http://code.google.com/p/android/issues/detail?id=16434
Change-Id: I08e98c4817f6340a0c396de060431185240d3ca3
|
| 0568a63ba1086a78ffb4cff68dd2eac4f9908e13 |
|
26-Apr-2011 |
Elliott Hughes <enh@google.com> |
Fix ByteBuffer.put(ByteBuffer).
To do this tastefully required some cunning in the native code. The new
ScopedBytesRO/ScopedBytesRW classes let us paper over the differences
between byte[] and DirectByteBuffer, which in turn lets us paper over the
differences between the various kinds of ByteBuffer.
I've also rewritten Posix.read/Posix.readDirectBuffer and
Posix.write/Posix.writeDirectBuffer to use the same idea. I haven't rewritten
readv and writev, but can do and probably should.
Bug: http://code.google.com/p/android/issues/detail?id=16184
Change-Id: Ia30d2f2fe1b1716a8f068187df2218b407a55aae
|
| 54298028777ffe4d5ec02e7908b333400d4f23a6 |
|
07-Apr-2011 |
Elliott Hughes <enh@google.com> |
Fix asReadOnlyBuffer to conserve the byte order (on everything except ByteBuffer).
And add tests to exercise another wart of non-uniformity on this heinous API.
Bug: http://code.google.com/p/android/issues/detail?id=15994
Change-Id: I49d2488a68a626e798f9bb39b47e710445b23fab
|
| 38f919c84cc2714ae2564ea1a04e2ced9c5aad04 |
|
26-Jan-2011 |
Elliott Hughes <enh@google.com> |
Our DirectByteBuffer can implement array(), arrayOffset(), and hasArray().
An interesting side-effect of moving direct buffers onto the Java heap.
Sufficiently sophisticated code can now have the best of both worlds.
Bug: 3384431
Change-Id: I741fc457277704016bc773cc2aec22e89045f839
|
| 5a1e8cc38e1cc6c3f2fc66f039ca0fc5309a0dc3 |
|
16-Dec-2010 |
Elliott Hughes <enh@google.com> |
MappedByteBuffer get(byte[]) and get(byte[], int, int) weren't updating 'position'.
The majority of this change is work to extend our tests to cover
MappedByteBuffer too, plus new tests to check that 'position' is
always updated correctly by ByteBuffer's relative get/put methods.
Bug: 3291927
Change-Id: I58217de45ba65675730f30771fba592cb2af28ff
|
| 17b2f493468764dc1f237c02d94747d122dbd101 |
|
08-Oct-2010 |
Elliott Hughes <enh@google.com> |
Fix our byte order behavior for slice and wrap operations.
Our documentation was correct, but our implementation was not. Includes
extensive new tests.
Bug: 3066167
Change-Id: Ie7d6e6432f1d675f20af020cc662dab6eb181a50
|
| 8fbc397fc09158bee0bc0cb231c609c4c6e9fc15 |
|
18-Sep-2010 |
Elliott Hughes <enh@google.com> |
Optimize non-direct (heap) buffer bulk put.
I've also factored out the bounds checking, even though the JIT can't yet
inline it back. I'm unwilling to duplicate all that code again.
This patch also fixes bugs in the previous checkin relating to offsets
and positions. In real life (and, seemingly, in all our tests) these tend
to be 0, making it rare that anyone trips over these bugs. (The first nio
change I made was fixing just such a bug.) I've improved the test I added
last time so that it covers more of these cases.
Here are the "after" performance figures for heap buffer bulk copies:
CharBuffer_getCharArray 5797
CharBuffer_putCharArray 5818
DoubleBuffer_getDoubleArray 13053
DoubleBuffer_putDoubleArray 13026
FloatBuffer_getFloatArray 8216
FloatBuffer_putFloatArray 8283
IntBuffer_getIntArray 8253
IntBuffer_putIntArray 8371
LongBuffer_getLongArray 13053
LongBuffer_putLongArray 13020
ShortBuffer_getShortArray 5796
ShortBuffer_putShortArray 5864
This compares well with with direct buffer performance (just gets shown here):
CharBuffer_getCharArray 4412
DoubleBuffer_getDoubleArray 11594
FloatBuffer_getFloatArray 6787
IntBuffer_getIntArray 6791
LongBuffer_getLongArray 11672
ShortBuffer_getShortArray 4430
Bug: 2985452
Change-Id: I37307f9b304c87a87af5313790444dcdf6174ff1
|
| 6944bea4a129dc2d4be687c72f2a9f228ec532bc |
|
17-Sep-2010 |
Elliott Hughes <enh@google.com> |
Make nio heap (non-direct) buffer bulk get orders of magnitude faster.
Bug: 2985452
Change-Id: I8bd210d1a623e434121f30eca6e2555e1aea11cd
|