こんにちは。アプリケーション基盤チームの横田です。 Javaの謎のパフォーマンス劣化にまつわる調査をしていたのですが、1ヶ月の苦労の末に原因がわかりましたので、報告させていただきます！ 公開後に頂いたはてなブックマークでのご指摘・社内でのタイポ・読みにくいなどの指摘を受けてたので、謹んで修正させいただきます。 修正した内容につきましては、記事の最後を参照してください。 忙しい人のためのまとめ jdk-7u4以降のjdk-7 *1 でJavaのパフォーマンスが劣化する謎の現象 CodeCacheの容量限界に近づくとJITコンパイラを停止してコンパイルしたコードを捨てる機能が原因だった 起動オプションで回避できるので、長期運用するときは -XX:-UseCodeCacheFlushing, -XX:ReservedCodeCacheSize=128m をつける 上のオプションを設定した時に、C
こんにちは、三苫です。 これは TECHSCORE Advent Calendar 2015 の11日目の記事です。 Arrays#stream(boolean[]) が無い！！ ごくまれにたまに、 boolean[] を Stream<Boolean> にしたいことってありますよね？ ところが Arrays#stream() には boolean[] を引数に受け取ってくれるシグニチャがありません。 というわけで、あるときシナジーマーケティングのエンジニア数人でどんな書き方で変換するのがいい感じか案を出して盛り上がったのその顛末を紹介します。 自分たちでかっこ良く実装しよう 案として出てきたのは以下の4案です。 案1「素直に Stream.Builder で作る」 もっとも素直で正攻法です。 Stream の作成時に全要素の boolean → Boolean のボクシングコストをすべて
はじめに 最近、フロントエンドのライブラリ乱立問題について盛り上がってました。 自分はnobkzさんの以下の文に全てがまとまっていると思います。 僕の最初の違和感は、「技術的な流行り」に乗ることに何の価値があるのだろうか?ということである。もちろん、最新のツールやフレームワークはより何かが良くなってるかもしれない。しかし、 それをあなたのプロジェクトで採用するには何の価値があるだろうか? 「最近のフロントエンドへの違和感 - nobkzのブログ」より 裏を返せば、新しいライブラリの内容、特に「どのような問題を解決するためにこのライブラリが生まれたのか」という思想を把握しておくことは重要だと言えます。 つまりは、 "How?(ライブラリの使い方)" よりも "Why?(なぜそのライブラリが必要なのか)" を学んでおこう ということです。この記事では どのような既存の問題・要求を どう解決して
一か月ほど前に New York Times で紹介されていた記事。 The Pi Machine - NYTimes.com ここで紹介されているのは、なんと驚くべきことに、2つのボールをぶつけるだけで円周率（3.1415...）の値がわかる、という内容。 これだけだと、全然ピンとこないと思うので、もう少し詳しく説明すると、次のようなことが書かれている。 ↓2つのボールを、下の図ように壁と床のある空間に置く。 ↓その後、壁から遠い方のボールを、他方に向かって転がす。 後は、ボールが衝突する回数をカウントするだけで、円周率がわかるらしい。 これでも、なんだかよくわからない。 まず2つのボールが同じ質量である場合を考えてみよう。 まず、手前のボールが他方のボールにぶつかる（これが1回め）。 続いて、ぶつかったボールが移動して壁にぶつかる（これが2回め）。 壁にぶつかったボールが跳ね返ってきて
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く