a5931185c97c7b17981a9fc5016834a0bdd9480b |
|
02-Sep-2016 |
Chih-Hung Hsieh <chh@google.com> |
Fix google-explicit-constructor warnings in art. * Add explicit keyword to conversion constructors, or NOLINT for implicit converters. Bug: 28341362 Test: build with WITH_TIDY=1 Change-Id: I1e1ee2661812944904fedadeff97b620506db47d
|
9ef26544e6d9c438b150dfda39be61a7b4fd8b20 |
|
20-Apr-2016 |
Vladimir Marko <vmarko@google.com> |
Fix HInstruction::ReplaceInput(), allow no-op. Allow HInstruction::ReplaceInput() to be called with a `replacement` being the same as the old input and do nothing in that case. This is a follow-up to https://android-review.googlesource.com/216923 where I erroneously assumed that it never happens. Also adhere to the standard C++ std::forward_list<> semantics in the single-element overload of `IntrusiveForwardList<>::splice_after()`. Bug: 28173563 (cherry picked from commit c6b5627c25ff5653e97ccff8c5ccf6ac967b6f83) Change-Id: I66b7d4b48f629284d0bcb1d31100519e02a872e5
|
c6b5627c25ff5653e97ccff8c5ccf6ac967b6f83 |
|
20-Apr-2016 |
Vladimir Marko <vmarko@google.com> |
Fix HInstruction::ReplaceInput(), allow no-op. Allow HInstruction::ReplaceInput() to be called with a `replacement` being the same as the old input and do nothing in that case. This is a follow-up to https://android-review.googlesource.com/216923 where I erroneously assumed that it never happens. Also adhere to the standard C++ std::forward_list<> semantics in the single-element overload of `IntrusiveForwardList<>::splice_after()`. Bug: 28173563 Change-Id: I5cea14c212b1083f90ffe6b5b53324ad663d57d8
|
d59f3b1b7f5c1ab9f0731ff9dc60611e8d9a6ede |
|
29-Mar-2016 |
Vladimir Marko <vmarko@google.com> |
Use iterators "before" the use node in HUserRecord<>. Create a new template class IntrusiveForwardList<> that mimicks std::forward_list<> except that all allocations are handled externally. This is essentially the same as boost::intrusive::slist<> but since we're not using Boost we have to reinvent the wheel. Use the new container to replace the HUseList and use the iterators to "before" use nodes in HUserRecord<> to avoid the extra pointer to the previous node which was used exclusively for removing nodes from the list. This reduces the size of the HUseListNode by 25%, 32B to 24B in 64-bit compiler, 16B to 12B in 32-bit compiler. This translates directly to overall memory savings for the 64-bit compiler but due to rounding up of the arena allocations to 8B, we do not get any improvement in the 32-bit compiler. Compiling the Nexus 5 boot image with the 64-bit dex2oat on host this CL reduces the memory used for compiling the most hungry method, BatteryStats.dumpLocked(), by ~3.3MiB: Before: MEM: used: 47829200, allocated: 48769120, lost: 939920 Number of arenas allocated: 345, Number of allocations: 815492, avg size: 58 ... UseListNode 13744640 ... After: MEM: used: 44393040, allocated: 45361248, lost: 968208 Number of arenas allocated: 319, Number of allocations: 815492, avg size: 54 ... UseListNode 10308480 ... Note that while we do not ship the 64-bit dex2oat to the device, the JIT compilation for 64-bit processes is using the 64-bit libart-compiler. Bug: 28173563 Bug: 27856014 (cherry picked from commit 46817b876ab00d6b78905b80ed12b4344c522b6c) Change-Id: Ifb2d7b357064b003244e92c0d601d81a05e56a7b
|
46817b876ab00d6b78905b80ed12b4344c522b6c |
|
29-Mar-2016 |
Vladimir Marko <vmarko@google.com> |
Use iterators "before" the use node in HUserRecord<>. Create a new template class IntrusiveForwardList<> that mimicks std::forward_list<> except that all allocations are handled externally. This is essentially the same as boost::intrusive::slist<> but since we're not using Boost we have to reinvent the wheel. Use the new container to replace the HUseList and use the iterators to "before" use nodes in HUserRecord<> to avoid the extra pointer to the previous node which was used exclusively for removing nodes from the list. This reduces the size of the HUseListNode by 25%, 32B to 24B in 64-bit compiler, 16B to 12B in 32-bit compiler. This translates directly to overall memory savings for the 64-bit compiler but due to rounding up of the arena allocations to 8B, we do not get any improvement in the 32-bit compiler. Compiling the Nexus 5 boot image with the 64-bit dex2oat on host this CL reduces the memory used for compiling the most hungry method, BatteryStats.dumpLocked(), by ~3.3MiB: Before: MEM: used: 47829200, allocated: 48769120, lost: 939920 Number of arenas allocated: 345, Number of allocations: 815492, avg size: 58 ... UseListNode 13744640 ... After: MEM: used: 44393040, allocated: 45361248, lost: 968208 Number of arenas allocated: 319, Number of allocations: 815492, avg size: 54 ... UseListNode 10308480 ... Note that while we do not ship the 64-bit dex2oat to the device, the JIT compilation for 64-bit processes is using the 64-bit libart-compiler. Bug: 28173563 Change-Id: I985eabd4816f845372d8aaa825a1489cf9569208
|