From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS4713 221.184.0.0/13 X-Spam-Status: No, score=-2.9 required=3.0 tests=AWL,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,RCVD_IN_DNSWL_MED,SPF_PASS,T_RP_MATCHES_RCVD shortcircuit=no autolearn=no autolearn_force=no version=3.4.0 Received: from neon.ruby-lang.org (neon.ruby-lang.org [221.186.184.75]) by dcvr.yhbt.net (Postfix) with ESMTP id 541B71F404 for ; Mon, 19 Feb 2018 02:40:07 +0000 (UTC) Received: from neon.ruby-lang.org (localhost [IPv6:::1]) by neon.ruby-lang.org (Postfix) with ESMTP id C5F00120922; Mon, 19 Feb 2018 11:40:05 +0900 (JST) Received: from dcvr.yhbt.net (dcvr.yhbt.net [64.71.152.64]) by neon.ruby-lang.org (Postfix) with ESMTPS id 8C326120922 for ; Mon, 19 Feb 2018 11:40:00 +0900 (JST) Received: from localhost (dcvr.yhbt.net [127.0.0.1]) by dcvr.yhbt.net (Postfix) with ESMTP id AA35F1F404; Mon, 19 Feb 2018 02:39:58 +0000 (UTC) Date: Mon, 19 Feb 2018 02:39:58 +0000 From: Eric Wong To: ruby-core@ruby-lang.org Message-ID: <20180219023958.GA29178@isuckatnamingthings> References: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-ML-Name: ruby-core X-Mail-Count: 85630 Subject: [ruby-core:85630] Re: [Ruby trunk Feature#14489] MJIT needs a reusable cache X-BeenThere: ruby-core@ruby-lang.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Ruby developers List-Id: Ruby developers List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ruby-core-bounces@ruby-lang.org Sender: "ruby-core" merch-redmine@jeremyevans.net wrote: > sam.saffron (Sam Saffron) wrote: > > It can use an ISEQ SHA1 hash as the key to the cache. > > If this feature is added, it should at least use SHA256 as the > hash function. While the currently known SHA1 weaknesses may > not matter in this particular case (if you are running > untrusted code, you already have worse problems), it doesn't > make sense to introduce usage of SHA1 in new code in cases > where it is feasible to use a better hash function. Agreed; and it needs to be written with hash agility in mind for the future when SHA256 becomes insufficient. Also, I think https://github.com/ko1/yomikomu should be in stdlib(*) and there will be code sharing opportunity for JIT and ISeq caches. (*) because rubygems itself is a startup bottleneck for me