関ジャバ'19 7月度 - connpass https://kanjava.connpass.com/event/134133/ 登壇資料
関ジャバ'19 7月度 - connpass https://kanjava.connpass.com/event/134133/ 登壇資料
You might think that if you are programming in Java, what do you need to know about how memory works? Java has automatic memory management, a nice and quiet garbage collector that works in the background to clean up the unused objects and free up some memory. Therefore, you as a Java programmer do not need to bother yourself with problems like destroying objects, as they are not used anymore. Howe
pwd が何の略か? ということを聞かれた。確かに答えられない。 http://www.abbreviations.com/pwd の中で working directory を含むものをピックアップすると、 Print Working Directory Present Working Directory Path of Working Directory の3説が見つかる。 man を見ても、あんまりしっくりこない。なんで cwd (current working directory)にしなかったんだろう? system call は getcwd(2) なのに。 昨日の続き。 早速中田さんが r49614 を入れてくれて、こういう a, b = x, y の時には、 push x # stack: x push y # stack: x y newarray 2 # stack: [
GoはPythonのようなLLと比べると実行速度は速いのですが、GCは特別速いわけではないので、相対的にGCがパフォーマンスに与える影響は大きくなります。 また、Java に比べると、一時オブジェクトなどのために頻繁にヒープアロケーションを行うとGCの停止時間が長くなりがちですが、一方でヒープアロケーションを避けたプログラミングがしやすい言語でもあります。 MySQL ドライバのような低レイヤーのライブラリを作る場合、アプリケーション側の性能要件を勝手に決めることができないので、現実的な範囲でアロケーションを減らす努力をするべきです。 ということで、前回の記事 で紹介したプレースホルダ置換を実装するにあたって経験した、アロケーションに気を使ったプログラミングについて、チューニングする手順やコード上のテクニックを紹介したいと思います。 1. まずは正しく動くものを作る go-sql-driv
コールバック、よく使いますよね。 非同期処理の結果を受け取るには、必ずと言っていいほど付き合うことになるコールバックですが、UI のようにライフサイクルを持つオブジェクトと共存するには、考慮すべきことがいくつかあります。 ここでは、おおまかに、上手にコールバックと付き合う方法を見ていきます。 基本となるポイント なんといってもまず抑えなければいけないポイントは、ライフサイクルを持つオブジェクトとの共存です。世に出回っている様々なコールバック管理のためのライブラリは、このライフサイクルを持つオブジェクトとの共存をいかに楽に、あるいは直感的にするか、ということをもとに作られています。 ライフサイクルとはつまり、オブジェクトが生成されてから消滅するまでの一連の流れのことです。 newしたりallocしたりしたタイミングでオブジェクトが生成され、GC に回収されたりdeallocしたりするタイミン
横浜Android and モバイルOS プラットフォーム部で発表した資料です。 資料はAndroidアプリ開発者をターゲットにまとめました。OutofMemoryErrorの発生原理とメモリ管理について最新事情を加味してまとめました(新版、なのはAndroid 1.xのころの発表が古いのにまだ参照されていたりで、さすがに最新事情に合わせて更新したかったのです)。 Androidアプリにおけるメモリ事情は(初期に比べたら)改善していますが、OpenCVなど画像処理の需要、高解像度対応を踏まえると依然として十分とは言いがたいユースケースもあります。そんな中でメモリ資源をうまく使うための指標となれば幸いです。 資料にもある通り書きかけの状態ですのでコメントやmentionなど「こんな情報があるから書き加えて」「ここ調べて」「こういうのがおすすめ」「ここ間違えてる!」というご意見いただければ嬉し
メモリリークに悩まされている技術者は多いだろう。メモリリークが嫌でGCという技術が開発されたといっても過言ではないし、歴史的にはC++からJavaへシフトが起きた大きな理由のひとつといっていい。Unix系の簡単な定義でいえば、ヒープ領域を指すポインタ(アドレス)をロストしてしまえばそのメモリはもう漏れたといってよい。たとえばこういったコードだ。 struct { int i; char c; } spam; int main(){ void* p; int i; for(i=0; i<1024; ++i){ p = malloc(sizeof(struct spam)); } pause(); } このコードではpause(3)の時点で約5KBのメモリが漏れている。free(3)を使えばメモリをOSに返却できるが、アドレスが分からないので返却できない。 ところが、ここでいいたいのは、メモリ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く