Return to Video

Memory GC and Performance

  • 0:00 - 0:03
    Now that all of our code is
    running fast and awesome, let's
  • 0:03 - 0:08
    talk a bit more about memory and how it
    affects the performance in our system.
  • 0:08 - 0:12
    Many programming languages that are
    known for being close to the hardware,
  • 0:12 - 0:14
    or rather, high performance,
    like C, C++,
  • 0:14 - 0:18
    and Fortran, usually programmers
    to manage memory themselves.
  • 0:18 - 0:20
    Effectively programmers
    are responsible for
  • 0:20 - 0:25
    allocating a block of memory and then
    sometime in the future de-allocating
  • 0:25 - 0:26
    it when they're actually done using it.
  • 0:26 - 0:31
    Since you define when and how much
    memory to allocate in free, the entire
  • 0:31 - 0:35
    quality of managing memory depends
    on your skills and effectiveness.
  • 0:35 - 0:36
    That's a lot of responsibility.
  • 0:36 - 0:40
    And the reality programmers aren't
    always the best at keeping track of
  • 0:40 - 0:42
    all those bits and pieces of memory.
  • 0:42 - 0:45
    I mean think about it,
    product development is a muddy and
  • 0:45 - 0:49
    crazy process and often memory ends
    up not getting freed properly.
  • 0:49 - 0:53
    These un-liberated blocks of memory, are
    called memory leaks and they just sit
  • 0:53 - 0:58
    around hogging resources, that you
    could use better or somewhere else.
  • 0:58 - 1:01
    To reduce this chaos, stress,
    and sometimes big money losses,
  • 1:01 - 1:05
    caused by memory leaks,
    managed memory languages were created.
  • 1:05 - 1:09
    The run times of these languages
    track memory allocations and
  • 1:09 - 1:12
    release memory back to the system
    when it's no longer being needed by
  • 1:12 - 1:16
    the application itself, all without
    any intervention from the programmer.
  • 1:16 - 1:20
    This art, or rather science,
    of reclaiming memory in a managed memory
  • 1:20 - 1:24
    environment is known as garbage
    collection, this concept was created by
  • 1:24 - 1:30
    John McCarthy in 1959 to solve problems
    in the lisp programming language.
  • 1:30 - 1:33
    The basic principles of garbage
    collection are as follows, number one,
  • 1:33 - 1:37
    find data objects in a program that
    cannot be accessed in the future for
  • 1:37 - 1:40
    example, any memory that is no
    longer referenced by the code.
  • 1:40 - 1:44
    And number two, reclaim
    the resources used by those objects.
  • 1:44 - 1:47
    Simple concept in theory, but
    it gets pretty complex once you've
  • 1:47 - 1:51
    got 2 million lines of code and
    four gigs worth of allocations.
  • 1:51 - 1:53
    Now think about it, garbage collection
    can be really gnarly, I mean,
  • 1:53 - 1:57
    if you've got some 20,000 allocations
    in your program right now.
  • 1:57 - 1:58
    Which ones aren't being needed anymore?
  • 1:58 - 2:01
    Or better yet, when should you
    execute a garbage collection event
  • 2:01 - 2:04
    to free up memory that isn't used?
  • 2:04 - 2:06
    These are actually very
    difficult questions, and
  • 2:06 - 2:10
    thankfully we've had about 50 years
    worth of innovation to improve them,
  • 2:10 - 2:12
    which is why the garbage
    collector in Android's Runtime,
  • 2:12 - 2:15
    is quite a bit more sophisticated
    than McCarthy's original proposal.
  • 2:15 - 2:19
    It's been built to be as fast and
    non-intrusive as possible.
  • 2:19 - 2:23
    Effectively the memory heaps in androids
    runtimes are segmented into spaces,
  • 2:23 - 2:24
    based on the type of allocation and
  • 2:24 - 2:28
    how best the system can organize
    allocations for future GC events.
  • 2:28 - 2:30
    As a new object is allocated,
  • 2:30 - 2:33
    these characteristics are taken into
    account to best fit what spaces should
  • 2:33 - 2:37
    be placed into depending what version
    of the android runtime you're using.
  • 2:37 - 2:39
    And here's the important part.
  • 2:39 - 2:41
    Each space has a set size,
  • 2:41 - 2:44
    as objects are allocated, we keep
    track of the combined sizes, and,
  • 2:44 - 2:47
    as a space starts to grow, the system
    will need to execute a garbage
  • 2:47 - 2:52
    collection event in an attempt to free
    up memory for future allocations.
  • 2:52 - 2:54
    Now it's worth putting out that
    GC events will behave differently
  • 2:54 - 2:57
    depending on what Android
    runtime you're using.
  • 2:57 - 3:01
    For example, in Dalvik many GC events
    are stop the world events, meaning
  • 3:01 - 3:05
    that any managed code that is running
    will stop until the operation completes.
  • 3:05 - 3:09
    Which can get very problematic, when
    these GCs take longer than normal or
  • 3:09 - 3:11
    there's a ton of them happening at once,
  • 3:11 - 3:14
    since it's going to significantly
    eat into your frame time.
  • 3:14 - 3:14
    >> And to be clear,
  • 3:14 - 3:18
    the Android engineers have spent a lot
    of time making sure that these events
  • 3:18 - 3:21
    are as fast as possible to reduce
    interruptions, that being said,
  • 3:21 - 3:25
    they can still cause some application
    performance problems in your code.
  • 3:25 - 3:29
    Firstly, understand that the more time
    your app is spending doing GCs in
  • 3:29 - 3:33
    a given frame, the less time it's got
    for the rest of the logic needed to keep
  • 3:33 - 3:35
    you under the 16 millisecond
    rendering barrier.
  • 3:35 - 3:38
    So if you got a lot of GCs or some long
    ones that are occurring right after
  • 3:38 - 3:42
    each other, it might put your frame
    processing time over the 16 millisecond
  • 3:42 - 3:47
    rendering barrier, which will cause
    visible hitching or jank for your users.
  • 3:47 - 3:50
    Secondly, understand that your code
    flow may be doing the kinds of work that
  • 3:50 - 3:55
    force GCs to occur more often, or making
    them last longer than normal duration.
  • 3:55 - 3:59
    For example, if you're allocating a
    hoard of objects in the inner most part
  • 3:59 - 4:02
    of a loop that runs for a long time,
    then you're going to be polluting your
  • 4:02 - 4:06
    memory heap with a lot of objects and
    you'll end up kicking off a lot of GCs
  • 4:06 - 4:09
    quickly, due to this
    additional memory pressure.
  • 4:09 - 4:12
    And even though we're in
    a managed memory environment,
  • 4:12 - 4:13
    memory leaks can still happen.
  • 4:13 - 4:17
    Although they're not as easy to
    create as the other languages.
  • 4:17 - 4:20
    These leaks can pollute your heat
    with objects that won't get freed
  • 4:20 - 4:24
    during a GC event, effectively reducing
    the amount of usable space you have and
  • 4:24 - 4:27
    forcing more GC events to be kicked off,
    in a regular fashion as a result.
  • 4:27 - 4:29
    So that's the deal, I mean,
  • 4:29 - 4:33
    if you want to reduce the amount of GC
    events that happen in a given frame,
  • 4:33 - 4:36
    then you need to focus on
    optimizing your apps memory usage.
  • 4:36 - 4:39
    From a code perspective, it might be
    difficult to track down where problems
  • 4:39 - 4:41
    like these are coming from, but
  • 4:41 - 4:45
    thankfully, the Android SDK has a set
    of powerful tools at your disposal.
  • 4:45 - 4:46
    Let's take a look.
Title:
Memory GC and Performance
Description:

04-02 Memory, GC, and Performance

more » « less
Video Language:
English
Team:
Udacity
Project:
ud825 - Android Performance
Duration:
04:47

English subtitles

Revisions Compare revisions