It looks like there is some good discussion going on around this topic, and possible alternatives being explored. Rather than prematurely forcing the issue with a vote, maybe we should stop the vote and continue the discussion for a while until we reach a consensus, then restart the vote.
What do you think? Regards, Tim Vasily Levchenko wrote: > On 10/12/07, Alexei Fedotov <[EMAIL PROTECTED]> wrote: >> Vasily, >> >> You wrote, >>> As I understand my project is single user of NCAI >> I believe this is not the only use case for NCAI. Keeping internal >> layer of debugging interfaces is important for VM development itself. > > > Why are you so sure that it will help you in internal VM development? you > can used it for building some kind viewer of state in JNI wrapper, but not > more. Your "viewer" can't get debugging services provided by kernel. You're > breaking the model that people build for a long time ago and develop new one > instead. You haven't (not personally you but harmony community I guess) > even try re-use the existing solutions. > > > Let me assure you that I'm far from convincing you to support NCAI in >> your stepchild tool if you don't want to. >> >> Thanks. >> >> On 10/12/07, Vasily Levchenko <[EMAIL PROTECTED]> wrote: >>> 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 >>> >> >> -- >> With best regards, >> Alexei, >> ESSD, Intel >> > > >
