<?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://github.com/Netflix/hollow"/>
	<rdf:li rdf:resource="https://www.infoq.com/presentations/optimizing-java-app-kubernetes/"/>
	<rdf:li rdf:resource="https://krzysztofslusarski.github.io/2022/12/12/async-manual.html"/>
	<rdf:li rdf:resource="https://twitter.com/nitsanw/status/1566677642748874753"/>
	<rdf:li rdf:resource="https://neilmadden.blog/2022/04/19/psychic-signatures-in-java/"/>
	<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://github.com/apple/servicetalk/"/>
	<rdf:li rdf:resource="http://batey.info/docker-jvm-k8s.html"/>
	<rdf:li rdf:resource="http://www.evanjones.ca/java-bytebuffer-leak.html"/>
	<rdf:li rdf:resource="https://confluence.atlassian.com/kb/how-to-change-jvm-arguments-at-runtime-to-avoid-application-restart-816682109.html"/>
	<rdf:li rdf:resource="https://groups.google.com/forum/#!msg/mechanical-sympathy/gchG_oQ_kQM/59BDMOdUAwAJ"/>
	<rdf:li rdf:resource="https://docs.oracle.com/javase/8/docs/technotes/guides/troubleshoot/tooldescr007.html"/>
	<rdf:li rdf:resource="http://psy-lob-saw.blogspot.ie/2017/02/flamegraphs-intro-fire-for-everyone.html"/>
	<rdf:li rdf:resource="https://github.com/AdoptOpenJDK/jitwatch"/>
	<rdf:li rdf:resource="https://plasma-umass.github.io/doppio-demo/"/>
	<rdf:li rdf:resource="http://www.evanjones.ca/java-native-leak-bug.html"/>
	<rdf:li rdf:resource="https://blog.buoyant.io/2016/06/17/small-memory-jvm-techniques-for-microservice-sidecars/"/>
	<rdf:li rdf:resource="https://github.com/ztellman/dirigiste"/>
	<rdf:li rdf:resource="https://gdstechnology.blog.gov.uk/2015/12/11/using-jemalloc-to-get-to-the-bottom-of-a-memory-leak/"/>
	<rdf:li rdf:resource="https://github.com/JCTools/JCTools/pull/93"/>
	<rdf:li rdf:resource="http://www.infoq.com/presentations/apple-netty"/>
	<rdf:li rdf:resource="https://www.voxxed.com/blog/2015/12/importance-tuning-thread-pools/"/>
	<rdf:li rdf:resource="http://byteman.jboss.org/"/>
	<rdf:li rdf:resource="http://steveloughran.blogspot.co.uk/2015/09/time-on-multi-core-multi-socket-servers.html"/>
	<rdf:li rdf:resource="http://gary-rowe.com/agilestack/2013/07/03/preventing-dependency-chain-attacks-in-maven/"/>
	<rdf:li rdf:resource="https://github.com/aragozin/jvm-tools"/>
	<rdf:li rdf:resource="https://github.com/electronicarts/orbit/tree/master/async"/>
	<rdf:li rdf:resource="https://databricks.com/blog/2015/05/28/tuning-java-garbage-collection-for-spark-applications.html"/>
	<rdf:li rdf:resource="https://github.com/caplogic/mappedbus"/>
	<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://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="https://blogs.oracle.com/dave/entry/biased_locking_in_hotspot"/>
	<rdf:li rdf:resource="http://www.jclarity.com/2015/02/24/why-we-built-illuminate-where-apm-is-going-next/"/>
	<rdf:li rdf:resource="https://sysdigcloud.com/gain-insights-jvms-sysdig-clouds-jmx-metrics/"/>
	<rdf:li rdf:resource="http://openjdk.java.net/projects/code-tools/jol/"/>
	<rdf:li rdf:resource="http://tobert.github.io/tldr/cassandra-java-huge-pages.html"/>
	<rdf:li rdf:resource="https://speakerdeck.com/elasticsearch/maintaining-performance-in-distributed-systems"/>
	<rdf:li rdf:resource="http://rdiyewar-tech.blogspot.de/2013/02/outofmemoryerror-because-of-default.html"/>
	<rdf:li rdf:resource="https://github.com/JCTools/JCTools"/>
	<rdf:li rdf:resource="http://tech.stolsvik.com/2010/01/linux-java-thread-priorities-workaround.html"/>
	<rdf:li rdf:resource="http://www.nurkiewicz.com/2014/11/executorservice-10-tips-and-tricks.html"/>
	<rdf:li rdf:resource="http://stackoverflow.com/questions/219585/setting-multiple-jars-in-java-classpath/219801#219801"/>
	<rdf:li rdf:resource="https://groups.google.com/forum/#!msg/project-voldemort/Y52UyHQ8tBA/9Ei79_RvS3EJ"/>
	<rdf:li rdf:resource="http://noahlz.roughdraft.io/865cc30e0fd93ad48369-troubleshooting-production-jvms-with-jcmd"/>
	<rdf:li rdf:resource="http://vanillajava.blogspot.it/2014/08/try-optimising-memory-consumption-first.html"/>
	<rdf:li rdf:resource="https://github.com/OpenHFT/hftc"/>
	<rdf:li rdf:resource="https://github.com/mariusaeriksen/heapster"/>
	<rdf:li rdf:resource="http://boundary.com/blog/2014/05/15/dynamic-tuple-performance-on-the-jvm/"/>
	<rdf:li rdf:resource="https://github.com/RuedigerMoeller/fast-serialization/wiki/Structs"/>
	<rdf:li rdf:resource="http://shipilev.net/blog/2014/exceptional-performance/"/>
	<rdf:li rdf:resource="http://shipilev.net/blog/2014/nanotrusting-nanotime/"/>
	<rdf:li rdf:resource="http://comcast.github.io/sirius/overview.html"/>
	<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://java-is-the-new-c.blogspot.ie/2013/07/impact-of-large-primitive-arrays-blobs.html"/>
	<rdf:li rdf:resource="http://highscalability.com/blog/2014/2/5/littles-law-scalability-and-fault-tolerance-the-os-is-your-b.html"/>
	<rdf:li rdf:resource="http://tech.shift.com/post/74311817513/cassandra-tuning-the-jvm-for-read-heavy-workloads"/>
	<rdf:li rdf:resource="https://groups.google.com/forum/#!msg/mechanical-sympathy/4EDCX0F_3ow/FxJ9nOvZqYUJ"/>
	<rdf:li rdf:resource="http://jpbempel.blogspot.ie/2013/10/hardware-performance-counters-atomic-vs.html"/>
	<rdf:li rdf:resource="http://www.youtube.com/watch?v=Yg6_ulhwLw0&amp;feature=youtu.be"/>
	<rdf:li rdf:resource="https://github.com/mgodave/barge"/>
	<rdf:li rdf:resource="https://spring.io/blog/2013/11/12/it-can-t-just-be-big-data-it-has-to-be-fast-data-reactor-1-0-goes-ga"/>
	<rdf:li rdf:resource="http://blog.ragozin.info/2013/11/hotspot-jvm-garbage-collection-options.html"/>
	<rdf:li rdf:resource="http://hg.openjdk.java.net/lambda/lambda/jdk/file/b55f1ce224fb/src/share/classes/java/util/stream/SpinedBuffer.java"/>
	<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://psy-lob-saw.blogspot.ie/2013/10/spsc-revisited-part-iii-fastflow-sparse.html"/>
	<rdf:li rdf:resource="https://speakerdeck.com/headius/down-the-rabbit-hole"/>
      </rdf:Seq>
    </items>
  </channel><item rdf:about="https://github.com/Netflix/hollow">
    <title>Netflix/hollow</title>
    <dc:date>2025-02-25T12:19:14+00:00</dc:date>
    <link>https://github.com/Netflix/hollow</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>
Hollow is a java library and toolset for disseminating in-memory datasets from a single producer to many consumers for high performance read-only access.

Hollow focuses narrowly on its prescribed problem set: keeping an entire, read-only dataset in-memory on consumers. It circumvents the consequences of updating and evicting data from a partial cache.

Due to its performance characteristics, Hollow shifts the scale in terms of appropriate dataset sizes for an in-memory solution. Datasets for which such liberation may never previously have been considered can be candidates for Hollow. For example, Hollow may be entirely appropriate for datasets which, if represented with json or XML, might require in excess of 100GB.
</blockquote>

Interesting approach, though possibly a bit scary in terms of circumventing the "keep things simple and boring" rule... still, a useful tool to have.]]></description>
<dc:subject>cache caching netflix java jvm memory hollow read-only architecture systems</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:3f732f05411d/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cache"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:caching"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:netflix"/>
	<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:memory"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:hollow"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:read-only"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:architecture"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:systems"/>
</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://krzysztofslusarski.github.io/2022/12/12/async-manual.html">
    <title>Async-profiler manual by use cases</title>
    <dc:date>2023-01-05T15:53:26+00:00</dc:date>
    <link>https://krzysztofslusarski.github.io/2022/12/12/async-manual.html</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Amazing collection of Java async-profiler commands and examples, each one representing a specific common (or not-so-common) use case we are liable to run into with production services: includes continuous profiling, wall-clock vs CPU, allocations, locks, cache misses, page faults, and thread-startup overhead]]></description>
<dc:subject>async-profiler java jvm profiling tracing performance tuning</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:8ec959433ae2/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:async-profiler"/>
	<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:profiling"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tracing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tuning"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://twitter.com/nitsanw/status/1566677642748874753">
    <title>don't use JVM Flight Recorder profiling</title>
    <dc:date>2022-09-05T10:57:00+00:00</dc:date>
    <link>https://twitter.com/nitsanw/status/1566677642748874753</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Solid tip from Nitsan Wakart on Twitter:

<blockquote>If you are profiling for a CPU bottleneck [in java], DO NOT RELY ON JVM FLIGHT RECORDER METHOD PROFILING. Not even a little bit.

Use `async-profiler` for profiling(`-e cpu,lock,alloc`), with `--jfrsync default/profile` for extra JVM/JDK events.</blockquote>

]]></description>
<dc:subject>profiling java performance optimization jvm async-profiler via:twitter</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:acdfaf080f4b/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:profiling"/>
	<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:optimization"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:jvm"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:async-profiler"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:via:twitter"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://neilmadden.blog/2022/04/19/psychic-signatures-in-java/">
    <title>CVE-2022-21449: Psychic Signatures in Java</title>
    <dc:date>2022-04-20T09:29:49+00:00</dc:date>
    <link>https://neilmadden.blog/2022/04/19/psychic-signatures-in-java/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Argh, this is a bad one:

<blockquote>Recent releases of Java were vulnerable to a similar kind of trick, in the implementation of widely-used ECDSA signatures. If you are running one of the vulnerable versions then an attacker can easily forge some types of SSL certificates and handshakes (allowing interception and modification of communications), signed JWTs, SAML assertions or OIDC id tokens, and even WebAuthn authentication messages. All using the digital equivalent of a blank piece of paper.

It’s hard to overstate the severity of this bug. If you are using ECDSA signatures for any of these security mechanisms, then an attacker can trivially and completely bypass them if your server is running any Java 15, 16, 17, or 18 version before the April 2022 Critical Patch Update (CPU). For context, almost all WebAuthn/FIDO devices in the real world (including Yubikeys*) use ECDSA signatures and many OIDC providers use ECDSA-signed JWTs.
</blockquote>]]></description>
<dc:subject>java jvm crypto security ecdsa webauthn saml jwt fail</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:19326f7fa161/</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:crypto"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:security"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ecdsa"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:webauthn"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:saml"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:jwt"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:fail"/>
</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://github.com/apple/servicetalk/">
    <title>ServiceTalk</title>
    <dc:date>2019-11-06T14:00:14+00:00</dc:date>
    <link>https://github.com/apple/servicetalk/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>a JVM network application framework with APIs tailored to specific protocols (e.g. HTTP/1.x, HTTP/2.x, etc…​) and supports multiple programming paradigms.
It is built on Netty and is designed to provide most of the performance/scalability benefits of Netty for common networking protocols used in service to service communication. ServiceTalk provides server support and "smart client" like features such as client-side load balancing and service discovery integration.</blockquote>

Open source from Apple.]]></description>
<dc:subject>apple servicetalk netty libraries java jvm coding http async</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:d97f22fd741a/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:apple"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:servicetalk"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:netty"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:libraries"/>
	<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:coding"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:http"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:async"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://batey.info/docker-jvm-k8s.html">
    <title>The JVM in Docker 2018</title>
    <dc:date>2018-11-19T11:57:33+00:00</dc:date>
    <link>http://batey.info/docker-jvm-k8s.html</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>
Later JDK versions have made it far easier to run a JVM application in a Linux container. The memory support means that if you relied on JVM ergonomics before than you can do the same inside a container where as previously you had to override all memory related settings. The CPU support for containers needs to be carefully evaluated for your application and environment. If you’ve previously set low cpu_shares in environments like Kubernetes to increase utilisation while relying on using up unused cycles then you might get a shock.</blockquote>

]]></description>
<dc:subject>jvm docker kubernetes linux containers ops</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:521b7b5a67e4/</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:docker"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:kubernetes"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:linux"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:containers"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.evanjones.ca/java-bytebuffer-leak.html">
    <title>Java's ByteBuffer native memory &quot;leak&quot;</title>
    <dc:date>2018-11-19T11:30:30+00:00</dc:date>
    <link>http://www.evanjones.ca/java-bytebuffer-leak.html</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Well this is suboptimal:

<blockquote>The Java NIO APIs use ByteBuffers as the source and destination of I/O calls, and come in two flavours. Heap ByteBuffers wrap a byte[] array, allocated in the garbage collected Java heap. Direct ByteBuffers wrap memory allocated outside the Java heap using malloc. Only "native" memory can be passed to operating system calls, so it won't be moved by the garbage collector. This means that when you use a heap ByteBuffer for I/O, it is copied into a temporary direct ByteBuffer. The JDK caches one temporary buffer per thread, without any memory limits. As a result, if you call I/O methods with large heap ByteBuffers from multiple threads, your process can use a huge amount of additional native memory, which looks like a native memory leak. This can cause your process to unexpectedly run into memory limits and get killed.</blockquote>

]]></description>
<dc:subject>jvm performance java memory leaks bytebuffers netty threads coding bugs</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:94c60cf2a090/</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:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:memory"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:leaks"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:bytebuffers"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:netty"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:threads"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:coding"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:bugs"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://confluence.atlassian.com/kb/how-to-change-jvm-arguments-at-runtime-to-avoid-application-restart-816682109.html">
    <title>How to change JVM arguments at runtime to avoid application restart</title>
    <dc:date>2018-06-06T15:27:52+00:00</dc:date>
    <link>https://confluence.atlassian.com/kb/how-to-change-jvm-arguments-at-runtime-to-avoid-application-restart-816682109.html</link>
    <dc:creator>jm</dc:creator><description><![CDATA[This is a super nifty feature of the JVM: turn on and off heap class histogram dumps at runtime, for instance.

<blockquote>java -XX:+PrintFlagsFinal -version|grep manageable</blockquote>

]]></description>
<dc:subject>jvm ops switches cli java heap-dumps memory debugging memory-leaks</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:b591a243dc1d/</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:ops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:switches"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cli"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:heap-dumps"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:memory"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:debugging"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:memory-leaks"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://groups.google.com/forum/#!msg/mechanical-sympathy/gchG_oQ_kQM/59BDMOdUAwAJ">
    <title>Locking, Little's Law, and the USL</title>
    <dc:date>2017-09-20T14:36:55+00:00</dc:date>
    <link>https://groups.google.com/forum/#!msg/mechanical-sympathy/gchG_oQ_kQM/59BDMOdUAwAJ</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Excellent explanatory mailing list post by Martin Thompson to the mechanical-sympathy group, discussing Little's Law vs the USL:

<blockquote>Little's law can be used to describe a system in steady state from a queuing perspective, i.e. arrival and leaving rates are balanced. In this case it is a crude way of modelling a system with a contention percentage of 100% under Amdahl's law, in that throughput is one over latency.

However this is an inaccurate way to model a system with locks. Amdahl's law does not account for coherence costs. For example, if you wrote a microbenchmark with a single thread to measure the lock cost then it is much lower than in a multi-threaded environment where cache coherence, other OS costs such as scheduling, and lock implementations need to be considered.

Universal Scalability Law (USL) accounts for both the contention and the coherence costs.
http://www.perfdynamics.com/Manifesto/USLscalability.html

When modelling locks it is necessary to consider how contention and coherence costs vary given how they can be implemented. Consider in Java how we have biased locking, thin locks, fat locks, inflation, and revoking biases which can cause safe points that bring all threads in the JVM to a stop with a significant coherence component.</blockquote>

]]></description>
<dc:subject>usl scaling scalability performance locking locks java jvm amdahls-law littles-law system-dynamics modelling systems caching threads schedulers contention</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:d64fb1279a0b/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:usl"/>
	<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:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:locking"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:locks"/>
	<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:amdahls-law"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:littles-law"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:system-dynamics"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:modelling"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:systems"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:caching"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:threads"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:schedulers"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:contention"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://docs.oracle.com/javase/8/docs/technotes/guides/troubleshoot/tooldescr007.html">
    <title>Native Memory Tracking</title>
    <dc:date>2017-09-18T09:35:48+00:00</dc:date>
    <link>https://docs.oracle.com/javase/8/docs/technotes/guides/troubleshoot/tooldescr007.html</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Java 8 HotSpot feature to monitor and diagnose native memory leaks]]></description>
<dc:subject>java jvm memory native-memory malloc debugging coding nmt java-8 jcmd</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:d2f2bae02fb3/</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:memory"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:native-memory"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:malloc"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:debugging"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:coding"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:nmt"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java-8"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:jcmd"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://psy-lob-saw.blogspot.ie/2017/02/flamegraphs-intro-fire-for-everyone.html">
    <title>Java Flame Graphs Introduction: Fire For Everyone!</title>
    <dc:date>2017-09-11T10:48:52+00:00</dc:date>
    <link>http://psy-lob-saw.blogspot.ie/2017/02/flamegraphs-intro-fire-for-everyone.html</link>
    <dc:creator>jm</dc:creator><description><![CDATA[lots of good detail on flame graph usage in Java, and the Honest Profiler (honest because it's safepoint-free)]]></description>
<dc:subject>profiling java safepoints jvm flame-graphs perf measurement benchmarking testing</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:1a6f8c8d9b75/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:profiling"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:safepoints"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:jvm"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:flame-graphs"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:perf"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:measurement"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:benchmarking"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:testing"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://github.com/AdoptOpenJDK/jitwatch">
    <title>AdoptOpenJDK/jitwatch</title>
    <dc:date>2017-08-24T16:22:31+00:00</dc:date>
    <link>https://github.com/AdoptOpenJDK/jitwatch</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>Log analyser and visualiser for the HotSpot JIT compiler. Inspect inlining decisions, hot methods, bytecode, and assembly. View results in the JavaFX user interface.</blockquote>

]]></description>
<dc:subject>analysis java jvm performance tools debugging optimization jit</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:404ca57f5933/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:analysis"/>
	<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:tools"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:debugging"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:optimization"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:jit"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://plasma-umass.github.io/doppio-demo/">
    <title>DoppioJVM</title>
    <dc:date>2017-07-12T10:53:58+00:00</dc:date>
    <link>https://plasma-umass.github.io/doppio-demo/</link>
    <dc:creator>jm</dc:creator><description><![CDATA['A Java Virtual Machine written in 100% JavaScript.'  Wrapping outbound TCP traffic in websockets, mad stuff]]></description>
<dc:subject>jvm java javascript js hacks browser emulation websockets</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:15ebe75eae91/</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:javascript"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:js"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:hacks"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:browser"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:emulation"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:websockets"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.evanjones.ca/java-native-leak-bug.html">
    <title>Debugging Java Native Memory Leaks (evanjones.ca)</title>
    <dc:date>2017-01-10T16:39:09+00:00</dc:date>
    <link>http://www.evanjones.ca/java-native-leak-bug.html</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Using jemalloc to instrument the contents of the native heap and record stack traces of each chunk's allocators, so that leakers can be quickly identified (GZIPInputStream in this case).

See also https://gdstechnology.blog.gov.uk/2015/12/11/using-jemalloc-to-get-to-the-bottom-of-a-memory-leak/ , https://github.com/jeffgriffith/native-jvm-leaks/blob/master/README.md .]]></description>
<dc:subject>debugging memory jvm java leaks memory-leaks leak-checking jemalloc malloc native heap off-heap gzipinputstream</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:5206aa65dc43/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:debugging"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:memory"/>
	<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:leaks"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:memory-leaks"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:leak-checking"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:jemalloc"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:malloc"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:native"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:heap"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:off-heap"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:gzipinputstream"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://blog.buoyant.io/2016/06/17/small-memory-jvm-techniques-for-microservice-sidecars/">
    <title>Squeezing blood from a stone: small-memory JVM techniques for microservice sidecars</title>
    <dc:date>2016-06-18T09:46:44+00:00</dc:date>
    <link>https://blog.buoyant.io/2016/06/17/small-memory-jvm-techniques-for-microservice-sidecars/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Reducing service memory usage from 500MB to 105MB:

<blockquote>We found two specific techniques to be the most beneficial: turning off one of the two JIT compilers enabled by default (the “C2” compiler), and using a 32-bit, rather than a 64-bit, JVM.</blockquote>

]]></description>
<dc:subject>32bit jvm java ops memory tuning jit linkerd</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:ade3b2e45f61/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:32bit"/>
	<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:ops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:memory"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tuning"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:jit"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:linkerd"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://github.com/ztellman/dirigiste">
    <title>ztellman/dirigiste</title>
    <dc:date>2016-06-01T11:55:13+00:00</dc:date>
    <link>https://github.com/ztellman/dirigiste</link>
    <dc:creator>jm</dc:creator><description><![CDATA['centrally-planned object and thread pools' for java.

'In the default JVM thread pools, once a thread is created it will only be retired when it hasn't performed a task in the last minute. In practice, this means that there are as many threads as the peak historical number of concurrent tasks handled by the pool, forever. These thread pools are also poorly instrumented, making it difficult to tune their latency or throughput.  Dirigiste provides a fast, richly instrumented version of a java.util.concurrent.ExecutorService, and provides a means to feed that instrumentation into a control mechanism that can grow or shrink the pool as needed. Default implementations that optimize the pool size for thread utilization are provided.  It also provides an object pool mechanism that uses a similar feedback mechanism to resize itself, and is significantly simpler than the Apache Commons object pool implementation.'

Great metric support, too.]]></description>
<dc:subject>async jvm dirigiste java threadpools concurrency utilization capacity executors object-pools object-pooling latency</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:5092c7f0c12e/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:async"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:jvm"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:dirigiste"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:threadpools"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:concurrency"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:utilization"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:capacity"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:executors"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:object-pools"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:object-pooling"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:latency"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://gdstechnology.blog.gov.uk/2015/12/11/using-jemalloc-to-get-to-the-bottom-of-a-memory-leak/">
    <title>Using jemalloc to get to the bottom of an off-heap Java memory leak</title>
    <dc:date>2016-04-14T11:39:20+00:00</dc:date>
    <link>https://gdstechnology.blog.gov.uk/2015/12/11/using-jemalloc-to-get-to-the-bottom-of-a-memory-leak/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Good technique]]></description>
<dc:subject>debugging java jvm memory jemalloc off-heap</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:e8651207606c/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:debugging"/>
	<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:memory"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:jemalloc"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:off-heap"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://github.com/JCTools/JCTools/pull/93">
    <title>Wait and lock free alternatives to LongAdder and AtomicLong by qwwdfsad</title>
    <dc:date>2016-03-14T17:32:46+00:00</dc:date>
    <link>https://github.com/JCTools/JCTools/pull/93</link>
    <dc:creator>jm</dc:creator><description><![CDATA[interesting new lock-free low-level hacking]]></description>
<dc:subject>longadder doug-lea mechanical-sympathy lock-free performance atomic multithreading java jvm</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:28819375e2f4/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:longadder"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:doug-lea"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:mechanical-sympathy"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:lock-free"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:atomic"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:multithreading"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:jvm"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.infoq.com/presentations/apple-netty">
    <title>Netty @Apple: Large Scale Deployment/Connectivity [video]</title>
    <dc:date>2016-01-08T10:04:43+00:00</dc:date>
    <link>http://www.infoq.com/presentations/apple-netty</link>
    <dc:creator>jm</dc:creator><description><![CDATA['Norman Maurer presents how Apple uses Netty for its Java based services and the challenges of doing so, including how they enhanced performance by participating in the Netty open source community. Maurer takes a deep dive into advanced topics like JNI, JVM internals, and others.']]></description>
<dc:subject>apple netty norman-maurer java jvm async talks presentations</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:09aa5e33f478/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:apple"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:netty"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:norman-maurer"/>
	<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:async"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:talks"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:presentations"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://www.voxxed.com/blog/2015/12/importance-tuning-thread-pools/">
    <title>The Importance of Tuning Your Thread Pools</title>
    <dc:date>2016-01-04T10:42:16+00:00</dc:date>
    <link>https://www.voxxed.com/blog/2015/12/importance-tuning-thread-pools/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Excellent blog post on thread pools, backpressure, Little's Law, and other Hystrix-related topics (PS: use Hystrix)]]></description>
<dc:subject>hystrix threadpools concurrency java jvm backpressure littles-law capacity</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:d8e4a0101363/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:hystrix"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:threadpools"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:concurrency"/>
	<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:backpressure"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:littles-law"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:capacity"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://byteman.jboss.org/">
    <title>Byteman</title>
    <dc:date>2015-09-24T10:11:48+00:00</dc:date>
    <link>http://byteman.jboss.org/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>a tool which simplifies tracing and testing of Java programs. Byteman allows you to insert extra Java code into your application, either as it is loaded during JVM startup or even after it has already started running. The injected code is allowed to access any of your data and call any application methods, including where they are private. You can inject code almost anywhere you want and there is no need to prepare the original source code in advance nor do you have to recompile, repackage or redeploy your application. In fact you can remove injected code and reinstall different code while the application continues to execute.  The simplest use of Byteman is to install code which traces what your application is doing. This can be used for monitoring or debugging live deployments as well as for instrumenting code under test so that you can be sure it has operated correctly. By injecting code at very specific locations you can avoid the overheads which often arise when you switch on debug or product trace. Also, you decide what to trace when you run your application rather than when you write it so you don't need 100% hindsight to be able to obtain the information you need.</blockquote>

]]></description>
<dc:subject>tracing java byteman injection jvm ops debugging testing</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:542b80c1b242/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tracing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:byteman"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:injection"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:jvm"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:debugging"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:testing"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://steveloughran.blogspot.co.uk/2015/09/time-on-multi-core-multi-socket-servers.html">
    <title>Time on multi-core, multi-socket servers</title>
    <dc:date>2015-09-18T09:15:02+00:00</dc:date>
    <link>http://steveloughran.blogspot.co.uk/2015/09/time-on-multi-core-multi-socket-servers.html</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Nice update on the state of System.currentTimeMillis() and System.nanoTime() in javaland.  Bottom line: both are non-monotonic nowadays:

<blockquote>The conclusion I've reached is that except for the special case of using nanoTime() in micro benchmarks, you may as well stick to currentTimeMillis() —knowing that it may sporadically jump forwards or backwards. Because if you switched to nanoTime(), you don't get any monotonicity guarantees, it doesn't relate to human time any more —and may be more likely to lead you into writing code which assumes a fast call with consistent, monotonic results.</blockquote>

]]></description>
<dc:subject>java time monotonic sequencing nanotime timers jvm multicore distributed-computing</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:7d7dedf4484e/</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:time"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:monotonic"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:sequencing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:nanotime"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:timers"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:jvm"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:multicore"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:distributed-computing"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://gary-rowe.com/agilestack/2013/07/03/preventing-dependency-chain-attacks-in-maven/">
    <title>Preventing Dependency Chain Attacks in Maven</title>
    <dc:date>2015-08-14T20:15:57+00:00</dc:date>
    <link>http://gary-rowe.com/agilestack/2013/07/03/preventing-dependency-chain-attacks-in-maven/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[using a whitelist of allowed dependency JARs and their SHAs]]></description>
<dc:subject>security whitelisting dependencies coding jar maven java jvm</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:cded21345b09/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:security"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:whitelisting"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:dependencies"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:coding"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:jar"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:maven"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:jvm"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://github.com/aragozin/jvm-tools">
    <title>sjk</title>
    <dc:date>2015-06-25T16:49:38+00:00</dc:date>
    <link>https://github.com/aragozin/jvm-tools</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>a command line tool for JVM diagnostic troubleshooting and profiling.</blockquote>

]]></description>
<dc:subject>java jvm monitoring commandline jmx sjk tools ops</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:8ecc9f104166/</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:monitoring"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:commandline"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:jmx"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:sjk"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tools"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://github.com/electronicarts/orbit/tree/master/async">
    <title>Orbit Async</title>
    <dc:date>2015-06-08T10:26:15+00:00</dc:date>
    <link>https://github.com/electronicarts/orbit/tree/master/async</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>Orbit Async implements async-await methods in the JVM. It allows programmers to write asynchronous code in a sequential fashion. It was developed by BioWare, a division of Electronic Arts.</blockquote>

Open source, BSD-licensed.]]></description>
<dc:subject>async await java jvm bioware coding threading</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:93545dab47e5/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:async"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:await"/>
	<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:bioware"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:coding"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:threading"/>
</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="https://github.com/caplogic/mappedbus">
    <title>MappedBus</title>
    <dc:date>2015-05-11T14:33:27+00:00</dc:date>
    <link>https://github.com/caplogic/mappedbus</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>a Java based low latency, high throughput message bus, built on top of a memory mapped file; inspired by Java Chronicle with the main difference that it's designed to efficiently support multiple writers – enabling use cases where the order of messages produced by multiple processes are important.  MappedBus can be also described as an efficient IPC mechanism which enable several Java programs to communicate by exchanging messages.</blockquote>

]]></description>
<dc:subject>ipc java jvm mappedbus low-latency mmap message-bus data-structures queue message-passing</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:2fd14b0d1310/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ipc"/>
	<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:mappedbus"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:low-latency"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:mmap"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:message-bus"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:data-structures"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:queue"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:message-passing"/>
</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://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="https://blogs.oracle.com/dave/entry/biased_locking_in_hotspot">
    <title>Biased Locking in HotSpot (David Dice's Weblog)</title>
    <dc:date>2015-03-09T23:35:31+00:00</dc:date>
    <link>https://blogs.oracle.com/dave/entry/biased_locking_in_hotspot</link>
    <dc:creator>jm</dc:creator><description><![CDATA[This is pretty nuts. If biased locking in the HotSpot JVM is causing performance issues, it can be turned off:

<blockquote>You can avoid biased locking on a per-object basis by calling System.identityHashCode(o). If the object is already biased, assigning an identity hashCode will result in revocation, otherwise, the assignment of a hashCode() will make the object ineligible for subsequent biased locking. </blockquote>

]]></description>
<dc:subject>hashcode jvm java biased-locking locking mutex synchronization locks performance</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:f50fdd3cde18/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:hashcode"/>
	<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:biased-locking"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:locking"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:mutex"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:synchronization"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:locks"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
</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="https://sysdigcloud.com/gain-insights-jvms-sysdig-clouds-jmx-metrics/">
    <title>Sysdig Cloud’s JMX Metrics</title>
    <dc:date>2015-02-19T23:38:03+00:00</dc:date>
    <link>https://sysdigcloud.com/gain-insights-jvms-sysdig-clouds-jmx-metrics/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>Sysdig Cloud users have the ability to view and analyze Java Management Extensions (JMX) metrics out of the box with no additional configuration or setup required.</blockquote>

]]></description>
<dc:subject>sysdig jmx java jvm</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:4c2a773bfd9d/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:sysdig"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:jmx"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:jvm"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://openjdk.java.net/projects/code-tools/jol/">
    <title>OpenJDK: jol</title>
    <dc:date>2015-02-16T11:17:41+00:00</dc:date>
    <link>http://openjdk.java.net/projects/code-tools/jol/</link>
    <dc:creator>jm</dc:creator><description><![CDATA['JOL (Java Object Layout) is the tiny toolbox to analyze object layout schemes in JVMs. These tools are using Unsafe, JVMTI, and Serviceability Agent (SA) heavily to decoder the actual object layout, footprint, and references. This makes JOL much more accurate than other tools relying on heap dumps, specification assumptions, etc.'

Recommended by Nitsan Wakart, looks pretty useful for JVM devs]]></description>
<dc:subject>java jvm tools scala memory estimation ram object-layout debugging via:nitsan</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:e605db4598c2/</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:tools"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:scala"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:memory"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:estimation"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ram"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:object-layout"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:debugging"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:via:nitsan"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://tobert.github.io/tldr/cassandra-java-huge-pages.html">
    <title>TL;DR: Cassandra Java Huge Pages</title>
    <dc:date>2015-02-03T22:09:12+00:00</dc:date>
    <link>http://tobert.github.io/tldr/cassandra-java-huge-pages.html</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Al Tobey does some trial runs of -XX:+AlwaysPreTouch and -XX:+UseHugePages]]></description>
<dc:subject>jvm performance tuning huge-pages vm ops cassandra java</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:d448b5d53e34/</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:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tuning"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:huge-pages"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:vm"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cassandra"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://speakerdeck.com/elasticsearch/maintaining-performance-in-distributed-systems">
    <title>Maintaining performance in distributed systems [slides]</title>
    <dc:date>2015-01-25T23:43:59+00:00</dc:date>
    <link>https://speakerdeck.com/elasticsearch/maintaining-performance-in-distributed-systems</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Great slide deck from Elasticsearch on JVM/dist-sys performance optimization]]></description>
<dc:subject>performance elasticsearch java jvm ops tuning</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:99d8451bc962/</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:elasticsearch"/>
	<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:ops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tuning"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://rdiyewar-tech.blogspot.de/2013/02/outofmemoryerror-because-of-default.html">
    <title>How to reduce the JVM thread stack size</title>
    <dc:date>2015-01-25T23:32:11+00:00</dc:date>
    <link>http://rdiyewar-tech.blogspot.de/2013/02/outofmemoryerror-because-of-default.html</link>
    <dc:creator>jm</dc:creator><description><![CDATA["-Xss" switch]]></description>
<dc:subject>jvm java threads ops stack-size memory</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:159a50a87d53/</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:threads"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:stack-size"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:memory"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://github.com/JCTools/JCTools">
    <title>JCTools</title>
    <dc:date>2015-01-25T08:50:22+00:00</dc:date>
    <link>https://github.com/JCTools/JCTools</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>Java Concurrency Tools for the JVM. This project aims to offer some concurrent data structures currently missing from the JDK:

Bounded lock free queues
SPSC/MPSC/SPMC/MPMC variations for concurrent queues
Alternative interfaces for queues (experimental)
Offheap concurrent ring buffer for ITC/IPC purposes (experimental)
Executor (planned)</blockquote>

]]></description>
<dc:subject>concurrency lock-free data-structures queues jvm java</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:48920e47e7f3/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:concurrency"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:lock-free"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:data-structures"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:queues"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:jvm"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://tech.stolsvik.com/2010/01/linux-java-thread-priorities-workaround.html">
    <title>Hack workaround to get JVM thread priorities working on Linux</title>
    <dc:date>2015-01-05T17:56:26+00:00</dc:date>
    <link>http://tech.stolsvik.com/2010/01/linux-java-thread-priorities-workaround.html</link>
    <dc:creator>jm</dc:creator><description><![CDATA[As used in Cassandra ( http://grokbase.com/t/hbase/dev/13bf9kezes/about-xx-threadprioritypolicy-42 )!

<blockquote>if you just set the "ThreadPriorityPolicy" to something else than the legal values 0 or 1, [...] a slight logic bug in Sun's JVM code kicks in, and thus sets the policy to be as if running with root - thus you get exactly what one desire. The operating system, Linux, won't allow priorities to be heightened above "Normal" (negative nice value), and thus just ignores those requests (setting it to normal instead, nice value 0) - but it lets through the requests to set it lower (setting the nice value to some positive value).</blockquote>

]]></description>
<dc:subject>cassandra thread-priorities threads java jvm linux nice hacks</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:abed46e6d700/</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:thread-priorities"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:threads"/>
	<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:linux"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:nice"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:hacks"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.nurkiewicz.com/2014/11/executorservice-10-tips-and-tricks.html">
    <title>ExecutorService - 10 tips and tricks</title>
    <dc:date>2014-11-25T12:28:16+00:00</dc:date>
    <link>http://www.nurkiewicz.com/2014/11/executorservice-10-tips-and-tricks.html</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Excellent advice from Tomasz Nurkiewicz' blog for anyone using java.util.concurrent.ExecutorService regularly.  The whole blog is full of great posts btw]]></description>
<dc:subject>concurrency java jvm threading threads executors coding</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:35ca20533835/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:concurrency"/>
	<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:threading"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:threads"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:executors"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:coding"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://stackoverflow.com/questions/219585/setting-multiple-jars-in-java-classpath/219801#219801">
    <title>the JVM now supports globbing in classpath specifications</title>
    <dc:date>2014-11-19T11:51:12+00:00</dc:date>
    <link>http://stackoverflow.com/questions/219585/setting-multiple-jars-in-java-classpath/219801#219801</link>
    <dc:creator>jm</dc:creator><description><![CDATA[hooray, no more uberjars or monster commandlines!]]></description>
<dc:subject>java jvm globbing classpath uberjars jars deployment</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:985e11ba3303/</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:globbing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:classpath"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:uberjars"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:jars"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:deployment"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://groups.google.com/forum/#!msg/project-voldemort/Y52UyHQ8tBA/9Ei79_RvS3EJ">
    <title>Tehuti</title>
    <dc:date>2014-10-08T09:45:50+00:00</dc:date>
    <link>https://groups.google.com/forum/#!msg/project-voldemort/Y52UyHQ8tBA/9Ei79_RvS3EJ</link>
    <dc:creator>jm</dc:creator><description><![CDATA[An embryonic metrics library for Java/Scala from Felix GV at LinkedIn, extracted from Kafka's metric implementation and in the new Voldemort release.  It fixes the major known problems with the Meter/Timer implementations in Coda-Hale/Dropwizard/Yammer Metrics.

'Regarding Tehuti: it has been extracted from Kafka's metric implementation. The code was originally written by Jay Kreps, and then maintained improved by some Kafka and Voldemort devs, so it definitely is not the work of just one person. It is in my repo at the moment but I'd like to put it in a more generally available (git and maven) repo in the future. I just haven't had the time yet...

As for comparing with CodaHale/Yammer, there were a few concerns with it, but the main one was that we didn't like the exponentially decaying histogram implementation. While that implementation is very appealing in terms of (low) memory usage, it has several misleading characteristics (a lack of incoming data points makes old measurements linger longer than they should, and there's also a fairly high possiblity of losing interesting outlier data points). This makes the exp decaying implementation robust in high throughput fairly constant workloads, but unreliable in sparse or spiky workloads. The Tehuti implementation provides semantics that we find easier to reason with and with a small code footprint (which we consider a plus in terms of maintainability). Of course, it is still a fairly young project, so it could be improved further.'

More background at the kafka-dev thread: http://mail-archives.apache.org/mod_mbox/kafka-dev/201402.mbox/%3C131A7649-ED57-45CB-B4D6-F34063267664@linkedin.com%3E]]></description>
<dc:subject>kafka metrics dropwizard java scala jvm timers ewma statistics measurement latency sampling tehuti voldemort linkedin jay-kreps</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:b56664c1a098/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:kafka"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:metrics"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:dropwizard"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:scala"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:jvm"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:timers"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ewma"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:statistics"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:measurement"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:latency"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:sampling"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tehuti"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:voldemort"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:linkedin"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:jay-kreps"/>
</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://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="https://github.com/OpenHFT/hftc">
    <title>OpenHFT/hftc · GitHub</title>
    <dc:date>2014-08-05T20:50:09+00:00</dc:date>
    <link>https://github.com/OpenHFT/hftc</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>This is a yet another Java collections library of primitive specializations. Java 6+. Apache 2.0 license. Currently only hash sets and hash maps are implemented.</blockquote>

]]></description>
<dc:subject>openhft performance java jvm collections asl hashsets hashmaps data-structures</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:3918981e9d4d/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:openhft"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
	<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:collections"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:asl"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:hashsets"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:hashmaps"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:data-structures"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://github.com/mariusaeriksen/heapster">
    <title>mariusaeriksen/heapster</title>
    <dc:date>2014-07-24T09:05:58+00:00</dc:date>
    <link>https://github.com/mariusaeriksen/heapster</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>Heapster provides an agent library to do heap profiling for JVM processes with output compatible with Google perftools. The goal of Heapster is to be able to do meaningful (sampled) heap profiling in a production setting.</blockquote>

Used by Twitter in production, apparently.]]></description>
<dc:subject>heap monitoring memory jvm java performance</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:5a7c8a71eb82/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:heap"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:monitoring"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:memory"/>
	<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: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="https://github.com/RuedigerMoeller/fast-serialization/wiki/Structs">
    <title>Structs</title>
    <dc:date>2014-05-16T08:54:53+00:00</dc:date>
    <link>https://github.com/RuedigerMoeller/fast-serialization/wiki/Structs</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>storage of structured data in a continuous block of memory. The memory can be allocated on the heap using a byte[] array or can be allocated off the java heap in native memory. [...] Use cases: store/cache huge amounts of data records without impact on GC duration; high performance data transfer in a cluster or in between processes</blockquote>

handy OSS from Ruediger Moeller]]></description>
<dc:subject>structs java jvm memory off-heap storage reference</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:714aaf030806/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:structs"/>
	<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:memory"/>
	<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:reference"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://shipilev.net/blog/2014/exceptional-performance/">
    <title>Exceptional Performance</title>
    <dc:date>2014-05-14T13:09:42+00:00</dc:date>
    <link>http://shipilev.net/blog/2014/exceptional-performance/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Good benchmark data on the performance of JVM exceptions
]]></description>
<dc:subject>java jvm exceptions benchmarking performance optimization coding</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:7d2c8fedbc9e/</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:exceptions"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:benchmarking"/>
	<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:coding"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://shipilev.net/blog/2014/nanotrusting-nanotime/">
    <title>Alexey Shipilev on Java's System.nanoTime()</title>
    <dc:date>2014-05-07T14:06:27+00:00</dc:date>
    <link>http://shipilev.net/blog/2014/nanotrusting-nanotime/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>System.nanoTime is as bad as String.intern now: you can use it, but use it wisely. The latency, granularity, and scalability effects introduced by timers may and will affect your measurements if done without proper rigor. This is one of the many reasons why System.nanoTime should be abstracted from the users by benchmarking frameworks, monitoring tools, profilers, and other tools written by people who have time to track if the underlying platform is capable of doing what we want it to do.

In some cases, there is no good solution to the problem at hand. Some things are not directly measurable. Some things are measurable with unpractical overheads. Internalize that fact, weep a little, and move on to building the indirect experiments. This is not the Wonderland, Alice. Understanding how the Universe works often needs side routes to explore.

In all seriousness, we should be happy our $1000 hardware can measure 30 nanosecond intervals pretty reliably. This is roughly the time needed for the Internet packets originating from my home router to leave my apartment. What else do you want, you spoiled brats?</blockquote>

]]></description>
<dc:subject>benchmarking jdk java measurement nanoseconds nsecs nanotime jvm alexey-shipilev jmh</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:6068e09f6496/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:benchmarking"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:jdk"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:measurement"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:nanoseconds"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:nsecs"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:nanotime"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:jvm"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:alexey-shipilev"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:jmh"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://comcast.github.io/sirius/overview.html">
    <title>Sirius by Comcast</title>
    <dc:date>2014-04-24T09:16:58+00:00</dc:date>
    <link>http://comcast.github.io/sirius/overview.html</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>At Comcast, our applications need convenient, low-latency access to important reference datasets. For example, our XfinityTV websites and apps need to use entertainment-related data to serve almost every API or web request to our datacenters: information like what year Casablanca was released, or how many episodes were in Season 7 of Seinfeld, or when the next episode of the Voice will be airing (and on which channel!).

We traditionally managed this information with a combination of relational databases and RESTful web services but yearned for something simpler than the ORM, HTTP client, and cache management code our developers dealt with on a daily basis. As main memory sizes on commodity servers continued to grow, however, we asked ourselves: How can we keep this reference data entirely in RAM, while ensuring it gets updated as needed and is easily accessible to application developers?

The Sirius distributed system library is our answer to that question, and we're happy to announce that we've made it available as an open source project. Sirius is written in Scala and uses the Akka actor system under the covers, but is easily usable by any JVM-based language.
</blockquote>

Also includes a Paxos implementation with "fast follower" read-only slave replication. ASL2-licensed open source.

The only thing I can spot to be worried about is speed of startup; they note that apps need to replay a log at startup to rebuild state, which can be slow if unoptimized in my experience. 

Update: in a twitter conversation at https://twitter.com/jon_moore/status/459363751893139456 , Jon Moore indicated they haven't had problems with this even with 'datasets consuming 10-20GB of heap', and have 'benchmarked a 5-node Sirius ingest cluster up to 1k updates/sec write throughput.'  That's pretty solid!]]></description>
<dc:subject>open-source comcast paxos replication read-only datastores storage memory memcached redis sirius scala akka jvm libraries</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:54736b003116/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:open-source"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:comcast"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:paxos"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:replication"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:read-only"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:datastores"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:storage"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:memory"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:memcached"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:redis"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:sirius"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:scala"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:akka"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:jvm"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:libraries"/>
</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://java-is-the-new-c.blogspot.ie/2013/07/impact-of-large-primitive-arrays-blobs.html">
    <title>Impact of large primitive arrays (BLOBS) on JVM Garbage Collection</title>
    <dc:date>2014-03-19T12:12:51+00:00</dc:date>
    <link>http://java-is-the-new-c.blogspot.ie/2013/07/impact-of-large-primitive-arrays-blobs.html</link>
    <dc:creator>jm</dc:creator><description><![CDATA[some nice graphs and data on CMS performance, with/without -XX:ParGCCardsPerStrideChunk]]></description>
<dc:subject>cms java jvm performance optimization tuning off-heap-storage memory</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:026572f118c8/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cms"/>
	<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:optimization"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tuning"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:off-heap-storage"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:memory"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://highscalability.com/blog/2014/2/5/littles-law-scalability-and-fault-tolerance-the-os-is-your-b.html">
    <title>Little’s Law, Scalability and Fault Tolerance: The OS is your bottleneck. What you can do?</title>
    <dc:date>2014-02-05T17:35:26+00:00</dc:date>
    <link>http://highscalability.com/blog/2014/2/5/littles-law-scalability-and-fault-tolerance-the-os-is-your-b.html</link>
    <dc:creator>jm</dc:creator><description><![CDATA[good blog post on Little's Law, plugging quasar, pulsar, and comsat, 3 new open-source libs offering Erlang-like lightweight threads on the JVM]]></description>
<dc:subject>jvm java quasar pulsar comsat littles-law scalability async erlang</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:bb3e77510a90/</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:quasar"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:pulsar"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:comsat"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:littles-law"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:scalability"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:async"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:erlang"/>
</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="https://groups.google.com/forum/#!msg/mechanical-sympathy/4EDCX0F_3ow/FxJ9nOvZqYUJ">
    <title>Safe cross-thread publication of a non-final variable in the JVM</title>
    <dc:date>2014-01-20T10:28:01+00:00</dc:date>
    <link>https://groups.google.com/forum/#!msg/mechanical-sympathy/4EDCX0F_3ow/FxJ9nOvZqYUJ</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Scary, but potentially useful in future, so worth bookmarking.  By carefully orchestrating memory accesses using volatile and non-volatile fields, one can ensure that a non-volatile, non-synchronized field's value is safely visible to all threads after that point due to JMM barrier semantics.

<blockquote>
What you are looking to do is enforce a barrier between your initializing stores and your publishing store, without that publishing store being made to a volatile field. This can be done by using volatile access to other fields in the publication path, without using those variables in the later access paths to the published object.</blockquote>

]]></description>
<dc:subject>volatile atomic java jvm gil-tene synchronization performance threading jmm memory-barriers</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:a75f0eb82bd3/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:volatile"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:atomic"/>
	<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:gil-tene"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:synchronization"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:threading"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:jmm"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:memory-barriers"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://jpbempel.blogspot.ie/2013/10/hardware-performance-counters-atomic-vs.html">
    <title>examining the Hardware Performance Counters</title>
    <dc:date>2013-12-30T21:29:25+00:00</dc:date>
    <link>http://jpbempel.blogspot.ie/2013/10/hardware-performance-counters-atomic-vs.html</link>
    <dc:creator>jm</dc:creator><description><![CDATA[using the overseer library and libpfm, it's possible for a JVM app to record metrics about L2/DRAM cache hit rates and latency]]></description>
<dc:subject>metrics hpc libpfm java jvm via:normanmaurer l2 dram llc cpu</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:b7f225c67024/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:metrics"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:hpc"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:libpfm"/>
	<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:via:normanmaurer"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:l2"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:dram"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:llc"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cpu"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.youtube.com/watch?v=Yg6_ulhwLw0&amp;feature=youtu.be">
    <title>Twitter tech talk video: &quot;Profiling Java In Production&quot;</title>
    <dc:date>2013-12-09T12:44:56+00:00</dc:date>
    <link>http://www.youtube.com/watch?v=Yg6_ulhwLw0&amp;feature=youtu.be</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>In this talk Kaushik Srenevasan describes a new, low overhead, full-stack tool (based on the Linux perf profiler and infrastructure built into the Hotspot JVM) we've built at Twitter to solve the problem of dynamically profiling and tracing the behavior of applications (including managed runtimes) in production.</blockquote>

Looks very interesting.  Haven't watched it yet though]]></description>
<dc:subject>twitter tech-talks video presentations java jvm profiling testing monitoring service-metrics performance production hotspot perf</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:ee6e08004f6c/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:twitter"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tech-talks"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:video"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:presentations"/>
	<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:profiling"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:testing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:monitoring"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:service-metrics"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:production"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:hotspot"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:perf"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://github.com/mgodave/barge">
    <title>mgodave/barge</title>
    <dc:date>2013-11-16T21:36:48+00:00</dc:date>
    <link>https://github.com/mgodave/barge</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Looks very alpha, but one to watch.

<blockquote>A JVM Implementation of the Raft Consensus Protocol
</blockquote>

]]></description>
<dc:subject>via:sbtourist raft jvm java consensus distributed-computing</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:564c92229ffb/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:via:sbtourist"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:raft"/>
	<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:consensus"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:distributed-computing"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://spring.io/blog/2013/11/12/it-can-t-just-be-big-data-it-has-to-be-fast-data-reactor-1-0-goes-ga">
    <title>Reactor hits GA</title>
    <dc:date>2013-11-12T13:39:16+00:00</dc:date>
    <link>https://spring.io/blog/2013/11/12/it-can-t-just-be-big-data-it-has-to-be-fast-data-reactor-1-0-goes-ga</link>
    <dc:creator>jm</dc:creator><description><![CDATA['It can't just be Big Data, it has to be Fast Data: Reactor 1.0 goes GA': 

<blockquote>
Reactor provides the necessary abstractions to build high-throughput, low-latency--what we now call "fast data"--applications that absolutely must work with thousands, tens of thousands, or even millions of concurrent requests per second.  Modern JVM applications must be built on a solid foundation of asynchronous and reactive components that efficiently manage the execution of a very large number of tasks on a very small number of system threads. Reactor is specifically designed to help you build these kinds of applications without getting in your way or forcing you to work within an opinionated pattern.
</blockquote>

Featuring the LMAX Disruptor ringbuffer, the JavaChronicle fast persistent message-passing queue, Groovy closures, and Netty 4.0.  This looks very handy indeed....]]></description>
<dc:subject>disruptor reactive-programming reactor async libraries java jvm frameworks spring netty fast-data</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:40b56ea65db9/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:disruptor"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:reactive-programming"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:reactor"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:async"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:libraries"/>
	<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:frameworks"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:spring"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:netty"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:fast-data"/>
</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://hg.openjdk.java.net/lambda/lambda/jdk/file/b55f1ce224fb/src/share/classes/java/util/stream/SpinedBuffer.java">
    <title>java.util.stream.SpinedBuffer</title>
    <dc:date>2013-10-25T10:46:56+00:00</dc:date>
    <link>http://hg.openjdk.java.net/lambda/lambda/jdk/file/b55f1ce224fb/src/share/classes/java/util/stream/SpinedBuffer.java</link>
    <dc:creator>jm</dc:creator><description><![CDATA[interesting new data structure, pending addition in Java 8. Basically an array of arrays which presents the API of a single List.

<blockquote>An ordered collection of elements.  Elements can be added, but not removed. Goes through a building phase, during which elements can be added, and a traversal phase, during which elements can be traversed in order but no further modifications are possible.</blockquote>

]]></description>
<dc:subject>spinedbuffer data-structures algorithms java jdk jvm java-8 arrays lists</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:79ed0824f439/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:spinedbuffer"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:data-structures"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:algorithms"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:jdk"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:jvm"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java-8"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:arrays"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:lists"/>
</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://psy-lob-saw.blogspot.ie/2013/10/spsc-revisited-part-iii-fastflow-sparse.html">
    <title>SPSC revisited part III - FastFlow + Sparse Data</title>
    <dc:date>2013-10-07T09:51:25+00:00</dc:date>
    <link>http://psy-lob-saw.blogspot.ie/2013/10/spsc-revisited-part-iii-fastflow-sparse.html</link>
    <dc:creator>jm</dc:creator><description><![CDATA[holy moly.  This is some heavily-optimized mechanical-sympathy Java code.  By using a sparse data structure, cache-aligned fields, and wait-free low-level CAS concurrency primitives via sun.misc.Unsafe, a single-producer/single-consumer queue implementation goes pretty damn fast compared to the current state of the art]]></description>
<dc:subject>nitsanw optimization concurrency java jvm cas spsc queues data-structures algorithms</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:76f60b5fe219/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:nitsanw"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:optimization"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:concurrency"/>
	<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:cas"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:spsc"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:queues"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:data-structures"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:algorithms"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://speakerdeck.com/headius/down-the-rabbit-hole">
    <title>Down the Rabbit Hole</title>
    <dc:date>2013-10-01T09:30:44+00:00</dc:date>
    <link>https://speakerdeck.com/headius/down-the-rabbit-hole</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>An adventure that takes you through several popular Java language features and shows how they compile to bytecode and eventually JIT to assembly code.</blockquote>

]]></description>
<dc:subject>charles-nutter java jvm compilation reversing talks slides</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:bf667f5b0e93/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:charles-nutter"/>
	<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:compilation"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:reversing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:talks"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:slides"/>
</rdf:Bag></taxo:topics>
</item>
</rdf:RDF>