Minutes for meeting 2007-07-11

[Elena Zannoni <elena dot zannoni at oracle dot com>]

Andrew, Mark, Tim, Elena, Phil, Rick, Adam, Teresa, Sami.

cni-> jni code because cni will not be supported any longer.
Jni not as efficiant and straightforward.
Are there performance issues? 
If so maybe move the bindings to a higher level into the core.
Move more stuff to C++.

Mark: CNI: you can just access a field. C++ and Java part will be the
same. If there is an array[], lock the array, ask for the element,
java array-> c++ array, lock again, put the element, etc. Much more
cumbersome. Java side more efficient, but for any access you have to
convert any data to c++.

Simple data type-> convert into integers. Even string converting is
kind of complicated.

Callbacks: C code calling Java code: Same thing: cannot just call a
Java method. first have to ask the class of the object, then the
identifier of the function, then the types, then call it. So also this
one not easy.

Beyond native function calls, it quickly gets inefficient.  You can do
caching.

If you move a lot into the C side and do not call back on the java
side, then return only one result and do calculation on java
side then it's not too bad, but small methods, and lots of cross language
calls, is very inefficient.

No good reflection because using CNI, if JNI used reflection is
better. Fix is maybe prelink everything into a .so lib so that nothing
gets lost.

Elf bindings have serious memory smashing, Reproducible: exception
thrown -> stdin gets closed. Elfutils clobbers memory leading to a FD
being closed.

Bindings are complex at the moment, JNI would add further to this
complexity. 

This would also move us away from gcj.

JNI: you also pass around the whole Java environment, the entire context.
Java Gnome is JNI code.

JNI: code is part of the VM that is in the executable, it's an
interpreter.  Interpreter has the machine in itself. Environment is
a pointer to the VM, plus some more stuff.


This will force us to have thinner bindings. (see java gnome bindings,
are thinner).


When is this change going to happen? Around end of 2007.

CNI users: Frysk, libgcj



Roundtable:
----------


Teresa: new implementation of finding debuginfo. Change design
pattern. libdwlf use something higher level and not do deep into the
library.

Interface change for looking up the debuginfo. Refactoring, and split
it up, oo it becomes easier for other users to plug into it, if needed
and easier to customize it.  Elfutils calls this code.

Pulling separate debuginfo is currently inefficient. Computing CRC
multiple times. Maybe use Hash to match debuginfo and executable instead.


Sami: print values of vars and params. Found bug, fixed it. Printing
var and values from previous frame. Pretty much done, except for 64
bit bug printing variables. Code is not command line specific.

Mark: finishing the step out of line framework. Chasing a bug. Display
value test fails -> Adam's code. Fails an assert. 
Frysk doesn't pull all breakpoints.

Rick: CDT parser problems. Macros handling related.  Pull in new
version of the CDT parser soon. How tightly integrated is it with the
eclipse core? Rick asking the eclipse people to see if they can split
it up more. Filed soe GUI bugs, working on those. Moving session
manager where both gui and cli can get at it. THey both can be session
aware.  Eggtray icon seems to have disappeared on fc6 and fc7, visible
on fc5.

Phil: testing 32 bit corefiles and 64 bit core files also on cross
platforms.  And with different endiannes.  


32x64 bit tests are disabled for live 32 bit processes on 64 bit
platforms. Can this be re-enabled.  Use --arch to enable.
Nurdin is comfortable with doing this.
Also you can run the whole testsuite twice. But Andrew suggests to
just do the first one for now.

Tim: look at breakpoints for different processes and threads for the
HPD. Tim working in RT, could go anywhere, Andrew says move it to
frysk.session. More refactoring!


Adam: working on display command on HPD. Include actionpoint commands
increase robustness and making it match the spec.


Andrew: Elfutils: problems with exceptions. 

libunwind bindings: exceptions thrown: reduced the number of
cases. Code no longer thowrs exceptions, if it does it will be java
exception.


Elf objects are held on for a long time. How long are they around? the
FD is held on. Should look into that.

dwfl cache is now per therad. It cleans up at the end of each
testrun. There are no dwfl objects left around. Code is still relying
on dwfl objecs being open for a long period of time. Cache algorithm
is simple minded. Nurdin looking at this. Correct alg. is to clone
the dwfl to contain the latest proc information. Dwfl will remain
open but internally will be more eficient.

Why cannot dwarf contructor open its own elf object?
Managing of dwfl, dwarf, elf objects seems not optimal. SHould be audited.