<?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://byroot.github.io/ruby/performance/2025/03/04/the-pitchfork-story.html"/>
	<rdf:li rdf:resource="https://github.com/cloudwego/goref"/>
	<rdf:li rdf:resource="https://www.infoq.com/presentations/optimizing-java-app-kubernetes/"/>
	<rdf:li rdf:resource="https://gceasy.io/"/>
	<rdf:li rdf:resource="https://medium.com/thron-tech/lessons-learned-about-monitoring-the-jvm-in-the-era-of-containers-47e7fe0b77dc"/>
	<rdf:li rdf:resource="https://dzone.com/articles/troubleshooting-problems-with-native-off-heap-memo"/>
	<rdf:li rdf:resource="https://www.cockroachlabs.com/blog/how-to-optimize-garbage-collection-in-go/"/>
	<rdf:li rdf:resource="http://chrisvest.github.io/stormpot/"/>
	<rdf:li rdf:resource="https://databricks.com/blog/2015/05/28/tuning-java-garbage-collection-for-spark-applications.html"/>
	<rdf:li rdf:resource="http://www.slideshare.net/MonicaBeckwith/garbage-first-garbage-collector-g1-gc-migration-to-expectations-and-advanced-tuning"/>
	<rdf:li rdf:resource="https://timharris.uk/papers/2015-hotos.pdf"/>
	<rdf:li rdf:resource="https://issues.apache.org/jira/browse/CASSANDRA-7486"/>
	<rdf:li rdf:resource="http://arxiv.org/pdf/1504.02578.pdf"/>
	<rdf:li rdf:resource="http://engineering.linkedin.com/java/optimizing-java-cms-garbage-collections-its-difficulties-and-using-jtune-solution"/>
	<rdf:li rdf:resource="http://www.evanjones.ca/jvm-mmap-pause.html"/>
	<rdf:li rdf:resource="http://www.jclarity.com/2015/02/24/why-we-built-illuminate-where-apm-is-going-next/"/>
	<rdf:li rdf:resource="http://arthurtw.github.io/2014/11/30/rust-borrow-lifetimes.html"/>
	<rdf:li rdf:resource="http://noahlz.roughdraft.io/865cc30e0fd93ad48369-troubleshooting-production-jvms-with-jcmd"/>
	<rdf:li rdf:resource="http://sourceforge.net/projects/ccfreaks/files/papers/LeftRight/leftright-extended.pdf"/>
	<rdf:li rdf:resource="http://spin.atomicobject.com/2014/09/03/visualizing-garbage-collection-algorithms/"/>
	<rdf:li rdf:resource="http://vanillajava.blogspot.it/2014/08/try-optimising-memory-consumption-first.html"/>
	<rdf:li rdf:resource="http://boundary.com/blog/2014/05/15/dynamic-tuple-performance-on-the-jvm/"/>
	<rdf:li rdf:resource="http://engineering.linkedin.com/garbage-collection/garbage-collection-optimization-high-throughput-and-low-latency-java-applications"/>
	<rdf:li rdf:resource="http://blog.phusion.nl/2014/01/31/phusion-passenger-now-supports-the-new-ruby-2-1-out-of-band-gc/"/>
	<rdf:li rdf:resource="http://www.omniref.com/blog/blog/2014/03/27/ruby-garbage-collection-still-not-ready-for-production/"/>
	<rdf:li rdf:resource="http://tech.shift.com/post/74311817513/cassandra-tuning-the-jvm-for-read-heavy-workloads"/>
	<rdf:li rdf:resource="http://blog.ragozin.info/2013/11/hotspot-jvm-garbage-collection-options.html"/>
	<rdf:li rdf:resource="http://java-is-the-new-c.blogspot.de/2013/07/what-drives-full-gc-duration-its.html"/>
	<rdf:li rdf:resource="http://www.infoq.com/articles/tuning-tips-G1-GC"/>
	<rdf:li rdf:resource="http://www.slideshare.net/amywtang/wbdb2012-voldemortssd"/>
	<rdf:li rdf:resource="http://www.jclarity.com/products/censum/"/>
	<rdf:li rdf:resource="http://java-is-the-new-c.blogspot.ie/2013/07/tuning-and-benchmarking-java-7s-garbage.html"/>
	<rdf:li rdf:resource="http://mechanical-sympathy.blogspot.ca/2013/07/java-garbage-collection-distilled.html"/>
	<rdf:li rdf:resource="http://www.infoq.com/articles/Java_Garbage_Collection_Distilled"/>
	<rdf:li rdf:resource="http://www.slideshare.net/r39132/q-con-ny2013modernwebsitescalabilityfinal-22989785"/>
	<rdf:li rdf:resource="https://github.com/blog/1489-hey-judy-don-t-make-it-bad"/>
	<rdf:li rdf:resource="https://github.com/cowtowncoder/low-gc-membuffers"/>
	<rdf:li rdf:resource="http://www.slideshare.net/aszegedi/everything-i-ever-learned-about-jvm-performance-tuning-twitter"/>
	<rdf:li rdf:resource="http://static.usenix.org/events/vee05/full_papers/p46-click.pdf"/>
	<rdf:li rdf:resource="http://blog.ragozin.info/2011/09/hotspot-jvm-garbage-collection-options.html"/>
	<rdf:li rdf:resource="http://blog.ragozin.info/2012/03/secret-hotspot-option-improving-gc.html"/>
	<rdf:li rdf:resource="https://github.com/twitter/jvmgcprof"/>
	<rdf:li rdf:resource="http://www.slideshare.net/boundary_slides/garbage-garbage-everywhere"/>
	<rdf:li rdf:resource="http://www.cloudera.com/blog/2011/03/avoiding-full-gcs-in-hbase-with-memstore-local-allocation-buffers-part-3/"/>
	<rdf:li rdf:resource="http://blogs.azulsystems.com/cliff/2007/08/why-weakhashmap.html"/>
      </rdf:Seq>
    </items>
  </channel><item rdf:about="https://byroot.github.io/ruby/performance/2025/03/04/the-pitchfork-story.html">
    <title>Pitchfork</title>
    <dc:date>2025-03-21T10:30:41+00:00</dc:date>
    <link>https://byroot.github.io/ruby/performance/2025/03/04/the-pitchfork-story.html</link>
    <dc:creator>jm</dc:creator><description><![CDATA[An amazing journey through Ruby heap memory optimization, from one of the experts at Shopify, who are heavy users of Rails.  Using cleverly-timed fork(2) usage, it's possible to optimize memory usage in a Rails app and discard a lot of performance/heap overhead caused by lazy loading and poorly-timed in-memory caching.

This very much reminds me of optimising similar issues in Perl-land, back in the day -- and really helps me appreciate how easy the modern JVM world has it, in comparison.  There's a lot of complaints to be made about the complexity of optimising JVM garbage collection settings, but this kind of problem is malleable there without a fundamental architectural rewrite like this approach.]]></description>
<dc:subject>ruby performance optimisation optimization heap memory fork forking http services servers monolith rails gc</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:2839524a8511/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ruby"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:optimisation"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:optimization"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:heap"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:memory"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:fork"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:forking"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:http"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:services"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:servers"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:monolith"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:rails"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:gc"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://github.com/cloudwego/goref">
    <title>goref</title>
    <dc:date>2025-01-27T10:43:30+00:00</dc:date>
    <link>https://github.com/cloudwego/goref</link>
    <dc:creator>jm</dc:creator><description><![CDATA["a Go heap object reference analysis tool based on delve: It can display the space and object count distribution of Go memory references, which is helpful for efficiently locating memory leak issues or viewing persistent heap objects to optimize the garbage collector (GC) overhead."

Nice to see Go supporting similar debugging/optimisation tools to those offered by the JVM.]]></description>
<dc:subject>go heap memory gc memory-leaks</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:379d693d5af4/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:go"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:heap"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:memory"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:gc"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:memory-leaks"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://www.infoq.com/presentations/optimizing-java-app-kubernetes/">
    <title>Optimizing Java Apps on Kubernetes</title>
    <dc:date>2025-01-23T14:45:35+00:00</dc:date>
    <link>https://www.infoq.com/presentations/optimizing-java-app-kubernetes/</link>
    <dc:creator>jm</dc:creator><description><![CDATA["Optimizing Java Applications on Kubernetes: beyond the Basics": Bruno Borges, at the InfoQ Dev Summit Boston, discusses the strategies for enhancing Java application performance on Kubernetes, focusing on leveraging JVM ergonomics, and managing garbage collection processes.  Some interesting tips here.]]></description>
<dc:subject>kubernetes java eks resources ops scaling scalability gc optimization jvm</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:2c9522ab8d41/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:kubernetes"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:eks"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:resources"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:scaling"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:scalability"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:gc"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:optimization"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:jvm"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://gceasy.io/">
    <title>GCEasy.io</title>
    <dc:date>2020-12-04T10:57:55+00:00</dc:date>
    <link>https://gceasy.io/</link>
    <dc:creator>jm</dc:creator><description><![CDATA['Java Garbage collection log analysis made easy: Industry's first machine learning guided Garbage collection log analysis tool. GCeasy has in-built intelligence to auto-detect problems in the JVM & Android GC logs and recommend solutions to it.'

Looks pretty simple to use, decent free tier.  Haven't tried it yet though....

]]></description>
<dc:subject>java gc tuning performance jvm logs ops</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:d3d8327d2376/</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:gc"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tuning"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:jvm"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:logs"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://medium.com/thron-tech/lessons-learned-about-monitoring-the-jvm-in-the-era-of-containers-47e7fe0b77dc">
    <title>G1 GC tuning metrics</title>
    <dc:date>2020-03-11T13:21:50+00:00</dc:date>
    <link>https://medium.com/thron-tech/lessons-learned-about-monitoring-the-jvm-in-the-era-of-containers-47e7fe0b77dc</link>
    <dc:creator>jm</dc:creator><description><![CDATA[supposedly this is about "tuning in the era of containers", but really it's more about which metrics are usable for GC tuning with the newish java G1 garbage collector.]]></description>
<dc:subject>jvm g1 g1gc gc tuning metrics ops</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:44d5b27b29bf/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:jvm"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:g1"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:g1gc"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:gc"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tuning"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:metrics"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://dzone.com/articles/troubleshooting-problems-with-native-off-heap-memo">
    <title>Troubleshooting Problems With Native (Off-Heap) Memory in Java Applications</title>
    <dc:date>2019-03-22T15:03:45+00:00</dc:date>
    <link>https://dzone.com/articles/troubleshooting-problems-with-native-off-heap-memo</link>
    <dc:creator>jm</dc:creator><description><![CDATA[quite good advice on dealing with memory problems caused by off-heap DirectByteBuffers in java 8.

'Furthermore, the JDK caches one or more DirectByteBuffers per thread, and by default, there is no limit on the number or size of these buffers. As a result, if a Java app creates many threads that perform I/O using HeapByteBuffers, and/or these buffers are big, the JVM process may end up using a lot of additional native memory that looks like a leak'.

'java.lang.OutOfMemoryError: Direct buffer memory' is the indicative error message.]]></description>
<dc:subject>java off-heap buffers memory memory-leaks gc jdk ops</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:cc36a7f2cf9b/</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:off-heap"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:buffers"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:memory"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:memory-leaks"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:gc"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:jdk"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://www.cockroachlabs.com/blog/how-to-optimize-garbage-collection-in-go/">
    <title>How to Optimize Garbage Collection in Go</title>
    <dc:date>2017-09-11T15:31:40+00:00</dc:date>
    <link>https://www.cockroachlabs.com/blog/how-to-optimize-garbage-collection-in-go/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>In this post, we’ll share a few powerful optimizations that mitigate many of the performance problems common to Go’s garbage collection (we will cover “fun with deadlocks” in a follow-up). In particular, we’ll share how embedding structs, using sync.Pool, and reusing backing arrays can minimize memory allocations and reduce garbage collection overhead.</blockquote>

]]></description>
<dc:subject>garbage performance gc golang go coding</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:7367dc904501/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:garbage"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:gc"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:golang"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:go"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:coding"/>
</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="https://databricks.com/blog/2015/05/28/tuning-java-garbage-collection-for-spark-applications.html">
    <title>Tuning Java Garbage Collection for Spark Applications</title>
    <dc:date>2015-06-06T07:02:50+00:00</dc:date>
    <link>https://databricks.com/blog/2015/05/28/tuning-java-garbage-collection-for-spark-applications.html</link>
    <dc:creator>jm</dc:creator><description><![CDATA[So much for G1GC being fire-and-forget]]></description>
<dc:subject>g1gc gc java jvm performance spark ops tuning</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:431050bae8c9/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:g1gc"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:gc"/>
	<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:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:spark"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tuning"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.slideshare.net/MonicaBeckwith/garbage-first-garbage-collector-g1-gc-migration-to-expectations-and-advanced-tuning">
    <title>Migration to, Expectations, and Advanced Tuning of G1GC</title>
    <dc:date>2015-05-09T08:19:41+00:00</dc:date>
    <link>http://www.slideshare.net/MonicaBeckwith/garbage-first-garbage-collector-g1-gc-migration-to-expectations-and-advanced-tuning</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Bookmarking for future reference.  recommended by one of the GC experts, I can't recall exactly who ;)]]></description>
<dc:subject>gc g1gc jvm java tuning performance ops migration</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:1dbd33f78572/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:gc"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:g1gc"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:jvm"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tuning"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:migration"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://timharris.uk/papers/2015-hotos.pdf">
    <title>&quot;Trash Day: Coordinating Garbage Collection in Distributed Systems&quot;</title>
    <dc:date>2015-05-06T16:34:59+00:00</dc:date>
    <link>https://timharris.uk/papers/2015-hotos.pdf</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Another GC-coordination strategy, similar to Blade (qv), with some real-world examples using Cassandra]]></description>
<dc:subject>blade via:adriancolyer papers gc distsys algorithms distributed java jvm latency spark cassandra</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:bf80614a2fb9/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:blade"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:via:adriancolyer"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:papers"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:gc"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:distsys"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:algorithms"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:distributed"/>
	<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:latency"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:spark"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cassandra"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://issues.apache.org/jira/browse/CASSANDRA-7486">
    <title>Cassandra moving to using G1 as the default recommended GC implementation</title>
    <dc:date>2015-04-29T15:42:34+00:00</dc:date>
    <link>https://issues.apache.org/jira/browse/CASSANDRA-7486</link>
    <dc:creator>jm</dc:creator><description><![CDATA[This is a big indicator that G1 is ready for primetime. CMS has long been the go-to GC for production usage, but requires careful, complex hand-tuning -- if G1 is getting to a stage where it's just a case of giving it enough RAM, that'd be great.

Also, looks like it'll be the JDK9 default: https://twitter.com/shipilev/status/593175793255219200]]></description>
<dc:subject>cassandra tuning ops g1gc cms gc java jvm production performance memory</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:0b4b3d1abe38/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cassandra"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tuning"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:g1gc"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cms"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:gc"/>
	<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:production"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:memory"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://arxiv.org/pdf/1504.02578.pdf">
    <title>_Blade: a Data Center Garbage Collector_</title>
    <dc:date>2015-04-17T09:46:59+00:00</dc:date>
    <link>http://arxiv.org/pdf/1504.02578.pdf</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Essentially, add a central GC scheduler to improve tail latencies in a cluster, by taking instances out of the pool to perform slow GC activity instead of letting them impact live operations.  I've been toying with this idea for a while, nice to see a solid paper about it]]></description>
<dc:subject>gc latency tail-latencies papers blade go java scheduling clustering load-balancing low-latency performance</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:604440c5b5eb/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:gc"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:latency"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tail-latencies"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:papers"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:blade"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:go"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:scheduling"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:clustering"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:load-balancing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:low-latency"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://engineering.linkedin.com/java/optimizing-java-cms-garbage-collections-its-difficulties-and-using-jtune-solution">
    <title>Optimizing Java CMS garbage collections, its difficulties, and using JTune as a solution | LinkedIn Engineering</title>
    <dc:date>2015-04-11T20:21:41+00:00</dc:date>
    <link>http://engineering.linkedin.com/java/optimizing-java-cms-garbage-collections-its-difficulties-and-using-jtune-solution</link>
    <dc:creator>jm</dc:creator><description><![CDATA[I like the sound of this -- automated Java CMS GC tuning, kind of like a free version of JClarity's Censum (via Miguel Ángel Pastor)]]></description>
<dc:subject>java jvm tuning gc cms linkedin performance ops</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:717dfe95f072/</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:jvm"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tuning"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:gc"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cms"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:linkedin"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.evanjones.ca/jvm-mmap-pause.html">
    <title>The Four Month Bug: JVM statistics cause garbage collection pauses (evanjones.ca)</title>
    <dc:date>2015-03-26T22:16:21+00:00</dc:date>
    <link>http://www.evanjones.ca/jvm-mmap-pause.html</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Ugh, tying GC safepoints to disk I/O? bad idea:

<blockquote>The JVM by default exports statistics by mmap-ing a file in /tmp (hsperfdata). On Linux, modifying a mmap-ed file can block until disk I/O completes, which can be hundreds of milliseconds. Since the JVM modifies these statistics during garbage collection and safepoints, this causes pauses that are hundreds of milliseconds long. To reduce worst-case pause latencies, add the -XX:+PerfDisableSharedMem JVM flag to disable this feature. This will break tools that read this file, like jstat.</blockquote>

]]></description>
<dc:subject>bugs gc java jvm disk mmap latency ops jstat</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:a8b7f0defa11/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:bugs"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:gc"/>
	<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:disk"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:mmap"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:latency"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:jstat"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.jclarity.com/2015/02/24/why-we-built-illuminate-where-apm-is-going-next/">
    <title>JClarity's Illuminate</title>
    <dc:date>2015-02-26T15:49:43+00:00</dc:date>
    <link>http://www.jclarity.com/2015/02/24/why-we-built-illuminate-where-apm-is-going-next/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Performance-diagnosis-as-a-service. Cool.

<blockquote>Users download and install an Illuminate Daemon using a simple installer which starts up a small stand alone Java process. The Daemon sits quietly unless it is asked to start gathering SLA data and/or to trigger a diagnosis. Users can set SLA’s via the dashboard and can opt to collect latency measurements of their transactions manually (using our library) or by asking Illuminate to automatically instrument their code (Servlet and JDBC based transactions are currently supported).

SLA latency data for transactions is collected on a short cycle. When the moving average of latency measurements goes above the SLA value (e.g. 150ms), a diagnosis is triggered. The diagnosis is very quick, gathering key data from O/S, JVM(s), virtualisation and other areas of the system. The data is then run through the machine learned algorithm which will quickly narrow down the possible causes and gather a little extra data if needed.

Once Illuminate has determined the root cause of the performance problem, the diagnosis report is sent back to the dashboard and an alert is sent to the user. That alert contains a link to the result of the diagnosis which the user can share with colleagues. Illuminate has all sorts of backoff strategies to ensure that users don’t get too many alerts of the same type in rapid succession!</blockquote>

]]></description>
<dc:subject>illuminate jclarity java jvm scala latency gc tuning performance</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:d8f4dcc75538/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:illuminate"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:jclarity"/>
	<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:scala"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:latency"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:gc"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tuning"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
</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://noahlz.roughdraft.io/865cc30e0fd93ad48369-troubleshooting-production-jvms-with-jcmd">
    <title>Troubleshooting Production JVMs with jcmd</title>
    <dc:date>2014-09-17T22:39:46+00:00</dc:date>
    <link>http://noahlz.roughdraft.io/865cc30e0fd93ad48369-troubleshooting-production-jvms-with-jcmd</link>
    <dc:creator>jm</dc:creator><description><![CDATA[remotely trigger GCs, finalization, heap dumps etc.  Handy]]></description>
<dc:subject>jvm jcmd debugging ops java gc heap troubleshooting</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:cc90aa62a26d/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:jvm"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:jcmd"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:debugging"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
	<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:heap"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:troubleshooting"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://sourceforge.net/projects/ccfreaks/files/papers/LeftRight/leftright-extended.pdf">
    <title>&quot;Left-Right: A Concurrency Control Technique with Wait-Free Population Oblivious Reads&quot; [pdf]</title>
    <dc:date>2014-09-17T14:29:55+00:00</dc:date>
    <link>http://sourceforge.net/projects/ccfreaks/files/papers/LeftRight/leftright-extended.pdf</link>
    <dc:creator>jm</dc:creator><description><![CDATA['In this paper, we describe a generic concurrency control technique with Blocking write operations and Wait-Free Population Oblivious read operations, which we named the Left-Right technique. It is of particular interest for real-time applications with dedicated Reader threads, due to its wait-free property that gives strong latency guarantees and, in addition, there is no need for automatic Garbage Collection.
The Left-Right pattern can be applied to any data structure, allowing concurrent access to it similarly to a Reader-Writer lock, but in a non-blocking manner for reads. We present several variations of the Left-Right technique, with different versioning mechanisms and state machines. In addition, we constructed an optimistic approach that can reduce synchronization for reads.'

See also http://concurrencyfreaks.blogspot.ie/2013/12/left-right-concurrency-control.html for java implementation code.]]></description>
<dc:subject>left-right concurrency multithreading wait-free blocking realtime gc latency reader-writer locking synchronization java</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:71e20ba2b8b1/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:left-right"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:concurrency"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:multithreading"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:wait-free"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:blocking"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:realtime"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:gc"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:latency"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:reader-writer"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:locking"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:synchronization"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://spin.atomicobject.com/2014/09/03/visualizing-garbage-collection-algorithms/">
    <title>Visualizing Garbage Collection Algorithms</title>
    <dc:date>2014-09-04T08:37:12+00:00</dc:date>
    <link>http://spin.atomicobject.com/2014/09/03/visualizing-garbage-collection-algorithms/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Great dataviz with animated GIFs]]></description>
<dc:subject>algorithms gc memory visualization garbage-collection dataviz refcounting mark-and-sweep</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:b610cc881a74/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:algorithms"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:gc"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:memory"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:visualization"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:garbage-collection"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:dataviz"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:refcounting"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:mark-and-sweep"/>
</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://boundary.com/blog/2014/05/15/dynamic-tuple-performance-on-the-jvm/">
    <title>Dynamic Tuple Performance On the JVM</title>
    <dc:date>2014-05-16T08:56:30+00:00</dc:date>
    <link>http://boundary.com/blog/2014/05/15/dynamic-tuple-performance-on-the-jvm/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[More JVM off-heap storage from Boundary:

<blockquote>generates heterogeneous collections of primitive values and ensures as best it can that they will be laid out adjacently in memory. The individual values in the tuple can either be accessed from a statically bound interface, via an indexed accessor, or via reflective or other dynamic invocation techniques. FastTuple is designed to deal with a large number of tuples therefore it will also attempt to pool tuples such that they do not add significantly to the GC load of a system. FastTuple is also capable of allocating the tuple value storage entirely off-heap, using Java’s direct memory capabilities.</blockquote>

]]></description>
<dc:subject>jvm java gc off-heap storage boundary memory</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:bac458affd01/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:jvm"/>
	<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:off-heap"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:storage"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:boundary"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:memory"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://engineering.linkedin.com/garbage-collection/garbage-collection-optimization-high-throughput-and-low-latency-java-applications">
    <title>Garbage Collection Optimization for High-Throughput and Low-Latency Java Applications</title>
    <dc:date>2014-04-08T21:54:13+00:00</dc:date>
    <link>http://engineering.linkedin.com/garbage-collection/garbage-collection-optimization-high-throughput-and-low-latency-java-applications</link>
    <dc:creator>jm</dc:creator><description><![CDATA[LinkedIn talk about the GC opts they used to optimize the Feed. good detail]]></description>
<dc:subject>performance optimization linkedin java jvm gc tuning</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:77cabe371f7c/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:optimization"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:linkedin"/>
	<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:gc"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tuning"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://blog.phusion.nl/2014/01/31/phusion-passenger-now-supports-the-new-ruby-2-1-out-of-band-gc/">
    <title>Phusion Passenger now supports the new Ruby 2.1 Out-Of-Band GC</title>
    <dc:date>2014-03-31T13:34:36+00:00</dc:date>
    <link>http://blog.phusion.nl/2014/01/31/phusion-passenger-now-supports-the-new-ruby-2-1-out-of-band-gc/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[a reasonable workaround for Ruby's GC problems in web apps]]></description>
<dc:subject>ruby gc ops performance phusion passenger rails unicorn out-of-band web-services</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:8ec55f6f8a2d/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ruby"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:gc"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:phusion"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:passenger"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:rails"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:unicorn"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:out-of-band"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:web-services"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.omniref.com/blog/blog/2014/03/27/ruby-garbage-collection-still-not-ready-for-production/">
    <title>Ruby Garbage Collection: Still Not Ready for Production</title>
    <dc:date>2014-03-29T08:15:41+00:00</dc:date>
    <link>http://www.omniref.com/blog/blog/2014/03/27/ruby-garbage-collection-still-not-ready-for-production/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[disastrous GC bugs in Ruby, requiring horrible kludgy workarounds.  Reddit thread at: http://www.reddit.com/r/programming/comments/21lrk4/ruby_garbage_collection_still_not_ready_for/]]></description>
<dc:subject>ruby gc memory</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:93972f7594a7/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ruby"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:gc"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:memory"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://tech.shift.com/post/74311817513/cassandra-tuning-the-jvm-for-read-heavy-workloads">
    <title>Cassandra: tuning the JVM for read heavy workloads</title>
    <dc:date>2014-01-24T10:14:24+00:00</dc:date>
    <link>http://tech.shift.com/post/74311817513/cassandra-tuning-the-jvm-for-read-heavy-workloads</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>The cluster we tuned is hosted on AWS and is comprised of 6 hi1.4xlarge EC2 instances, with 2 1TB SSDs raided together in a raid 0 configuration. The cluster’s dataset is growing steadily. At the time of this writing, our dataset is 341GB, up from less than 200GB a few months ago, and is growing by 2-3GB per day. The workload on this cluster is very read heavy, with quorum reads making up 99% of all operations.</blockquote>

Some careful GC tuning here.  Probably not applicable to anyone else, but good approach in general.]]></description>
<dc:subject>java performance jvm scaling gc tuning cassandra ops</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:bc4cff6803b7/</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:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:jvm"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:scaling"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:gc"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tuning"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cassandra"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://blog.ragozin.info/2013/11/hotspot-jvm-garbage-collection-options.html">
    <title>HotSpot JVM garbage collection options cheat sheet (v3)</title>
    <dc:date>2013-11-10T00:10:17+00:00</dc:date>
    <link>http://blog.ragozin.info/2013/11/hotspot-jvm-garbage-collection-options.html</link>
    <dc:creator>jm</dc:creator><description><![CDATA[authoritative]]></description>
<dc:subject>jvm hotspot java tuning ops gc</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:a6b132013693/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:jvm"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:hotspot"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tuning"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:gc"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://java-is-the-new-c.blogspot.de/2013/07/what-drives-full-gc-duration-its.html">
    <title>What drives JVM full GC duration</title>
    <dc:date>2013-10-08T11:15:46+00:00</dc:date>
    <link>http://java-is-the-new-c.blogspot.de/2013/07/what-drives-full-gc-duration-its.html</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Interesting empirical results using JDK 7u21:

<blockquote>Full GC duration depends on the number of objects allocated and the locality of their references. It does not depend that much on actual heap size.</blockquote>

Reference locality has a surprisingly high effect.]]></description>
<dc:subject>java jvm data gc tuning performance cms g1</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:71efc8abad7c/</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:jvm"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:data"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:gc"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tuning"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cms"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:g1"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.infoq.com/articles/tuning-tips-G1-GC">
    <title>Tips for Tuning the Garbage First Garbage Collector</title>
    <dc:date>2013-09-18T21:34:06+00:00</dc:date>
    <link>http://www.infoq.com/articles/tuning-tips-G1-GC</link>
    <dc:creator>jm</dc:creator><dc:subject>g1gc gc java jvm tuning ops optimization</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:6b12d8d218aa/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:g1gc"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:gc"/>
	<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:tuning"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:optimization"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.slideshare.net/amywtang/wbdb2012-voldemortssd">
    <title>Voldemort on Solid State Drives [paper]</title>
    <dc:date>2013-09-04T14:26:32+00:00</dc:date>
    <link>http://www.slideshare.net/amywtang/wbdb2012-voldemortssd</link>
    <dc:creator>jm</dc:creator><description><![CDATA['This paper and talk was given by the LinkedIn Voldemort Team at the Workshop on Big Data Benchmarking (WBDB May 2012).'

<blockquote>
With SSD, we find that garbage collection will become a very significant bottleneck, especially for systems which have little control over the storage layer and rely on Java memory management. Big heapsizes make the cost of garbage collection expensive, especially the single threaded CMS Initial mark. We believe that data systems must revisit their caching strategies with SSDs. In this regard, SSD has provided an efficient solution for handling fragmentation and moving towards predictable multitenancy.</blockquote>]]></description>
<dc:subject>voldemort storage ssd disk linkedin big-data jvm tuning ops gc</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:086f50102a3b/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:voldemort"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:storage"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ssd"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:disk"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:linkedin"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:big-data"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:jvm"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tuning"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:gc"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.jclarity.com/products/censum/">
    <title> Censum</title>
    <dc:date>2013-07-25T11:43:37+00:00</dc:date>
    <link>http://www.jclarity.com/products/censum/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>[JVM] GC is a difficult, specialised area that can be very frustrating for busy developers or devops folks to deal with. The JVM has a number of Garbage Collectors and a bewildering array of switches that can alter the behaviour of each collector. Censum does all of the parsing, number crunching and statistical analysis for you, so you don't have to go and get that PhD in Computer Science in order to solve your GC performance problem.  Censum gives you straight answers as opposed to a ton of raw data. can eat any GC log you care to throw at it. is easy to install and use.</blockquote>

Commercial software, UKP 495 per license.]]></description>
<dc:subject>censum gc tuning ops java jvm commercial</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:ed538dc1a0a6/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:censum"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:gc"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tuning"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
	<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:commercial"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://java-is-the-new-c.blogspot.ie/2013/07/tuning-and-benchmarking-java-7s-garbage.html">
    <title>Tuning and benchmarking Java 7's Garbage Collectors: Default, CMS and G1</title>
    <dc:date>2013-07-25T11:27:30+00:00</dc:date>
    <link>http://java-is-the-new-c.blogspot.ie/2013/07/tuning-and-benchmarking-java-7s-garbage.html</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Rudiger Moller runs through a typical GC-tuning session, in exhaustive detail]]></description>
<dc:subject>java gc tuning jvm cms g1 ops</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:6ef833ae0fa3/</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:gc"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tuning"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:jvm"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cms"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:g1"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://mechanical-sympathy.blogspot.ca/2013/07/java-garbage-collection-distilled.html">
    <title>Java Garbage Collection Distilled</title>
    <dc:date>2013-07-16T22:22:21+00:00</dc:date>
    <link>http://mechanical-sympathy.blogspot.ca/2013/07/java-garbage-collection-distilled.html</link>
    <dc:creator>jm</dc:creator><description><![CDATA[a great summary of the state of JVM garbage collection from Martin Thompson]]></description>
<dc:subject>jvm java gc garbage-collection tuning memory performance martin-thompson</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:f32e30988004/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:jvm"/>
	<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:garbage-collection"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tuning"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:memory"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:martin-thompson"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.infoq.com/articles/Java_Garbage_Collection_Distilled">
    <title>Java Garbage Collection Distilled</title>
    <dc:date>2013-06-19T10:07:19+00:00</dc:date>
    <link>http://www.infoq.com/articles/Java_Garbage_Collection_Distilled</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Martin Thompson lays it out:

<blockquote>Serial, Parallel, Concurrent, CMS, G1, Young Gen, New Gen, Old Gen, Perm Gen, Eden, Tenured, Survivor Spaces, Safepoints, and the hundreds of JVM start-up flags. Does this all baffle you when trying to tune the garbage collector while trying to get the required throughput and latency from your Java application? If it does then don’t worry, you are not alone. Documentation describing garbage collection feels like man pages for an aircraft. Every knob and dial is detailed and explained but nowhere can you find a guide on how to fly. This article will attempt to explain the tradeoffs when choosing and tuning garbage collection algorithms for a particular workload.</blockquote>

]]></description>
<dc:subject>gc java garbage-collection coding cms g1 jvm optimization</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:f59114d2c748/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:gc"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:garbage-collection"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:coding"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cms"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:g1"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:jvm"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:optimization"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.slideshare.net/r39132/q-con-ny2013modernwebsitescalabilityfinal-22989785">
    <title>Building a Modern Website for Scale (QCon NY 2013) [slides]</title>
    <dc:date>2013-06-17T10:37:00+00:00</dc:date>
    <link>http://www.slideshare.net/r39132/q-con-ny2013modernwebsitescalabilityfinal-22989785</link>
    <dc:creator>jm</dc:creator><description><![CDATA[some great scalability ideas from LinkedIn.  Particularly interesting are the best practices suggested for scaling web services:

1. store client-call timeouts and SLAs in Zookeeper for each REST endpoint;
2. isolate backend calls using async/threadpools;
3. cancel work on failures;
4. avoid sending requests to GC'ing hosts;
5. rate limits on the server.

#4 is particularly cool.  They do this using a "GC scout" request before every "real" request; a cheap TCP request to a dedicated "scout" Netty port, which replies near-instantly.  If it comes back with a 1-packet response within 1 millisecond, send the real request, else fail over immediately to the next host in the failover set.

There's still a potential race condition where the "GC scout" can be achieved quickly, then a GC starts just before the "real" request is issued.  But the incidence of GC-blocking-request is probably massively reduced.

It also helps against packet loss on the rack or server host, since packet loss will cause the drop of one of the TCP packets, and the TCP retransmit timeout will certainly be higher than 1ms, causing the deadline to be missed.  (UDP would probably work just as well, for this reason.)  However, in the case of packet loss in the client's network vicinity, it will be vital to still attempt to send the request to the final host in the failover set regardless of a GC-scout failure, otherwise all requests may be skipped.

The GC-scout system also helps balance request load off heavily-loaded hosts, or hosts with poor performance for other reasons; they'll fail to achieve their 1 msec deadline and the request will be shunted off elsewhere.

For service APIs with real low-latency requirements, this is a great idea.]]></description>
<dc:subject>gc-scout gc java scaling scalability linkedin qcon async threadpools rest slas timeouts networking distcomp netty tcp udp failover fault-tolerance packet-loss</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:8766348f43f5/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:gc-scout"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:gc"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:scaling"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:scalability"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:linkedin"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:qcon"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:async"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:threadpools"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:rest"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:slas"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:timeouts"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:networking"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:distcomp"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:netty"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tcp"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:udp"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:failover"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:fault-tolerance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:packet-loss"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://github.com/blog/1489-hey-judy-don-t-make-it-bad">
    <title>Hey Judy, don't make it bad</title>
    <dc:date>2013-05-02T11:41:48+00:00</dc:date>
    <link>https://github.com/blog/1489-hey-judy-don-t-make-it-bad</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Github get good results using Judy arrays to replace a Ruby hash.  However: the whole blog post is a bit dodgy to me.  It feels like there are much better ways to fix the problem:

1. the big one: don't do GC-heavy activity in the front-end web servers.  Split that language-classification code into a separate service.  Write its results to a cache and don't re-query needlessly.
2. why isn't this benchmarked against a C/C++ hash?  it's only 36000 entries, loaded once at startup.  lookups against that should be blisteringly fast even with the basic data structures, and that would also be outside the Ruby heap so avoid the GC overhead.  Feels like the use of a Judy array was a "because I want to" decision.
3. personally, I'd have preferred they spend time fixing their uptime problems....

See also https://news.ycombinator.com/item?id=5639013 for more kvetching.]]></description>
<dc:subject>ruby github gc judy-arrays linguist hashes data-structures</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:8a17f7e093d8/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ruby"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:github"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:gc"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:judy-arrays"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:linguist"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:hashes"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:data-structures"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://github.com/cowtowncoder/low-gc-membuffers">
    <title>low-gc-membuffers</title>
    <dc:date>2012-12-06T22:14:32+00:00</dc:date>
    <link>https://github.com/cowtowncoder/low-gc-membuffers</link>
    <dc:creator>jm</dc:creator><description><![CDATA["This project aims at creating a simple efficient building block for "Big Data" libraries, applications and frameworks; thing that can be used as an in-memory, bounded queue with opaque values (sequence of JDK primitive values): insertions at tail, removal from head, single entry peeks), and that has minimal garbage collection overhead. Insertions and removals are as individual entries, which are sub-sequences of the full buffer.

GC overhead minimization is achieved by use of direct ByteBuffers (memory allocated outside of GC-prone heap); and bounded nature by only supporting storage of simple primitive value (byte, `long') sequences where size is explicitly known.

Conceptually memory buffers are just simple circular buffers (ring buffers) that hold a sequence of primitive values, bit like arrays, but in a way that allows dynamic automatic resizings of the underlying storage. Library supports efficient reusing and sharing of underlying segments for sets of buffers, although for many use cases a single buffer suffices."]]></description>
<dc:subject>gc java jvm bytebuffer</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:3ff7ac76f33b/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:gc"/>
	<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:bytebuffer"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.slideshare.net/aszegedi/everything-i-ever-learned-about-jvm-performance-tuning-twitter">
    <title>Everything I Ever Learned About JVM Performance Tuning @Twitter</title>
    <dc:date>2012-12-01T18:51:22+00:00</dc:date>
    <link>http://www.slideshare.net/aszegedi/everything-i-ever-learned-about-jvm-performance-tuning-twitter</link>
    <dc:creator>jm</dc:creator><description><![CDATA[presentation by Attila Szegedi of Twitter from last year.  Some good tips here, well-presented]]></description>
<dc:subject>tuning jvm java gc cms presentations slides twitter</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:80c49db84474/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tuning"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:jvm"/>
	<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:cms"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:presentations"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:slides"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:twitter"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://static.usenix.org/events/vee05/full_papers/p46-click.pdf">
    <title>_The Pauseless GC Algorithm_ [pdf]</title>
    <dc:date>2012-12-01T18:36:58+00:00</dc:date>
    <link>http://static.usenix.org/events/vee05/full_papers/p46-click.pdf</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Paper from USENIX VEE '05, by Cliff Click, Gil Tene, and Michael Wolf of Azul Systems, describing some details of the Azul secret sauce (via b6n)]]></description>
<dc:subject>via:b3n azul gc jvm java usenix papers</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:1a4308ccbf52/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:via:b3n"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:azul"/>
	<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:java"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:usenix"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:papers"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://blog.ragozin.info/2011/09/hotspot-jvm-garbage-collection-options.html">
    <title>HotSpot JVM garbage collection options cheat sheet (v2)</title>
    <dc:date>2012-09-01T08:09:44+00:00</dc:date>
    <link>http://blog.ragozin.info/2011/09/hotspot-jvm-garbage-collection-options.html</link>
    <dc:creator>jm</dc:creator><description><![CDATA['In this article I have collected a list of options related to GC tuning in JVM. This is not a comprehensive list, I have only collected options which I use in practice (or at least understand why I may want to use them).
Compared to previous version a few useful diagnostic options was added. Additionally section for G1 specific options was introduced.']]></description>
<dc:subject>hotspot jvm coding gc java performance</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:b55a15b22be0/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:hotspot"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:jvm"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:coding"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:gc"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://blog.ragozin.info/2012/03/secret-hotspot-option-improving-gc.html">
    <title>Secret HotSpot option improving GC pauses on large heaps</title>
    <dc:date>2012-04-05T09:06:56+00:00</dc:date>
    <link>http://blog.ragozin.info/2012/03/secret-hotspot-option-improving-gc.html</link>
    <dc:creator>jm</dc:creator><description><![CDATA[via Toby DiPasquale.  nice tip]]></description>
<dc:subject>java jvm gc performance hotspot undocumented</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:2fa6006fc991/</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:jvm"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:gc"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:hotspot"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:undocumented"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://github.com/twitter/jvmgcprof">
    <title>twitter/jvmgcprof - GitHub</title>
    <dc:date>2012-02-26T22:58:24+00:00</dc:date>
    <link>https://github.com/twitter/jvmgcprof</link>
    <dc:creator>jm</dc:creator><description><![CDATA['gcprof is a simple utility for profile allocation and garbage collection activity in the JVM  [...] Profile allocation and garbage collection activity in the JVM. The gcprof command runs a java command under profiling. Allocation and collection statistics are printed periodically. If -n or -no are provided, statistics are also reported in terms of the given application metric. Total allocation, allocation rate, and a survival histogram is given. The intended use for this tool is twofold: (1) monitor and test garbage allocation and GC behavior, and (2) inform GC tuning.']]></description>
<dc:subject>gc java performance twitter jvm tools</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:5e922d601dca/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:gc"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:twitter"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:jvm"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tools"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.slideshare.net/boundary_slides/garbage-garbage-everywhere">
    <title>Scott Andreas - Garbage, Garbage Everywhere [slides]</title>
    <dc:date>2011-12-04T23:00:35+00:00</dc:date>
    <link>http://www.slideshare.net/boundary_slides/garbage-garbage-everywhere</link>
    <dc:creator>jm</dc:creator><description><![CDATA['GC Strategies for Event Processing Systems on the JVM']]></description>
<dc:subject>gc java jvm event-streams event-processing tuning slides presentations scott-andreas performance</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:750e291a35af/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:gc"/>
	<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:event-streams"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:event-processing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tuning"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:slides"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:presentations"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:scott-andreas"/>
	<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>
<item rdf:about="http://blogs.azulsystems.com/cliff/2007/08/why-weakhashmap.html">
    <title>Why WeakHashMap Sucks</title>
    <dc:date>2009-09-01T17:06:24+00:00</dc:date>
    <link>http://blogs.azulsystems.com/cliff/2007/08/why-weakhashmap.html</link>
    <dc:creator>jm</dc:creator><description><![CDATA['SoftReferences are the cheap, crappy caching mechanism [...] perfect for when you'd like your cache to be cleared at random times and in random order.']]></description>
<dc:subject>softreferences weakreferences weak references gc java jvm caching hash memory collections vm weakhashmap via:spyced</dc:subject>
<dc:identifier>https://pinboard.in/u:jm/b:30d2ba377aa4/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:softreferences"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:weakreferences"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:weak"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:references"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:gc"/>
	<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:caching"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:hash"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:memory"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:collections"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:vm"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:weakhashmap"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:via:spyced"/>
</rdf:Bag></taxo:topics>
</item>
</rdf:RDF>