четверг, 22 декабря 2011 г.
суббота, 17 декабря 2011 г.
Cassandra Architecture Internals
Cassandra Architecture Internals
Literature:
- Gossip: "Efficient reconciliation and flow control for anti-entropy protocols"
- Failure detection: "The Phi accrual failure detector"
- and more ...
Literature:
- Gossip: "Efficient reconciliation and flow control for anti-entropy protocols"
- Failure detection: "The Phi accrual failure detector"
- and more ...
вторник, 13 декабря 2011 г.
Google издевается над веб-сервисами Microsoft
Google издевается над веб-сервисами Microsoft
Это мелочи, главно, что гуглоид дает ценную ссылку - The Datacenter as a Computer: An Introduction to the Design of Warehouse-Scale Machines
Это мелочи, главно, что гуглоид дает ценную ссылку - The Datacenter as a Computer: An Introduction to the Design of Warehouse-Scale Machines
среда, 7 декабря 2011 г.
Java наносит ответный удар (по Scala)
Real life Scala feedback from Yammer
"Right now at Yammer we're moving our basic infrastructure stack over to Java"
"Scala, as a language, has some profoundly interesting ideas in it. That's one of the things which attracted me to it in the first place. But it's also a very complex language. The number of concepts I had to explain to new members of our team for even the simplest usage of a collection was surprising: implicit parameters, builder typeclasses, "operator overloahttp://www.blogger.com/img/blank.gifding", return type inference, etc. etc. Then the particulars: what's a Traversable vs. a TraversableOnce? GenTraversable? Iterable? IterableLike? Should they be choosing the most general type for parameters, and if so what was that? What was a =:= and where could they get one from?"
"In addition to the concepts and specific implementations that Scala introduces, there is also a cultural layer of what it means to write idiomatic Scala."
"In hindsight, I definitely underestimated both the difficulty and importance of learning (and teaching) Scala."
"Contrast this with the default for the JVM ecosystem: if new hires write Java, they're productive as soon as we can get them a keyboard."
"Despite the fact that we're moving away from Scala, I still think it's one of the most interesting, innovative, and exciting languages I've used ..."
"Right now at Yammer we're moving our basic infrastructure stack over to Java"
"Scala, as a language, has some profoundly interesting ideas in it. That's one of the things which attracted me to it in the first place. But it's also a very complex language. The number of concepts I had to explain to new members of our team for even the simplest usage of a collection was surprising: implicit parameters, builder typeclasses, "operator overloahttp://www.blogger.com/img/blank.gifding", return type inference, etc. etc. Then the particulars: what's a Traversable vs. a TraversableOnce? GenTraversable? Iterable? IterableLike? Should they be choosing the most general type for parameters, and if so what was that? What was a =:= and where could they get one from?"
"In addition to the concepts and specific implementations that Scala introduces, there is also a cultural layer of what it means to write idiomatic Scala."
"In hindsight, I definitely underestimated both the difficulty and importance of learning (and teaching) Scala."
"Contrast this with the default for the JVM ecosystem: if new hires write Java, they're productive as soon as we can get them a keyboard."
"Despite the fact that we're moving away from Scala, I still think it's one of the most interesting, innovative, and exciting languages I've used ..."
вторник, 6 декабря 2011 г.
[Book]: Actors in Scala
Actors in Scala
Table of contents:
Contents viii
List of Figures x
List of Listings xi
Preface xiii
1. Concurrency Everywhere 15 (download free sample chapter PDF)
2. Messages All the Way Up 25
3. Scala's Language Support for Actors 41
4. Actor Chat 42
5. Event-Based Programming 52
6. Exception Handling, Actor Termination and Shutdown 65
7. Customizing Actor Execution 80
8. Remote Actors 95
9. Using Scala Actors with Java APIs 96
10. Distributed and Parallel Computing with Scala Actors 97
Bibliography 98
About the Authors 100
Index 101
Table of contents:
Contents viii
List of Figures x
List of Listings xi
Preface xiii
1. Concurrency Everywhere 15 (download free sample chapter PDF)
2. Messages All the Way Up 25
3. Scala's Language Support for Actors 41
4. Actor Chat 42
5. Event-Based Programming 52
6. Exception Handling, Actor Termination and Shutdown 65
7. Customizing Actor Execution 80
8. Remote Actors 95
9. Using Scala Actors with Java APIs 96
10. Distributed and Parallel Computing with Scala Actors 97
Bibliography 98
About the Authors 100
Index 101
State: You're Doing It Wrong - Alternative Concurrency Paradigms For The JVM
"State: You're Doing It Wrong - Alternative Concurrency Paradigms For The JVM"
"What is an Identity?
A stable logical Identity associated with a series of different Values over time."
"What is State?
The Value an entity with a specific Identity has at a particular point in time."
"Haw do we know if something has State?
If a function is invoked with the same arguments at two different points in time and returns different values ... than it has State."
P.S. More on State (Clojure)
"What is an Identity?
A stable logical Identity associated with a series of different Values over time."
"What is State?
The Value an entity with a specific Identity has at a particular point in time."
"Haw do we know if something has State?
If a function is invoked with the same arguments at two different points in time and returns different values ... than it has State."
P.S. More on State (Clojure)
понедельник, 5 декабря 2011 г.
Akka: Transactor
Transactors
"Generally, the STM is not needed very often when working with Akka. Some use-cases (that we can think of) are:
1. When you really need composable message flows across many actors updating their internal local state but need them to do that atomically in one big transaction. Might not often, but when you do need this then you are screwed without it.
2. When you want to share a datastructure across actors.
3. When you need to use the persistence modules.
"
"Actors are excellent for solving problems where you have many independent processes that can work in isolation and only interact with other Actors through message passing."
"But the actor model is unfortunately a terrible model for implementing truly shared state. E.g. when you need to have consensus and a stable view of state across many components."
"STM on the other hand is excellent for problems where you need consensus and a stable view of the state by providing compositional transactional shared state. Some of the really nice traits of STM are that transactions compose, and it raises the abstraction level from lock-based concurrency."
"Akka provides an explicit mechanism for coordinating transactions across Actors. Under the hood it uses a CountDownCommitBarrier, similar to a CountDownLatch."
"Generally, the STM is not needed very often when working with Akka. Some use-cases (that we can think of) are:
1. When you really need composable message flows across many actors updating their internal local state but need them to do that atomically in one big transaction. Might not often, but when you do need this then you are screwed without it.
2. When you want to share a datastructure across actors.
3. When you need to use the persistence modules.
"
"Actors are excellent for solving problems where you have many independent processes that can work in isolation and only interact with other Actors through message passing."
"But the actor model is unfortunately a terrible model for implementing truly shared state. E.g. when you need to have consensus and a stable view of state across many components."
"STM on the other hand is excellent for problems where you need consensus and a stable view of the state by providing compositional transactional shared state. Some of the really nice traits of STM are that transactions compose, and it raises the abstraction level from lock-based concurrency."
"Akka provides an explicit mechanism for coordinating transactions across Actors. Under the hood it uses a CountDownCommitBarrier, similar to a CountDownLatch."
Akka - an open source, event-driven middleware project
"Akka - an open source, event-driven middleware project"
"... It is designed to allow developers to write simpler, correct concurrent applications using Actors, STM (software transactional memory) and transactors."
"... It is designed to allow developers to write simpler, correct concurrent applications using Actors, STM (software transactional memory) and transactors."
Doug Lea Discusses the Fork/Join Framework
"Doug Lea Discusses the Fork/Join Framework"
"...Part of this is that we have the luxury of building this framework on systems that have, for example, high performance, scalable, concurrent garbage collection, because garbage collection in these frameworks turns out to be an interesting issue. If you are implementing them, say in C, you generally have to slow down a lot of things in order to get the memory allocation right. In our case, we will spew lots of garbage, but it's very well behaved garbage and it's picked up by the garbage collector because it is unused 99% of the time."
"...Part of this is that we have the luxury of building this framework on systems that have, for example, high performance, scalable, concurrent garbage collection, because garbage collection in these frameworks turns out to be an interesting issue. If you are implementing them, say in C, you generally have to slow down a lot of things in order to get the memory allocation right. In our case, we will spew lots of garbage, but it's very well behaved garbage and it's picked up by the garbage collector because it is unused 99% of the time."
вторник, 29 ноября 2011 г.
Microsoft drops Dryad; puts its big-data bets on Hadoop
Microsoft drops Dryad; puts its big-data bets on Hadoop
"Hadoop has emerged as a great platform for analyzing unstructured data or large volumes of data at low cost, which aligns well with Microsoft’s vision for its Information Platform. It also has a vibrant community of users and developers eager to innovate on this platform. Microsoft is keen to not only contribute to this vibrant community, but also help its adoption in the Enterprise."
Microsoft to develop Hadoop distributions for Windows Server and Azure
О-ло-ло! MS мерзко крадет наш Hadoop, который мы честно украли у Google:)
"Hadoop has emerged as a great platform for analyzing unstructured data or large volumes of data at low cost, which aligns well with Microsoft’s vision for its Information Platform. It also has a vibrant community of users and developers eager to innovate on this platform. Microsoft is keen to not only contribute to this vibrant community, but also help its adoption in the Enterprise."
Microsoft to develop Hadoop distributions for Windows Server and Azure
О-ло-ло! MS мерзко крадет наш Hadoop, который мы честно украли у Google:)
понедельник, 28 ноября 2011 г.
Trees in SQL
Нашел обсуждение "Threes in SQL" и необычайно богатую коллекцию ссылок:
http://philip.greenspun.com/sql/trees.html
http://troels.arvin.dk/db/rdbms/links/#hierarchical
Особенно полезно про neseted intervals прочитать
http://www.dbazine.com/oracle/or-articles/tropashko4
http://www.dbazine.com/oracle/or-articles/tropashko5
http://philip.greenspun.com/sql/trees.html
http://troels.arvin.dk/db/rdbms/links/#hierarchical
Особенно полезно про neseted intervals прочитать
http://www.dbazine.com/oracle/or-articles/tropashko4
http://www.dbazine.com/oracle/or-articles/tropashko5
воскресенье, 27 ноября 2011 г.
четверг, 17 ноября 2011 г.
среда, 16 ноября 2011 г.
Top 10 Reasons Java Programs Envy Scala
"Top 10 Reasons Java Programs Envy Scala"
Черт побери!
Это действительно те вещи, которых мне не хватает в java по несколько раз в день ...
P.S. Для пользования презентацией надо интенсивно использовать zoom in/zoom out.
Черт побери!
Это действительно те вещи, которых мне не хватает в java по несколько раз в день ...
P.S. Для пользования презентацией надо интенсивно использовать zoom in/zoom out.
понедельник, 7 ноября 2011 г.
10 Core Architecture Pattern Variations for Achieving Scalability
10 Core Architecture Pattern Variations for Achieving Scalability
LB (Load Balancers) + Shared nothing Units. Units that do not share anything with each other fronted with a load balancer that routes incoming messages to a unit based on some criteria.
LB + Stateless Nodes + Scalable Storage. Several stateless nodes talking to a scalable storage, and a load balancer distributes load among the nodes.
Peer to Peer Architectures (Distributed Hash Table (DHT) and Content Addressable Networks (CAN)). Algorithm for scaling up logarithmically.
Distributed Queues. Queue implementation (FIFO delivery) implemented as a network service.
Publish/Subscribe Paradigm. Network publish subscribe brokers that route messages to each other.
Gossip and Nature-inspired Architectures. Each node randomly pick and exchange information with follow nodes.
Map Reduce/ Data flows. Scalable pattern to describe and execute Jobs.
Tree of responsibility. Break the problem down recursively and assign to a tree, each parent node delegating work to children nodes.
Stream processing. Process data streams, data that is keeps coming.
Scalable Storages. Ranges from Databases, NoSQL storages, Service Registries, to File systems.
P.S. Thanks highscalability.com for link.
LB (Load Balancers) + Shared nothing Units. Units that do not share anything with each other fronted with a load balancer that routes incoming messages to a unit based on some criteria.
LB + Stateless Nodes + Scalable Storage. Several stateless nodes talking to a scalable storage, and a load balancer distributes load among the nodes.
Peer to Peer Architectures (Distributed Hash Table (DHT) and Content Addressable Networks (CAN)). Algorithm for scaling up logarithmically.
Distributed Queues. Queue implementation (FIFO delivery) implemented as a network service.
Publish/Subscribe Paradigm. Network publish subscribe brokers that route messages to each other.
Gossip and Nature-inspired Architectures. Each node randomly pick and exchange information with follow nodes.
Map Reduce/ Data flows. Scalable pattern to describe and execute Jobs.
Tree of responsibility. Break the problem down recursively and assign to a tree, each parent node delegating work to children nodes.
Stream processing. Process data streams, data that is keeps coming.
Scalable Storages. Ranges from Databases, NoSQL storages, Service Registries, to File systems.
P.S. Thanks highscalability.com for link.
пятница, 30 сентября 2011 г.
Embedded Design Patterns
Embedded Design Patterns
еще не успел почитать, но имена архитектур для меня совершенно новы:
- Hierarchical State Machine
- State Machine Inheritance
- ...
Классика паттернов, которая используется в J2EE:
- GoF patterns
- J2EE patterns
- PEAA from Fawler
но самое вкусное - distributed/multithreaded/realtime/... patterns надо искать самому.
Кста, если кто знает еще интересные паттерны - киньте в коммент.
еще не успел почитать, но имена архитектур для меня совершенно новы:
- Hierarchical State Machine
- State Machine Inheritance
- ...
Классика паттернов, которая используется в J2EE:
- GoF patterns
- J2EE patterns
- PEAA from Fawler
но самое вкусное - distributed/multithreaded/realtime/... patterns надо искать самому.
Кста, если кто знает еще интересные паттерны - киньте в коммент.
среда, 31 августа 2011 г.
пятница, 5 августа 2011 г.
Практичные регулярки: современные движки рвут и мечут
Практичные регулярки: современные движки рвут и мечут
Пост содержит ряд дельных (как я понимаю) ссылок.
Пост содержит ряд дельных (как я понимаю) ссылок.
среда, 20 июля 2011 г.
Distributed Algorithms: Time
Тезисы к моему докладу на Java Club #2:
Многие современных "Большие Игроки" для обеспечения задачи хранения состояния в cloud-системах используют кастомные нереляционные решения:
Amazon
- SimpleDB
- Dynamo
Google
- GFS + BigTable + MapReduce
- Megastore
Yahoo
- HDFS + HBase + Hadoop
- PNUTS
Facebook
- Cassandra
Не рассматривая вызвавшие это причины, можно констатировать факт, что задача анализа реализованных или проектирования и разработки своего "in cloud" nonrelational хранилища актуальна для R&D отделов больших корпорация.
Но, в таком случае, нам придется "выйти за пределы реляционного словаря": ACID, optimistic/pessimistic locking, read uncommitted, read committed, repeatable read, serializable, two phase commit (2PL), two phase locking (2PL), normal forms, primary/foreign key...
И оперировать более фундаментальными понятиями. На основе которых, в том числе, возможно строить и реляционные решения.
Time:
- 0-d Scalar Lamport Logical Time
- 1-d Scalar Virtual Time
- 1-d Vector Time
- 2-d Matrix time
P.S. В целом про Time in Distributed Algorithms (в том числе про Vector Time) отлично прочитать Chapter #3 из книги "Distributed Computing: Principles, Algorithms, and Systems"
Многие современных "Большие Игроки" для обеспечения задачи хранения состояния в cloud-системах используют кастомные нереляционные решения:
Amazon
- SimpleDB
- Dynamo
- GFS + BigTable + MapReduce
- Megastore
Yahoo
- HDFS + HBase + Hadoop
- PNUTS
- Cassandra
Не рассматривая вызвавшие это причины, можно констатировать факт, что задача анализа реализованных или проектирования и разработки своего "in cloud" nonrelational хранилища актуальна для R&D отделов больших корпорация.
Но, в таком случае, нам придется "выйти за пределы реляционного словаря": ACID, optimistic/pessimistic locking, read uncommitted, read committed, repeatable read, serializable, two phase commit (2PL), two phase locking (2PL), normal forms, primary/foreign key...
И оперировать более фундаментальными понятиями. На основе которых, в том числе, возможно строить и реляционные решения.
Time:
- 0-d Scalar Lamport Logical Time
- 1-d Scalar Virtual Time
- 1-d Vector Time
- 2-d Matrix time
P.S. В целом про Time in Distributed Algorithms (в том числе про Vector Time) отлично прочитать Chapter #3 из книги "Distributed Computing: Principles, Algorithms, and Systems"
пятница, 17 июня 2011 г.
Architecture of a Database System
Short book "Architecture of a Database System" from Joseph M. Hellerstein, Michael Stonebraker and James Hamilton.
Oracle Real Application Clusters and Industry Trends in Cluster Parallelism and Availability
"Oracle Real Application Clusters and Industry Trends in Cluster Parallelism and Availability" from James Hamilton, Architect of Microsoft SQL Server:)
четверг, 16 июня 2011 г.
Game theory for automatic device driver synthesis
Article "Automatic Device Driver Synthesis with Termite" from scientists [EN].
ABSTRACT
Faulty device drivers cause significant damage through down time and data loss. The problem can be mitigated by an improved driver development process that guarantees correctness by construction. We achieve this by synthesising drivers automatically from formal specifications of device interfaces, thus reducing the impact of human error on driver reliability and potentially cutting down on development costs.
We present a concrete driver synthesis approach and tool called Termite. We discuss the methodology, the technical and practical limitations of driver synthesis, and provide an evaluation of nontrivial drivers for Linux, generated using our tool. We show that the performance of the generated drivers is on par with the equivalent manually developed drivers. Furthermore, we demonstrate that device specifications can be reused across different operating systems by generating a driver for FreeBSD from the same specification as used for Linux.
Short description [RU].
ABSTRACT
Faulty device drivers cause significant damage through down time and data loss. The problem can be mitigated by an improved driver development process that guarantees correctness by construction. We achieve this by synthesising drivers automatically from formal specifications of device interfaces, thus reducing the impact of human error on driver reliability and potentially cutting down on development costs.
We present a concrete driver synthesis approach and tool called Termite. We discuss the methodology, the technical and practical limitations of driver synthesis, and provide an evaluation of nontrivial drivers for Linux, generated using our tool. We show that the performance of the generated drivers is on par with the equivalent manually developed drivers. Furthermore, we demonstrate that device specifications can be reused across different operating systems by generating a driver for FreeBSD from the same specification as used for Linux.
Short description [RU].
суббота, 11 июня 2011 г.
вторник, 7 июня 2011 г.
Spring + NoSQL
Spring Data project
Subprojects:
- Blob-Stores
- Column Stores
- Document Stores
- Graph Databases
- Key Value Stores
- Map-Reduce
- Relational Databases
- Common Infrastructure
P.S. Один мой друг, который всерьез занимается Cloud, утверждает, что VmWare (Spring owner) мечтает свой стек технологий сделать стандартом для "облаков". И, вроде как, все к тому и идет. Спринговский доступ ко всякого рода "облачным хранилищам данных" фактически станем стандартом de facto.
P.P.S. Мой личный интерес в следующем:
Cloud - это абстракция над кластером. "Степаныч, скока щас?" - "100" - "подымай еще 100". Всякое приложение под cloud - stateless app, который все данные хранит в некотором распределенном хранилище. Это может быть Azure Table Storage, Google Datastore API, Amazon SimpleDB. Вот, по-моему, проектировать и реализовывать такие хранилища под заказ - самое интересное. Не использовать то, что уже есть, сидя на чужом public cloud, а реализовывать новое хранилище для заказного private cloud.
Subprojects:
- Blob-Stores
- Column Stores
- Document Stores
- Graph Databases
- Key Value Stores
- Map-Reduce
- Relational Databases
- Common Infrastructure
P.S. Один мой друг, который всерьез занимается Cloud, утверждает, что VmWare (Spring owner) мечтает свой стек технологий сделать стандартом для "облаков". И, вроде как, все к тому и идет. Спринговский доступ ко всякого рода "облачным хранилищам данных" фактически станем стандартом de facto.
P.P.S. Мой личный интерес в следующем:
Cloud - это абстракция над кластером. "Степаныч, скока щас?" - "100" - "подымай еще 100". Всякое приложение под cloud - stateless app, который все данные хранит в некотором распределенном хранилище. Это может быть Azure Table Storage, Google Datastore API, Amazon SimpleDB. Вот, по-моему, проектировать и реализовывать такие хранилища под заказ - самое интересное. Не использовать то, что уже есть, сидя на чужом public cloud, а реализовывать новое хранилище для заказного private cloud.
NoSQL Databases
NoSQL Databases
Lecture
Selected Topics on Software-Technology
Ultra-Large Scale Sites
Contents
1 Introduction 1
1.1 Introduction and Overview
1.2 Uncovered Topics
2 The NoSQL-Movement
2.1 Motives and Main Drivers
2.2 Criticism
2.3 Classifications and Comparisons of NoSQL Databases
3 Basic Concepts, Techniques and Patterns
3.1 Consistency
3.2 Partitioning
3.3 Storage Layout
3.4 Query Models
3.5 Distributed Data Processing via MapReduce
4 Key-/Value-Stores
4.1 Amazon’s Dynamo
4.2 Project Voldemort
4.3 Other Key-/Value-Stores
5 Document Databases
5.1 Apache CouchDB
5.2 MongoDB
6 Column-Oriented Databases
6.1 Google’s Bigtable
6.2 Bigtable Derivatives
6.3 Cassandra
7 Conclusion
A Further Reading, Listening and Watching
B List of abbreviations
C Bibliography
P.S. Many thanks to Mark for the link.
Lecture
Selected Topics on Software-Technology
Ultra-Large Scale Sites
Contents
1 Introduction 1
1.1 Introduction and Overview
1.2 Uncovered Topics
2 The NoSQL-Movement
2.1 Motives and Main Drivers
2.2 Criticism
2.3 Classifications and Comparisons of NoSQL Databases
3 Basic Concepts, Techniques and Patterns
3.1 Consistency
3.2 Partitioning
3.3 Storage Layout
3.4 Query Models
3.5 Distributed Data Processing via MapReduce
4 Key-/Value-Stores
4.1 Amazon’s Dynamo
4.2 Project Voldemort
4.3 Other Key-/Value-Stores
5 Document Databases
5.1 Apache CouchDB
5.2 MongoDB
6 Column-Oriented Databases
6.1 Google’s Bigtable
6.2 Bigtable Derivatives
6.3 Cassandra
7 Conclusion
A Further Reading, Listening and Watching
B List of abbreviations
C Bibliography
P.S. Many thanks to Mark for the link.
пятница, 27 мая 2011 г.
суббота, 21 мая 2011 г.
ZooKeeper - A Reliable, Scalable Distributed Coordination System
ZooKeeper - A Reliable, Scalable Distributed Coordination System
Abstract
ZooKeeper is a high available and reliable coordination system. Distributed applications use ZooKeeper to store and mediate updates key configuration information. ZooKeeper can be used for leader election, group membership, and configuration maintenance. In addition ZooKeeper can be used for event notification, locking, and as a priority queue mechanism. It's a sort of central nervous system for distributed systems where the role of the brain is played by the coordination service, axons are the network, processes are the monitored and controlled body parts, and events are the hormones and neurotransmitters used for messaging. Every complex distributed application needs a coordination and orchestration system of some sort, so the ZooKeeper folks at Yahoo decide to build a good one and open source it for everyone to use.
P.S. So ZooKeeper is open-source realization (from Yahoo) of "close-source" Chubby lock service (from Google).
Abstract
ZooKeeper is a high available and reliable coordination system. Distributed applications use ZooKeeper to store and mediate updates key configuration information. ZooKeeper can be used for leader election, group membership, and configuration maintenance. In addition ZooKeeper can be used for event notification, locking, and as a priority queue mechanism. It's a sort of central nervous system for distributed systems where the role of the brain is played by the coordination service, axons are the network, processes are the monitored and controlled body parts, and events are the hormones and neurotransmitters used for messaging. Every complex distributed application needs a coordination and orchestration system of some sort, so the ZooKeeper folks at Yahoo decide to build a good one and open source it for everyone to use.
P.S. So ZooKeeper is open-source realization (from Yahoo) of "close-source" Chubby lock service (from Google).
понедельник, 16 мая 2011 г.
Notes on Google Megastore
Notes on Google Megastore
More notes
Google Megastore
P.S. Megastore is the data engine supporting the Google Application Engine.
More notes
Google Megastore
P.S. Megastore is the data engine supporting the Google Application Engine.
Are Cloud Based Memory Architectures the Next Big Thing?
Who are the Major Players in this Space?:
With that bit of background behind us, there are several major players in this space (in alphabetical order):
Coherence - is a peer-to-peer, clustered, in-memory data management system. Coherence is a good match for applications that need write-behind functionality when working with a database and you require multiple applications have ACID transactions on the database. Java, JavaEE, C++, and .NET.
GemFire - an in-memory data caching solution that provides low-latency and near-zero downtime along with horizontal & global scalability. C++, Java and .NET.
GigaSpaces - GigaSpaces attacks the whole stack: Compute Grid, Data Grid, Message, Colocation, and Application Server capabilities. This makes for greater complexity, but it means there's less plumbing that needs to be written and developers can concentrate on writing business logic. Java, C, or .Net.
GridGain - A compute grid that can operate over many data grids. It specializes in the transparent and low configuration implementation of features. Java only.
Terracotta - Terracotta is network-attached memory that allows you share memory and do anything across a cluster. Terracotta works its magic at the JVM level and provides: high availability, an end of messaging, distributed caching, a single JVM image. Java only.
WebSphere eXtreme Scale. Operates as an in-memory data grid that dynamically caches, partitions, replicates, and manages application data and business logic across multiple servers.
With that bit of background behind us, there are several major players in this space (in alphabetical order):
Coherence - is a peer-to-peer, clustered, in-memory data management system. Coherence is a good match for applications that need write-behind functionality when working with a database and you require multiple applications have ACID transactions on the database. Java, JavaEE, C++, and .NET.
GemFire - an in-memory data caching solution that provides low-latency and near-zero downtime along with horizontal & global scalability. C++, Java and .NET.
GigaSpaces - GigaSpaces attacks the whole stack: Compute Grid, Data Grid, Message, Colocation, and Application Server capabilities. This makes for greater complexity, but it means there's less plumbing that needs to be written and developers can concentrate on writing business logic. Java, C, or .Net.
GridGain - A compute grid that can operate over many data grids. It specializes in the transparent and low configuration implementation of features. Java only.
Terracotta - Terracotta is network-attached memory that allows you share memory and do anything across a cluster. Terracotta works its magic at the JVM level and provides: high availability, an end of messaging, distributed caching, a single JVM image. Java only.
WebSphere eXtreme Scale. Operates as an in-memory data grid that dynamically caches, partitions, replicates, and manages application data and business logic across multiple servers.
Q&A with Tangosol's Cameron Purdy and Peter Utzschneider
Q&A with Tangosol's Cameron Purdy and Peter Utzschneider:
"Their functionality and the data that they depend on must all be continuously available, surviving failures of servers, networks and even data centers."
"We can now detect a remote garbage collection within milliseconds, and dynamically reshape the cluster's traffic to avoid overheating that node."
"The self-tuning algorithms, flow control and traffic shaping features have propelled us years ahead of the technology curve, and help to explain how Coherence is the lowest latency, highest throughput and most scalable clustered data management system in existence."
"This 3.2 release is also notable because it is the first release that we have focused specifically on cluster latency, largely related to specific requests from telecom and financial services customers."
"In my experience, switching to Infiniband form GigE is a big win. But also, I've seen a strictly linear, by-the-ruler, scaling to nearly 400 cache nodes"
"Their functionality and the data that they depend on must all be continuously available, surviving failures of servers, networks and even data centers."
"We can now detect a remote garbage collection within milliseconds, and dynamically reshape the cluster's traffic to avoid overheating that node."
"The self-tuning algorithms, flow control and traffic shaping features have propelled us years ahead of the technology curve, and help to explain how Coherence is the lowest latency, highest throughput and most scalable clustered data management system in existence."
"This 3.2 release is also notable because it is the first release that we have focused specifically on cluster latency, largely related to specific requests from telecom and financial services customers."
"In my experience, switching to Infiniband form GigE is a big win. But also, I've seen a strictly linear, by-the-ruler, scaling to nearly 400 cache nodes"
вторник, 26 апреля 2011 г.
Есть желающие стать Junior Java Developer в EPAM?
Лаборатория пока не распределённых систем, а учебная. Ответственен в том числе за подготовку Junior Java Developer (D1). Новость следующая - в период 15июня-15сентября в харьковском офисе EPAM будет работать так называемая Pre-prodaction program:
1. Как попасть?
- прислать мне на Golovach.Ivan@gmail.com резюме (главное: Ваш уровень английского, что писали/изучали в институте)
- выполнить ряд заданий (на написание нескольких сот строк кода на Java), которые я вышлю в ответ на резюме
- выслушать мои замечания на выполненные задания и исправить решения
// по сути дела проверятся Ваши: базовые знания + способность изменить решение в свете новых требований
2. Что будет происходить?
- в период 15июня-15сентября Вы работаете в харьковском офисе EPAM на full-time на боевом проекте под моим руководством
- получаете на время обучения зп - 250$
- слушаете и применяете теор материал, который я Вам начитываю: Spring Core, Spring MVC, Hibernate, RDBMS fundamentals, web-app fundamentals.
- по окончанию срока обучения (15 сентября) Вы сдаете экзамен
- по результатам экзамена (15 сентября) Вы либо отчисляетесь, либо я передаю Вас на другие проекты в другие команды с переходом в статус Junior Java Developer (D1)
- в зависимости от результатов экзамена Вы получаете повышение зп
3. Что Вы с этого будете иметь?
- гарантированную зп на время обучения
- фундаментальные знания от System Architect
- опыт работы в реальном проекте с реальным стеком технологий (JSF+Spring+Hibernate+Oracle)
- возможность продолжить работу в одной из крупнейших IT компаний
P.S. Если у Вас есть знакомые заинтересованные в быстром старте в карьере в IT - передайте новость им.
1. Как попасть?
- прислать мне на Golovach.Ivan@gmail.com резюме (главное: Ваш уровень английского, что писали/изучали в институте)
- выполнить ряд заданий (на написание нескольких сот строк кода на Java), которые я вышлю в ответ на резюме
- выслушать мои замечания на выполненные задания и исправить решения
// по сути дела проверятся Ваши: базовые знания + способность изменить решение в свете новых требований
2. Что будет происходить?
- в период 15июня-15сентября Вы работаете в харьковском офисе EPAM на full-time на боевом проекте под моим руководством
- получаете на время обучения зп - 250$
- слушаете и применяете теор материал, который я Вам начитываю: Spring Core, Spring MVC, Hibernate, RDBMS fundamentals, web-app fundamentals.
- по окончанию срока обучения (15 сентября) Вы сдаете экзамен
- по результатам экзамена (15 сентября) Вы либо отчисляетесь, либо я передаю Вас на другие проекты в другие команды с переходом в статус Junior Java Developer (D1)
- в зависимости от результатов экзамена Вы получаете повышение зп
3. Что Вы с этого будете иметь?
- гарантированную зп на время обучения
- фундаментальные знания от System Architect
- опыт работы в реальном проекте с реальным стеком технологий (JSF+Spring+Hibernate+Oracle)
- возможность продолжить работу в одной из крупнейших IT компаний
P.S. Если у Вас есть знакомые заинтересованные в быстром старте в карьере в IT - передайте новость им.
Получил четвертую звезду!
Всем привет.
Я с 11 апреля работаю в харьковском офисе EPAM на должности Lab Lead в звании System Architect (D4).
Я с 11 апреля работаю в харьковском офисе EPAM на должности Lab Lead в звании System Architect (D4).
четверг, 21 апреля 2011 г.
Intel® Threading Building Blocks – Documentation
Intel® Threading Building Blocks – Documentation::
- Release Notes [TXT 6KB]
- Getting Started Guide [PDF 122KB]
- Tutorial [PDF 573KB]
- Reference Manual [PDF 1.1MB]
- Design Patterns [PDF 264KB]
- Release Notes [TXT 6KB]
- Getting Started Guide [PDF 122KB]
- Tutorial [PDF 573KB]
- Reference Manual [PDF 1.1MB]
- Design Patterns [PDF 264KB]
пятница, 1 апреля 2011 г.
checkdeadlock.org - первый релиз
В продолжении к предыдущему посту. Т.к. домашний компьютер постоянно включенным оказалось очень неудобно, разместил на hosting.ua проект checkdeadlock.org. На этом хостинге нет контейнера сервлетов, поэтому пришлось написать свой небольшой сервер, который работает на 8080 порту (т.к. я не root, то доступ к 80 мне пока закрыт. Нужно будет поговорить по этому поводу с саппортом. Но пока и так неплохо).
суббота, 26 марта 2011 г.
Нахождение взаимных блокировок потоков при статическом анализе кода
Всем доброго вечера.
Когда Иван читал у нас, на мех-мате в Каразина свой спецкурс у меня появилась навящевая идея по поиску дедлоков без запуска программы, только на основании ее кода. Было сделано несколько попыток найти какой-то внятный алгоритм. К настоящему моменту я достаточно неплохо, как мне кажется, продвинулся в этом направлении.
Чтобы не усложнять до предела работу по парсингу кода на Java или C я написал простой язык для описания потоков.
Когда Иван читал у нас, на мех-мате в Каразина свой спецкурс у меня появилась навящевая идея по поиску дедлоков без запуска программы, только на основании ее кода. Было сделано несколько попыток найти какой-то внятный алгоритм. К настоящему моменту я достаточно неплохо, как мне кажется, продвинулся в этом направлении.
Чтобы не усложнять до предела работу по парсингу кода на Java или C я написал простой язык для описания потоков.
среда, 16 марта 2011 г.
среда, 9 марта 2011 г.
вторник, 8 марта 2011 г.
habrahabr: Обзор NoSQL систем
Обзор NoSQL систем
Cassandra, HBase, Riak, Scalaris, Voldemort, CouchDB, MongoDB, Neo4j, Redis, Tokyo Cabinet
Cassandra, HBase, Riak, Scalaris, Voldemort, CouchDB, MongoDB, Neo4j, Redis, Tokyo Cabinet
понедельник, 7 марта 2011 г.
A Note on Distributed Computing
A Note on Distributed Computing
Abstract
We argue that objects that interact in a distributed system need to be dealt with in ways that are intrinsically different from objects that interact in a single address space. These differences are required because distributed systems require that the programmer be aware of latency, have a different model of memory access, and take into account issues of concurrency and partial failure.
We look at a number of distributed systems that have attempted to paper over the distinction between local and remote objects, and show that such systems fail to support basic requirements of robustness and reliability. These failures have been masked in the past by the small size of the distributed systems that have been built. In the enterprise-wide distributed systems foreseen in the near future, however, such a masking will be impossible.
We conclude by discussing what is required of both systems-level and application level programmers and designers if one is to take distribution seriously.
Abstract
We argue that objects that interact in a distributed system need to be dealt with in ways that are intrinsically different from objects that interact in a single address space. These differences are required because distributed systems require that the programmer be aware of latency, have a different model of memory access, and take into account issues of concurrency and partial failure.
We look at a number of distributed systems that have attempted to paper over the distinction between local and remote objects, and show that such systems fail to support basic requirements of robustness and reliability. These failures have been masked in the past by the small size of the distributed systems that have been built. In the enterprise-wide distributed systems foreseen in the near future, however, such a masking will be impossible.
We conclude by discussing what is required of both systems-level and application level programmers and designers if one is to take distribution seriously.
Oracle Coherence: author blog
Обнаружен блог Cameron Purdy.
Cameron Purdy was the founder and president of Tangosol, Inc, a market leader in delivering in-memory caching and data management solutions to companies building and running mission critical enterprise J2EE applications. He currently is VP of Development at Oracle.
P.S. Tangosol разработал Coherence, был куплен Ораклом за 200М.
P.P.S. Cameron Purdy on Scaling Out Data Grids.
Cameron Purdy was the founder and president of Tangosol, Inc, a market leader in delivering in-memory caching and data management solutions to companies building and running mission critical enterprise J2EE applications. He currently is VP of Development at Oracle.
P.S. Tangosol разработал Coherence, был куплен Ораклом за 200М.
P.P.S. Cameron Purdy on Scaling Out Data Grids.
среда, 2 марта 2011 г.
Deep-deep-deep Google internals: Chubby
1. "The Chubby Lock Service for Loosely-Coupled Distributed Systems"
Mike Burrows, Google Inc.
Abstract
We describe our experiences with the Chubby lock service, which is intended to provide coarse-grained locking as well as reliable (though low-volume) storage for a loosely-coupled distributed system. Chubby provides an interface much like a distributed file system with advisory locks, but the design emphasis is on availability and reliability, as opposed to high performance. Many instances of the service have been used for over a year, with several of them each handling a few tens of thousands of clients concurrently. The paper describes the initial design and expected use, compares it with actual use, and explains how the design had to be modified to accommodate the differences.
OSDI'06: Seventh Symposium on Operating System Design and Implementation, Seattle, WA, November, 2006.
"We expected Chubby to help developers deal with coarse-grained synchronization within their systems, and in particular to deal with the problem of electing a leader from among a set of otherwise equivalent servers. For example, the Google File System [7] uses a Chubby lock to appoint a GFS master server, and Bigtable [3] uses Chubby in several ways: to elect a master, to allow the master to discover the servers it controls, and to permit clients to find the master. In addition, both GFS and Bigtable use Chubby as a well-known and available location to store a small amount of meta-data; in effect they use Chubby as the root of their distributed data structures. Some services use locks to partition work (at a coarse grain) between several servers."
-------------
"Paxos Made Live - An Engineering Perspective"
Paxos Made Live - An Engineering Perspective
Tushar Chandra
Robert Griesemer
Joshua Redstone
June 20, 2007
Abstract
We describe our experience in building a fault-tolerant data-base using the Paxos consensus algorithm. Despite the existing literature in the field, building such a database proved to be non-trivial. We describe selected algorithmic and engineering problems encountered, and the solutions we found for them. Our measurements indicate that we have built a competitive system.
Mike Burrows, Google Inc.
Abstract
We describe our experiences with the Chubby lock service, which is intended to provide coarse-grained locking as well as reliable (though low-volume) storage for a loosely-coupled distributed system. Chubby provides an interface much like a distributed file system with advisory locks, but the design emphasis is on availability and reliability, as opposed to high performance. Many instances of the service have been used for over a year, with several of them each handling a few tens of thousands of clients concurrently. The paper describes the initial design and expected use, compares it with actual use, and explains how the design had to be modified to accommodate the differences.
OSDI'06: Seventh Symposium on Operating System Design and Implementation, Seattle, WA, November, 2006.
"We expected Chubby to help developers deal with coarse-grained synchronization within their systems, and in particular to deal with the problem of electing a leader from among a set of otherwise equivalent servers. For example, the Google File System [7] uses a Chubby lock to appoint a GFS master server, and Bigtable [3] uses Chubby in several ways: to elect a master, to allow the master to discover the servers it controls, and to permit clients to find the master. In addition, both GFS and Bigtable use Chubby as a well-known and available location to store a small amount of meta-data; in effect they use Chubby as the root of their distributed data structures. Some services use locks to partition work (at a coarse grain) between several servers."
-------------
"Paxos Made Live - An Engineering Perspective"
Paxos Made Live - An Engineering Perspective
Tushar Chandra
Robert Griesemer
Joshua Redstone
June 20, 2007
Abstract
We describe our experience in building a fault-tolerant data-base using the Paxos consensus algorithm. Despite the existing literature in the field, building such a database proved to be non-trivial. We describe selected algorithmic and engineering problems encountered, and the solutions we found for them. Our measurements indicate that we have built a competitive system.
вторник, 1 марта 2011 г.
Ищу работу
Добрый день.
Я подумываю о смене работы.
Ищу пописать какую-нибудь низкоуровневую распределенную инфраструктуру на основе Netty/JGroups/etc.
Или сервер многопоточный какой.
Или распределенной хранилище данных.
Или инфраструктуру для MMOGame.
Или поюзать какую-нибудь низкоуровневую распределенную инфраструктуру: Cassandra, HBase, HDFS, Hadoop, PIG, etc
Бизнес-проекты на {GWT,JSF}/{Spring, EJB}/Hibernate/RDBMS пока не рассматриваю.
Рассмотрю любой город бСССР и любой режим работы.
Могу менторить юниоров.
К "печенькам" не требователен.
P.S. Golovach.Ivan@gmail.com
P.P.S. На письма вида "высылайте резюме, а потом мы вам как-нибудь расскажем про проект" не отвечу.
Я подумываю о смене работы.
Ищу пописать какую-нибудь низкоуровневую распределенную инфраструктуру на основе Netty/JGroups/etc.
Или сервер многопоточный какой.
Или распределенной хранилище данных.
Или инфраструктуру для MMOGame.
Или поюзать какую-нибудь низкоуровневую распределенную инфраструктуру: Cassandra, HBase, HDFS, Hadoop, PIG, etc
Бизнес-проекты на {GWT,JSF}/{Spring, EJB}/Hibernate/RDBMS пока не рассматриваю.
Рассмотрю любой город бСССР и любой режим работы.
Могу менторить юниоров.
К "печенькам" не требователен.
P.S. Golovach.Ivan@gmail.com
P.P.S. На письма вида "высылайте резюме, а потом мы вам как-нибудь расскажем про проект" не отвечу.
суббота, 19 февраля 2011 г.
Почему я заинтересовался IMDG.
Десятилетие 2005-2015 - это десятилетие (в том числе) The Concurrency Revolution.
Но текущая ситуация такова, что ядра то лепят (уже десятками), ноды объединяют в кластеры (уже сотнями), а новых подходов все нет.
Threads, Actors - это не выход: 1) слишком низкоуровнево, 2) количество сущностей thread/actor должно расти с колвом ядер.
Fork/Join как попытка уйти от явного указания кол-ва потоков - применима если мы сами параллелим задачу. Колво потоков задает framework, но правило разбиения задачи - задаем мы.
Моя идея такова, что чем более масштабируема система/задача, тем более слабой моделью памати она обладает. На уровне процессора(x86 mem model) или языка (New Java Mem Model) модель памяти уже задана, и мы можем только спорить - хорошо ли приспособлена Java для 100K потоков, или тут уже нужен Erlang.
Но если мы сами создаем Модель Памяти? Скажем берем realiable multicasting, на нем строим другие мулькастинги (atomic, causal, total order, etc), на них строим любые модели Shared Memory, поверх Shared Memory реализуем какой-нибудь механизм координации - что-то вроди Linda. Это текущие процессы.
А если так: business people пишут свою логику, а система по логике 1) находит слабейшую можель памяти на которой это еще будет работать, 2) указывает, какие моменты в бизнесс-правилах наиболее органичивают систему в масштабировании. Под эту модель памяти поднимается Grid. Т.е. масштабируемость системы зависит исключительно от бизнесс-логики, а не от того какой кэш вы выбрали: GemFire ReplicatedCache или Coherence PartitionedCache.
P.S. В моем представлении, сейчас период безвременья между Февральской и Октябрьскими Революциями. Царя уже свергли (ядра лепят, кластеры поднимают), но нет мощной идеи определяющей развитие на десятилетие вперед (конституционная монархия, либеральная демократия, мировая революция == Shared Memory, MOM, Linda, IMDG, Actors, ...).
P.P.S. Естественно государственный деятель должен учитывать вызовы будущего - мировые войны, модернизацию промышленности, решение проблем урбанизации (я имею в виду квантовые компьютеры с миллионами/миллиардами "потоков" между которыми очень-очень странные и асимметричные взаимодействия).
Но текущая ситуация такова, что ядра то лепят (уже десятками), ноды объединяют в кластеры (уже сотнями), а новых подходов все нет.
Threads, Actors - это не выход: 1) слишком низкоуровнево, 2) количество сущностей thread/actor должно расти с колвом ядер.
Fork/Join как попытка уйти от явного указания кол-ва потоков - применима если мы сами параллелим задачу. Колво потоков задает framework, но правило разбиения задачи - задаем мы.
Моя идея такова, что чем более масштабируема система/задача, тем более слабой моделью памати она обладает. На уровне процессора(x86 mem model) или языка (New Java Mem Model) модель памяти уже задана, и мы можем только спорить - хорошо ли приспособлена Java для 100K потоков, или тут уже нужен Erlang.
Но если мы сами создаем Модель Памяти? Скажем берем realiable multicasting, на нем строим другие мулькастинги (atomic, causal, total order, etc), на них строим любые модели Shared Memory, поверх Shared Memory реализуем какой-нибудь механизм координации - что-то вроди Linda. Это текущие процессы.
А если так: business people пишут свою логику, а система по логике 1) находит слабейшую можель памяти на которой это еще будет работать, 2) указывает, какие моменты в бизнесс-правилах наиболее органичивают систему в масштабировании. Под эту модель памяти поднимается Grid. Т.е. масштабируемость системы зависит исключительно от бизнесс-логики, а не от того какой кэш вы выбрали: GemFire ReplicatedCache или Coherence PartitionedCache.
P.S. В моем представлении, сейчас период безвременья между Февральской и Октябрьскими Революциями. Царя уже свергли (ядра лепят, кластеры поднимают), но нет мощной идеи определяющей развитие на десятилетие вперед (конституционная монархия, либеральная демократия, мировая революция == Shared Memory, MOM, Linda, IMDG, Actors, ...).
P.P.S. Естественно государственный деятель должен учитывать вызовы будущего - мировые войны, модернизацию промышленности, решение проблем урбанизации (я имею в виду квантовые компьютеры с миллионами/миллиардами "потоков" между которыми очень-очень странные и асимметричные взаимодействия).
Зачем писать свой IMDG?
Info: лицензия за GemFire на 1 нод на один год - 25K$. Т.е. кластер на 40 нодов - 1M$/year.
1.000.000$ с КАЖДОГО бизнеса КАЖДЫЙ год пользования твоим IMDG!
Так это еще и низкая цена - Oracle Coherence стоит заметно дороже.
P.S. Да к черту эти стартапы! Социальные сети для собак, e-shops, новейшие сервисы по отсылу СМС, ... Все на написание IMDG!
1.000.000$ с КАЖДОГО бизнеса КАЖДЫЙ год пользования твоим IMDG!
Так это еще и низкая цена - Oracle Coherence стоит заметно дороже.
P.S. Да к черту эти стартапы! Социальные сети для собак, e-shops, новейшие сервисы по отсылу СМС, ... Все на написание IMDG!
JGroups: author blog
Обнаружен блог автора и основного разработчика JGroups. Также он еще и разработчик JBoss Infinispan (IMDG).
пятница, 18 февраля 2011 г.
IMDG Internals: JGroups
Давно уже чесались взяться за JGroups - a toolkit for reliable multicast communication.
И вот выяснилось, что ее используют Ehcache, GemFire, JBoss Infinispan:
Ehcache - Replicated Caching using JGroups.
Gemfire - для Member Discovery (не уверен на счет Communication and Data Transfer)
JBoss Infinispan
Тут много всяких доков включая даже книгу (ссылка не работает). "Ken Birman: Building Secure and Reliable Network Applications. Excellent book on group communication. In-depth description of various protocols (atomic bcast, causal, total order, probabilistic broadcast). Very technical content."
P.S. Есть желание изучить ключевые либы, на которых строятся cutting edge проекты для JVM. Пока обнаружено два кандидата: JGroups и Netty (пожулуй самая производительная либа для NIO). Netty вместе с автором сейчас работают над JBoss Infinispan.
И вот выяснилось, что ее используют Ehcache, GemFire, JBoss Infinispan:
Ehcache - Replicated Caching using JGroups.
Gemfire - для Member Discovery (не уверен на счет Communication and Data Transfer)
JBoss Infinispan
Тут много всяких доков включая даже книгу (ссылка не работает). "Ken Birman: Building Secure and Reliable Network Applications. Excellent book on group communication. In-depth description of various protocols (atomic bcast, causal, total order, probabilistic broadcast). Very technical content."
P.S. Есть желание изучить ключевые либы, на которых строятся cutting edge проекты для JVM. Пока обнаружено два кандидата: JGroups и Netty (пожулуй самая производительная либа для NIO). Netty вместе с автором сейчас работают над JBoss Infinispan.
среда, 16 февраля 2011 г.
Собираю материал по Memory Consistency Models of IMDGs
Собираю материал по Memory Consistency Models of IMDGs.
Помогите кто чем богат:)
В корпоративном блоге Алексей Рогозин начал писать серию статей "Data Grid Pattern-s". Я зацепился за Data Grid Pattern - Network shared memory.
Как известно всякая Shared Memory должна обладать какой-то Memory Consistency Model. Но по бедноте материала на эту тему даже от "монстров" рынка: Oracle Coherence, IBM WebSphere eXtreme Scale стало понятно, что это "больное место" IMDG (да собственно и большинства NoSQL-решений).
Помогите кто чем богат:)
В корпоративном блоге Алексей Рогозин начал писать серию статей "Data Grid Pattern-s". Я зацепился за Data Grid Pattern - Network shared memory.
Как известно всякая Shared Memory должна обладать какой-то Memory Consistency Model. Но по бедноте материала на эту тему даже от "монстров" рынка: Oracle Coherence, IBM WebSphere eXtreme Scale стало понятно, что это "больное место" IMDG (да собственно и большинства NoSQL-решений).
понедельник, 14 февраля 2011 г.
воскресенье, 30 января 2011 г.
понедельник, 24 января 2011 г.
Coordination language: Linda
- Linda (wiki)
- from author: "Coordination Languages and their Significance"
- 10 years expirience: "Coordination Languages: Back to the Future with Linda"
- from Java viewpoint: "Linda implementations in Java for concurrent systems"
P.S. JavaSpaces is an implementation of Linda in Java by Sun, incorporated into the Jini project.
P.P.S. JavaSpaces is a base for GigaSpaces XAP.
- from author: "Coordination Languages and their Significance"
- 10 years expirience: "Coordination Languages: Back to the Future with Linda"
- from Java viewpoint: "Linda implementations in Java for concurrent systems"
P.S. JavaSpaces is an implementation of Linda in Java by Sun, incorporated into the Jini project.
P.P.S. JavaSpaces is a base for GigaSpaces XAP.
пятница, 21 января 2011 г.
Mostly Concurrent Compaction for Mark-Sweep GC
Mostly Concurrent Compaction for Mark-Sweep GC
ABSTRACT
A memory manager that does not move objects may suffer from memory fragmentation. Compaction is an efficient, and sometimes inevitable, mechanism for reducing fragmentation. A Mark-Sweep garbage collector must occasionally execute a compaction, usually while the application is suspended. Compaction during pause time can have detrimental effects for interactive applications that require guarantees for maximal pause time. This work presents a method for reducing the pause time created by compaction at a negligible throughput hit. The solution is most suitable when added to a Mark-Sweep garbage collector.
Compaction normally consists of two major activities: the moving of objects and the update of all the objects’ references to the new locations. We present a method for executing the reference updates concurrently, thus eliminating a substantial portion of the pause time hit. To reduce the time for moving objects in each compaction, we use the existing technique of incremental compaction, but select the optimal area to compact. Selecting the area is done after executing the mark and sweep phases, and is based on their results.
We implemented our compaction on top of the IBM J9 JVM V2.2, and present measurements of its effect on pause time, throughput, and mutator utilization. We show that our compaction is indeed an efficient fragmentation reduction tool, and that it improves the performance of a few of the benchmarks we used, with very little increase in the pause time (typically far below the cost of the mark phase).
P.S. Найдено тут. Проект ManagedRuntime.org интересен сам по себе. Создан компанией Azul, как я опнял, они частично переписали OpenJDK + подсистему работы с памятью Linux.
ABSTRACT
A memory manager that does not move objects may suffer from memory fragmentation. Compaction is an efficient, and sometimes inevitable, mechanism for reducing fragmentation. A Mark-Sweep garbage collector must occasionally execute a compaction, usually while the application is suspended. Compaction during pause time can have detrimental effects for interactive applications that require guarantees for maximal pause time. This work presents a method for reducing the pause time created by compaction at a negligible throughput hit. The solution is most suitable when added to a Mark-Sweep garbage collector.
Compaction normally consists of two major activities: the moving of objects and the update of all the objects’ references to the new locations. We present a method for executing the reference updates concurrently, thus eliminating a substantial portion of the pause time hit. To reduce the time for moving objects in each compaction, we use the existing technique of incremental compaction, but select the optimal area to compact. Selecting the area is done after executing the mark and sweep phases, and is based on their results.
We implemented our compaction on top of the IBM J9 JVM V2.2, and present measurements of its effect on pause time, throughput, and mutator utilization. We show that our compaction is indeed an efficient fragmentation reduction tool, and that it improves the performance of a few of the benchmarks we used, with very little increase in the pause time (typically far below the cost of the mark phase).
P.S. Найдено тут. Проект ManagedRuntime.org интересен сам по себе. Создан компанией Azul, как я опнял, они частично переписали OpenJDK + подсистему работы с памятью Linux.
Подписаться на:
Сообщения (Atom)