harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Ellison <t.p.elli...@gmail.com>
Subject Thoughts... (was: Re: [vote] HARMONY-4689 - JVMTI Extension: Native Code Access Interface implementation)
Date Fri, 12 Oct 2007 19:52:26 GMT
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 <alexei.fedotov@gmail.com> 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 <vasily.v.levchenko@gmail.com> wrote:
>>> 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
>>>
>>
>> --
>> With best regards,
>> Alexei,
>> ESSD, Intel
>>
> 
> 
> 

Mime
View raw message