• Paulo Pinto (16/16) Jun 27 2014 Hi,
• Kagamin (2/2) Jun 28 2014 BTW, how GC compares to RC with respect to battery life? All
• Paulo Pinto (8/10) Jun 28 2014 I don't know, but given the focus to battery life in the upcoming
• w0rp (10/29) Jun 28 2014 I like his focus on the duration of frames per second. If you are

Paulo Pinto <pjmlp progtools.org> writes:

Hi,

posting this talk here, as Java performance on Android is often 
mentioned in the discussions about GC vs RC performance.

So here you have the Android  team explaining:

- Dalvik GC sucks and is a basic stop the world implementation with 
pauses > 10ms

- ART solves the GC issue by adopting multiple concurrent GC algorithms,
depending on the application state thus reducing the stop down to 3ms. 
More optimizations still to be done until the final release

- JIT compiler optimized for battery life and low power processors, thus 
only very hot methods get actually compiled to native code

- Performance sorted out, by doing AOT compilation on install, similar 
to approach taken by OS/400, Windows Phone 8

https://www.youtube.com/watch?v=EBlTzQsUoOw



--
Paulo

"Kagamin" <spam here.lot> writes:

BTW, how GC compares to RC with respect to battery life? All 
those memory scans don't come for free.

Paulo Pinto <pjmlp progtools.org> writes:

Am 28.06.2014 14:42, schrieb Kagamin:
 BTW, how GC compares to RC with respect to battery life? All those
 memory scans don't come for free.

I don't know, but given the focus to battery life in the upcoming 
Android release I would say it should be good enough.

My S3 with Dalvik can last almost two days with occasional network usage.

My older Android phone, an operator specific model running 2.2, can last 
almost four days.

--
Paulo

"w0rp" <devw0rp gmail.com> writes:

On Saturday, 28 June 2014 at 06:23:25 UTC, Paulo Pinto wrote:
 Hi,

 posting this talk here, as Java performance on Android is often 
 mentioned in the discussions about GC vs RC performance.

 So here you have the Android  team explaining:

 - Dalvik GC sucks and is a basic stop the world implementation 
 with pauses > 10ms

 - ART solves the GC issue by adopting multiple concurrent GC 
 algorithms,
 depending on the application state thus reducing the stop down 
 to 3ms. More optimizations still to be done until the final 
 release

 - JIT compiler optimized for battery life and low power 
 processors, thus only very hot methods get actually compiled to 
 native code

 - Performance sorted out, by doing AOT compilation on install, 
 similar to approach taken by OS/400, Windows Phone 8

 https://www.youtube.com/watch?v=EBlTzQsUoOw



 --
 Paulo

I like his focus on the duration of frames per second. If you are 
aiming for 60FPS, you are aiming for a time period of about 16ms 
to 17ms per frame. So he mentions the current Dalvik GC occupying 
about 10ms for a collection in most cases, leading to a single 
dropped frame, and a near full memory case leading to about 50ms 
and above, leading to a few dropped frames. So when thinking 
about optimising GC, aiming for a collection time small enough to 
fit comfortably inside a frame seems like a good way to think 
about it.