GitLab

ART already does this when a threads are attached. There's no need
to do it another time.

Also add a test that documents the behaviour wrt. to thread naming
for attached threads.

bug: 27748318

(cherry picked from commit 81888044)

Change-Id: I8b1ac9407114d0fc399a3bc644d45e2f00ef7200

Bug: http://b/24803663

(cherry picked from commit 44f7ca86)

Change-Id: Ida3b9a0916504e750e9fac710debf599a4989f65

Bug: http://b/24803663
Change-Id: Icfe8f3b4c630ad133ce2d7006749ed905a2ca09d

Bug: http://b/25928358

This reverts commit 4b347baf.

The NativeAllocationRegistry API provides a way to associate native
allocations with Java objects. The native allocations will
automatically be freed when the correspondong Java object becomes
unreachable.

Use NativeAllocationRegistry for BigInt.

Bug: 23130675
Change-Id: If89dc03f0668afdecf1086280d16d2803e07a62a

libcrypto isn't used and libnativehelper should be switched over
to an NDK built version since it's for use from CTS tests.

bug: 26457850
Change-Id: I3ad754051c4eeaadc501339db9c8782d469018ff

The debug version, libopenjdkd, depends on the debug version for
the jvm connector, libopenjdkjvmd.

Bug: 26422233
Change-Id: I78a948bccd4a06e738194537233fa0cfca050087

Change-Id: I4fe7bd0cd8661b426fef110c876ce9923d92798f

Change-Id: Iffeffc2ed0cfe4c1568c74ddf3176de22930b2a5

Change-Id: If805cf537bfe247dd8a5717771f5ac3007af0ddd

ART's GetDirectBufferAddress(java.nio.Buffer) implementation returns
the value stored in the Buffer.address field.
java.nio.DirectByteBuffer was not initializing this field correctly
when slicing buffers from non-zero position.

This change fixes the issue and adds tests. This change also removes
the TODO inside DirectByteBuffer.address() because it is now confirmed
that this method is supposed to return exactly the same value as
GetDirectBufferAddress.

Bug: 26233076
Change-Id: I6e7509d443c8cd8ae50eaf1e4ea42d1c04423883

Clang generates illegal instruction on mips64r6 with -O0.
https://dmz-portal.mips.com/bugz/show_bug.cgi?id=2218

Bug: 25928358

Change-Id: I8ccd644f1509b4b341384fa67facc07cb966dfa8

Removed CharacterData* and CharacterName classes.
+ bugfixes from mnc

Bug: 25442844
Change-Id: I8c20cdf32ca3530dc425c8117c637769463c1f93
(cherry picked from commit 2614ae16)

Helps us to commit trivial makefile changes ahead of the larger
code merge.

Change-Id: I2710a664e3a39afead03fc617f04e432df7f8fea

Change-Id: I598b9454e0ebcf2191fbc97980cb8267771ec530

This change also contains a revert of ac740d8c.

Change-Id: Ie69ec7242576af80fce4d518a504d19ddd9dc580

Removed CharacterData* and CharacterName classes.
+ bugfixes from mnc

No longer breaks the build.

Bug: 25442844
Change-Id: I8c20cdf32ca3530dc425c8117c637769463c1f93

Revert "java.lang.Character implemented using icu4c DO NOT MERGE"

This reverts commit c307caca.

Change-Id: I1c8b6f7ba7b28d578b8081c409d6b8a774918284

Removed CharacterData* and CharacterName classes.
+ bugfixes from mnc

Bug: 25442844
Change-Id: Iec64a29a6d2d70a5f4fcc1ada2c2446339965880

Change-Id: I3dfbf6b417a883165421b79748ae0bc5bdb4ee1e

Change-Id: I62df0291e41199b52409f2a0628646c6bea48d12

Change-Id: I1ef3fbece2b44b08e6b2b5168ed34beeee341bd8

The general sequence of operations here is :

(1) Compile core-all with a specified input obfuscation map (see below).
Classes that aren't specified in the input obfuscation map are
obfuscated according to proguard's usual algorithm. Classes that match
keep rules (public API, usually) are left alone. In addition, proguard
will produce an output obfuscation mapping after it processes this target.
This will be a superset of the input obfuscation map.

(2) Compile core-all-obfuscated, which uses the same input fileset as
core-all but has proguard turned off.

(3) Compile core-oj and core-libart against core-all-obfuscated. Then
apply the obfuscation map from (1).

Why is an input obfuscation map necessary for step (1) ?
Native methods, mainly. Proguard will leave package names unchanged
for classes that have native methods. This will force *all* classes in
that package to have unobfuscated package names since proguard doesn't
go through the trouble of proving there's no package private accesses
across these packages. We want to force these classes to be obfuscated,
but in a manner that allows us to easily to fix up the native code to
reflect the new naming. This change includes a script that can munge an
obfuscation map from proguard to force obfuscation of known bad classes
and packages. In addition, we force proguard to perform an "inconsistent"
obfuscation for sun.misc. We want to leave the package name for Unsafe
unchanged but want the rest of the package to be obfuscated. This is
provably safe because Unsafe doesn't contain any non public methods.

Change-Id: Ibdfb8ca36d6e0bfedd7552268c5cb83e68cccf09

Nothing too alarming, except for a change to deal with code
that assumed imr_multiaddr and imr_interface in ip_mreq were
uint32_t (like in the kernel UAPI) and not in_addr like they
are in glibc.

Change-Id: I98f7208939df12edb086e6cdf6f09cec0527ec50

- Move some of the internal implementation details of libcore's
  zipfile into StrictJarFile.
- TODO: Adler32 continues to use old native code from libcore, this
  must be switched over.
- InflaterInputStream: |closed| becomes protected.
- ZipFile : Always use mmap.
- ZipEntry : Add a long dataOffset.
- Switch all native code over to explicit registration.

Change-Id: Id5519b4548ea1eb22fd182edfbd2c804dc6f3bb5

We must use UTF-8 and not modified UTF-8.

bug: 23523042
Change-Id: I24fe6e2653ee8876c603776b835c91804826724c

Libcore tests reference standard libcore headers, including objects
that use libnativehelper code. Thus the tests also require
libnativehelper.

This breaks ASan build. Does not reproduce in the normal build because
all libnativehelper references are in dead code, and ASan disables
dead code stripping:
https://code.google.com/p/address-sanitizer/issues/detail?id=260

Bug: 21785137
Change-Id: Ic272384cc1a6f77e81079bf4f4ea751a0ed92ea1

This is to enable host testing of ART on 32bits of the
dalvik.system package.

Change-Id: Iec78ccb29ac14aa14e2e32a86d6a19914b2fc960

Fixes host run-tests that were broken by de9a75e2ab579804ea44f9688

Change-Id: I0cbd40048f9a222996858f3574d6faa93121a61f

Pulled in by the static libziparchive dependency.

Note that we can't add these dependencies in the sub-makefile
because libziparchive has different module names for target
vs host (libziparchve vs libziparchive-host).

Change-Id: Ie2e036f9e1bfd13d439501e2577651e42642c1bd

The move from to gcc 4.8 to gcc 4.9 for arm32 introduced a bug in this
code. The original code is trying to out smart the compiler by arch, but
we got caught. Running benchmarks, the amount of time we save by doing this
is in the nanosecond range, so just let the compiler figure things out on
it's own.

It turns out for aarch64, x86, x86_64, two of the functions produce exactly
the same code. For swapLongs, x86/x86_64 produces slightly different code
but is about the same performance.

For arm32, letting the compiler optimize also leads to about the same
performance.

Adding unit tests and benchmark code for these.

Bug: 19692084

Change-Id: I858eb3147ef1e9e2c1894ddb226cdddcc0baf933

Bug: 15350832
Change-Id: I8d84f3e50b643806ccf01190797c69ce6445b539

The tests that exercise this code were removed. This code doesn't
compile with BoringSSL, so just remove it.

Change-Id: I9598ef5e5a2d7b7d115b63b5b670976d39ca1405

Change-Id: I79c5389af44ff2aea784d4f57c82d6aebf560132

These are all picked up by virtue of the libraries that we use.

Change-Id: Ib5e86c65d53f3448d5f1d0c0d24f0f63ef5f1868

Since libcore is now using std::unique_ptr, we need to have a sane,
modern STL on all platforms. Since the Mac build is stuck on libstdc++
4.2, use libc++.

Change-Id: Id4cd32fa181ae53123f808a9366211748c44276f

Switch from stlport to libcxx as stlport lacks std::unique_ptr.

Change-Id: I45a3588a8ecf4689521f1df6654ed279a6d0669e

Change-Id: I7827331202482e28e824fc6583f590ddadaa2087

Change-Id: I32fdb9dabbc87d49e0be82ea39c2eea6f452fd6f

Change-Id: I52559cfcc806dfe0d8682be50a6078cb678e4169