harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexei Fedotov" <alexei.fedo...@gmail.com>
Subject Re: [vote] HARMONY-4689 - JVMTI Extension: Native Code Access Interface implementation
Date Fri, 12 Oct 2007 13:48:43 GMT
Vasily,

1.
You use capitalized wordings like "Mixed Mode" debugging or
"Integrated Debugger was transferred to me". This sound like names of
internal projects you are participating. It would be great if you
start a new thread and disclose your activity to the community (and
your humble servant). Or if they are top secret projects, I have never
seen these references on the dev list. :-) Thank you in advance.

2.
Sorry for being unaware of projects like libthread_db.so. I've tried
to google it and the first search item didn't describe this project
well:
> 'Crashes in /lib/libthread_db.so.1' thread - MARC

Could you please support your words with references to these
alternative projects and their licenses?

3.
In any case I believe we need to take the code now, and than compare
it with alternative when it is ready. Technologies quickly change and
replace each other, and I don't think we should reject a contribution
counting on its possible future obsolescence.

Contrary, our mission is to make today's code a good base for the new
development. Any code will become obsolete one day. I believe
interfaces are the easiest thing to be replaced. Other things in this
implementation such as stack frame enumeration will live much longer
because there are not too many sane maniacs which are able to
understand all our calling conventions.

Thanks!


On 10/12/07, Vasily Levchenko <vasily.v.levchenko@gmail.com> wrote:
> On 10/12/07, Alexei Fedotov <alexei.fedotov@gmail.com> wrote:
> >
> > 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.
>
>
> It's really doesn't matter you can find the sample of GDB agents under LGPL
> and BSD license, actually good example libthread_db.so that provide access
> to libpthread.so internals fo GDB usually it's the same version as the rest
> of the system libraries.
>
>
> 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.
>
>
>
> It were actually one of the lack of good crash handling that we discussed
> when the Integrated Debugger was transfered to me.
>
>
> Having a level of internal
> > reflection from inside VM is very important to express assertions
> > about correct VM state for a debug build.
>
>
>
> Yes, it's true but it should be done in similar way as thread_db interface
> which could provide even core file analyzing, but with in-process debugger
> it is impossible or very hard to implement.
>
>
> 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.
>
>
>
> GDB or any other out-of-process debugger provides the same functionality
> without any side-effects.
>
>
> Thanks.
> >
> >
> > On 10/12/07, Vasily Levchenko <vasily.v.levchenko@gmail.com> wrote:
> > > On 10/12/07, Alexei Fedotov <alexei.fedotov@gmail.com> 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 <vasily.v.levchenko@gmail.com> 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 <mloenko@gmail.com> 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
> >
>
>
>
> --
> --vvl
>


-- 
With best regards,
Alexei,
ESSD, Intel

Mime
View raw message