GitHub user andrewor14 opened a pull request:

    https://github.com/apache/spark/pull/9000

    [SPARK-10956] Common MemoryManager interface for storage and execution

    This patch introduces a `MemoryManager` that is the central arbiter of how 
much memory to grant to storage and execution. This patch is primarily 
concerned only with refactoring while preserving the existing behavior as much 
as possible.
    
    This is the first step away from the existing rigid separation of storage 
and execution memory, which has several major drawbacks discussed on the 
[issue](https://issues.apache.org/jira/browse/SPARK-10956). It is the precursor 
of a series of patches that will attempt to address those drawbacks.

You can merge this pull request into a Git repository by running:

    $ git pull https://github.com/andrewor14/spark memory-manager

Alternatively you can review and apply these changes as the patch at:

    https://github.com/apache/spark/pull/9000.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

    This closes #9000
    
----
commit 9e73981280b6dfdfdd6132e2a213b6c4a95c026c
Author: Andrew Or <[email protected]>
Date:   2015-09-30T23:57:06Z

    Introduce MemoryManager + StaticMemoryManager
    
    This commit does not represent any change in behavior. The
    MemoryManager's introduced are not actually used anywhere yet.
    This will come in the next commit.

commit b5df241669f6679742ec782d41b96174967f3911
Author: Andrew Or <[email protected]>
Date:   2015-10-01T01:32:48Z

    Derive max memory from MemoryManager
    
    This commit refactors BlockManager and ShuffleMemoryManager to
    take in a MemoryManager in their constructors, such that the max
    memory is derived from the MemoryManager instead of from a Long
    that is passed around everywhere.
    
    Note that no memory acquisition or release goes through the
    MemoryManager yet. This will come in future commits.

commit 700e5d12c2f644a48f067f0e344f46aeabbc40c7
Author: Andrew Or <[email protected]>
Date:   2015-10-01T20:29:17Z

    Route ShuffleMemoryManager through new interface
    
    All execution memory is now acquired through the new MemoryManager
    interface as of this commit. The next step is to do it for storage
    memory.

commit 933de614df6e84d7776aa1d11ae1d82042f3f6dd
Author: Andrew Or <[email protected]>
Date:   2015-10-05T22:29:38Z

    Route MemoryStore through new interface
    
    All storage memory is now acquired through the new MemoryManager
    interface. This requires non-trivial refactoring due to the fact
    that the unrolling and eviction logic are closely intertwined.

commit e73e463ccaf8220387903b59b9a6ab71662d2ee7
Author: Andrew Or <[email protected]>
Date:   2015-10-05T23:57:41Z

    Limit scope of synchronized blocks to avoid deadlocks

commit 52e201480e07974e9d13936d779b7c57e7c349a1
Author: Andrew Or <[email protected]>
Date:   2015-10-06T01:01:36Z

    Remove ResultWithDroppedBlocks
    
    It was an awkward case class that didn't really do much. Instead
    we'll pass a mutable list into the methods to get the dropped
    blocks.

commit 88faede150c83b197d17f0571fa2af2503a76179
Author: Andrew Or <[email protected]>
Date:   2015-10-06T19:17:28Z

    Add unit test for StaticMemoryManager

----


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at [email protected] or file a JIRA ticket
with INFRA.
---

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to