From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from m0.truegem.net (m0.truegem.net [69.55.228.47]) by sourceware.org (Postfix) with ESMTPS id E0740386F82A for ; Tue, 16 Jun 2020 09:16:15 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org E0740386F82A Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=maxrnd.com Authentication-Results: sourceware.org; spf=none smtp.mailfrom=mark@maxrnd.com Received: from localhost (mark@localhost) by m0.truegem.net (8.12.11/8.12.11) with ESMTP id 05G9GE5b041068 for ; Tue, 16 Jun 2020 02:16:14 -0700 (PDT) (envelope-from mark@maxrnd.com) X-Authentication-Warning: m0.truegem.net: mark owned process doing -bs Date: Tue, 16 Jun 2020 02:16:14 -0700 (PDT) From: Mark Geisert X-X-Sender: mark@m0.truegem.net To: cygwin-developers@cygwin.com Subject: More (?) steps toward jemalloc within Cygwin DLL Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Status: No, score=-2.9 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, KAM_LAZY_DOMAIN_SECURITY, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: cygwin-developers@cygwin.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Cygwin core component developers mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2020 09:16:18 -0000 I'm just putting a flag down on this new (to me) territory. If somebody else has claimed this project already, let me know and I'll shove off. It wasn't much trouble to build a jemalloc.lib and statically link it into the Cygwin DLL when the latter is built. I'm still learning which jemalloc configure options are required in order to get complete test coverage and to initialize properly within cygwin1.dll. I'm currently using the "supply your own malloc" mechanism provided by Cygwin's malloc_wrapper.cc to overlay the usual dlmalloc-sourced functions with replacements from jemalloc. I suspect there will be allocation collisions ahead... One question has popped up though. I see from the docs that if one wants jemalloc to run thread-aware, it wraps pthread_create() to find out when the app has gone from single-threaded to multi-threaded. But in Cygwin's case we'll additionally need to consider cygthreads, won't we? Thanks, ..mark