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.
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 <[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 > -- --vvl
