この記事は sessionstack blog に投稿されている、How JavaScript works シリーズの一記事 "How JavaScript works: memory management + how to handle 4 common memory leaks" の和訳です。投稿されたのは Alexander Zlatkov, 原文はこちらです。翻訳については許諾いただいています。 メモリ管理もしくはC言語におけるメモリ解説他、用語なども怪しい箇所は多分にありますので、間違いがありましたら修正のご指摘・編集リクエスト等ください。 日本語の参考 URL 先に日本語の参考URLを記載しておきます。 JavaScriptで起こるメモリリークのパターン - EagleLand Browser Computing Structure // Speaker Deck Unders
10年以上前の昔話であり、そんなこともあったのねという話。あるいはエンタープライズサポートってそんなことやってるのねという話。 カーネルメモリダンプLinuxカーネルをエンタープライズに使おうとした企業、富士通やIBM、日立といった企業がこぞってカーネルに入れようとした機能がカーネルがパニックした時に「なぜコケたのか」調べるための機能であった。その最たるものがメモリダンプだった。この機能はカーネルパニックが起きた後のメモリをディスクに吐き出す。この吐き出されたメモリイメージをダンプと呼び、これをデバッガに食わせて原因調査をする。 カーネルデベロッパはパニックが起きたら再現条件を探して理詰めでバグを探すのが得意だが、顧客先でパニックが起きたら「再現させてくれ」とは中々言えないのでこの機能はサポートには重要だった。そして、ダンプ調査の技を持つエンジニアも居た。 地雷型メモリ破壊パニック色々と調
毎年12月25日のクリスマスにアップデートされるオブジェクト指向スクリプト言語の「Ruby」。今回も新バージョンとなるRuby 2.7正式版が予定通り、2019年12月25日にリリースされました。 Ruby 2.7の主な新機能は、case文でのオブジェクトのパターンマッチ、コマンドラインからRubyが利用できるirbにおける複数行編集の対応、コンパクションガベージコレクタ、JITコンパイラ性能の改善などです。 Ruby 2.7の主な新機能 実験的実装による新機能として追加されたオブジェクトのパターンマッチ機能は、case文で使うことができます。 一般にパターンマッチとは文字列などの値に関するパターンの一致や不一致を思い浮かべますが、Ruby 2.7で追加されたのオブジェクトの構造がパターンと一致するかどうかが調べられ、一致した場合に処理が実行される、というものです。 これまでif分などを組
複数の Apple 製品で使用している SecureROM には解放済みメモリ使用 (use-after-free) の脆弱性が存在します。 プロセッサチップ A5 から A11 を搭載する次の製品 iPhones 4s から iPhone X まで iPad 第 2 世代から 第 7 世代まで iPad Mini 第 2 世代および 第 3 世代 iPad Air および iPad Air 2 iPad Pro 10.5 インチ および 12.9 インチ 第 2 世代 Apple Watch Series 1 から Series 3 まで Apple TV 第 3 世代 および 4k iPod Touch 第 5 世代 から 第 7 世代 脆弱性に該当するプロセッサチップを利用している製品であれば、上記以外の製品も影響を受けます。 なお、 A12 以降のプロセッサチップを使用している i
MBPのバタフライキーボードとTouch Barに絶望して乗り換え先のWindowsノートを探したメモ。 外部キーボードで使い始めたら割と快適なので結局買わなそうなのだがせっかく調べたので。 絶対条件 まずは以下の条件で絞った。 15インチディスプレイ 4Kディスプレイ 32GBメモリ(換装や増設で32GB以上にできれば元はそれ以下でもOK) SSD NVMeで1TB以上(換装や増設で1TB以上にできれば元はそれ以下でもOK) USB-Cポート(できれば2個以上) おのずとプレミアムノートとかクリエイターズノート、ゲーミングノートとか呼ばれているクラスになり、かなり数が絞られる。価格もお高くなるが仕事の道具なのでまあ。 4Kにこだわるのは表示の見やすさから。 メモリは16GBでも十分実用になるとは思うが、最近はいっぱいいっぱいになることも珍しくなくなってきたので数年から5年程度使うことを考
仮想マシンのメモリを、ネットワーク経由でほかのサーバから拝借して増やせる「VMware Cluster Memory」、VMwareが開発中 VMwareは、仮想マシンに別のサーバに搭載されているメモリをネットワーク経由で利用する能力を持たせることで、ホストサーバが搭載する物理メモリ以上のメモリ容量を仮想マシンで利用できるようにする「VMware Cluster Memory」機能を開発していることを、VMworld 2019 USのセッションで明らかにしました。 RDMAを使って高速に別サーバのメモリにアクセス 「VMware Cluster Memory」実現の背景には、ネットワークの高速化が進んだことで、ネットワーク経由でのリソースアクセスのレイテンシがマイクロセカンドレベルにまで縮小し、ネットワーク経由でメモリにアクセスするRDMA(Remote Direct Memory Acc
「ストレージクラスメモリ」がついに実用化。DRAMと同じDDR4スロットに挿せる不揮発性メモリ「Intel Optane DCパーシステントメモリ」と新Xeonプロセッサ、一般販売開始 ストレージの世界では、不揮発性メモリによって構成されたフラッシュストレージの登場によって技術的にも市場的にも大きな変革が起こりました。かつて主流だったハードディスクドライブを基盤とした技術や製品は、すでに時代遅れなものになりつつあります。 それと同じような大きな変化が、今度はメモリの分野で起きようとしています。不揮発性メモリを大容量メインメモリに用いる、いわゆる「ストレージクラスメモリ」の実現です。 米インテルは4月2日、イベント「Data-Centric Innovation Day」を開催。DRAMと同じDDR4スロットにさせる不揮発性メモリ「Intel Optane DCパーシステント・メモリ」と、こ
「MESH: Compacting Memory Management for C/C++ Applications」という論文を読んだのでその紹介です。arXiv.org で公開されています。PLDI 2019 で採択されている論文のドラフトだそうです。私は v2 を読みました。ソースコードが GitHub (plasma-umass/Mesh) で公開されています。 免責 読み間違えている可能性があります。正確な情報が欲しい方は必ず論文を読んでください。誤りの指摘や補足、議論などは GitHub Issue や Twitter へお願いします。 読んだ動機 C/C++ でリロケーションせずにコンパクションを行う手法に興味があった。 Speedmetor 2.0 benchmark を走らせた Firefox でメモリ消費量が減ったと報告されており、ブラウザ開発者として気になった。 Ch
objcにARCが導入されてから久しいですが、開発者がメモリ管理から解放されたかというと、そうでもないです。strongとweakの導入によって、少し抽象化がなされましたが、オブジェクトのallocate/releaseは意識してプログラムする必要があります。この記事は、ARC環境下での強参照/弱参照/循環参照についてイマイチ理解が及ばないという人のための記事であると同時に、私の個人的なまとめでもあります。 循環参照とは? 循環参照という現象は、私も最初はなかなか理解できませんでした。まず、文字的な定義から言うと、循環参照(retain cycle)とは 「オブジェクト同士がお互いに強い参照を持っているからどちらも解放されない」という現象のことです。 iOSにはObjective-C 2.0のランタイムが実装されていますが、ガベージコレクションは存在しません。理由はよく知らないですがシステ
技術部のフルタイムRubyコミッタの遠藤(@mametter)です。昨日の Hackarade #04 の開催報告に続き、2日連続で記事を投稿します。 今回は、ある条件下でのRubyの実行速度を高速化した話を紹介します。この改善はすでにMRIの先端にコミットされていて*1、年末リリース予定のRuby 2.6に含まれる予定です。 ひとことで言うと、「簡潔ビットベクトルを索引に使うことで、プログラムカウンタから行番号を計算するアルゴリズムをO(log N)からO(1)に改善した。これにより、TracePoint有効時やコードカバレッジ測定下で、長さ N のメソッドの実行が O(N log N) から O(N) に高速化される」ということです。順に説明します。 背景:Rubyのバイトコードの構造 この最適化を理解するにはまず、Rubyのバイトコードのある特徴を知る必要があります。 たとえば x
巨大な集合に対して、定数メモリ&定数時間で近似値を計算できる、確率的データ構造の紹介スライドです。 本スライドは、株式会社エフ・コードの社内勉強会(2018/08/30)にて使用されたものです。
メモリリークに悩まされている技術者は多いだろう。メモリリークが嫌で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に返却できるが、アドレスが分からないので返却できない。 ところが、ここでいいたいのは、メモリ
[頂いた回答・コメント、その後の考察によって得た結論を自己回答として投稿しました。] ターゲットとなるディストリビューション: CentOS 6.2 x86-64 版。ただし、他のディストリビューション -- 特に新しめのもの -- についての情報も歓迎です。 背景 Linux において、プログラム中から、何か別コマンドを実行したい場合、以下のいずれかの方法がよく使われると思います。 fork() + exec系() + waitpid() (その場で完了待ちしたい場合) fork() + exec系()。SIGCHILD を受けて wait系() (親と並列に実行させたい場合) system() ※ その場で完了待ちしたい場合と、親と並列に実行させたい場合の2通りを挙げましたが、今回必要としているのは前者。とはいえ、後者の場合でも問題は共通なので列挙しました。 ところが、大量にメモリを使
Tweet お知らせ - 2018.02.22 Linux カーネルはメモリが枯渇した際の挙動を十分に考慮しておらず、メモリの枯渇が原因でLinux システムがハングアップしてしまうことがあるという問題があります。 この問題に当社ソリューション事業部 半田 哲夫が4年半取り組み続けた結果、メモリの枯渇時にハングアップしてしまう処理の多くが修正されました。現時点までの道のりは、以下の資料/動画でご覧いただけます。 資料:https://elinux.org/images/7/73/CELFJP-Jamboree63-handa-ja.pdf(社外サイト) 動画:https://youtu.be/ZznEyf1PN0Q(社外サイト)
Twitter で「読みたい」と呟いたら著者の武内覚さんから献本しましょうかとお声を掛けて頂いたので即答でお願いしました。 僕はいつも Linux でしか動作しないソフトウェアを Windows に対応させるパッチを書いたりしているので、普段 Windows しか触っていないと思われがちですが、実は僕が Linux を触り始めたのは 1996 年にトッパンから出版された「Linux 入門」くらい昔だったりします。ちょうど Linux 2.0 が出た頃だったと思います。その頃の Linux はようやく SMB カーネルが出た頃で、まだまだお遊び感のある OS で不安定でもありました。ディストリビューションもほぼ Slackware くらいしか無かったかもしれません。 あの頃の Linux はインターネットを検索しても殆ど情報が出て来ず、本気で調べるにはソースコードを読むしかありませんでした。
7月中旬からEdgeのセキュリティの仕事を始めて、各ブラウザごとに面白いセキュリティの対策をしていることを学んだのでまとめてみる。ちなみに、僕が担当しているのはSOPバイパスなどのデザインレベルのバグですが、最近のブラウザ セキュリティで各社アツいのは「メモリ破壊を使った攻撃を設計レベルでどの様に悪用出来なくするか」という点なのでそこをまとめます。専門ではないので広く浅く(笑) Chrome Chromeはブラウザのサンドボックスに力を入れているブラウザです。Chromeの報奨金制度でもサンドボックスのバイパスが最高額で、レンダラRCEの倍額であることからも見てとれます。Chromeはそのサンドボックス技術を使ったSite Isolationという保護機能を開発しています。 Site Isolation Chromeにはレンダラプロセスというウェブページを処理し表示するプロセスと、ブラウザ
ハードウェアのエラーでメモリの内容が化けてしまうことが稀にある。大抵のDRAMエラーはせいぜいプログラムがクラッシュする結果になるだけだが、データ破壊になることもありえるし、悪意のある使い方をすればセキュリティ破りに使うこともできてしまう。ここではメモリエラーとセキュリティの話をしようと思う。 メモリのエラー率は意外なほど高い。データセンターで大規模なマシン群を対象に実際に観測したところ、1年間に1回以上のエラーが発生したDIMMモジュールは全体の8%にのぼったそうだ。DIMM 1枚に数百億個のメモリセルが実装されているといっても、このエラー率はちょっとびっくりするくらい大きな数字ではないだろうか? サーバでは普通はエラー訂正付きのDIMMを使うので1ビットのエラーは問題にならないが、エラー訂正のないコンシューマ機器ではこれは実際的な問題になりえる。 メモリエラーを利用したセキュリティ破り
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く