harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vasily Levchenko" <vasily.v.levche...@gmail.com>
Subject Re: [vote] HARMONY-4689 - JVMTI Extension: Native Code Access Interface implementation
Date Fri, 12 Oct 2007 14:22:48 GMT
On 10/12/07, Alexei Fedotov <alexei.fedotov@gmail.com> wrote:
>
> 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.



Yes it's public available semi-product that available on
http://whatif.intel.com, and actually I'm the owner of Integrated debugger
for Java/JNI environments. As I understand my project is single user of NCAI
and will available during Q4.


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?


libthread_db.so is usual part of system libraries e.g. for GLIbc is LGPL
in BSD world  it's  BSDL and so on.


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.



I don't really undestand what harry for?


Contrary, our mission is to make today's code a good base for the new
> development.


If you really want good code for development, read NetBSD source tree and
polish current code ;)


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
>



-- 
--vvl

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message