Hot Swap not working every now and then

I never noticed this behaviour in Idea 4.5, so I guess it's a bug in Irida.
Unfortunately I haven't found a reliable way to reproduce.
Has anybody else also seen this behaviour:

I re-compile, Idea hot swaps without any error messages, but actually the
old code is still run.

Happens mostly when I hot swap for a couple of times in a row.
Also it happens only sporadically, but it makes me trust hot swap not at all.

(using JDK 1.5.0_04 on Windows)

5 comments
Comment actions Permalink

Successful hotswap doesn't mean that the old code will be abandoned. If there are references kept to the outdated object instances
they will work until the instances are collected. Any new instances of the reloaded class will, however, behave in a new way.

--
Best regards,
Eugene Zhuravlev
Software Developer
JetBrains Inc.
http://www.jetbrains.com
"Develop with pleasure!"

"Stephen Kelvin" <mail@gremlin.info> wrote in message news:ddhlf9$p2m$1@is.intellij.net...
>I never noticed this behaviour in Idea 4.5, so I guess it's a bug in Irida.

Unfortunately I haven't found a reliable way to reproduce.
Has anybody else also seen this behaviour:

>

I re-compile, Idea hot swaps without any error messages, but actually the
old code is still run.

>

Happens mostly when I hot swap for a couple of times in a row.
Also it happens only sporadically, but it makes me trust hot swap not at all.

>

(using JDK 1.5.0_04 on Windows)



0
Comment actions Permalink

Eugene Zhuravlev (JetBrains) wrote:

Successful hotswap doesn't mean that the old code will be abandoned. If there are references kept to the outdated object instances
they will work until the instances are collected. Any new instances of the reloaded class will, however, behave in a new way.


That's not true - instances are completely unrelated to method (byte code) changes.
Changes to a class will be picked up immediately by instances of the class.
Only if a thread has an active stackframe in method foo() changes to the method will only
be picked up after foo() has been left.

I did some more test and it seems that the problem is caused by using JDK 1.5 (don't know
if it's Idea's fault or a bug in the JDK):
Try this code (note that there ever is only a single instance of Test involved):

public class Test {
private void foo() throws InterruptedException {
while(true) {
Thread.sleep(1000);
print();
System.out.println("---"); // (A)
}
}

private void print() {
System.out.println("..."); // (B)
}

public static void main(String[] args) throws InterruptedException {
new Test().foo();
}
}

Then try this:
1) use JDK 1.4
2) Start to debug
3) Change the string at (B), recompile, hot swap. Note that changes are picked up immediately.
4) Change the string at (A), recompile, hot swap.
Idea shows an error message "foo() breakpoints will be ignored for the obsolete version of the method".
Changes will not picked up, because method foo() is never left and the 'obsolete version' still executes.
5) Change the string at (B) again. Changes are still picked up immediately.

NOW FOR THE INTERESTING PART:
- Use JDK 1.5 instead
- Error message from step 4) does not show
- HOT SWAP IN 5) NO LONGER WORKS

0
Comment actions Permalink

Any comment from a JetBrainer? This behavior is reproducible.

Stephen Kelvin wrote:

Eugene Zhuravlev (JetBrains) wrote:

>> Successful hotswap doesn't mean that the old code will be abandoned.
>> If there are references kept to the outdated object instances they
>> will work until the instances are collected. Any new instances of the
>> reloaded class will, however, behave in a new way.


That's not true - instances are completely unrelated to method (byte
code) changes.
Changes to a class will be picked up immediately by instances of the class.
Only if a thread has an active stackframe in method foo() changes to the
method will only
be picked up after foo() has been left.

I did some more test and it seems that the problem is caused by using
JDK 1.5 (don't know
if it's Idea's fault or a bug in the JDK):
Try this code (note that there ever is only a single instance of Test
involved):

public class Test {
private void foo() throws InterruptedException {
while(true) {
Thread.sleep(1000);
print();
System.out.println("---"); // (A)
}
}

private void print() {
System.out.println("..."); // (B)
}

public static void main(String[] args) throws InterruptedException {
new Test().foo();
}
}

Then try this:
1) use JDK 1.4
2) Start to debug
3) Change the string at (B), recompile, hot swap. Note that changes are
picked up immediately.
4) Change the string at (A), recompile, hot swap.
Idea shows an error message "foo() breakpoints will be ignored for
the obsolete version of the method".
Changes will not picked up, because method foo() is never left and
the 'obsolete version' still executes.
5) Change the string at (B) again. Changes are still picked up immediately.

NOW FOR THE INTERESTING PART:
- Use JDK 1.5 instead
- Error message from step 4) does not show
- HOT SWAP IN 5) NO LONGER WORKS

0
Comment actions Permalink

We might be a bit slow in replying to specific topics in August since
some of the guys are on vacation these days. I'm afraid this particular
issue has to wait until our Chief Debugger Engineer aka Eugene Zhuravlev
comes back soon. I apologize for the inconvenience it might have caused
but this is really a "hardcore" stuff :)

Eugene Belyaev
JetBrains
http://www.jetbrains.com

"Develop with pleasure!"


Stephen Kelvin wrote:

Any comment from a JetBrainer? This behavior is reproducible.

Stephen Kelvin wrote:

>> Eugene Zhuravlev (JetBrains) wrote:
>>
>>> Successful hotswap doesn't mean that the old code will be abandoned.
>>> If there are references kept to the outdated object instances they
>>> will work until the instances are collected. Any new instances of the
>>> reloaded class will, however, behave in a new way.
>>
>>
>>
>> That's not true - instances are completely unrelated to method (byte
>> code) changes.
>> Changes to a class will be picked up immediately by instances of the
>> class.
>> Only if a thread has an active stackframe in method foo() changes to
>> the method will only
>> be picked up after foo() has been left.
>>
>> I did some more test and it seems that the problem is caused by using
>> JDK 1.5 (don't know
>> if it's Idea's fault or a bug in the JDK):
>> Try this code (note that there ever is only a single instance of Test
>> involved):
>>
>> public class Test {
>> private void foo() throws InterruptedException {
>> while(true) {
>> Thread.sleep(1000);
>> print();
>> System.out.println("---"); // (A)
>> }
>> }
>>
>> private void print() {
>> System.out.println("..."); // (B)
>> }
>>
>> public static void main(String[] args) throws InterruptedException {
>> new Test().foo();
>> }
>> }
>>
>> Then try this:
>> 1) use JDK 1.4
>> 2) Start to debug
>> 3) Change the string at (B), recompile, hot swap. Note that changes
>> are picked up immediately.
>> 4) Change the string at (A), recompile, hot swap.
>> Idea shows an error message "foo() breakpoints will be ignored for
>> the obsolete version of the method".
>> Changes will not picked up, because method foo() is never left and
>> the 'obsolete version' still executes.
>> 5) Change the string at (B) again. Changes are still picked up
>> immediately.
>>
>> NOW FOR THE INTERESTING PART:
>> - Use JDK 1.5 instead
>> - Error message from step 4) does not show
>> - HOT SWAP IN 5) NO LONGER WORKS

0
Comment actions Permalink

No problem. Thanks a lot for the notice.
We are currently back to Java 1.4 for debugging (fortunately we were still
in the first phase of Java 5 migration where only the environment was
changed, but no Java 5 features used in code).
The intermittent, silent HotSwap failures so far have no longer happened
with Java 1.4.

Eugene Belyaev (JetBrains) wrote:

We might be a bit slow in replying to specific topics in August since
some of the guys are on vacation these days. I'm afraid this particular
issue has to wait until our Chief Debugger Engineer aka Eugene Zhuravlev
comes back soon. I apologize for the inconvenience it might have caused
but this is really a "hardcore" stuff :)

0

Please sign in to leave a comment.