+1 Accept this contribution Thanks, Eugene.
On 10/12/07, Pavel Afremov <[EMAIL PROTECTED]> wrote: > +1 to accept this contribution > > It could be helpful for me. > > BR. > Pavel Afremov. > > On 10/12/07, Alexei Fedotov <[EMAIL PROTECTED]> 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. > > > > 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 <[EMAIL PROTECTED]> wrote: > > > On 10/12/07, Alexei Fedotov <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> wrote: > > > > > On 10/12/07, Alexei Fedotov <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 > > >
