Vasily Levchenko wrote: > I've forgot the debugger, where I have got ownership. It's implemented on > top of NCAI. and you could try and compare what is good for Java/JNI > development and VM internal development. > > http://softwarecommunity.intel.com/articles/eng/1435.htm
Thanks. I read it, and watched the video -- that's just what I would like to be able to do! Regards, Tim > On 10/12/07, Tim Ellison <[EMAIL PROTECTED]> wrote: >> 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 >>>> >>> >>> > > >
