[DGD] Java or LPC (DGD)?

[Sampsa Ranta]

On Sun, 17 Aug 2003, Felix A. Croes wrote:

> Tavis Elliott <tavise at nwlink.com> wrote:
>
> > To weigh in on the bytecode update issue (Java has also been my primary
> > development language for quite some time) ... I would advise checking into
> > the JDI interface for Java 1.4, there are mechanisms for runtime
> > replacement of bytecodes that don't require horrendous fancy ClassLoader
> > schemes.  Granted they are 'debug' interfaces, and there are still
> > questions about introducing runtime problems, but they are easier than some
> > of the solutions already discussed.
>
> The JDI itself is pure Java, but the way it works isn't.

This is defined in Java Platform, the reference implementation is not pure
Java, that I can agree on. Nothing prevents you implementing JVM by Java,
tho, of course this might be overhead for now.. =)

http://java.sun.com/j2se/1.4.1/docs/guide/jpda/enhancements.html
"
Enable "HotSwap" Class File Replacement

    This new feature encapsulates the ability to substitute modified code
in a running application through the debugger APIs. For example, one can
recompile a single class and replace the old instance with the new
instance.

    This change was made to address these issues:

        * Tool (IDE) vendors want the ability to do fix-and-continue
debugging. That is, while debugging, identify a problem, fix it, and
continue debugging with fixed code.
        * Organizations deploying long running servers wish to be able to
fix bugs without taking down the server.

    HotSwap adds functionality to the JavaTM Platform Debugger
Architecture (JPDA) to allow a class to be updated while under the control
of a debugger. The two central components of this functionality are
RedefineClasses which replaces the class definitions and PopFrame which
pops frames off the stack allowing a method which has been redefined to be
re-executed.

    In the reference implementation, this functionality is implemented at
the Java Virtual Machine Debug Interface (JVMDI) layer and made available
through the higher layers of JPDA - the Java Debug Wire Protocol (JDWP)
and the Java Debug Interface (JDI).
"

Clearly the people behind this are not lobbying this as a big thing or
don't see the real needs objectivedly as they might have never coded
muds with DGD and seen requirements for environments ment for continous
use without restarts.. =)

But it's good this interface comes planned as part of the Java Platform so
the common interface can be used.

As stated in my original message, the reference implementation is not
always the best way. From my experiences I've learned that something once
coded as reference implementation can be read by other person and
second or thrid refactoring round will make it much more smooth...

So the JDI API might do the thing, the under hood reference implementation
has the stink of new and raw thing as usual.. =)

Anyway, one can design and implement DGD like behaviour under Java with
this stuff and when more decent implementation comes in hand, if JDI level
was used, upgrading process will be pretty straightforward.

> Sun's Java VM defines a debugger interface called JVMDI.  This is a
> C-level interface.  When using JDI to debug, you communicate with a
> backend which interfaces with JVMDI -- and which therefore is written
> in C.

Well, this is again reference implementation, JDI does not require JVMDI
ideology to be used.

I guess GCJ folks might do this different way, the project is more C++
related so C API might be just overhead API over the real one. And IBM
fellows sometimes bang heads together in proper order, it is of course
easier to say that "Hey, our code beats easily your original code!"
because the original code had nothing to compare to..

Nothing says that JVM must be "software based" or C-level things, there
are native Java bytecode based platforms, too..

> The JVM which the JDI executes on is distinct from the JVM that you are
> debugging.  And the JVMDI interface is optional -- JVMs are not required
> to implement it.

"JVMDI clients run in the same virtual machine as the application being
debugged and access JVMDI through a native interface. The native,
in-process interface allows maximal control with minimal intrusion on the
part of a debugging tool. Typically, JVMDI clients are relatively compact.
They can be controlled by a separate process which implements the bulk of
a debugger's function without interfering with the target application's
normal execution."

Nothing says that it is REQUIRED to run on different virtual machine..

> If we are going to make comparisions on this level, I request that I
> be allowed to run one DGD process within gdb, communicating through a
> C backend with another DGD process :)  Still, the JVMDI interface
> <does> include a RedefineClasses function which performs exactly
> the upgrade function that was being discussed.  At the JDI level,
> the method is called redefineClasses().  The documentation is at

I am not sure weather we are doing comparison or I was trying to make a
point of anything, my point was to give review the technologies used and
give basic idea what one can do and implement under what environment..

Running DGD under gdb gave some advantage at the time it crashed, I
recall.. =)

Anyway, you, Felix, have done nice thinking even before Java world emerged
and DGD gave me good lessons on this stuff... =) Nowadays I need
solutions that can be easily introduced to business(commercial) world and
integrates with more systems on commonly used language.

However the systems lack part of the functionality DGD gave me but if I
had a point, it was that nowadays the Java world is gaining rapidly on
DGD and most things could be implemented..

Not that I would encourage anyone to do exact copy but rather to do even
better if possible, that would be called evolving! =)

Yours,
 Sampsa Ranta


_________________________________________________________________
List config page:  http://list.imaginary.com/mailman/listinfo/dgd