Dynamic CDSよりJava10からある自力ダンプの方が起動が速い

昨日のエントリでDynamic CDSを使いましたが、自分でダンプしたクラスデータを使うほうが速くなりました。
Java 13のDynamic CDSで想像以上に起動速度が速くなった - きしだのHatena

Java 10からOpenJDKでもApp CDSが使えるようになりました。Oracle JDKでは8u40からあるっぽい。
JEP 310: Application Class-Data Sharing

Dynamic CDSと違うのは、クラス一覧を指定しないといけないところ。

クラス一覧は、こんな感じで-XX:DumpLoadedClassListでファイル名を指定すると生成されます。

$ java -Xshare:off -XX:DumpLoadedClassList=mn.lst -jar build/libs/myapp-0.1.jar 

そうするとこんな感じでロードされたクラス一覧が記録されます。

java/lang/Object
java/lang/String
java/io/Serializable
java/lang/Comparable
java/lang/CharSequence
java/lang/Class
...

このクラス一覧を使ってクラスデータをダンプします。このとき、アプリケーションは実行されません。ダンプだけ行われます。

$ java -Xshare:dump -XX:SharedClassListFile=mn.lst -XX:SharedArchiveFile=mn13.jsa -jar build/libs/myapp-0.1.jar
Allocated shared space: 3221225472 bytes at 0x0000000800000000
Loading classes to share ...
Preload Warning: Cannot find jdk/internal/misc/JavaLangRefAccess
Preload Warning: Cannot find jdk/internal/misc/SharedSecrets
Preload Warning: Cannot find jdk/internal/misc/JavaIOFileDescriptorAccess
Preload Warning: Cannot find jdk/internal/misc/JavaNioAccess
...

実行はDynamic CDSを使う場合と同じです。

$ java -XX:SharedArchiveFile=mn13.jsa -jar build/libs/myapp-0.1.jar 

Java 11ではそれぞれに-XX:+UseAppCDSをつけておく必要があります。
計測したら、だいぶ速くなっていました。6回実行して2回目以降5回分の平均をとっています。

	JVM起動	アプリケーション起動
No CDS	149.6	1028.6
Default CDS	98.6	1009.2
Dynamic CDS	89.2	688.8
AOT+DynCDS	144	625.6
App CDS	93	451.4

なにも指定していない場合の倍の速さで起動していますね。

Java 13のDynamic CDSで想像以上に起動速度が速くなった

Java 13で、読み込み済みのクラスデータを終了時に保存するDynamic CDSが導入されました。
https://openjdk.java.net/jeps/350

で、試してみたら結構起動速度が変わっていました。

Micronautで試してみます。

追記: Java 10でApplication Class-Data Sharingが入っているので、自分でクラスリストを作ってダンプすれば同等のことができていたのだけど、面倒さが低減された感じです。LTSであるJava 11ではAppCDSを使うといいと思います。

追記2: 自分でダンプしたほうがかなり速かった
Dynamic CDSよりJava10からある自力ダンプの方が起動が速い - きしだのHatena

準備

インストールは全部SDKMAN!で行います。(Windowsの場合はCygwinかWSLを使います)

$ curl -s "https://get.sdkman.io" | bash

ターミナルを開き直すとSDKMAN!が使えるようになります。
まずはJDKを。Micronautは現時点ではJDK13でビルドできないので、JDK12を使います。

$ sdk use java 12.0.2-open

次にMicronautをインストールします。

$ sdk use micronaut 1.2.4

Micronautのアプリケーションを作成します。

$ mn create-app myapp

できたフォルダに移動。

$ cd myapp

ビルドします。テストでこけることがあるので、テストをスキップ。

$ ./gradlew -x test build

実行してみます。

$ java -jar build/libs/myapp-0.1.jar 
21:02:22.782 [main] INFO  io.micronaut.runtime.Micronaut - Startup completed in 1103ms. Server Running: http://localhost:8080

終了はctrl+cで。

Dynamic CDSを試してみる

Dynamic CDSでクラスデータを保存するときは-XX:ArchiveClassesAtExitをつけてアーカイブファイル名を指定します。

$ java -XX:ArchiveClassesAtExit=mn.jsa -jar build/libs/myapp-0.1.jar 
myapp $ java -XX:ArchiveClassesAtExit=mn.jsa -jar build/libs/myapp-0.1.jar 
22:09:12.011 [main] INFO  io.micronaut.runtime.Micronaut - Startup completed in 1681ms. Server Running: http://localhost:8080
^C22:09:14.530 [Thread-2] INFO  io.micronaut.runtime.Micronaut - Embedded Application shutting down
[4.593s][warning][cds] Skipping io/micronaut/http/client/$DefaultHttpClientConfiguration$DefaultConnectionPoolConfigurationDefinition: Not linked
[4.593s][warning][cds] Skipping io/reactivex/internal/operators/mixed/ObservableSwitchMapCompletable: Not linked
[4.593s][warning][cds] Skipping io/reactivex/internal/operators/completable/CompletableTimeout: Not linked
...

18MBのファイルができています。

$ ls -l -h mn.jsa
-r--r--r--  1 kishida  staff    18M 10 17 22:09 mn.jsa

このシェア用アーカイブファイルを利用するときは-XX:SharedArchiveFileをつけてアーカイブファイルを指定します。

$ java -XX:SharedArchiveFile=mn.jsa -jar build/libs/myapp-0.1.jar 

結果はあとでまとめますが、結構起動が速くなりました。

結果

ということで結果です。
Javaの標準クラスに関してはDefault CDSとしてJDK12から用意されるようになっていますが、これを使わないものも試してみました。
-Xshare:offをつけるとDefault CDSファイルが使われなくなります。

$ java -Xshare:off -jar build/libs/myapp-0.1.jar

もうひとつ、Java 9から導入されているAOTも試してみます。今回はjava.baseモジュールだけAOTをかけてみます。

$ jaotc --output=libjava.base.so --module java.base

これを使うときは-XX:AOTLibraryをつけてライブラリファイルを指定します。

$ java -XX:AOTLibrary=./libjava.base.so -XX:SharedArchiveFile=mn.jsa -jar build/libs/myapp-0.1.jar

6回連続で起動して2番目以降の平均を計測値にします。
また、Micronautの起動時間はmainメソッド以降の実行時間なので、mainメソッドの最初に

System.out.println(ManagementFactory.getRuntimeMXBean().getUptime());

をつけてJVM自体の起動時間も計測しています。

package myapp;

import io.micronaut.runtime.Micronaut;
import java.lang.management.ManagementFactory;

public class Application {

    public static void main(String[] args) {
System.out.println(ManagementFactory.getRuntimeMXBean().getUptime());
        Micronaut.run(Application.class);
    }
}

	JVM起動	アプリケーション起動
No CDS	149.6	1028.6
Default CDS	98.6	1009.2
Dynamic CDS	89.2	688.8
AOT+DynCDS	144	625.6

ということでこんな結果に。
Default CDSではアプリケーション起動時間はあまり変わりませんがJVMの起動時間が短くなっています。そしてDynamic CDSでアプリケーションのクラスデータも再利用すると、アプリケーション起動時間がかなり縮まっていますね。
残念なのはAOTで、アプリケーション起動時間が縮まっているけどJVM起動時間がすこしのびて、トータルでは結局同じくらいの起動時間になっています。

Vector APIを試す

Vector APIはSIMD命令をJavaから利用するためのAPIです。
Project Panamaの一部ということになっていますが、最近はなんかPanamaとは別扱いになってる気がします。

Vector APIはJEPがすでに作成されていて、感触としてはJDK 14に入りそうな勢い。
JEP 338: Vector API (Incubator)
※追記(2020/10/24) JDK16に入ることになりました。

ビルド

いまのところ簡単に試せるバイナリは提供されていないので、自分でビルドする必要があります。
※追記(2020/10/24) JDK16 ea21から取り込まれているのでビルド不要で試せます。

いままでJDKのビルドをするときにはソースをMercurialでとってきていましたが、OpenJDKのソースはGitHubにミラーされるようになったので、Gitを使うほうが断然速いです。

$ git clone https://github.com/openjdk/panama/

Vector APIはvectorIntrinsicsブランチで開発されていてmasterには取り込まれていないので、ブランチを切り替える必要があります。

$ cd panama
$ git checkout vectorIntrinsics

あとは通常どおりビルドします。

$ bash configure
$ make images

足りないライブラリがあればconfigure時に示してくれるはずなので、インストールして再び試すといいです。

JShellで試す

それでは、JShellで試してみましょう。Vector APIモジュールはデフォルトでは有効になっていないので、java / javac / jshell各コマンドに--add-modules jdk.incubator.vectorをつけてモジュールを読み込む必要があります。

$ build/linux-x86_64-server-release/images/jdk/bin/jshell --add-modules jdk.incubator.vector
|  Welcome to JShell -- Version 14-internal
|  For an introduction type: /help intro

jehsll> import jdk.incubator.vector.*

jshell> var SP = DoubleVector.SPECIES_256
SP ==> Species[double, 4, S_256_BIT]

jshell> var v1 = DoubleVector.fromValues(SP, 1, 2, 3, 4)
v1 ==> [1.0, 2.0, 3.0, 4.0]

jshell> v1.add(2)
$4 ==> [3.0, 4.0, 5.0, 6.0]

jshell> var v2 = DoubleVector.fromValues(SP, 2, 3, 4, 5)
v2 ==> [2.0, 3.0, 4.0, 5.0]

jshell> v1.add(v2)
$6 ==> [3.0, 5.0, 7.0, 9.0]

このように複数の値に対してひとつの命令で演算が行えることがわかります。
コードを書く際に最初に注意する点としては、パッケージはjdk.incubator.vectorに入っているということと、どの型のどのサイズのVectorを使うか示すためにSPECIESが必要、というところですね。
あとの演算は、JavaDocを見れば比較的わかりやすいんではないかと思います。
jdk.incubator.vector (Java SE 13 & JDK 13 [ad-hoc build])

気がむいたらAPIについてもまとめます。
※追記(2020/10/24) fromValuesは正式版からは外れてるようなので代わりにfromArray(SP, new double[]{1, 2, 3, 4}, 0)などとする必要があります。

Vector APIを理解するためにSIMD命令をCで試す

JavaのVector APIはSIMD命令を呼び出すためのAPIです。
ということで、実際にSIMD命令を知っておいたほうが理解が深まる気がします。
ただ、直接SIMD命令を試すのはめんどいので、C++から呼びだしてみます。

Cの文法とかだいぶ忘れてるというか知らないものが多いので、適当にぐぐりながら書いてみました。

#include<cstdio>
#include<x86intrin.h>

typedef __attribute__((aligned(32))) struct {
    double x;
    double y;
    double z;
    double w;
} Vec;

int main(void) {
  Vec v1 = {2, 3,4, 0};
  Vec v2 = {3, 4, 5,0};
  const __m256d d1 = _mm256_load_pd((double*)&v1);
  const __m256d d2 = _mm256_load_pd((double*)&v2);
  const __m256d r = _mm256_add_pd(d1, d2);
  Vec *v3 = (Vec*)&r;
  printf("%f, %f, %f\n", v3->x, v3->y, v3->z);
}

最初まったくコンパイルが通らなくてあきらめたんだけど、 Twitterで-mavx2とかつければいいと教えてもらいました。
https://twitter.com/objectxplosive/status/1165307957417930752

$ gcc -mavx2 hello.cpp -o hello
$ ./hello
5.000000, 7.000000, 9.000000

無事うごいた。

OpenJDK Committer's Workshop 2019 - Day 2(JVMLS Day 5)

CommitterではないけどOpenJDK Committer's Workshop(OCW)に参加しています。
OpenJDK Committers’ Workshop

初日はこちら。
OpenJDK Committer's Workshop 2019 - Day 1(JVMLS Day 4) - きしだのHatena

Unconference

今日もアンカンファレンス形式で行います。というStuart Marksさんの話。

ということで、トピックを持ってる人は書き出します。

それぞれ自分のトピックを説明。

そして投票します。

RMI De-evolution気になるけど人気なかった・・・

Graal JIT Adoption

Graal JITについてのディスカッション。Twitterの人など、JITをやってる人が集まっていました。

Graalに興味がある人っていう質問に手をあげる人はたくさんいたのだけど、Graalを使ってる人っていう質問ではTwitterの人が手をあげただけでした。

話題としては

• libgraalがプロファイルを汚染しないとか
• GraalVM CEとEEの違いはなんなの？ -> EEの機能は完全に分離してるからOpenJDKとしては忘れて。みんなが使ってたらOpenJDK/CEにポートもあるのかも？
• Twitterの人のGraalロードマップ(完全にぼーっとして聞き逃してもったいない)
• Native Imageのデバッグ情報ってどうなってるの？ -> SubstrateVMでは？
• C2とGraalを同時に使えるか -> 技術的には可能。C2の性能がよいけどGraalはEscape Analisysが強い
• C2はDeprecateできる？ -> 難しそう
• LLVMバックエンドがどうのこうの

という感じで、いろんな話が行われておもしろかったです。C2をどうするかという話が結構時間をとってた気がする。

Preview Featured: Experiences + Enhancements

Alex BuckleyさんとBrian GoetzさんによるPreview機能についての話

話題としては3つ

• IDEとか他のツールでの対応めんどくない？
• フィードバック目的だけどうまくいってる？
• APIへの影響は？

IDEなどのツールへの影響というのは、たとえばValhallaのように独立したEAとして出ると対応する必要だけどPreviewとしてリリースに入ると対応が必要であることを言っています。
IDEだとswitch式の構文対応やリファクタリングがありますね。また、JDK12では値を返すのがbreakだったけどJDK13ではyieldになります。 JDKでは値を返すbreakは不要になりますが、IDEでは保持する必要があります。
そのことについて、JetBrainsの人が、サポート大変だけどがんばる！と言ってました。

フィードバックという点では、たとえばLambdaは機能ごとのプレビューリリースが出ていましたが、試用する人が少なかったということです。
ただ、それでpreviewとして入れてフィードバックがあったのかという点では、期待していたより少ないということです。preview使ってる人という質問にはたくさんの手があがりましたが、フィードバックした？という質問にだれも手をあげず苦笑。
6ヶ月ごとのリリースでは短いんではという指摘もありました。

APIへの影響というのは、たとえばText Blocks (Preview)ではstripIndentなどのメソッドが入りますが、これはDeprecatedではありますが--enable-previewをつけなくても使えます。
Preview用のアノテーションはどうだろうという話がでていました。 また、もしPreview機能導入によって動きがかわるメソッドがあるとき、どうやってフラグするかという話も出ました。

Portola/Alpine

PortolaプロジェクトをやっているMikaelさんによるAlpine対応の話
PortolaプロジェクトはJDKをAlpine Linuxに対応するためのプロジェクトですが、Cライブラリがglibcではなくmuslになっていて対応が必要です。

「This is my hobby project」と言ってたのでメーリングリストを確認してみたら、Mikaelさんがひとりでやってる感じですね。

BellSoftの人が、Alpineを使ったDockerイメージをリリースしているので、少し話していました。

How to promote Java new great features to people outside this conference

Vladimir Kozlovさんによる、Javaの素敵機能をどう広めるかという話

JDK8からJDK11で、156のJEPと4961の機能改善が入ったのをどう広めるかという話ですね。

多くがJDK9でのモジュールシステムがらみな気がするけど。

リリースノートが見にくいんではという話も出てた気がする。

Finish

これでOpenJDK Committer's Workshopは終了。

6ヶ月後にブリュッセルで会いましょう、ということでした。FOSDEM 2020かな。

お昼ごはんは出るので食べる。

終わってから、ついでにNetwork Circleという名前のついている外周を歩いて帰って終了。おつかれさまでした！

OpenJDK Committer's Workshop 2019 - Day 1(JVMLS Day 4)

JVM Language Summitが終わると、引き続いてOpenJDK Committer's Workshop(OCW)が開かれるので、コミッターではないけど参加してみました。
OpenJDK Committers’ Workshop

JVMLSはこちら。
JVM Language Summit 2019(JVMLS) day 1 - きしだのHatena
JVM Language Summit 2019(JVMLS) day 2 - きしだのHatena
JVM Language Summit 2019(JVMLS) day 3 - きしだのHatena

Unconference

まず最初にMark Reinholdさんの開始のあいさつ。ほんとは9時開始だけど9:20くらいまでぐだぐだしてた気がする。

コミットが多い会社の一覧。それぞれの会社に所属している人が順に起立してみんなで拍手。

OCWは事前にタイムテーブルが決まっていないアンカンファレンス形式で行われます。というStuart Marksさんからの説明

まずは話し合いたいネタがある人がトピックを書いて貼っていきます。

そして、それぞれ短く説明のピッチ。

そのとき、前のほうの席で関係ない話をしてたGilさんにReinholdさんが声を抑えてってジェスチャーしにきたり、時間を超過してピッチしてたGilさんに時間切れ〜とReinholdさんがやってたりして面白かった。

そのあと、みんなで投票して、内容が決まります。

Project Skara

最初はあらかじめ応募があったSkaraの話。

Project Skaraは、現在Mercurialで管理されているOpenJDKのソースをGitに移行するというプロジェクトです。すでにGitHubにリポジトリが作られて、リポジトリがミラーされています。メインリポジトリだけではなく、ValhallaやPanamaなどのプロジェクトやJMCのようなツールなど周辺プロジェクトもリポジトリが作られています。
OpenJDK

そうすると、WebRevというツールとメーリングリストで行われているコードレビューの代わりにPull Requestを使いたいとか、Bug管理の代わりにGitHubのIssueを使いたいとか、開発作業のツールもGitHubに移行する必要が出て、どうしようかという話でした。

JEPはこれです。
JEP 357: Migrate from Mercurial to Git

すでに資料は公開されています。
http://cr.openjdk.java.net/~darcy/Presentations/OCW/ocw-2019-08-skara.pdf

Warmup

AzulのCTOであるGil Tateさんによる、Javaのウォームアップの話

JVMではJITが進むごとにパフォーマンスがあがって、ピークパフォーマンスが出るまでにしばらくかかります。

サーバーが複数台あると、そういうピークパフォーマンスが出る前の状態をそれぞれ経過することになりますが、これは無駄です。

その問題に対処するために、AzulのJVMであるZingでの実装や、JVMLS2日目で話されていたJWarmup、OpenJ9のJITキャッシュなどがあります。

これは通常のOpenJDKとGraalVMネイティブイメージ、CRaCを使ったものの比較で、ネイティブイメージほどではないですが、起動時間が短縮できています。

起動時間の短縮には、ネイティブイメージ以外にもいろいろなアプローチがあるんだなぁという感想でした。

Lanch

ここで昼休み

同じテーブルにいた人が、テストをどうするかっていうセッションの提案をしていたAdoptOpenJDKのひとに、OpenJDKにコミットするのめっちゃハードル高い、自分が使ってない環境でのテストとかできないと相談していました。
AdoptOpenJDKでは、そういった環境も提供したい、ということを言っていました。

ごはんを食べたら、午後からのタイムテーブルの発表です。

こんな感じに1階と2階にわかれて全部で8セッション行われます。

Core Lib、JFR Enhansment

Stuart Marksさんによるコアライブラリにロギングやメトリクスを入れる話。

あとJFRの話。

よく聞いてなかった。

Virtual Container

Alibabaの人たちによるVirtual Containerの話

JVMのレベルで仮想化しようという話

Amazon Corretto Crypt Provider

Correttoのなにか。

Finalization

finalize()をどうやって滅ぼすかという話。

8/9 追記 問題 GC実装の複雑化とオーバーヘッド

代替 java.lang.ref.Cleaner ReferenceQueue

進捗 JDK9からdeprecated baseモジュールではほぼ変更・削除されている(クライアントやJavaFXで残ってる)

3rdパーティーライブラリはどうする？ ドキュメント・広報など どのくらい時間が？ ステップは？

アイデア GCでfinalizeを無効にする スイッチをつける デフォルトをあとで変更する アプリケーションは失敗したりdegradeするかも

GC

CMSをどうやって滅ぼすかという話。

手書きでしたね。そして、WindowsじゃなくUbuntuっぽい。

14で消すぞ、ってことらしい。
なんで14よりあとじゃないの？って質問には、まあみんなLTSしか使わないからLTS以外ならどこでやっても同じなんでは？と言ってた。

Dinner

という感じでOpenJDKの大きめの問題についてみんなで議論する、という感じでした。
あしたの予定はJVMLSをどう広めるかとPanamaの話っぽい。のこりはまた明日アンカンファレンス形式でというStuart Marksさんからの話。

晩ごはんはそのまま近所で食べるので、歩きます。Oracleキャンパスを出たところの道が「Sun Fire Way」という名前なんですが、Sun Microsystemsのサーバー「Sun Fire」から来ているらしい。

晩ごはんは、jyukutyo御用達のチポトレ

注文のしかたぜんぜんわからんだった。あとこれ1000KCal以上あるっぽく、全部食べたらおなかいっぱい+αになった。けどおいしかったです。
インスタ映えしないけど。

こちらはインスタ映えするskrb

ついでに同じエリアにあるSafewayというスーパーで、KOMBCHAという謎の飲み物を教えてもらいます。昆布のお茶ではなく、紅茶キノコ系らしい。
ここに写ってるのほとんど全部KOMBCHAです。

新しい知識も仕入れたところで、OCW1日目終了です。またあした。

JVM Language Summit 2019(JVMLS) day 3

JVMLSに来ています。3日目。
JVM Language Summit — July 29–31, 2019

2日目まではこちら。
JVM Language Summit 2019(JVMLS) day 1 - きしだのHatena
JVM Language Summit 2019(JVMLS) day 2 - きしだのHatena

今日は3つのセッションとLTです。 終わったあとはみんなでコンピュータ歴史博物館に行きました。

Annotation for Java

寝坊して遅刻・・・
最初はNonNull/Nullableをアノテーションを使って型システムに組み込む話。

Map.getはNullableだけど、コード上NonNullになるときもあるよね、とか。

動画は今の時点(西海岸時間 3:28 日本時間19:28)ではアップされていませんね。

Fast type checking for Ruby

Sorbetというtype checkerを使ってRubyに型検査を導入する話
Sorbet · A static type checker for Ruby

Gradual typing for Ruby at Scale with Sorbet - Dmitry Petrashko

LT

ここで3つLT

最初は"It's time to remove checked exceptions!"っていう、ネタ的な話。LTらしさある。

2番目はAzulのGilさんによる、Javaにチェックポイントを入れる話。
動作中のJVM上の状態を保存して他のマシンで再開できるようにする、みたいな話でした。

3番目はEclipseの人の、Javaエディタをどう実装してるかという話。

Differentiable Programming

機械学習でコーディングをもっと改善する、という話。

FacebookのDeveloper InfrastructureチームのErik Meijerさんの話です。Wikipediaあるのね。
Erik Meijer (computer scientist) - Wikipedia

Aromaというツールを作っています。
Aroma: Using ML for code recommendation

資料がほぼ全部イラスト入りの手書きでめちゃくちゃかわいい。

一番最初、ちょっと政治的な話から始まりましたが、YouTubeではそのあとから収録されてますね。

話し方もめちゃくちゃおもしろくて、何の話をしてるかその場では全然わからなかったのだけどなんか面白い、という感じでした。
昨日のjWarmupの人は話の内容は面白いはずなのにずっと手元をみていて話し方が面白くなかったので、なんも面白くなかったというのと対照的。
というか、何の話をしてたかわかった上でYouTube見返すと、めちゃくちゃ面白いな、これ。

内容のほとんどは、二重数を導入して自動微分するという話でした。

eは二乗すると-1になる数ですが、二乗すると0になるεを導入してa+bεという数を定義すると自動微分ができるっぽい。
二重数で自動微分する - Qiita

Scalaで二重数を定義して、各演算も定義すると、こう。

で、なんかニューラルネットワークのコードがすっきり実行効率よく書けるようになるのだけど、最後にJVMに線形代数ライブラリを導入してくれ〜そしたらPython使わなくていいんだ、という話で終わりました。

Differentiable Programming with Erik Meijer

Lunch

ということで、 @ajis_ka による終わったのポーズでJVMLS終了です。

ランチも出てましたが、Mountain ViewのComputer History Museumに行くのでそのあたりで食べるということに。

行こうとしてた店はいっぱいだったので、隣の韓国料理屋さんで石焼ビビンバ。

Computer History Museum

ということで、Computer History Museum

Crayとかあってテンションあがる

MSXもあった！

データベースの記号がなんであんな形なのかわかるハードディスク

説明をみてる @jyukutyo

あと、IBM 1401の実際に動くデモがあったので見ます。

デモの流れはこのツイートにぶらさげてるので、こちらを。

電算室！！！こんな最新コンピューターがあるところで働きたいですね！ pic.twitter.com/hRQsVIHiJD

— きしだൠ(K8S(Kishidades)) (@kis) 2019年7月31日

まんなかに鎮座するのがProcessor Unit。つまりCPU。

メモリはコアメモリといって、磁石で記憶するやつ。6$/bitらしい。1401には4KBのメモリが載ってるらしいので、2000万円くらいですね。

これがそのコアです。手は @skrb

楽しかった。

Dinner

晩ごはんを食べに、Mountain Viewのダウンタウンまで30分ほど歩きます。

途中、Googleのオフィスがあったりする。

そして、まずはスイーツ。

となると、スイーツを撮る @skrb を撮るのは重要

そのあと、自家醸造してる Tied House Cafe & Breweryに

ビールを！Alpine Goldおいしい。

ハンバーガー、1/3サイズというのを頼んだら、マクドナルドの倍くらいの出てきました。1/1サイズどんだけ・・・

1/2ポンド400gが標準らしくその1/3なので75gくらい。 @megascus 情報でマクドナルドが45gなので、やはり大きい。
8/2 追記 @skrb 情報で、1/3ポンドということなので150gっぽい。

ということで、JVMLS最終日終了。おつかれさまでした！