Mavenで実行しているTestに割り当てるヒープを増やす方法
Maven Surefire Pluginを使う。
https://maven.apache.org/surefire/maven-surefire-plugin/
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<configuration>
<argLine>-Xmx1024m -XX:MaxPermSize=256m</argLine>
</configuration>
</plugin>ぐぐると、MAVEN_OPTSに書けばいい とか、 Jenkinsの場合はGlobal MAVEN_OPTSに書けばいい とか出てくるんだけど、
これは、MavenのJavaプロセスに割り当てるメモリ。
その中で実行されるテスト用のメモリは別に確保される。
実際、テストコード内で以下のように割り当てメモリを書き出してみると
int mb = 1024 * 1024;
Runtime runtime = Runtime.getRuntime();
System.out.println("Max Memory:" + runtime.maxMemory() / mb);MAVEN_OPTSに何を書いても増えないし減らない。
Chrome Tech Talk Night
events.withgoogle.com
Google さんで行われた、Chrome Tech Talk Night に参加してきました。
弊社の新人研修依頼、10年以上ぶりに森タワーのオフィスに入ったなぁ とか しょうもないことを思いながら。
そもそも私、フロントエンジニアではないので、正直細かいところはよくわからんというか的はずれな理解だった感も否めないのですが…
発表する人、発表する人、
くっ ここはそういう世界か…！
と。
テクノロジー会社としてのあるべき姿をまざまざと見せつけられた気がしました。
なので忘れないようにブログ。
"Fiber" で 100万スレッドが実行可能に！？ - Project Valhalla とProject Loom : JavaDayTokyo 2018 参加レポート2 #JavaDayTokyo
Project XXX系の話について、Project ValhallaとProject Loomについて聞きました。
どちらも講演はDavid Buckさん*1。
残念ながら、どちらもJava11には入らないので、LTSのリリースサイクルを考えるとまともにサービスで使えるのは早くて2021年…
とはいえ、どちらもとても夢のある話でした。
Project Valhalla
Value Types (値型）
class Point { int x; int y; }
のような、プリミティブ型をフィールドとして持つクラスがある時に
Point[] points;
配列を作ると、各Pointインスタンス毎にヘッダを持ってしまい、大きなメモリのオーバーヘッドが発生します。
メモリの最適化だけ考えると
int[] xList; int[] yList;
とプリミティブ変数の配列を宣言するのが最も良いのですが、これではせっかくのオブジェクト指向が台無し。
そこで、「例えば*2」
value class Point { int x; int y; }
このようにクラス宣言した際に、さも intの配列が2つあるかのようなメモリ確保がされる… というのが概要です。
これによって、省メモリ化に加えて、参照の高速化も図ることができるようになります。
What is Project #Valhalla and what it will bring to your #Java development experience?https://t.co/k8KMxOj0ya pic.twitter.com/V5G1fpvn84
— Java (@java) 2017年11月12日
ここまでは昨年のJavaDayTokyoでも既に紹介されていました。
Generic Specialization (ジェネリックの特殊化）
上記を実現する過程で、このようなことができる様になる… と紹介されました。
ArrayList<int> xList;
要はプリミティブ型がほとんど普通のオブジェクトのように使えると。
さらに、intStreamのような（普通のstreamと別にメソッドを用意しなくてはならないような）「ダサい」対応も不要になるとのことです。
とは言えいろいろ悩んでるらしい
とは言え、この「ジェネリックの特殊化」をいざ実装しようとすると悩ましい課題が多いらしく… まだまだ実用化には時間がかかりそうでした。
実際の所、どのくらい使えるんだろう
現実的な利用シーンを考えると、フィールドにプリミティブしか持たないクラスというのはあんまりない気も。
せめて、StringやLocalDate系が混ざっていてもうまいこと扱っていただけるようになると良さそうなのですが。
Project Loom
こちらがタイトルの、”100万スレッド”です。
現在のJVMでは、JVM上のスレッドは、OSが管理するスレッドとマッピングされています。それぞれのスレッドは、用途が異なるかもしれません。あるスレッドは複雑な暗号化に使われるかもしれないし、またあるスレッドは単に変数を一つ書き換えるだけの簡単な処理に使われるかもしれません。
しかしながらOSは、アプリケーションのコードを知らないため、各スレッドの用途もわかりません。そのため、どのスレッドも一律、「何にでも使えるスレッド」を用意することになります。
ここで、「Fiber」という考え方が登場します。Fiberは、OSではなく、Javaのruntimeやユーザコードによって支配されるスレッド。アプリケーションはスレッドの用途を知っているため、無駄のないスレッドを効率的に作ることが可能です。その結果、OS管理のスレッドに比べてなんと1000倍ほど数のスレッドが作れるようになるとのこと。
それだけOSが作るスレッドには「無駄」があるそうです。
ブロッキングと非同期
ちょうど一年前のJavaDayTokyoで聞いた話ですが、
taichiw.hatenablog.com
ブロッキングな処理はスケールしにくい、という問題点があります。
その対策として、非同期（ノンブロッキング）に処理を制御する、という方法があるものの、プログラミングやデバッギングが難しい、という問題があります。
この双方の問題を解決するのがFiber.
スレッドモデル（＝ブロッキングな処理）であるため取扱が簡単であるにもかかわらず、スケーラビリティに優れるという夢のようなお話です。
言ってることが未来
Fiberはスレッドなので、「どんな処理が」「どこまで進んだか」が管理されています。
他方、JVM上で管理されているオブジェクトなので、Serializeが可能とのこと。
その結果何ができるようになるかと言うと…
と言ったことができるようになるとのこと。
… よくわかりません。
まだ検討段階
実際の所、まだまだ開発が始まったばかりでCommitもないとか。
早くて今年中にアーリーアクセスが出る…… かも。
とのことでした。
しかしとっても夢のある話。実現が楽しみです。
Java11について : JavaDayTokyo 2018 参加レポート1 #JavaDayTokyo
今年もJavaDayTokyoに参加させていただきました。
今年の自分なりのテーマは、以下についての情報収集でした。
- 半年後にリリースされるLTSバージョンであるJava11の新機能
- その他今後追加される機能について
- 特に、一昨年くらいから聞いているProject Valhalla。結構な数のコレクションをゴリゴリ処理するのが最近の自分のお仕事の大事なところなので、どうなったか興味アリ
このエントリでは主にJava 11についてまとめます。
Java 10とJava 11 の差
Java 10 からJava 11への追加機能として、現在8件のJPEが予定されているそうです。
http://openjdk.java.net/projects/jdk/11/
この内、コードの書き方に影響がありそうな、文法面での変更は、Project Amberの一つでもあるこれだけかなぁ…と。
JEP 323: Local-Variable Syntax for Lambda Parameters
ということで、Java8 → Java11の差は雑に言うと、
Project Jigsaw + "var"
と言っていいかなぁ… という気がしました。
櫻庭 祐一 さんのセッション、「Java SE 10、そしてJava SE 11への移行ガイド」でも、8つのチェックポイントが紹介されていましたが、ハマりどころになるのは概ねJigsaw絡みと感じました。
Ask the Experts! でもそのような回答だったようです。
Q.Java8からOpenJDK11に行こうとしてる、注意点ある？
— Takeo Hashimoto (@sempreff) 2018年5月17日
A.リコンパイルする前にそのまま動かす、エラー直す、コンパイルする、エラー直す、でテストする。非互換性が一番大きいのは 8-9 なので、そこを乗り越えれば多分いける。#JavaDayTokyo
11 の次の LTS バージョンは 17 !
Java 11の次のLTSバージョンは、2021年9月にリリースされるJava17とのこと。
私、1年半に一回LTSが出るものだと思っていたんですが、3年後なんですね。オリンピック終わっちゃってるのかぁ…
Mission Control と Flight RecorderがJDK11からオープンソースに
これまで有償ツールだったMission ControlとFlight Recorderが、JDK11から無償で使えるようになるとのこと。
基調講演内でデモがあったのですが、パフォーマンスの問題を見つけるのにずいぶん使えそうに見えました。
気になる…！
チームビルディングのために性格診断を使ってみたい
チームビルディングのために性格診断を使ってみたい …と思っています。
背景
今、一緒に開発をしているチームのコミュニケーションを、より円滑にしたいと考えています。
各メンバーが、もっと他のチームメンバーの、「良いところ」や「自分との違い（どっちが良い悪いではない）」を発見することによって、より良いコミュニケーションと、そこから生まれるチームワークが実現できると考えています。
ジョハリの窓
私が、チーム内のコミュニケーションがより円滑になると考えている根拠が、ジョハリの窓です。
ジョハリの窓 - Wikipedia
IとIIの間の敷居、IとIIIの間の敷居を移動させて「公開された自己」の領域が広がることでコミュニケーションが円滑になる、という理論。
このうち、IとIIIの間の敷居を移動させ、Iの領域を広げるために、性格診断が使えそうというアイディアです。
きっかけ
一番始めにこの手のことを考えたのは一昨年のXPまつり。
「ピンポンゲームを使ったチームビルディング」の話を新井さんから聞いたときでした。
残念ながら記録を残していなかったので記憶ベースの話になりますが…
- ゲーム内で、自身の自己開示を進める。例えば
- 「自分はプレッシャーに弱い」
- チームの勝利は大事だが、自身の記録も大事にしたい
- ゲーム内でチームメンバーの性格を把握したことが、業務内でのコミュニケーションに生きる
といった内容だったと思います。
これすごく良い！試そう！と思った記憶があります。（思っただけで試さなかったのですが…）
そして1年半ほど経過した先日、「ふりかえりワークショップ*1」に参加した際、今度は、
性格診断を使って自己開示する
というアイディアを聴きました。（このときに、前述のピンポンゲームの話も久しぶりに思い出しました…）
今の私のチームは、メンバーが半々ほどで東京と上海に分かれており、アジャイルのゲームのように同じ場にいることを前提としたアクティビティを使うことが難しいです。
そこで、この性格診断を使った方法、ありなんじゃないかな？ と思った次第です。
こんな進め方を考えています
性格診断は、
MBTI理論をもとにしている、
無料性格診断テスト | 16Personalities
の利用を考えています。
- ふりかえりワークショップで教えてもらったのがMBTIだったこと
- 上記サイトは非常に多くの言語をサポートしていること（現在のチームは多国籍で、母国語が異なるメンバーで構成されています）
が理由です。
事前準備
・性格診断を受ける
・結果の中であたってる！と思ったところを抜粋
・具体的なエピソードを思い出し、上記抜粋と併記
ここまでを、事前準備として参加者に行っておいてもらいます。
なお、前述のとおり私の今のチームは母国語が異なるメンバーで構成されているため、
性格診断と結果の確認は母国語版で、
共有のための書き出しは英語版で行ってもらうことを想定しています。
自己の開示
上記、準備したものを参加者それぞれに共有してもらいます。
この共有の仕方が実は悩みどころでして…
真っ先に思いついたのは、全員同じ場で（拠点はビデオ会議でつないで）、順番に発表してもらう、「同期」方法です。
ただ、この方法ですと、他の人は基本的に受け身になってしまう、という問題があります。
全部で9人いるので、一人3分としても27分、5分なら45分。順番に聞いていくのってなかなか疲れますよね。
他の参加者が発表者に対してフィードバックを行うことも考えたのですが、できるとしたら
- たしかにあなたはそういうところがありますね、という同調。
- 発展させて、他にもこういう事例もありますよね、という「事例の追加」
あたりでしょうか。
続いて、非同期な方法も考えてみました。
せっかく事前準備をしてもらうので、事前準備を集めて共有し、あとは各メンバーに読んでもらうという方法です。
こちらは、「ちゃんと読んでくれるかなぁ…」 という懸念が募ります。
言葉ではない方法で共有する方法も考えました。
こちらのブログでは、結果を四象限上にマッピングしているようで、
qiita.com
このような形で、パッと見でメンバー9人全員の結果がわかるような形にできれば、そこから興味を持って話を聞くなり読むなりしてくれそうです。
とりあえず一回やってみたい
ということで、いきなりチームでやると難しそうなので、まずはリハーサルをやってみたいなと思っています。
付き合ってくれそうな方に声をかけて、やらせてもらおうかなぁと思っています。
（もしくはご興味がある方、是非一緒にやりましょう）
ちなみに私の結果
“仲介者”型の性格 (INFP-A / INFP-T) | 16Personalities
でした。
あたっているな、と思ったのは以下の点です。
- 「同じ考えを持つ人々を見つけて共に過ごす時、そこで感じる調和が、仲介者型にとって、喜び」
→ 逆に、ある集団内で意見が対立していると、大変居心地が悪い。健全な組織のために時には意見対立も必要だ…と思いつつ、中間状態を見ているのがめちゃ辛い。*2
- 「難なく比喩表現やたとえ話を用い、シンボルを理解し生み出しながら、自分の考えを共有できます」
→ 比較的複雑な概念、難しい概念を、わかった気にさせる『デフォルメ』は得意な方だと思う
- 「一度に多くのことをやろうとすると力尽き」
→ やることが複数になるとすぐパニックになります
- 「生きて行く上で欠かせない日常生活の維持を疎かにしてしまう可能性もあるので注意しましょう」
→ 特に『ノッてる』ときは、食事すらしたくないときがある。*3
- 「放っておくと、まるで隠者のように引きこもったまま連絡が途絶え」
→ 『俺のこと放っておいてほしい』とき、よくあります。ひとりで考え事に集中したいです。*4
超余談
この投稿が、ちょうど本ブログの100記事目だったようです。
2011年11月、サンフランシスコへの長期研修中に始めて、ここまで約6年半かかりました。
タイトルのとおり毎週書いていたら、わずか2年弱で達成されていたはずなのですが、3倍半程かかりました（笑）
続・続・計算量を減らす：Newの回数を減らしたらもっと速く… なるどころか遅くなった！？
前回までのお話
taichiw.hatenablog.com
たった一行、乱数の初期化をループの中からクラス生成時に移しただけで５倍も速くなったというお話でした。
じゃあ、クラス変数にしたらNewが減るじゃん！ということでstaticをつけてみました。
private static Random rnd = new SecureRandom();
結果。
37秒, 39秒, 45秒, 49秒, 49秒, …
って… 元々３０秒だったのが遅くなってるじゃないですカー！
CPUがサボってやがる
CPUの使われ方を比較してみると
インスタンス変数（＝Classが作られるタイミングでNewする場合）
クラス変数（= Classがロードされるタイミングで一回だけNewする場合）
クラス変数のほうがギザギザしていて、天井に張り付いて『ない』気が。
（上のスクリーンショットだとあまりそうは見えませんが… 動いているものを見るとそんな気がしました）
おそらくこのサボりが遅さの原因…
ということは、マルチスレッド間でアクセスの待ちが発生している？
と思い調べてみると、案の定でした。
SecureRandomクラスでは、
public int nextInt(int bound) {
から呼ばれている
@Override final protected int next(int numBits) {
から呼ばれている
@Override public void nextBytes(byte[] bytes) {
から呼ばれている
public synchronized void engineNextBytes(byte[] var1) {
こいつがsynchronized。
ということで、マルチスレッド間で１インスタンスを共有した結果、メソッドにロックがかかって待ちが発生し、遅くなってしまっていたのでした。
SecureRandomをやめたら…
これまで、なんとなくSecureRandomクラスを使っていたのですが*1、改めて見るといかにも「Secureを得るために速度を犠牲にしている」っぽい名前です。
そこで改めて確認したところ、SecureRandomクラスの他に、単なるRandomクラスが存在しました*2。
Randomクラスで用いられている乱数生成アルゴリズムは予測可能であるために、暗号などには使えないそうなのですが、別に暗号を作っているわけではないのでこれで十分。
ということで、ただのRandomクラスに差し替えてみます。
22秒、21秒、20秒、22秒、…
おおおお… 速くなった！！
しかも、クラス変数でも、インスタンス変数でも、はたまたループ内で都度生成されるメソッドローカルな変数でも、ほぼ実行時間が変わらないという。
要は、SecureRandomの生成が遅かったのか…。
おまけ そもそも乱数を使わなかったら
Randomクラスにした結果、どうやら生成のコストは下がったのですが、それでもなお毎回の乱数の取得が重そうだなぁ… ということで、
試しに乱数を使うのをやめてみました*3
13秒、11秒、11秒、12秒、…
ということで、10秒前後縮まりました。
乱数って用法・容量を守って正しく使わないとコワイですね。
