summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* Merge "Rewrite tests and add tests that demonstrate a bug"Neil Fuller2014-09-262-58/+229
|\
| * Rewrite tests and add tests that demonstrate a bugNeil Fuller2014-09-262-58/+229
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The bug: DecimalFormat.format() behavior is slightly lossy around 15 decimal digits even without any digit constraints. This change isolates the test failures that result from this bug to 2 test cases: test_formatDouble_bug17656132 test_formatDouble_roundingProblemCases Example of the bug: Double: 999999999999999.9 is represented as an IEEE 754 value which is exactly decimal 999999999999999.875 When format(999999999999999.9) is called on a DecimalFormat with large MaxIntegerDigit and MaxFractionDigit.... Correct answer: "999999999999999.9" Actual answer: "1000000000000000" By contrast Double.toString() prints 9.999999999999999E14 for Android and the RI (correctly). The DecimalFormat is printing to 16 decimal digits: The inclusion of the 16th digit implies slightly more precision than IEEE 754 provides (~15.9 decimal digits for most of the representable range). However, the use of 16 decimal digits for outputting IEEE 754 appears consistent with Double.toString() and elsewhere. Before printing, DecimalFormat appears to be rounding to 15 decimal digits internally (or something similar). Parsing "1000000000000000" produces a different double representation than the original double (one that is closer to 1000000000000000 than 999999999999999.9). This is the bug - we just lost information. We should be able to round-trip a double if there is no rounding since every double is representable with decimal and we have sufficient digits available to represent it (close enough) in decimal. Additional tests have been added to demonstrate the bug and also demonstrate the (correct) formatting behavior when the formatter is rounding. test_formatDouble_maxFractionDigits: rounding at 1, 10, 14 digits after the dp. test_formatDouble_roundingTo15Digits: rounding at 15 total digits overall test_formatDouble_bug17656132: Demonstrates the bug concisely. The test changes: test_formatDouble_wideRange(): implicitly assumed that the any loss of accuracy when a decimal string was turned into a double would be undone when format() was called, and it would always arrive back at the original string. The test has been re-written here to use BigDecimal rather than Double.parseDouble(), and to compare two doubles rather than original string with the output from format(). The test was previously failing with the RI for 1E23: the closest representable double to 1E23 is exactly 99999999999999991611392. The value produces "99999999999999990000000" when formatted with the RI and not "100000000000000000000000". On Android it was passing for 1E23 because of bug 17656132 rounding back to the original decimal value. This test was previously failing on Android with 1E-309 because below 1E-308 IEEE 754 starts losing precision and the closest representable value is not close to the original string. The test now isn't affected if the double being tested is not close to the original decimal; it passes providing the can be round tripped. test_formatDouble_roundingProblemCases: Re-written like the _wideRange test but continues to demonstrate the bug due to the test values (intentionally) chosen. Bug: 17656132 Change-Id: I7d81e38bd1f9dbfd1e1b2caa60a6bb16b871b925
* Merge "Mark ↵Neil Fuller2014-09-262-8/+18
|\ | | | | | | libcore.java.text.DecimalFormatSymbolsTest#test_getInstance_unknown_or_invalid_locale a known failure."
| * Mark ↵Elliott Hughes2014-09-262-8/+18
|/ | | | | | | | | | | | | libcore.java.text.DecimalFormatSymbolsTest#test_getInstance_unknown_or_invalid_locale a known failure. The good news is that for the first time we understand why this is failing. Too big to fix for L though, and not a regression. Bug: 17374604 (cherry-picked from commit f887ab7ef74d3ca821aca63ccee2c86cc6a42489) Change-Id: I589fe2eae0643e07e8db8cbcc7df52563aa24604
* Merge "Fix test_formatToCharacterIterator_original"Neil Fuller2014-09-261-8/+10
|\
| * Fix test_formatToCharacterIterator_originalNeil Fuller2014-09-251-8/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Two issues fixed: 1) The negative currency cases appear to have never been correct. Almost certainly they would have had the sign bit as the first element in the format. 2) The recent change in Android to support the Turkish currency format broke the TR tests (previously obscured by 1). Bug 16727554 / commits ef91d1dbd60e9a245b121e3d31c8aad0332a64c7 and 44b0a574cbc3a54e421f5c79020cc59fbd4f34b9. Bug: 12781028 Change-Id: I6187f7f1feed915b1d8fd5fb398caef7998bfa04
* | Merge "Fixing formatDouble scientific notation tests"Neil Fuller2014-09-261-192/+393
|\ \
| * | Fixing formatDouble scientific notation testsNeil Fuller2014-09-251-192/+393
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Rather than having perpetually failing test cases the current Android behavior has been captured and compared against the Android docs. The "problem cases" have been merged into one test. The tests now execute all format() calls and report at the end if any fail, rather than failing at the first problem. This makes debugging and comparison easier. Each output from the affected tests has been inspected. The formatter settings and some justification have been documented in the tests for later engineers. For format() with scientific notation the desired behavior is often unclear because some parts of the docs contradict others about how much the min/max integer/fraction values are used. Many of the "problem cases" were the result of the significant digit rules not being obeyed by the RI which probably introduced doubt as to whether Android/ICU was correct. None of the results were found to be actually wrong, i.e. they appear to output the input number to the correct amount of precision. When using min/max integer/fraction digits (i.e. not using '@' characters), apparently by design DecimalFormat does not produce strings that make clear the number of significant digits used to generate them. e.g. 1.0 output to 4 sig digits does not output 1.000E0, but may output 1.0E0 or 1E0 depending on the pattern. Bug reports have been created to record why some categories of results are ok or to follow up where behavior is open to interpretation, e.g. the choice of exponent, or whether leading or trailing zeros are present in the output. Bug: 17654561 Bug: 17653864 Bug: 17652647 Bug: 17652196 Bug: 12781028 Change-Id: I6b3944b40ff837ecafd1b1be62c5824edb979930
* | | Merge "Update Class.primitiveType field uses."Hiroshi Yamauchi2014-09-251-2/+5
|\ \ \ | |_|/ |/| |
| * | Update Class.primitiveType field uses.Hiroshi Yamauchi2014-09-251-2/+5
|/ / | | | | | | | | | | | | This goes with the array allocation path optimization CL 108967. Bug: 9986565 Change-Id: I96de4725d4517d84af34ad05792fce8aa322f57a
* | Merge "Libcore: Allow "os.arch" system property to be changed"Andreas Gampe2014-09-241-1/+4
|\ \
| * | Libcore: Allow "os.arch" system property to be changedjgu212014-09-241-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | In a native bridge environment, it is necessary to change the "os.arch" system property to reflect the emulated architecture. Change-Id: I0b93da93251c6b4638de786bf98cf99df07c3fc2 Signed-off-by: jgu21 <jinghui.gu@intel.com>
* | | Merge "Tidy up DecimalFormatTest"Neil Fuller2014-09-241-1478/+1259
|\ \ \ | |/ / |/| / | |/
| * Tidy up DecimalFormatTestNeil Fuller2014-09-231-1478/+1259
| | | | | | | | | | | | | | | | | | | | | | The intent is to clean up the code to make it more obvious where things are failing and why. The names of the tests now better reflect their purpose and the code is reformatted. Some tests have been merged where they overlapped and some have been split. Change-Id: Ic31e2062c2682b6b3ac349c8fb76c9b9809e2150
* | Merge "Make libcore compile with BoringSSL."Elliott Hughes2014-09-242-23/+43
|\ \
| * | Make libcore compile with BoringSSL.Adam Langley2014-09-182-23/+43
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | NativeBN_putULongInt was cleaned up because of a slightly worrying mix of signed and unsigned ints, and because of an unneeded preprocessor test. However, as I look down the rest of the file, there's a lot of it but I didn't get to fixing it all up. Bug: 17409664 Change-Id: If0adde83bebf04e7e3be163c1b30ebef75a67d05 Signed-off-by: Adam Langley <agl@google.com>
* | | Merge "Revert "Make parameter name match comments for sdk build.""Elliott Hughes2014-09-231-1/+1
|\ \ \
| * | | Revert "Make parameter name match comments for sdk build."Elliott Hughes2014-09-231-1/+1
|/ / / | | | | | | | | | This reverts commit 716ec14a8b68157293c33b3bdd79a6ecc57f579b.
* | | Merge "Revert "Implements some StrictMath functions for improved performance.""Elliott Hughes2014-09-232-476/+38
|\ \ \
| * | | Revert "Implements some StrictMath functions for improved performance."Elliott Hughes2014-09-232-476/+38
|/ / / | | | | | | | | | This reverts commit 165e2b4075dadb99afc0856ab3c698809a6355a2.
* | | Merge "Change FinalizerWatchdogDaemon to not hold objects live"Mathieu Chartier2014-09-191-11/+22
|\ \ \ | |_|/ |/| |
| * | Change FinalizerWatchdogDaemon to not hold objects liveMathieu Chartier2014-09-191-11/+22
|/ / | | | | | | | | | | | | | | | | | | | | | | | | | | Previously, waitForFinalization would hold whatever object was being finalized live for MAX_FINALIZE_NANOS even though the finalizer on this object was run much earlier. This caused a test to be flaky since it was assuming that the JNI weak global reference of a recently finalized object wouldn't be held live. Bug: 17305633 (cherry picked from commit 6ba680664fa14a547543a8c63708543ea8072680) Change-Id: Ide60db55190a3764c16e4919a7c71a113cbf3968
* | Merge "libcore changes to support ConnectionPool cache flushing"Neil Fuller2014-09-173-0/+184
|\ \
| * | libcore changes to support ConnectionPool cache flushingNeil Fuller2014-09-163-0/+184
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A set of observer / listener components for network events. Party A, e.g. the Android ConnectivityManager, can make changes to network configuration that impacts the java network objects (e.g. connection pools, caches, etc.). Party B, e.g. Android libcore network components are interested in network configuration changes. The NetworkEventDispatcher enables Party A to communicate with Party B without hardcoding their details. Additional parties like B can be added. Bug: 17314604 (cherry-picked from commit b1e60e2015b81c285938ca569b66edda63d6533d) Change-Id: Ie0d0a8afe14e6a15253ce72f1abf9b996176e02f
* | | Merge "Fix FilePreferencesImplTest test initialization errors."Neil Fuller2014-09-171-15/+5
|\ \ \ | |/ / |/| |
| * | Fix FilePreferencesImplTest test initialization errors.Neil Fuller2014-09-171-15/+5
|/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fix IllegalAccessException from Preferences when this test is run "stand alone". The java.util.prefs.Preferences class is normally already initialized by the time this test runs (and initialized when there is no system property). However, in standalone cases the system property is pointing to a class that cannot be instantiated by ServiceLoader. The normal fallback process when the system property is not set would lead to FilePreferencesFactoryImpl being instantiated directly by java.util.prefs.Preferences, which is legal. Removing the system property fixes the issue. The FilePreferencesFactoryImpl is not intended to be created by ServiceLoader and so it is reasonable that the class is declared as package-protected. This test is for the implementation so it's reasonable just to bypass Preferences entirely. Bug: 17515057 Change-Id: I02ea38b4a50fc3b7299a35d0a1050455cb9ca970
* | Merge "Removing some compiler-warning suppressions from EnumMap"Neil Fuller2014-09-162-80/+70
|\ \
| * | Removing some compiler-warning suppressions from EnumMapNeil Fuller2014-09-152-80/+70
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The original motivation was to fix a report that line 162 does not compile with newer compilers: https://code.google.com/p/android/issues/detail?id=73244 There are a lot of compiler warning suppressions which made the problem less obvious than it should have been. The fact it compiled before was possibly a compiler bug. This change removes a lot of the suppression, and where it cannot be removed it narrows the scope to just local-variable declarations. One method-level suppression remains. This commit also adds a bug fix for situations where the raw type is being used and an EnumMap is being created from an existing Map. Previously a NullPointerException would have been thrown if the first key found was not actually an enum, now a ClassCastException will be thrown. Some additional comments have been added and some loops made into foreach. Bug: https://code.google.com/p/android/issues/detail?id=73244 Change-Id: I7f23744dc55237a94e5906e77720a9595caa64e8
* | | Merge "Fix ZoneInfo.useDaylightTime()"Neil Fuller2014-09-161-8/+7
|\ \ \
| * | | Fix ZoneInfo.useDaylightTime()Neil Fuller2014-09-151-8/+7
| |/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently implemented is "are there any offset transitions in the future?". This is wrong: Transitions may occur in the future because of DST, but can also occur for other reasons (e.g. if the raw offset for a zone changes). We should be implementing: Is the currently active transition, or any transition in the future, one that has isDst == true. This was causing a test failure in libcore.java.util.TimeZoneTest#testDisplayNames for Asia/Novokuznetsk and Europe/Simferopol for tzdata2014g. This is because they have a transition entry for October 26, 2014 (i.e. in the future). For each, the existance of the transition entry is not due to an offset change at all: For Asia/Novokuznetsk it is because the abbreviation for the zone changes on that date (information we don't curently use). For Europe/Simferopol it is because the offset from UTC changes on that date (but there is no actual DST transtion). Bug: 17377276 (cherry-picked from commit d42af6ed0fec3cfca52912b0d8b3b459e72be4b4) Change-Id: I148503280b8dee653bac32eec3aa58d232102628
* | | Merge "Delete RuntimeTest freeMemory test"Mathieu Chartier2014-09-151-15/+0
|\ \ \
| * | | Delete RuntimeTest freeMemory testMathieu Chartier2014-09-141-15/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Test was flaky due to bad assumptions, Runtime.freeMemory is already tested by test_memory, test_gc. Bug: 17448025 (cherry picked from commit e2233ca92da0339686da18db4a1e27b9a4c76b91) Change-Id: I88d09ee5cd1c4e34c97814afd2cbadc870222738
* | | | Merge "Libcore: Change miranda modifier flag"Andreas Gampe2014-09-151-1/+1
|\ \ \ \ | |/ / / |/| | |
| * | | Libcore: Change miranda modifier flagAndreas Gampe2014-09-151-1/+1
|/ / / | | | | | | | | | | | | | | | | | | | | | | | | | | | Flag was changed in ART. Move accordingly. Bug: 16161620 (cherry picked from commit 93b153dea95bfa5068d2146228d62c3e4e905da2) Change-Id: I2f591d53b7d1559171e70aaaf22225d94b4882f5
* | | Merge "Fix race between finalizeAllEnqueued and GC"Mathieu Chartier2014-09-141-5/+19
|\ \ \
| * | | Fix race between finalizeAllEnqueued and GCMathieu Chartier2014-09-141-5/+19
|/ / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Problem: GC uses pendingNext field for its internal references. This causes a race where the GC can see the sentinel finalizer reference through the internal doubly linked list and scan it before the referent is marked, resulting in the pendingNext being part of a GC internal reference queue. Then when we updated the pendingNext to make a circular list it broke the list since the node never reached the head. The solution is to use native code so that we can use the same lock that the GC uses when enqueing references and retry if the GC changed the pendingNext. Bug: 17462553 (cherry picked from commit e928a238e5e7f7b9fd74ed460f7e7943484d96af) Change-Id: I6b68ca210bdda3c2468c5519d423f0bb1f00fc14
* | | Merge "Introduce checks for integer overflow during division."Neil Fuller2014-09-111-0/+8
|\ \ \
| * | | Introduce checks for integer overflow during division.Neil Fuller2014-09-101-0/+8
| |/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Historically, Android would refuse to perform calculations on memory grounds for large values or would cast to an int and produce incorrect result for diffScales outside of the int range. This change adds a check to prevent scale overflow for large scale division. Bug: 17393664 Change-Id: I090c271bb02379f35d3c4392aa38be2bb0cf431f
* | | Merge "Remove referenceStaticOffsets from Class.java since it's not needed ↵Mingyao Yang2014-09-101-3/+0
|\ \ \ | | | | | | | | | | | | anymore."
| * | | Remove referenceStaticOffsets from Class.java since it's not needed anymore.Mingyao Yang2014-09-101-3/+0
| | | | | | | | | | | | | | | | | | | | Bug: 16236588 Change-Id: Icebdf0febee72a5dbbebc1906b069d52bf756e80
* | | | Merge "High CPU load in java.nio using poll"Elliott Hughes2014-09-101-1/+2
|\ \ \ \ | |_|/ / |/| | |
| * | | High CPU load in java.nio using pollPrzemyslaw Jakwert2014-09-101-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Sometimes when phone goes out of coverage CPU is stuck at high load when it should not. System.os.poll() returns the number of file descriptors ready to be processed, but since they all have revent=POLLERR, they are not handled/sent to the application. Next time application does Selector.select(), native will not block since there are FDs which have to be processed and Java will discard them again. As a result, Selector.select() gets called again and again, producing 100% CPU load per thread that polls for FDs with POLLERR set. The fix is to add POLLERR handling (POLLHUP is being handled already). Bug: 17456151 Change-Id: I04bbb8e64bf64aee1e95ea7a1a2e1d16c6e1c990
* | | | Merge "Add Reference.getReferent for reference intrinsic."Mathieu Chartier2014-09-091-1/+13
|\ \ \ \ | |_|/ / |/| | |
| * | | Add Reference.getReferent for reference intrinsic.Mathieu Chartier2014-09-091-1/+13
|/ / / | | | | | | | | | | | | | | | | | | | | | | | | Reference intrinsic was incorrectly inlining PhantomReference.get(). We get around this by adding a layer of indirection. Reference.get() now calls getReferent() which is intrinsified and inlined. Bug: 17429865 Change-Id: I39803506c7bd800500ca3632a6cdf1077e382bff
* | | Merge "Suppress one more apache-harmony sql test"Neil Fuller2014-09-091-0/+1
|\ \ \
| * | | Suppress one more apache-harmony sql testNeil Fuller2014-09-091-0/+1
|/ / / | | | | | | | | | | | | | | | | | | | | | The test is broken and is being suppressed: com.android.org.apache.harmony.sql.tests.java.sql.DataTruncationTest Bug: 17342415 Change-Id: I5dd2f506400fff7c290e27adf4d3bd34f0624044
* | | Merge "Suppress broken apache-harmony beans CTS tests"Neil Fuller2014-09-091-0/+17
|\ \ \ | |/ / |/| |
| * | Suppress broken apache-harmony beans CTS testsNeil Fuller2014-09-091-0/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | One of the apache-harmony serialization tests is package-sensitive. The other tests suppressed probably broke due to a fix in the Android fork of harmony (commit 19a270e90b1e992c1f6639f355ae13564c2f3a6a). The code may be incorrect but if so it has been broken subtly since Dec 2010. Bug 17433734 has been created to investigate. Bug: 17394106 Change-Id: I654d82b607e5487e0e6614ec4bcc5be98a9394e9
* | | Merge "Add handling for hashed uninflated object."Mathieu Chartier2014-09-091-0/+6
|\ \ \ | |/ / |/| |
| * | Add handling for hashed uninflated object.Mathieu Chartier2014-09-081-0/+6
|/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is an Optimization to reduce how often we call System.identityHashCode. If the lockword is set to the hash code state then we simply return this value. Otherwise, we use System.identityHashCode. Maps launch exclusive time spent in System.identityHashCode: Before: 4.5% After: 2.4% Bug: 16828525 (cherry picked from commit 6917aebf2eb26c2b003a72d09c1c5bb6310160b0) Change-Id: I0ccad53cb5f8f4f27fe11725a91ab45a117452a3
generated by cgit v1.1 at 2025-01-10 09:19:17 +0000