| 7cd6760f7045d771faae8080a8c6150bf678f679 |
|
04-May-2012 |
Elliott Hughes <enh@google.com> |
Make libjavacore independent of libnativehelper for the PDK.
Bug: 6369821
Change-Id: Ie038571a5dac1f301c0c3c6fb84df432e67b62c0
|
| 909a18fd6628cee6718865a7b7bf2534ea25f5ec |
|
28-Jan-2011 |
Elliott Hughes <enh@google.com> |
Use the standard zlib options everyone else uses.
Change-Id: I000b39553aa6499ff1ebe615439d4e52745a7833
|
| fa5cdaa79ff491dd5c05d72baad27f931cf2d08e |
|
08-Dec-2010 |
Elliott Hughes <enh@google.com> |
Make Deflater.cpp more like Inflater.cpp.
I didn't have a bug as motivation for this (Z_NEED_DICT isn't relevant
for deflation), but I want the deflation code to look at least as sane
as the inflation code. This still passes our tests, boots, and seems
to work okay. I think the "!= Z_FINISH" test was just a premature
optimization rather than anything meaningful.
Change-Id: I8db567605712a079aaf9e18cf8836c8d5673edb1
|
| b7f0ced490fa5c5ad389c58b8584def84391f591 |
|
08-Dec-2010 |
Elliott Hughes <enh@google.com> |
Remove an unnecessary check and clarify some weird code in Deflater.cpp.
More java.util.zip cleanup. We throw the IllegalStateException in Java.
Strictly, that's racy, and we might want to move all this checking into
toNativeZipStream, but we haven't made such arrangements in general,
and I'll do that as a follow-up if desired; this patch just ensures that
we're consistent.
Change-Id: I86e47461117b3747e6fad9fe344cd68029bb78b1
|
| 2d9c5fa8ce0182cd8c14736241b709fd50cab6f8 |
|
23-Nov-2010 |
Elliott Hughes <enh@google.com> |
Slight cleanup of java.util.zip code, plus a bug fix.
The key fix is switching to zstream's next_in and next_out fields (the
pointers into the input and output buffers) rather than relying on the
integer "accounting" fields. If turns out in the Z_NEED_DICT case that
the accounting goes slightly awry. (We shouldn't have been using the
accounting anyway, because we were silently coercing longs to ints.)
The new code is simpler, clearer, and doesn't need a special case for
Z_NEED_DICT at all.
I've also removed yet another hand-written UTF-8 encoder, made Inflater
throw ArrayIndexOutOfBoundsExceptions with useful detail messages (factored
out into Arrays so we can make this change more widely), and
rewritten the Inflater and Deflater documentation.
The unit test reproduces the problem (and tests as many other cases as
it can too). Critical for testing this bug is that we needed to limit
the size of the input buffer so that zlib has to ask us for more input.
Bug: 3220923
Change-Id: I39e5456620eaa7f75d12d885db279f009ee3e8ef
|
| e22935d3c7040c22b48d53bd18878844f381287c |
|
13-Aug-2010 |
Elliott Hughes <enh@google.com> |
Remove most of our C-style casts.
After being burned by an incorrect C-style cast that cast away const, I've been
keen to remove them all and turn on -Wold-style-cast. This patch doesn't get us
that far, but it does kill the majority of our C-style casts. In turn, the
majority of the casts that it removes are the ones from our tables of native
methods to be registered.
The new NATIVE_METHOD macro also _enforces_ our convention of using the
"Class_nativeMethod" style of naming. Mostly this works out fine. In some
cases (most notably ExpatParser and ExpatAttributes) I've had to un-overload
a few functions, but I don't like overloading anyway, and in the particular
case of a native method, where the stack trace doesn't show a line number,
overloading makes it one step harder to work out which native method you're
actually in. So good riddance to that. The only unfortunate case is
Math.copySign, where there are two overloads corresponding to copysign(3)
and copysignf(3). I had to add an extra layer of indirection there. In my
defense, we've never shipped these functions before, they're unlikely to
become anyone's hotspot, and the right fix is to be doing such trivial work
on the Java side anyway, with intrinsics making the conversion between
float/double and int/long cheap.
This patch also replaces other C-style casts, primarily in
"OSNetworkSystem.cpp".
This patch also removes unnecessary uses of the "struct" keyword.
This patch also fixes a "may be used uninitialized" warning (now error) in
the sim build for "ICU.cpp".
The remaining C-style casts are in the hairy float-parsing code. That stuff --
and turning on -Wold-style-cast -- will have to wait for another day.
Change-Id: I9b3ee14aefd4676f980f6a7ca757595d78d80e6a
|
| 0adb7b318dd5d67559d5b31b1ef3280dd72e1f5f |
|
17-Jul-2010 |
Elliott Hughes <enh@google.com> |
Fix a long-latent bug in the zip code, exposed by -Xjniopts:forcecopy.
We were using ScopedByteArrayRO to access a byte[] read-write, and accidentally
relying on the fact that normally the VM will give us a pointer to the actual
array. A C-style cast that cast away const hid this obvious bug from the
compiler, so this patch also removes all the other C-style casts from the zip
code.
Change-Id: I15b2175af7d089ddc86448f54219abef2a9ef8cd
|
| a9f5c16a864ff63ba63f810410f8a27c086d5d52 |
|
17-Jun-2010 |
Elliott Hughes <enh@google.com> |
Remove dynamic calls to FindClass.
Initially, I was just fixing a threading bug in NativeDecimalFormat.cpp where
we were bypassing GCC's built-in static initializer thread safety. This led me
to the question of how expensive FindClass is, which led me to creating a new
canonical cache of jclasses.
Here's the motivating benchmark, showing the cost of calling an empty regular
(non-native) method, an empty native method, a native method that calls
FindClass, a native method that calls FindClass and GetFieldID, and a native
method that calls FindClass and GetMethodID:
benchmark ns logarithmic runtime
NoArgsRegular 74 ||||||||||||||
NoArgsNative 428 XX|||||||||||||||||||
FindClass 3064 XXXXXXXXXXXXXXXX|||||||||||
FindClassGetField 3654 XXXXXXXXXXXXXXXXXXX|||||||||
FindClassGetMethod 5634 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Change-Id: I41ab2b347895f043a7e21d8fa19e4541e198c3fc
|
| abf945fb9ce99d8c2769ac5b2691b2732fa59887 |
|
04-Jun-2010 |
Elliott Hughes <enh@google.com> |
Bullet-proof the lseek/read in Inflater.setFileInput.
Also document why that non-API method exists, and that we don't have
benchmarks to support the claimed optimization.
Also be more consistent about setting LOG_TAG, and fix a few old-school
copyright headers.
Change-Id: If9fdc4583eaf91275ed44e2dc56174819d1913d0
|
| ebca53a204302c5e559b5c2c9014b48048faf4d4 |
|
21-May-2010 |
Elliott Hughes <enh@google.com> |
Add write-back ScopedPrimitiveArrays (and use them).
I've left the remaining Get/Release Critical calls in "NativeConverter.cpp"
for the next patch, even though getting into position to fix them is part of
the point of this patch.
Change-Id: I99e15a3cf3919008343ae4dc856c86ced233e07a
|
| 99c59bfa432e36933a7a5033fba8b89209f737bc |
|
18-May-2010 |
Elliott Hughes <enh@google.com> |
Expand upon the old ScopedByteArray, and start removing some of the Get/ReleaseCritical calls.
This adds Scoped*Array classes for all primitive types, and switches all
read-only users of arrays over. At the same time, all read-only users of
Get/ReleaseCritical get switched to non-critical access.
Bug: 2663177
Change-Id: I5542cea3e24faa987ced463fcb695b9598da94af
|
| 0356c447b30e092bdc12a4b7288c08f5ef87534c |
|
08-May-2010 |
Elliott Hughes <enh@google.com> |
Fix sim build, remove static initalizers from Deflater/Inflater.
Change-Id: I56a453a1382559cdcf9f22c6a185db7178fbe098
|
| 44e0e560c92338110953ce806df475fedcdf926e |
|
07-May-2010 |
Brian Carlstrom <bdc@google.com> |
Enable -Wall -Wextra for libcore and cleanup all but one warning
Change-Id: Ied76662c470ba878cec61189acf29f5cbbd4ccd4
|
| 74c05e2a892f236c8648af7f4cfb2bcb483f267b |
|
07-May-2010 |
Elliott Hughes <enh@google.com> |
Clean up the zlib-related native code.
All the dude wanted was to get rid of Get/Release*Critical... First, though I
needed to switch the C files over to C++, and getting them to compile with a
stricter compiler made me realize how much of this stuff is unnecessary junk.
Eventually, I managed to get rid of all the "hy" and "sieb" crap, and you can
actually see what's going on now.
As usual, this reduces duplication and fixes leaks. I've also fixed a bug where
we'd never update inCap, meaning that we'd always allocate a new buffer and
never reuse the existing one even if it was large enough.
Bug: 2663177
Change-Id: I71fcbf9ff958ebf71ef3063d50ea34c28c30dd26
|