Manipulate objects in heap
habib
I would like to access and manipulate live objects in heap directly in
a Java program.
Does the Sun JVM or other implementations of JVM allow this via their
APIs or I need to edit source code of an implementation and create some
APIs for this need?
Thank you in advance,
Habib
Stefan Schulz
class Foo {
int x = 5;
public int setX(int newX){
x = newX;
}
}
calling setX will manipulate the x field, which is in the heap. However,
i do not know if this is what you wanted to do. What do you want to do?
--
You can't run away forever,
But there's nothing wrong with getting a good head start.
--- Jim Steinman, "Rock and Roll Dreams Come Through"
habib
to edit the heap in some way.
Anyway, thank you for your reply.
Habib
Oliver Wong
"habib" <habib...@gmail.com> wrote in message
news:1129878901....@g43g2000cwa.googlegroups.com...
> Hi there,
> I would like to access and manipulate live objects in heap directly in
> a Java program.
> Does the Sun JVM or other implementations of JVM allow this via their
> APIs or I need to edit source code of an implementation and create some
> APIs for this need?
> Habib
>
"habib" <habib...@gmail.com> wrote in message
news:1129910760.6...@g14g2000cwa.googlegroups.com...
>I need to add a method to a class, for example, in runtime. So, I need
> to edit the heap in some way.
To answer your original question, I don't think there's an API provided
to do what you want to do.
I'm also curious as to why you *need* to add methods to a class. I'm
pretty sure whatever you want to do by adding methods to a class at runtime
can be done without adding methods to a class at runtime (my evidence is
Turing-Completeness of the Java language), so as Stefan mentioned in an
earlier post:
"Stefan Schulz" <te...@spacetime.de> wrote in message
news:pan.2005.10.21....@spacetime.de...
> What do you want to do?
- Oliver
Andrew Thompson
> I'm also curious as to why you *need* to add methods to a class.
To the OP. Can you fill in the blank?
This feature provides ______ to the end user.
[ I think that will help us all understand what you are
trying to achieve. ]
Thomas Fritsch
to a class at runtime.
The only place I know of, where such things are done, are profilers or
coverage tools. Such tools hook themselves into class-loading and add
some byte-code to the loaded classes. Since Java1.5 there is package
java.lang.instrument, which makes developing of such tools easier.
<http://java.sun.com/j2se/1.5.0/docs/api/java/lang/instrument/package-summary.html>
But I very much doubt, that your application falls into this category.
--
"Thomas:Fritsch$ops:de".replace(':','.').replace('$','@')
habib
It sounds all of you intersted in my reason of changing classes in
runtime.
If we could so, we could change software without stopping it and
therefore avalibility becomes higher.
Anyway, thank you for your replies.
Ross Bamford
Whether you can do exactly what you want to do depends on a number of
factors, such as:
+ is the class final?
+ do you need data from existing instances, or new instances with new
features?
+ Are you in a security managed environment? Do you have the ability to
set permissions?
There is an open source API to do what you want to do -
http://jen.dev.java.net/ . It can do pretty much anything to a class
(including at runtime) but whether you can then do anything with the
result very much depends on the answers you gave above.
The other question is, do you want to add a method to a class, or create a
subclass with a new method? Again, you can do both, but the above
questions have a bearing on how you use the result, and which of the
provided tools will do the job.
--
Ross Bamford - ro...@roscopeco.remove.co.uk
Oliver Wong
Well, presumably, not only will you then need to add methods to a class,
but also to somehow modify existing methods. Or else how do you plan on
calling the newly added methods?
And if you're going to modify existing methods, you might have to
untangle the optimized code that the JIT compiler produced, and that sounds
like a big headache.
What about the solution of unloading a class, modifying the class file,
and then reloading it? Or having "two versions" of the "same" class loaded
in memory at a time, with one of them considered deprecated, and released as
soon as the last client code finishes using it?
Anyway, if you really are going this route, I'd imagine
comp.lang.java.machine might be a more appropriate group, since knowledge of
the implementations of JVMs will undoubtly be helpful in implementing what
you're trying to do.
- Oliver
Ross Bamford
<my_email_is_post...@munged.invalid> wrote:
> On Fri, 21 Oct 2005 21:59:17 GMT, "Oliver Wong" <ow...@castortech.com>
> wrote or quoted :
>
>> And if you're going to modify existing methods, you might have to
>> untangle the optimized code that the JIT compiler produced, and that
>> sounds
>> like a big headache.
>
> understatement of the year.
It's not as big a concern as you'd imagine if done correctly. You must
remember that the JIT operates entirely transparently and entirely
optionally, even from the point of view of the .class file and bytecode
therein. So when a method changes a naive (but workable) option would be
to dump any optimizations from the prior one, and start from scratch.
The more complicated problem (as Oliver touched on) is you have to take
into account currently executing methods. The way they tackled this in the
1.5 instrumentation API (and especially in Mustang, which adds the ability
to retransform, as well as redefine classes, which effectively means we
can change methods on instances from 1.6 up) was to have the transformed
method applied only to post-transform invocations, while the previous code
was retained (presumably at a relocated index) while it had active stack
frames. So of course any JIT'd code for those would stick around, until
the method itself is cleared (assuming, of course, that it is).
habib
I think https://jen.dev.java.net and http://asm.objectweb.org have a
lot for me.
habib
them if you look at some papers in this area.
I myself write a paper and introduce some of isuues and their solutions
but my problem is implementing them.
Of course, the two excellent sites Ross sent, can help me in
implementing my ideas in a JVM a lot.
Ross Bamford
> The site you introduced helped me a lot.
Glad to be of service :) I'd definitely be interested to know how your
research turns out.
DrMatrix
"habib" <habib...@gmail.com> wrote:
Oh my!!!
You've never worked on real production code, have you?
You don't let programmers just change software on the fly. There are
audit trails to worry about. Quality Assurance testing should be
performed by someone other than programmers.
Letting programmers just make changes on the fly would bypass QA and
introduce more problems than it would solve. Your system's avalibility
would not be higher, it would be much, much lower.
What you're suggesting is giving programmers the ability to introduce
untested code into production. No one would allow that.
Roedy Green
quoted or indirectly quoted someone who said :
>You've never worked on real production code, have you?
>
>You don't let programmers just change software on the fly. There are
>audit trails to worry about. Quality Assurance testing should be
>performed by someone other than programmers.
>
>Letting programmers just make changes on the fly would bypass QA and
>introduce more problems than it would solve. Your system's avalibility
>would not be higher, it would be much, much lower.
>
>What you're suggesting is giving programmers the ability to introduce
>untested code into production. No one would allow that.
You still may do all sorts of tests on a copy of the live system and
then do an on the fly flip over on the live system. There are
instances that you can't ever shut down the system. Java is better
suited for than most languages with its classLoader solution to the
problem.
You special purpose duplicated hardware where it is possible to repair
the machine without turning off the power. Compaq bought out Tandem
circa 1997 who used to specialise in this sort of thing. I don't know
what happened since.
--
Canadian Mind Products, Roedy Green.
http://mindprod.com Java custom programming, consulting and coaching.
Chris Smith
> >What you're suggesting is giving programmers the ability to introduce
> >untested code into production. No one would allow that.
>
> You still may do all sorts of tests on a copy of the live system and
> then do an on the fly flip over on the live system. There are
> instances that you can't ever shut down the system. Java is better
> suited for than most languages with its classLoader solution to the
> problem.
Yep. That still leaves the problem that the number of potential sources
of error increases exponentially while you're changing over from the old
code to the new code in a running system... but testing is certainly not
the problem, in any way that's unique to nonintrusive uploads.
> You special purpose duplicated hardware where it is possible to repair
> the machine without turning off the power. Compaq bought out Tandem
> circa 1997 who used to specialise in this sort of thing. I don't know
> what happened since.
Well, one thing that's happened since is that HP bought Compaq. :)
--
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.
Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation
Tim Smith
He didn't say anything (at least in the part you quoted) about
introducing untested code into production, or bypassing QA.
Example: I wrote a chat server, in C++, for an online gaming system.
Besides chat between users, it is also used to handle the communication
between games. To deploy a new version, I upload it to the server
machine, and then send an administrative command to the chat server
telling it a new version is there. In response to this, it saves the
state of all its objects to disk, execs the new version (which, on Unix,
does not close the network connections), passing the new version an
argument that says that it needs to initialize from the saved objects.
The new version reads the saved objects, and users have no idea that the
server has been upgraded. Their chats and games are undisturbed.
Do I do this with untested code? No! This is only done when I have
code that has been tested and is ready to deploy. All this
save/exec/restore capability does is make it so the deployment can be
done without disrupting service.
He could very well be wanting to do something similar.
--
--Tim Smith