[vote] HARMONY-4689 - JVMTI Extension: Native Code Access Interface implementation

[Mikhail Loenko <ml...@gmail.com>]

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.

Re: [vote] HARMONY-4689 - JVMTI Extension: Native Code Access Interface implementation

[Tim Ellison <t....@gmail.com>]

+1

I think it is great to see such innovation taking place in Harmony.

Note that the contribution should be committed as-is, but there are a
number of files that need the standard copyright block added soon
thereafter.

It would also be good to pull the documentation out and add it to the
website.  I found it very useful reading.

Regards,
Tim

Mikhail Loenko 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.
> 

Re: [vote] HARMONY-4689 - JVMTI Extension: Native Code Access Interface implementation

[Spark Shen <sm...@gmail.com>]

+1. The only way to verify the effective of a tool is to use it first. So
accept.

2007/10/18, Tim Ellison <t....@gmail.com>:
>
> It would be good to see some more votes expressing an opinion one way or
> the other.
>
> *Everyone* is invited to cast a vote for or against the proposal.  PMC
> members are charged with such project oversight, and committers are
> expected to participate (hint, hint).
>
> Regards,
> Tim
>
> Mikhail Loenko 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.
> >
>



-- 
Spark Shen
China Software Development Lab, IBM

Re: [vote] HARMONY-4689 - JVMTI Extension: Native Code Access Interface implementation

[Tim Ellison <t....@gmail.com>]

Alexey Petrenko wrote:
> +1 from me for "legally approve" usage and investigation of this contribution.
> However I'm not sure yet about integration to the HEAD...

We are voting for both Alexey.  If you have an objection then please
raise it for discussion.

Regards,
Tim

Re: [vote] HARMONY-4689 - JVMTI Extension: Native Code Access Interface implementation

[Alexey Petrenko <al...@gmail.com>]

+1 from me for "legally approve" usage and investigation of this contribution.
However I'm not sure yet about integration to the HEAD...

SY, Alexey

2007/10/18, Tim Ellison <t....@gmail.com>:
> It would be good to see some more votes expressing an opinion one way or
> the other.
>
> *Everyone* is invited to cast a vote for or against the proposal.  PMC
> members are charged with such project oversight, and committers are
> expected to participate (hint, hint).
>
> Regards,
> Tim
>
> Mikhail Loenko 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.
> >
>

Re: [vote] HARMONY-4689 - JVMTI Extension: Native Code Access Interface implementation

[Ilya Berezhniuk <il...@gmail.com>]

For now NCAI patch does not apply because of some conflicting changes
in VM core. So I'll start rebasing the patch to apply perfectly - it
will take some time.

Also help from JIT gurus could be needed - there were some problems in
encoder preventing OPT from working correctly with extended encoder
tables.


2007/10/25, Tim Ellison <t....@gmail.com>:
> Mikhail Loenko wrote:
> > There are unclear voices. So, I'd like to ask an explicite question:
> > are there votes against?
>
> It would seem not.
>
> Regards,
> Tim
>


-- 

Ilya

Re: [vote] HARMONY-4689 - JVMTI Extension: Native Code Access Interface implementation

[Tim Ellison <t....@gmail.com>]

Mikhail Loenko wrote:
> There are unclear voices. So, I'd like to ask an explicite question:
> are there votes against?

It would seem not.

Regards,
Tim

Re: [vote] HARMONY-4689 - JVMTI Extension: Native Code Access Interface implementation

[Mikhail Loenko <ml...@gmail.com>]

There are unclear voices. So, I'd like to ask an explicite question:
are there votes against?

Thanks,
Mikhail

2007/10/18, Tim Ellison <t....@gmail.com>:
> It would be good to see some more votes expressing an opinion one way or
> the other.
>
> *Everyone* is invited to cast a vote for or against the proposal.  PMC
> members are charged with such project oversight, and committers are
> expected to participate (hint, hint).
>
> Regards,
> Tim
>
> Mikhail Loenko 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.
> >
>

Re: [vote] HARMONY-4689 - JVMTI Extension: Native Code Access Interface implementation

[Sian January <si...@googlemail.com>]

+1

I've wanted something like this in the past and it looks like it would be
really useful for anyone working on Java and native code together.


On 18/10/2007, Tim Ellison <t....@gmail.com> wrote:
>
> It would be good to see some more votes expressing an opinion one way or
> the other.
>
> *Everyone* is invited to cast a vote for or against the proposal.  PMC
> members are charged with such project oversight, and committers are
> expected to participate (hint, hint).
>
> Regards,
> Tim
>
> Mikhail Loenko 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.
> >
>



-- 
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

Re: [vote] HARMONY-4689 - JVMTI Extension: Native Code Access Interface implementation

[Mikhail Loenko <ml...@gmail.com>]

agree with Mark +1 for accepting and integrating

Thanks,
Mikhail

2007/10/18, Mark Hindess <ma...@googlemail.com>:
>
> +1 for both acceptance and integration.  If someone will find it useful
> today, then let's integrate it.  If Vasily makes it redundant next month
> (and I can debug entirely from gdb) then we can remove it.
>
> -Mark.
>
> On 18 October 2007 at 14:37, Tim Ellison <t....@gmail.com> wrote:
> > It would be good to see some more votes expressing an opinion one way or
> > the other.
> >
> > *Everyone* is invited to cast a vote for or against the proposal.  PMC
> > members are charged with such project oversight, and committers are
> > expected to participate (hint, hint).
> >
> > Regards,
> > Tim
> >
> > Mikhail Loenko 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.
> > >
> >
>
>
>

Re: [vote] HARMONY-4689 - JVMTI Extension: Native Code Access Interface implementation

[Mark Hindess <ma...@googlemail.com>]

+1 for both acceptance and integration.  If someone will find it useful
today, then let's integrate it.  If Vasily makes it redundant next month
(and I can debug entirely from gdb) then we can remove it.

-Mark.

On 18 October 2007 at 14:37, Tim Ellison <t....@gmail.com> wrote:
> It would be good to see some more votes expressing an opinion one way or
> the other.
> 
> *Everyone* is invited to cast a vote for or against the proposal.  PMC
> members are charged with such project oversight, and committers are
> expected to participate (hint, hint).
> 
> Regards,
> Tim
> 
> Mikhail Loenko 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.
> > 
> 

Re: [vote] HARMONY-4689 - JVMTI Extension: Native Code Access Interface implementation

[Tim Ellison <t....@gmail.com>]

It would be good to see some more votes expressing an opinion one way or
the other.

*Everyone* is invited to cast a vote for or against the proposal.  PMC
members are charged with such project oversight, and committers are
expected to participate (hint, hint).

Regards,
Tim

Mikhail Loenko 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.
> 

Re: [vote] HARMONY-4689 - JVMTI Extension: Native Code Access Interface implementation

[Stepan Mishura <st...@gmail.com>]

+1

-Stepan.

On 10/12/07, Mikhail Loenko <ml...@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.
>

Re: [vote] HARMONY-4689 - JVMTI Extension: Native Code Access Interface implementation

[Mikhail Loenko <ml...@gmail.com>]

+1 from Alexei F, Pavel A, Eugene O, Pavel P, Pavel R, Leo, Sean, Tim,
Alexey P, Sian, Mikhail M, Mark, Spark, Stepan, Andrey P, Mikhail L

no votes against

accepted

2007/10/12, Mikhail Loenko <ml...@gmail.com>:
> 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.
>

Re: [vote] HARMONY-4689 - JVMTI Extension: Native Code Access Interface implementation

[Sean Qiu <se...@gmail.com>]

+1 to accept NCAI .
 It is worth my deep study.

2007/10/15, Leo Li <li...@gmail.com>:
>
> +1 to accept the NCAI. Debugging native in java is always a trouble
> not only for us but user as well.
>
> On 10/14/07, Ilya Berezhniuk <il...@gmail.com> wrote:
> > Hi all,
> >
> > Let me speak to NCAI debugging approach.
> >
> > 1) JVMTI is implemented using self-process debugging; it will never be
> > implemented by another way, I guess. So NCAI merely extends JVMTI
> > approach to native code debugging.
> > Using external debugger for debugging native code will lead to using 2
> > different debuggers simultaneously - it can lead to conflicts between
> > the debuggers.
> >
> > 2) Any debugger should be aware about some VM internals when debugging
> > JNI code. So external debugger would use some callbacks functions in
> > VM. But those callbacks would be not for debugging itself, but for
> > exposing some raw info about VM internals. Quite the opposite, NCAI is
> > well defined debug interface which provides processed data in a form
> > like JVMTI does.
> >
> >
> > 2007/10/12, Pavel Pervov <pm...@gmail.com>:
> > > +1 for accepting it now. NCAI is a good extension to mechanisms
> naturally
> > > provided by Java debugger.
> > >
> > > On 10/12/07, Mikhail Loenko <ml...@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.
> > > >
> > >
> > >
> > >
> > > --
> > > Pavel Pervov,
> > > Intel Enterprise Solutions Software Division
> > >
> >
> >
> > --
> >
> > Ilya
> >
>
>
> --
> Leo Li
> China Software Development Lab, IBM
>



-- 
Sean Qiu
China Software Development Lab, IBM

Re: [vote] HARMONY-4689 - JVMTI Extension: Native Code Access Interface implementation

[Leo Li <li...@gmail.com>]

+1 to accept the NCAI. Debugging native in java is always a trouble
not only for us but user as well.

On 10/14/07, Ilya Berezhniuk <il...@gmail.com> wrote:
> Hi all,
>
> Let me speak to NCAI debugging approach.
>
> 1) JVMTI is implemented using self-process debugging; it will never be
> implemented by another way, I guess. So NCAI merely extends JVMTI
> approach to native code debugging.
> Using external debugger for debugging native code will lead to using 2
> different debuggers simultaneously - it can lead to conflicts between
> the debuggers.
>
> 2) Any debugger should be aware about some VM internals when debugging
> JNI code. So external debugger would use some callbacks functions in
> VM. But those callbacks would be not for debugging itself, but for
> exposing some raw info about VM internals. Quite the opposite, NCAI is
> well defined debug interface which provides processed data in a form
> like JVMTI does.
>
>
> 2007/10/12, Pavel Pervov <pm...@gmail.com>:
> > +1 for accepting it now. NCAI is a good extension to mechanisms naturally
> > provided by Java debugger.
> >
> > On 10/12/07, Mikhail Loenko <ml...@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.
> > >
> >
> >
> >
> > --
> > Pavel Pervov,
> > Intel Enterprise Solutions Software Division
> >
>
>
> --
>
> Ilya
>


-- 
Leo Li
China Software Development Lab, IBM

Re: [vote] HARMONY-4689 - JVMTI Extension: Native Code Access Interface implementation

[Ilya Berezhniuk <il...@gmail.com>]

Hi all,

Let me speak to NCAI debugging approach.

1) JVMTI is implemented using self-process debugging; it will never be
implemented by another way, I guess. So NCAI merely extends JVMTI
approach to native code debugging.
Using external debugger for debugging native code will lead to using 2
different debuggers simultaneously - it can lead to conflicts between
the debuggers.

2) Any debugger should be aware about some VM internals when debugging
JNI code. So external debugger would use some callbacks functions in
VM. But those callbacks would be not for debugging itself, but for
exposing some raw info about VM internals. Quite the opposite, NCAI is
well defined debug interface which provides processed data in a form
like JVMTI does.


2007/10/12, Pavel Pervov <pm...@gmail.com>:
> +1 for accepting it now. NCAI is a good extension to mechanisms naturally
> provided by Java debugger.
>
> On 10/12/07, Mikhail Loenko <ml...@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.
> >
>
>
>
> --
> Pavel Pervov,
> Intel Enterprise Solutions Software Division
>


-- 

Ilya

Re: [vote] HARMONY-4689 - JVMTI Extension: Native Code Access Interface implementation

[Pavel Pervov <pm...@gmail.com>]

+1 for accepting it now. NCAI is a good extension to mechanisms naturally
provided by Java debugger.

On 10/12/07, Mikhail Loenko <ml...@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.
>



-- 
Pavel Pervov,
Intel Enterprise Solutions Software Division

Re: [vote] HARMONY-4689 - JVMTI Extension: Native Code Access Interface implementation

["Pavlenko, Andrey A" <an...@googlemail.com>]

+1 for accepting.

On 10/12/07, Mikhail Loenko <ml...@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.
>

Re: [vote] HARMONY-4689 - JVMTI Extension: Native Code Access Interface implementation

[Eugene Ostrovsky <eu...@gmail.com>]

+1 Accept this contribution

Thanks,
Eugene.

On 10/12/07, Pavel Afremov <pa...@gmail.com> wrote:
> +1 to accept this contribution
>
> It could be helpful for me.
>
> BR.
> Pavel Afremov.
>
> On 10/12/07, Alexei Fedotov <al...@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.
> >
> > 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 <va...@gmail.com> wrote:
> > > On 10/12/07, Alexei Fedotov <al...@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 <va...@gmail.com> wrote:
> > > > > On 10/12/07, Alexei Fedotov <al...@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 <va...@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 <ml...@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
> >
>

Re: [vote] HARMONY-4689 - JVMTI Extension: Native Code Access Interface implementation

[Pavel Afremov <pa...@gmail.com>]

+1 to accept this contribution

It could be helpful for me.

BR.
Pavel Afremov.

On 10/12/07, Alexei Fedotov <al...@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.
>
> 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 <va...@gmail.com> wrote:
> > On 10/12/07, Alexei Fedotov <al...@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 <va...@gmail.com> wrote:
> > > > On 10/12/07, Alexei Fedotov <al...@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 <va...@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 <ml...@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
>

Re: Thoughts...

[Tim Ellison <t....@gmail.com>]

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 <t....@gmail.com> 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 <al...@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 <va...@gmail.com> wrote:
>>>>> On 10/12/07, Alexei Fedotov <al...@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 <va...@gmail.com> wrote:
>>>>>>> On 10/12/07, Alexei Fedotov <al...@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 <va...@gmail.com>
>>>> wrote:
>>>>>>>>> On 10/12/07, Alexei Fedotov <al...@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 <va...@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 <ml...@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
>>>>
>>>
>>>
> 
> 
> 

Re: Thoughts... (was: Re: [vote] HARMONY-4689 - JVMTI Extension: Native Code Access Interface implementation)

[Vasily Levchenko <va...@gmail.com>]

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

On 10/12/07, Tim Ellison <t....@gmail.com> 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 <al...@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 <va...@gmail.com> wrote:
> >>> On 10/12/07, Alexei Fedotov <al...@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 <va...@gmail.com> wrote:
> >>>>> On 10/12/07, Alexei Fedotov <al...@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 <va...@gmail.com>
> >> wrote:
> >>>>>>> On 10/12/07, Alexei Fedotov <al...@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 <va...@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 <ml...@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
> >>
> >
> >
> >
>



-- 
--vvl

Re: Thoughts... (was: Re: [vote] HARMONY-4689 - JVMTI Extension: Native Code Access Interface implementation)

[Ilya Berezhniuk <il...@gmail.com>]

Hello Vasily,

Both these approaches (NCAI and external debugger) have their own
advantages. I'll describe a couple of major NCAI advantages:

1) Using two debuggers at once looks risky for me; one debugger
extending JVMTI functionality is safer. There are several areas of
possible conflicts between the debuggers. It's breakpoints handling -
some caught breakpoints should be processed by the external debugger,
and some of them should be delivered to JVMTI. I guess there can be
possible conflicts while working with threads - only VM internal code
can take care of Java threads specifics. There can be other
conflicting areas.

2) AFAIK, gdb cannot enumerate the whole stack of Java thread
correctly, because it cannot continue unwinding native stack below
Java frames. Also gdb is unable to unwind native stack when the code
is called from JVMTI breakpoint/single step handling routine.
Moreover, gdb often provides native stack that is worse than the stack
provided by the heuristic stack walker I've implemented for NCAI.
(This stack walker is already integrated for using by the crash
handler, so NCAI Frame functions are simply wrappers.)
To tell the truth, the above statement is correct for IA-32; AMD64
calling conventions prevent heuristic stack unwinding. AFAIU, GDB can
use dwarf stack info for unwinding - so GDB could provide better stack
on x86_64.


2007/10/14, Alexei Fedotov <al...@gmail.com>:
> Hello Vasily,
>
> I like your constructive overview. I agree with you that traversing
> managed frames is quite VM specific and proves to be a problem for
> native debuggers.
>
> To my personal point of view, the complexity of using external thread
> libraries is underestimated in your analysis since VM uses several
> self-made synchronization primitives which do most of the job. For
> example, not far from now gdb on IPF crashed in a simple test.
>
> Windows threading model may prove some unexpected challenges. For
> example, Ivan Volosyuk spent a day trying to understand that our VM
> thread local data should be prefixed with unused field to made
> debugging possible. I faced a number of gdb crashes on Windows.
>
> As for your questions of alternatives, a year ago I investigated cross
> platform alternatives for native frame enumeration. I considered gdb
> and a debugger from Intel compiler. I talked to people who developed
> the debuggers, and then decided to use our internal solution Ilya was
> finalizing.
>
> Thank you for your attention.
>
> BTW, I believe we should not mix two things in our discussion. I like
> if someone will come up with better solution: many places of DRLVM can
> be improved. From the other side casting a vote
>
> BTW2, the file pthread_dbg.h you've provided a reference to doesn't
> have a pure BSD license, see the third item.
>
> On 10/13/07, Vasily Levchenko <va...@gmail.com> wrote:
> > Originally,  Java developers using JNI have to debug their application using
> > two debugger for accessing java and native world(
> > http://www-128.ibm.com/developerworks/java/library/j-jnidebug/index.html,
> > http://developers.sun.com/learning/javaoneonline/2006/tools/TS-1011.pdf).
> > This concept should be the foundation for "mixed" debugger. Native debugger
> > (gdb, adb or other) to debug java world need information how to deal with
> > java stack, other jdb functionality comes almost automatically. Let me start
> > from the final stage of the good "mixed  mode debugger". Ideal mixed mode
> > debugger should open core or dump file of java application  crush  restoring
> > internal state like it do for other application, it should attach and start
> > application in debugging mode. If look on debuggers' history we can see
> > similar task that was done before, e.g. thread handling in debugger. How
> > debugger operates with thread? How it get TSD and TLS from the thread on
> > remote application or core file? A long-long time ago Solaris or Sun OS
> > introduced thread debugging interface libc_db
> > http://docs.sun.com/app/docs/doc/816-5173/6mbb8adsh?l=en&a=view and then it
> > migrated to Linux world (
> > http://sources.redhat.com/cgi-bin/cvsweb.cgi/libc/nptl_db/?cvsroot=glibc)
> > and BSD (http://cvsweb.netbsd.org/bsdweb.cgi/src/lib/libpthread_dbg/) world
> > (thread_db). This library inform debugger how to fetch thread information
> > from core file or debugee process. Similar approach could be done with java
> > world but before we need several baby steps.
> >
> > Short-term:
> > 1. Using JVMTI possibilities provide information for debugger to operate
> > with the java stack
> > 2. Provide debugger operations throw JVMTI (break points, watch points and
> > so on)
> >
> > Result construction could used as a source for a long solution described as
> > ideal mixed-mode-debugger.
> >
> > BTW: here some links about ready to use short-term solutions:
> > http://www.hp.com/products1/unix/java/pdfs/07_06Tools_NativeDebug.pdf
> > http://docs.sun.com/source/819-3683/Java_debug.html
> >
> > On 10/12/07, Tim Ellison <t....@gmail.com> 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 <al...@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 <al...@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 <al...@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 <va...@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 <va...@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
> > > >>
> > > >
> > > >
> > > >
> > >
> >
> >
> >
> > --
> > --vvl
> >
>
>
> --
> With best regards,
> Alexei,
> ESSD, Intel
>


-- 

Ilya

Re: Thoughts... (was: Re: [vote] HARMONY-4689 - JVMTI Extension: Native Code Access Interface implementation)

[Alexei Fedotov <al...@gmail.com>]

Hello Vasily,

I like your constructive overview. I agree with you that traversing
managed frames is quite VM specific and proves to be a problem for
native debuggers.

To my personal point of view, the complexity of using external thread
libraries is underestimated in your analysis since VM uses several
self-made synchronization primitives which do most of the job. For
example, not far from now gdb on IPF crashed in a simple test.

Windows threading model may prove some unexpected challenges. For
example, Ivan Volosyuk spent a day trying to understand that our VM
thread local data should be prefixed with unused field to made
debugging possible. I faced a number of gdb crashes on Windows.

As for your questions of alternatives, a year ago I investigated cross
platform alternatives for native frame enumeration. I considered gdb
and a debugger from Intel compiler. I talked to people who developed
the debuggers, and then decided to use our internal solution Ilya was
finalizing.

Thank you for your attention.

BTW, I believe we should not mix two things in our discussion. I like
if someone will come up with better solution: many places of DRLVM can
be improved. From the other side casting a vote

BTW2, the file pthread_dbg.h you've provided a reference to doesn't
have a pure BSD license, see the third item.

On 10/13/07, Vasily Levchenko <va...@gmail.com> wrote:
> Originally,  Java developers using JNI have to debug their application using
> two debugger for accessing java and native world(
> http://www-128.ibm.com/developerworks/java/library/j-jnidebug/index.html,
> http://developers.sun.com/learning/javaoneonline/2006/tools/TS-1011.pdf).
> This concept should be the foundation for "mixed" debugger. Native debugger
> (gdb, adb or other) to debug java world need information how to deal with
> java stack, other jdb functionality comes almost automatically. Let me start
> from the final stage of the good "mixed  mode debugger". Ideal mixed mode
> debugger should open core or dump file of java application  crush  restoring
> internal state like it do for other application, it should attach and start
> application in debugging mode. If look on debuggers' history we can see
> similar task that was done before, e.g. thread handling in debugger. How
> debugger operates with thread? How it get TSD and TLS from the thread on
> remote application or core file? A long-long time ago Solaris or Sun OS
> introduced thread debugging interface libc_db
> http://docs.sun.com/app/docs/doc/816-5173/6mbb8adsh?l=en&a=view and then it
> migrated to Linux world (
> http://sources.redhat.com/cgi-bin/cvsweb.cgi/libc/nptl_db/?cvsroot=glibc)
> and BSD (http://cvsweb.netbsd.org/bsdweb.cgi/src/lib/libpthread_dbg/) world
> (thread_db). This library inform debugger how to fetch thread information
> from core file or debugee process. Similar approach could be done with java
> world but before we need several baby steps.
>
> Short-term:
> 1. Using JVMTI possibilities provide information for debugger to operate
> with the java stack
> 2. Provide debugger operations throw JVMTI (break points, watch points and
> so on)
>
> Result construction could used as a source for a long solution described as
> ideal mixed-mode-debugger.
>
> BTW: here some links about ready to use short-term solutions:
> http://www.hp.com/products1/unix/java/pdfs/07_06Tools_NativeDebug.pdf
> http://docs.sun.com/source/819-3683/Java_debug.html
>
> On 10/12/07, Tim Ellison <t....@gmail.com> 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 <al...@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 <al...@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 <al...@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 <va...@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 <va...@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
> > >>
> > >
> > >
> > >
> >
>
>
>
> --
> --vvl
>


-- 
With best regards,
Alexei,
ESSD, Intel

Re: Thoughts...

[Tim Ellison <t....@gmail.com>]

Vasily Levchenko wrote:
> Originally,  Java developers using JNI have to debug their application using
> two debugger for accessing java and native world(
> http://www-128.ibm.com/developerworks/java/library/j-jnidebug/index.html,
> http://developers.sun.com/learning/javaoneonline/2006/tools/TS-1011.pdf).
> This concept should be the foundation for "mixed" debugger. Native debugger
> (gdb, adb or other) to debug java world need information how to deal with
> java stack, other jdb functionality comes almost automatically.

I understand the issue well enough; it's been a wish for years when
running 'managed' and native code to have a debugger that can cross the
boundary seamlessly, so I'm very excited to see this is being addressed.

> Let me start
> from the final stage of the good "mixed  mode debugger". Ideal mixed mode
> debugger should open core or dump file of java application  crush  restoring
> internal state like it do for other application, it should attach and start
> application in debugging mode. If look on debuggers' history we can see
> similar task that was done before, e.g. thread handling in debugger. How
> debugger operates with thread? How it get TSD and TLS from the thread on
> remote application or core file? A long-long time ago Solaris or Sun OS
> introduced thread debugging interface libc_db
> http://docs.sun.com/app/docs/doc/816-5173/6mbb8adsh?l=en&a=view and then it
> migrated to Linux world (
> http://sources.redhat.com/cgi-bin/cvsweb.cgi/libc/nptl_db/?cvsroot=glibc)
> and BSD (http://cvsweb.netbsd.org/bsdweb.cgi/src/lib/libpthread_dbg/) world
> (thread_db). This library inform debugger how to fetch thread information
> from core file or debugee process. Similar approach could be done with java
> world but before we need several baby steps.

Agreed, and this is going to be highly VM-specific, i.e. you likely want
to poke about in the VM data structures for crash diagnosis, so expect
it to be a build-specific tool.

> Short-term:
> 1. Using JVMTI possibilities provide information for debugger to operate
> with the java stack
> 2. Provide debugger operations throw JVMTI (break points, watch points and
> so on)
> 
> Result construction could used as a source for a long solution described as
> ideal mixed-mode-debugger.
> 
> BTW: here some links about ready to use short-term solutions:
> http://www.hp.com/products1/unix/java/pdfs/07_06Tools_NativeDebug.pdf
> http://docs.sun.com/source/819-3683/Java_debug.html

So I was just suggesting that, based on what I read on this thread, some
people wanted to discuss the topic before deciding on a vote to accept
this contribution.  I'm not suggesting the code would/would not be
accepted, but its usually better to discuss the viability before the
vote rather than afterwards.

Regards,
Tim

> On 10/12/07, Tim Ellison <t....@gmail.com> 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 <al...@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 <al...@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 <al...@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 <va...@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 <va...@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
>>>>
>>>
>>>
> 
> 
> 

Re: Thoughts... (was: Re: [vote] HARMONY-4689 - JVMTI Extension: Native Code Access Interface implementation)

[Vasily Levchenko <va...@gmail.com>]

Originally,  Java developers using JNI have to debug their application using
two debugger for accessing java and native world(
http://www-128.ibm.com/developerworks/java/library/j-jnidebug/index.html,
http://developers.sun.com/learning/javaoneonline/2006/tools/TS-1011.pdf).
This concept should be the foundation for "mixed" debugger. Native debugger
(gdb, adb or other) to debug java world need information how to deal with
java stack, other jdb functionality comes almost automatically. Let me start
from the final stage of the good "mixed  mode debugger". Ideal mixed mode
debugger should open core or dump file of java application  crush  restoring
internal state like it do for other application, it should attach and start
application in debugging mode. If look on debuggers' history we can see
similar task that was done before, e.g. thread handling in debugger. How
debugger operates with thread? How it get TSD and TLS from the thread on
remote application or core file? A long-long time ago Solaris or Sun OS
introduced thread debugging interface libc_db
http://docs.sun.com/app/docs/doc/816-5173/6mbb8adsh?l=en&a=view and then it
migrated to Linux world (
http://sources.redhat.com/cgi-bin/cvsweb.cgi/libc/nptl_db/?cvsroot=glibc)
and BSD (http://cvsweb.netbsd.org/bsdweb.cgi/src/lib/libpthread_dbg/) world
(thread_db). This library inform debugger how to fetch thread information
from core file or debugee process. Similar approach could be done with java
world but before we need several baby steps.

Short-term:
1. Using JVMTI possibilities provide information for debugger to operate
with the java stack
2. Provide debugger operations throw JVMTI (break points, watch points and
so on)

Result construction could used as a source for a long solution described as
ideal mixed-mode-debugger.

BTW: here some links about ready to use short-term solutions:
http://www.hp.com/products1/unix/java/pdfs/07_06Tools_NativeDebug.pdf
http://docs.sun.com/source/819-3683/Java_debug.html

On 10/12/07, Tim Ellison <t....@gmail.com> 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 <al...@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 <al...@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 <al...@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 <va...@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 <va...@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
> >>
> >
> >
> >
>



-- 
--vvl

Re: Thoughts...

[Tim Ellison <t....@gmail.com>]

Mikhail Loenko wrote:
> The first reason is to be consistent with the past. I'm reluctant to list
> contributions that we accepted but did not intergrated, but still we have
> precedents.

For sure, though there are some things we try not to be consistent on ;-)

> The second reason is flexibility that we gain once we accept the code:
> then if someone finds that for example 10-lines of some utility code can
> be reused elsewhere, they can simply copy-paste it to SVN.
> 
> If for technical reasons we decline the contribution, then we don't
> have such a flexibility

Understood, and as I said, I am not opposed to the contribution, I'm
just taking a little time to understand it.  The vote should reflect
both the housekeeping duties have been considered, of it being a
presented with the right paperwork etc, *and* that it is in keeping with
the goals and direction of the project.

Apologies that I'm always the slow one in getting to that place :*)

Regards,
Tim

Re: [offlist] Re: Thoughts...

[Mikhail Loenko <ml...@gmail.com>]

2007/10/15, Tim Ellison <t....@gmail.com>:
> Tim Ellison wrote:
> > off-list for a momnent, but I may raise this on the list too...
>
> then I guess I should have changed the address line too ;-)

LOL


>
> I was trying to avoid a meta-discussion in the voting thread, and have
> really messed it up now, d'oh.
>
> Enjoy anyway!
> Tim
>

The first reason is to be consistent with the past. I'm reluctant to list
contributions that we accepted but did not intergrated, but still we have
precedents.

The second reason is flexibility that we gain once we accept the code:
then if someone finds that for example 10-lines of some utility code can
be reused elsewhere, they can simply copy-paste it to SVN.

If for technical reasons we decline the contribution, then we don't
have such a flexibility

Thanks,
Mikhail

Re: [offlist] Re: Thoughts...

[Tim Ellison <t....@gmail.com>]

Tim Ellison wrote:
> off-list for a momnent, but I may raise this on the list too...

then I guess I should have changed the address line too ;-)

I was trying to avoid a meta-discussion in the voting thread, and have
really messed it up now, d'oh.

Enjoy anyway!
Tim

[offlist] Re: Thoughts...

[Tim Ellison <t....@gmail.com>]

off-list for a momnent, but I may raise this on the list too...

Mikhail Loenko wrote:
> 2007/10/13, Tim Ellison <t....@gmail.com>:
>> 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?
> 
> I think this is a separate discussion: accepting contribution is
> something formal, not technical thing.

Why do you say that?  It is both 'formal' (as described below) and
technical (i.e. this is something we should commit and work on).

> We should check whether
> contribution relates to the project, whether we have questions
> to authorship or origin of the code, etc
> 
> If we accept contribution we may have a technical discussion,
> which parts worth integration, etc.

What if we then think this is a bad idea?  I don't think it *is* a bad
idea, quite the opposite, but I don't see why you wouldn't have the
debate first then decide to take it into the project.

> So I suggest that we continue both vote and the technical discussion

Maybe I misread the discussion -- is there an alternative being proposed
or not?  I though there was at first, but now I reread the thread it
seems not.

Regards,
Tim

Re: Thoughts...

[Gregory Shimansky <gs...@apache.org>]

Mikhail Loenko wrote:
> 2007/10/13, Tim Ellison <t....@gmail.com>:
>> 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?
> 
> I think this is a separate discussion: accepting contribution is
> something formal, not technical thing. We should check whether
> contribution relates to the project, whether we have questions
> to authorship or origin of the code, etc
> 
> If we accept contribution we may have a technical discussion,
> which parts worth integration, etc.
> 
> So I suggest that we continue both vote and the technical discussion

I want to agree with Mikhail.

+1 to formally accepting contribution code.

Let's move technical discussion to a different thread.

-- 
Gregory

Re: Thoughts... (was: Re: [vote] HARMONY-4689 - JVMTI Extension: Native Code Access Interface implementation)

[Mikhail Loenko <ml...@gmail.com>]

2007/10/13, Tim Ellison <t....@gmail.com>:
> 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?

I think this is a separate discussion: accepting contribution is
something formal, not technical thing. We should check whether
contribution relates to the project, whether we have questions
to authorship or origin of the code, etc

If we accept contribution we may have a technical discussion,
which parts worth integration, etc.

So I suggest that we continue both vote and the technical discussion

Thanks,
Mikhail


>
> Regards,
> Tim
>
> Vasily Levchenko wrote:
> > On 10/12/07, Alexei Fedotov <al...@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 <va...@gmail.com> wrote:
> >>> On 10/12/07, Alexei Fedotov <al...@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 <va...@gmail.com> wrote:
> >>>>> On 10/12/07, Alexei Fedotov <al...@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 <va...@gmail.com>
> >> wrote:
> >>>>>>> On 10/12/07, Alexei Fedotov <al...@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 <va...@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 <ml...@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
> >>
> >
> >
> >
>

Thoughts... (was: Re: [vote] HARMONY-4689 - JVMTI Extension: Native Code Access Interface implementation)

[Tim Ellison <t....@gmail.com>]

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 <al...@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 <va...@gmail.com> wrote:
>>> On 10/12/07, Alexei Fedotov <al...@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 <va...@gmail.com> wrote:
>>>>> On 10/12/07, Alexei Fedotov <al...@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 <va...@gmail.com>
>> wrote:
>>>>>>> On 10/12/07, Alexei Fedotov <al...@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 <va...@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 <ml...@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
>>
> 
> 
> 

Re: [vote] HARMONY-4689 - JVMTI Extension: Native Code Access Interface implementation

[Vasily Levchenko <va...@gmail.com>]

On 10/12/07, Alexei Fedotov <al...@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 <va...@gmail.com> wrote:
> > On 10/12/07, Alexei Fedotov <al...@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 <va...@gmail.com> wrote:
> > > > On 10/12/07, Alexei Fedotov <al...@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 <va...@gmail.com>
> wrote:
> > > > > > On 10/12/07, Alexei Fedotov <al...@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 <va...@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 <ml...@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
>



-- 
--vvl

Re: [vote] HARMONY-4689 - JVMTI Extension: Native Code Access Interface implementation

[Alexei Fedotov <al...@gmail.com>]

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.
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 <va...@gmail.com> wrote:
> On 10/12/07, Alexei Fedotov <al...@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 <va...@gmail.com> wrote:
> > > On 10/12/07, Alexei Fedotov <al...@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 <va...@gmail.com> wrote:
> > > > > On 10/12/07, Alexei Fedotov <al...@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 <va...@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 <ml...@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

Re: [vote] HARMONY-4689 - JVMTI Extension: Native Code Access Interface implementation

[Vasily Levchenko <va...@gmail.com>]

On 10/12/07, Alexei Fedotov <al...@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 <va...@gmail.com> wrote:
> > On 10/12/07, Alexei Fedotov <al...@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 <va...@gmail.com> wrote:
> > > > On 10/12/07, Alexei Fedotov <al...@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 <va...@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 <ml...@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

Re: [vote] HARMONY-4689 - JVMTI Extension: Native Code Access Interface implementation

[Alexei Fedotov <al...@gmail.com>]

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 <va...@gmail.com> wrote:
> On 10/12/07, Alexei Fedotov <al...@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 <va...@gmail.com> wrote:
> > > On 10/12/07, Alexei Fedotov <al...@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 <va...@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 <ml...@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

Re: [vote] HARMONY-4689 - JVMTI Extension: Native Code Access Interface implementation

[Vasily Levchenko <va...@gmail.com>]

On 10/12/07, Alexei Fedotov <al...@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 <va...@gmail.com> wrote:
> > On 10/12/07, Alexei Fedotov <al...@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 <va...@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 <ml...@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

Re: [vote] HARMONY-4689 - JVMTI Extension: Native Code Access Interface implementation

[Alexei Fedotov <al...@gmail.com>]

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.

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. Having a level of internal
reflection from inside VM is very important to express assertions
about correct VM state for a debug build.

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.

Thanks.


On 10/12/07, Vasily Levchenko <va...@gmail.com> wrote:
> On 10/12/07, Alexei Fedotov <al...@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 <va...@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 <ml...@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

Re: [vote] HARMONY-4689 - JVMTI Extension: Native Code Access Interface implementation

[Vasily Levchenko <va...@gmail.com>]

On 10/12/07, Alexei Fedotov <al...@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 <va...@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 <ml...@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

Re: [vote] HARMONY-4689 - JVMTI Extension: Native Code Access Interface implementation

[Alexei Fedotov <al...@gmail.com>]

+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.



On 10/12/07, Vasily Levchenko <va...@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 <ml...@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

Re: [vote] HARMONY-4689 - JVMTI Extension: Native Code Access Interface implementation

[Vasily Levchenko <va...@gmail.com>]

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 <ml...@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

Re: [vote] HARMONY-4689 - JVMTI Extension: Native Code Access Interface implementation

[Mikhail Markov <mi...@gmail.com>]

+1 for accepting the contribution.

Thanks,
Mikhail

On 10/12/07, Mikhail Loenko <ml...@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.
>

Re: [vote] HARMONY-4689 - JVMTI Extension: Native Code Access Interface implementation

[Pavel Rebriy <pa...@gmail.com>]

+1 for NCA (it helps me to debug)
+1 for separate technical discussion

On 12/10/2007, Mikhail Loenko <ml...@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.
>



-- 
Best regards,
Pavel Rebriy