<?xml version="1.0" encoding="UTF-8"?>
 <rdf:RDF xmlns="http://purl.org/rss/1.0/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:cc="http://web.resource.org/cc/" xmlns:syn="http://purl.org/rss/1.0/modules/syndication/" xmlns:admin="http://webns.net/mvcb/">
  <channel rdf:about="http://pinboard.in">
    <title>Pinboard (jm)</title>
    <link>https://pinboard.in/u:jm/public/</link>
    <description>recent bookmarks from jm</description>
    <items>
      <rdf:Seq>	<rdf:li rdf:resource="https://devcenter.heroku.com/articles/tuning-glibc-memory-behavior#what-value-to-choose-for-malloc_arena_max"/>
	<rdf:li rdf:resource="http://chrisvest.github.io/stormpot/"/>
	<rdf:li rdf:resource="http://www.slideshare.net/nathariel/microservices-and-elastic-resource-pools-with-amazon-ec2-container-service"/>
	<rdf:li rdf:resource="http://arthurtw.github.io/2014/11/30/rust-borrow-lifetimes.html"/>
	<rdf:li rdf:resource="http://blog.mozilla.org/nnethercote/2014/11/04/please-grow-your-buffers-exponentially/"/>
	<rdf:li rdf:resource="http://vanillajava.blogspot.it/2014/08/try-optimising-memory-consumption-first.html"/>
	<rdf:li rdf:resource="http://www.cloudera.com/blog/2011/03/avoiding-full-gcs-in-hbase-with-memstore-local-allocation-buffers-part-3/"/>
      </rdf:Seq>
    </items>
  </channel><item rdf:about="https://devcenter.heroku.com/articles/tuning-glibc-memory-behavior#what-value-to-choose-for-malloc_arena_max">
    <title>Fix glibc's MALLOC_ARENA_MAX variable</title>
    <dc:date>2019-03-25T12:37:07+00:00</dc:date>
    <link>https://devcenter.heroku.com/articles/tuning-glibc-memory-behavior#what-value-to-choose-for-malloc_arena_max</link>
    <dc:creator>jm</dc:creator><description><![CDATA[It seems that recent versions of glibc (up to glibc 2.25 at least) have some dysfunctional behaviour around malloc's arenas on multi-CPU systems,  massively inflating the number of arenas allocated, which inflate reported VM sizes and (for multi-threaded Ruby services in particular) fragmenting memory badly.

See also https://devcenter.heroku.com/articles/testing-cedar-14-memory-use

Presto issue reported with glibc malloc arena-per-thread behaviour resulting in Presto OOMs: https://github.com/prestodb/presto/issues/8993

Hadoop affected by the inflated VM sizes reported as a side effect: https://issues.apache.org/jira/browse/HADOOP-7154

Good detailed writeup from IBM's WebSphere blog: https://www.ibm.com/developerworks/community/blogs/kevgrig/entry/linux_glibc_2_10_rhel_6_malloc_may_show_excessive_virtual_memory_usage]]></description>
<dc:subject>ops ruby memory malloc allocation arenas tuning fragmentation</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:f6214c1a141c/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ruby"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:memory"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:malloc"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:allocation"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:arenas"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tuning"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:fragmentation"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://chrisvest.github.io/stormpot/">
    <title>Stormpot</title>
    <dc:date>2015-09-08T10:43:41+00:00</dc:date>
    <link>http://chrisvest.github.io/stormpot/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>an object pooling library for Java. Use it to recycle objects that are expensive to create. The library will take care of creating and destroying your objects in the background. Stormpot is very mature, is used in production, and has done over a trillion claim-release cycles in testing. It is faster and scales better than any competing pool.</blockquote>

Apache-licensed, and extremely fast: https://medium.com/@chrisvest/released-stormpot-2-4-eeab4aec86d0]]></description>
<dc:subject>java stormpot object-pooling object-pools pools allocation gc open-source apache performance</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:ef38e7baa4ad/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:stormpot"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:object-pooling"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:object-pools"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:pools"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:allocation"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:gc"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:open-source"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:apache"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.slideshare.net/nathariel/microservices-and-elastic-resource-pools-with-amazon-ec2-container-service">
    <title>Microservices and elastic resource pools with Amazon EC2 Container Service</title>
    <dc:date>2015-04-16T16:06:38+00:00</dc:date>
    <link>http://www.slideshare.net/nathariel/microservices-and-elastic-resource-pools-with-amazon-ec2-container-service</link>
    <dc:creator>jm</dc:creator><description><![CDATA[interesting approach to working around ECS' shortcomings -- bit specific to Hailo's microservices arch and IPC mechanism though.

aside: I like their version numbering scheme: ISO-8601, YYYYMMDDHHMMSS.  keep it simple!]]></description>
<dc:subject>versioning microservices hailo aws ec2 ecs docker containers scheduling allocation deployment provisioning qos</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:6721d7ee3f45/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:versioning"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:microservices"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:hailo"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:aws"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ec2"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ecs"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:docker"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:containers"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:scheduling"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:allocation"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:deployment"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:provisioning"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:qos"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://arthurtw.github.io/2014/11/30/rust-borrow-lifetimes.html">
    <title>Rust borrow and lifetimes</title>
    <dc:date>2014-11-30T22:34:29+00:00</dc:date>
    <link>http://arthurtw.github.io/2014/11/30/rust-borrow-lifetimes.html</link>
    <dc:creator>jm</dc:creator><description><![CDATA[How Rust avoids GC overhead using it's "borrow" system:

<blockquote>Rust achieves memory safety without GC by using a sophiscated borrow system. For any resource (stack memory, heap memory, file handle and so on), there is exactly one owner which takes care of its resource deallocation, if needed. You may create new bindings to refer to the resource using & or &mut, which is called a borrow or mutable borrow. The compiler ensures all owners and borrowers behave correctly.</blockquote>

]]></description>
<dc:subject>languages rust gc borrow lifecycle stack heap allocation</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:cf250eeb69f7/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:languages"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:rust"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:gc"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:borrow"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:lifecycle"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:stack"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:heap"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:allocation"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://blog.mozilla.org/nnethercote/2014/11/04/please-grow-your-buffers-exponentially/">
    <title>Please grow your buffers exponentially</title>
    <dc:date>2014-11-04T18:08:34+00:00</dc:date>
    <link>http://blog.mozilla.org/nnethercote/2014/11/04/please-grow-your-buffers-exponentially/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Although in some cases x1.5 is considered good practice. YMMV I guess]]></description>
<dc:subject>malloc memory coding buffers exponential jemalloc firefox heap allocation</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:2cc5cdfc065a/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:malloc"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:memory"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:coding"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:buffers"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:exponential"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:jemalloc"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:firefox"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:heap"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:allocation"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://vanillajava.blogspot.it/2014/08/try-optimising-memory-consumption-first.html">
    <title>Java tip: optimizing memory consumption</title>
    <dc:date>2014-08-20T13:07:51+00:00</dc:date>
    <link>http://vanillajava.blogspot.it/2014/08/try-optimising-memory-consumption-first.html</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Good tips on how to tell if object allocation rate is a bottleneck in your JVM-based code]]></description>
<dc:subject>yourkit memory java jvm allocation gc bottlenecks performance</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:ba674f43806e/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:yourkit"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:memory"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:jvm"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:allocation"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:gc"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:bottlenecks"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.cloudera.com/blog/2011/03/avoiding-full-gcs-in-hbase-with-memstore-local-allocation-buffers-part-3/">
    <title>Avoiding Full GCs in HBase with MemStore-Local Allocation Buffers</title>
    <dc:date>2011-10-22T21:20:06+00:00</dc:date>
    <link>http://www.cloudera.com/blog/2011/03/avoiding-full-gcs-in-hbase-with-memstore-local-allocation-buffers-part-3/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Fascinating. Evading the Java GC by reimplementing a slab allocator, basically]]></description>
<dc:subject>memory allocation java gc jvm hbase memstore via:dehora slab-allocator</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:76e4aad99f52/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:memory"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:allocation"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:gc"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:jvm"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:hbase"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:memstore"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:via:dehora"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:slab-allocator"/>
</rdf:Bag></taxo:topics>
</item>
</rdf:RDF>