Return-Path: Delivered-To: apmail-incubator-harmony-dev-archive@www.apache.org Received: (qmail 55680 invoked from network); 19 Sep 2006 15:19:19 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 19 Sep 2006 15:19:19 -0000 Received: (qmail 24025 invoked by uid 500); 19 Sep 2006 15:19:02 -0000 Delivered-To: apmail-incubator-harmony-dev-archive@incubator.apache.org Received: (qmail 23949 invoked by uid 500); 19 Sep 2006 15:19:02 -0000 Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: harmony-dev@incubator.apache.org Delivered-To: mailing list harmony-dev@incubator.apache.org Received: (qmail 23908 invoked by uid 99); 19 Sep 2006 15:19:01 -0000 Received: from idunn.apache.osuosl.org (HELO idunn.apache.osuosl.org) (140.211.166.84) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 19 Sep 2006 08:19:01 -0700 Authentication-Results: idunn.apache.osuosl.org header.from=mike.fursov@gmail.com; domainkeys=good X-ASF-Spam-Status: No, hits=0.5 required=5.0 tests=DNS_FROM_RFC_ABUSE,HTML_00_10,HTML_MESSAGE,RCVD_BY_IP DomainKey-Status: good X-DomainKeys: Ecelerity dk_validate implementing draft-delany-domainkeys-base-01 Received: from ([64.233.182.190:41359] helo=nf-out-0910.google.com) by idunn.apache.osuosl.org (ecelerity 2.1 r(10620)) with ESMTP id D7/11-28275-26A00154 for ; Tue, 19 Sep 2006 08:18:58 -0700 Received: by nf-out-0910.google.com with SMTP id x4so190746nfb for ; Tue, 19 Sep 2006 08:18:55 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=QjxK49jm/Lb10Z6NZpMZ2V3408cxm/8tr0bd60Kd75g7fvrzf3LoTZ1H6ywhaK9FnWk/faxIs6ONcXor6S2Otx+mPut4N8hjOlzd+ALxtGG50VA3gZKVhuDXX6g8EFdozkabBUJ9TMQRIBELLDrSBFBLPyD2cbiT4ngONCEmD3A= Received: by 10.78.202.19 with SMTP id z19mr3974056huf; Tue, 19 Sep 2006 08:18:54 -0700 (PDT) Received: by 10.78.182.4 with HTTP; Tue, 19 Sep 2006 08:18:54 -0700 (PDT) Message-ID: Date: Tue, 19 Sep 2006 22:18:54 +0700 From: "Mikhail Fursov" To: harmony-dev@incubator.apache.org Subject: Re: [drlvm]A subject to profiling instrumenting In-Reply-To: <6342af3e0609190636y36881a06s1cd387ed3fe713a1@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_14984_8383960.1158679134722" References: <6342af3e0608301949h1820ddacq33a1107178eb693e@mail.gmail.com> <6342af3e0609040756o76770f24rbd9417d8ab68d8f0@mail.gmail.com> <6342af3e0609051855y7286784erbef231365da95275@mail.gmail.com> <6342af3e0609070718s399e97dbye2babea5269654af@mail.gmail.com> <6342af3e0609180253p20cd657fxe7b31edc1f74507e@mail.gmail.com> <6342af3e0609180254k726c44d2ge138b11a72667cd5@mail.gmail.com> <6342af3e0609190636y36881a06s1cd387ed3fe713a1@mail.gmail.com> X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N ------=_Part_14984_8383960.1158679134722 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Qiong, I tried to apply and to build your patch on Windows. I checked out the revision required by the patch, built the code but had some problems to run it: the VM crashed at startup. I'll try to build the patched version on Linux (as you did) and will report soon. -Xem jet option is default configuration for JET-only mode. No profiling is done in this mode. When both JET and OPT compilers work JET does profiling for OPT compiler. Here is the place you added your code. I think that failure in this mode is result of the patch. As far as I understand from the diffs your patch does the following: 1) Calls the new VM helper for every memory access. This helper saves the trace for every thread separately. 2) Collects some kind of edge profile for blocks in JET. This is OK, but the way you did it looks unsafe. My proposal is to increase the code and feature base step by step. I mean that it's hard to find out the reason of the problem when there are several features added simultaneously and none of them is stable. Can we remove the code changes from VM side and leave test JET changes only first? If you need to track all memory access addresses in JIT we can add an internal JET helper that dumps addresses to a file. Most of the spec98 benchmarks are single threaded so no TLS support is needed on the early stage. Once we are sure that tracing feature is implemented in JET properly we can move the helper body to VM, add TLS support and test the code again. And only after it's done we can add and test edge profiling support to JET. What do you think about this plan? BTW the JIRA 1363 that is already merged to the SVN trunk adds edge profiler support to the EM. The Edge Profiler is used in OPT only but has a lot of JIT independent code we can reuse. -- Mikhail Fursov ------=_Part_14984_8383960.1158679134722--