| 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
|
| 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
|
| 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
|
| a1603838fe9e865575c87982e32c6343740e464c |
|
11-Dec-2010 |
Elliott Hughes <enh@google.com> |
Lots more bounds-checking/exception-throwing consistency.
Overflow-safe checks all round, plus better detail messages. This isn't
quite everything, but it's a large chunk of the work. Most notably, this
is all of io and nio.
There are numerous changes of exception priority here, and the harmony
tests noticed a subset of them in the nio code. I've modified our checked-out
copy of the tests to accept any of the throwable exceptions.
Change-Id: Id185f1228fb9a1d5fc9494e78375b5623fb0fe14
|
| 43a9f774d075e0e441d8b996e3f6c81ea483ec89 |
|
19-Oct-2010 |
Elliott Hughes <enh@google.com> |
BufferIterator support for byte[].
Bug: 3032515
Change-Id: I040a92c3ce241aa97719ff94e3cc31c62473bf46
|
| 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
|
| 961da1e7487bdb8ad8ac226d4f2789d003aa87b9 |
|
11-Sep-2010 |
Elliott Hughes <enh@google.com> |
Optimize bulk get of char[], double[], float[], long[], and short[].
I optimized int[] the other day, and byte[] has always been optimized.
This now makes our get performance equivalent to our put performance,
rather than orders of magnitude worse.
Before:
ByteBuffer_getByteArray 2041 ==========
ByteBuffer_putByteArray 1983 =========
CharBuffer_getCharArray 705152 ============================
CharBuffer_putCharArray 4375 ============
DoubleBuffer_getDoubleArray 860884 =============================
DoubleBuffer_putDoubleArray 11591 ===============
FloatBuffer_getFloatArray 839085 =============================
FloatBuffer_putFloatArray 6690 =============
IntBuffer_getIntArray 6814 =============
IntBuffer_putIntArray 6775 =============
LongBuffer_getLongArray 668171 ============================
LongBuffer_putLongArray 11585 ===============
ShortBuffer_getShortArray 620122 ============================
ShortBuffer_putShortArray 4350 ============
After:
ByteBuffer_getByteArray 2028 ===========
ByteBuffer_putByteArray 1948 ===========
CharBuffer_getCharArray 4376 =================
CharBuffer_putCharArray 4342 =================
DoubleBuffer_getDoubleArray 11616 =======================
DoubleBuffer_putDoubleArray 11540 =======================
FloatBuffer_getFloatArray 6827 ====================
FloatBuffer_putFloatArray 6747 ====================
IntBuffer_getIntArray 6824 ====================
IntBuffer_putIntArray 6733 ====================
LongBuffer_getLongArray 11597 =======================
LongBuffer_putLongArray 11489 =======================
ShortBuffer_getShortArray 4392 =================
ShortBuffer_putShortArray 4329 =================
(All times in microseconds. The relatively large amount of noise visibile from
the code that didn't change is because I told caliper I wanted results quickly,
since it was order of magnitude I cared about, not tens of microseconds. That
is, the scales on the two graphs are completely different, and it's only the
shapes of the graphs that you can usefully compare: after is less spiky,
because I've filled in the performance potholes.)
Bug: 2935622
Change-Id: Ia5a36e641ef67648fcdbda092fab36111613b1c2
|
| 0e1b748ecabf720065a632f28330f5d4d037d5ae |
|
10-Sep-2010 |
Elliott Hughes <enh@google.com> |
Consistent naming for get/put/wrap arguments.
Bug: 2935622
Change-Id: Icb39392f9106f9fe5ba70ccdcb6b059dbf5617bc
|
| 692222b08ff88eb92b523bf4780d7ea17a23aa80 |
|
10-Sep-2010 |
Elliott Hughes <enh@google.com> |
Fast-path nio put for char[], double[], long[], nio get for int[].
The other vector puts were already special-cased.
int[] is the first get to be accelerated; I'll come back and do the others.
I don't know how used vector gets are, but our nio unit tests go from ~4minutes
to ~15s after these changes, and all but the last five seconds of that is
from the get(int[]) part of this change.
Bug: 2935622
Change-Id: I1f5afb77e0fc7abcb661f861fa435cbec4b3f348
|
| 0440837fd0013373ba3476283151299e7be9e5a3 |
|
08-Sep-2010 |
Elliott Hughes <enh@google.com> |
Move the MemoryBlock up into java.nio.Buffer.
This lets me kill getBaseAddress and the (bogus) DirectBuffer interface.
Bug: 2935622
Change-Id: I51c758e7687a6cfa4a3a64ef089fb600b847b70f
|
| eb29579498a8860f81fd38275f8657c21bb67abb |
|
08-Sep-2010 |
Elliott Hughes <enh@google.com> |
Rename PlatformAddress to MemoryBlock.
Bug: 2935622
Change-Id: I8a09cb9be0b0ea468278f7808f1a18c3ce820b49
|
| 0f335c4ed1a0cb419c8ce82183fabb241d5dd032 |
|
07-Sep-2010 |
Elliott Hughes <enh@google.com> |
Kill getEffectiveAddress.
Set the corresponding field in the constructors.
Requires a dalvikvm change: https://android-git.corp.google.com/g/64866
Bug: 2935622
Change-Id: I26663bfcdb80db75672be71395b861c1a79c24fc
|
| c73a5be50cdd804ff3c12e7b43da08c33cdd6f21 |
|
04-Sep-2010 |
Elliott Hughes <enh@google.com> |
Move some of the nio implementation into java.nio.
Another stepping-stone to simplifying the PlatformAddress/OSMemory situation.
Bug: 2935622
Change-Id: Ic5b941ee7c17d6b5aeda53c3c2cdf2c43cebff55
|
| c3c38fbbccaf428200acdd819b1f7799edac54d2 |
|
04-Sep-2010 |
Elliott Hughes <enh@google.com> |
Remove nio cruft, move the implementation cost of 'free' where it belongs...
...and inline some getBaseAddress calls. The JIT doesn't manage to do that, it
seems, but being the JIT is not really my purpose: I'm trying to kill
getBaseAddress.
Bug: 2935622
Change-Id: I3cd99cd131a2c09796f5ff5bb31332287db2130f
|
| 29dbfe19b113a13b712be2bc762ef1c81cd06c47 |
|
03-Sep-2010 |
Elliott Hughes <enh@google.com> |
Use finalizers to free direct buffers.
Also switch to a cheaper scheme for avoiding double-frees (which could only
happen if library code is broken; at the moment the only caller is the
iovec-style stuff). This halves the cost of direct buffer access, at the
unimportant cost of not throwing an exception if we try to access a buffer
we freed while we still had a reference to it.
Also use named constants for the sizes of primitive types.
Also kill BufferFactory.
Bug: 2935622
Change-Id: I6021ce7531f49d8cff7635d6d2cc54851bacaf69
|
| f46d2ce4d4c92d16e2574f57f70fc5477dc12697 |
|
02-Sep-2010 |
Elliott Hughes <enh@google.com> |
Make DirectBuffer.getEffectiveAddress cheaper.
DirectBuffer.getEffectiveAddress is used to implement the JNI function
GetDirectBufferAddress. Currently it uses reference types unnecessarily,
and we have an object pool to reduce the cost of this. Switch to using
int instead.
I'll remove the pool in a later change.
Note that this change requires a corresponding change to the
GetDirectBufferAddress implementation in dalvik:
https://android-git.corp.google.com/g/64328
Bug: 2935622
Change-Id: Ia0c20bd58c5355550f6af840feb08acff14fd4e9
|
| 7365de1056414750d0a7d1fdd26025fd247f0d04 |
|
12-Aug-2010 |
Jesse Wilson <jessewilson@google.com> |
Sorting imports.
Change-Id: I8347bc625480a1c37a1ed9976193ddfedeb00bbc
|
| f33eae7e84eb6d3b0f4e86b59605bb3de73009f3 |
|
13-May-2010 |
Elliott Hughes <enh@google.com> |
Remove all trailing whitespace from the dalvik team-maintained parts of libcore.
Gentlemen, you may now set your editors to "strip trailing whitespace"...
Change-Id: I85b2f6c80e5fbef1af6cab11789790b078c11b1b
|
| 3ff29eb11a241d58c54ecc84230bb0672f4aa148 |
|
23-Apr-2010 |
Peter Hallam <peterhal@google.com> |
More merging of nio into luni
Change-Id: Ib4356b3cd57490df8ff246ea6a4bc1c269ba848b
|