Return-Path: Delivered-To: apmail-harmony-dev-archive@www.apache.org Received: (qmail 82011 invoked from network); 12 Oct 2007 12:02:58 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 12 Oct 2007 12:02:58 -0000 Received: (qmail 42875 invoked by uid 500); 12 Oct 2007 12:02:45 -0000 Delivered-To: apmail-harmony-dev-archive@harmony.apache.org Received: (qmail 42846 invoked by uid 500); 12 Oct 2007 12:02:45 -0000 Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@harmony.apache.org Delivered-To: mailing list dev@harmony.apache.org Received: (qmail 42834 invoked by uid 99); 12 Oct 2007 12:02:45 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 12 Oct 2007 05:02:45 -0700 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of alexei.fedotov@gmail.com designates 209.85.162.177 as permitted sender) Received: from [209.85.162.177] (HELO el-out-1112.google.com) (209.85.162.177) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 12 Oct 2007 12:02:48 +0000 Received: by el-out-1112.google.com with SMTP id y26so226373ele for ; Fri, 12 Oct 2007 05:02:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=W2bImf4Vg+nVWAWHflxb6SiYzBohFW+eu6V8zfhPf+8=; b=hY9GkxWqEFiTFN5Cu94Hk5QYrMGkyUOOSSocaaDHFZdYnJqksmuBlBtPhCxJW63W97To7MMrrWyfAHPqTXMXdzdyt06snKH9IBvJpfpw8bToCL9RkpaXJfgV2HOJEDr/fUzeVt2Ks9HYTSbSv+I5PvPR+BV6T95gsdBa9QG7sHs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Vh85oncpo6pnxK+DZHlu9aQU2BKwNqUeWGdBzEDOGEYvkqFUW2Fz3w781Ff+FLejnWLx9QPIAd8t2VLWBj7UWm31TQfG121YfqtWaXlJ0mFDDHkjXc87QDO0gsVaQZK2LRuP1TCp99ZdNEcUyzPgaLhQfxTa64uoGdqVzRTOHCs= Received: by 10.66.250.18 with SMTP id x18mr4270472ugh.1192190546175; Fri, 12 Oct 2007 05:02:26 -0700 (PDT) Received: by 10.67.21.8 with HTTP; Fri, 12 Oct 2007 05:02:26 -0700 (PDT) Message-ID: Date: Fri, 12 Oct 2007 16:02:26 +0400 From: "Alexei Fedotov" To: dev@harmony.apache.org Subject: Re: [vote] HARMONY-4689 - JVMTI Extension: Native Code Access Interface implementation In-Reply-To: <14ecfd680710120437o51ee4bd8t384800af1fdbd90@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <906dd82e0710120355y3455fcb1g75dbbef14e61ce94@mail.gmail.com> <14ecfd680710120401t6dfa405ak5575d962c20e9883@mail.gmail.com> <14ecfd680710120437o51ee4bd8t384800af1fdbd90@mail.gmail.com> X-Virus-Checked: Checked by ClamAV on apache.org Hello Vasily, Now I see your attitude towards this donation. :-) When I initally looked through interface specification, I was not very supportive and replied with the same argument about gdb. Unfortunately, gdb is not BSD-licensed or Apache compatible. So we cannot link with it. It is important if we want to debug application in a JVMTI-like way from the same process. If you like solutions with external debuggers, you may come up with one as well as Salikh did two years ago, and this proved to be useful. This just does not help in two areas I've initially outlined: defensive programming and crash handling. Having a level of internal reflection from inside VM is very important to express assertions about correct VM state for a debug build. Finally I want to address your concern of a "pure viewing" nature of NCAI. NCAI allows changes in runtime environment. For example, you can change values of variables, or any memory location. Thanks. On 10/12/07, Vasily Levchenko wrote: > On 10/12/07, Alexei Fedotov wrote: > > > > +1 > > NCAI adds very useful architectural level for VM internal debugging > > and defensive programming. The best example is a crash handler, but > > other utilities such us self-detection of deadlocks, is also quite > > interesting. > > > NCAI could be interface to build some kind of viewer, but no real debugger. > 1. It couldn't be very useful just because it's single process debugging > model and if you set breakpoint incorrectly you could lock whole JVM. > 2. building debugger from the very beginning you try to invent wheel once > again, you have to develop new mechanisms that already exists in native > debuggers. > 3. building infrastructure for Mixed Mode debugging using native debugger > could be implemented in 1-2 month and it'll be really powerful and useful > solution especially JNI developers. > > HP(gdb) and Sun (dbx) already introduced native debugger-centric solutions > for debugging in mixed environments. So NCAI seams to be potential dead code > and I won't be surprised if year or two later you'll be voting for removing > this code. > > On 10/12/07, Vasily Levchenko wrote: > > > Hi Mikhail, > > > Have you got any idea how to use it? Except "Integrated Debugger for > > > Java/JNI environment" (former MMD). > > > > > > On 10/12/07, Mikhail Loenko wrote: > > > > > > > > We now have all requisite paperwork in place for > > > > http://issues.apache.org/jira/browse/HARMONY-4689, so let's vote to > > > > accept: > > > > > > > > [ ] +1 Accept this contribution > > > > [ ] -1 Reject because... > > > > > > > > As usual, 3 days unless someone complains they need more time. > > > > > > > > > > > > > > > > -- > > > --vvl > > > > > > > > > -- > > With best regards, > > Alexei, > > ESSD, Intel > > > > > > -- > --vvl > -- With best regards, Alexei, ESSD, Intel