Offline transformation of rt.jar

[bien...@googlemail.com]

Hi,

I am trying to transactify some applications and got stuck, when using
java.util.* collections within atomic methods.
As I got from some previous posts, I have to manually transfrom the
rt.jar.
I tried:

java -cp deuceAgent.jar -Dorg.deuce.exclude='com.*,junit.*'
org.deuce.transform.asm.Agent rt.jar deuce_rt.jar

and similarly for the project:

java -cp deuceAgent.jar -Dorg.deuce.exclude='com.*,junit.*'
org.deuce.transform.asm.Agent project.jar deuce_project.jar

and finally ran it with:

java -Dorg.deuce.exclude='com.*,junit.*' -cp
deuceAgent.jar:deuce_project.jar -
Xbootclasspath:deuce_rt.jar:deuceAgent.jar com.blub.Main

I then get this error:
Exception in thread "main" java.lang.VerifyError: class
com.blub.ConstantNode$Type overrides final method ordinal.(Lorg/deuce/
transaction/Context;)I

What am I doing wrong?

Regards,
Annette

[nir shavit]

Hi Annette, my student Guy who is the main Author on Deuce will answer
you the moment he has time as we are trying to meet a deadline...Take
care, Nir

[Guy Korland]

Hi,

Can you please send me a test case, is seems like a bug I already fixed in Enum classes.

Regards,
Guy Korland

--
You received this message because you are subscribed to the Google Groups "Deuce-STM" group.
To post to this group, send email to deuc...@googlegroups.com.
To unsubscribe from this group, send email to deuce-stm+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/deuce-stm?hl=en.

[bien...@googlemail.com]

Unfortunately, the code is confidential, such that I cannot send it.
But I just checked:
class com.blub.ConstantNode$Type is indeed an Enum class, and at the
place where the exception is thrown one instance is used as a
parameter
in a constructor call.

Regards,
Annette

On 9 Feb., 20:48, Guy Korland <gkorl...@gmail.com> wrote:
> Hi,
>
> Can you please send me a test case, is seems like a bug I already fixed in
> Enum classes.
>
> Regards,
> Guy Korland
>

> On Tue, Feb 9, 2010 at 3:39 PM, bieni...@googlemail.com <

> > deuce-stm+...@googlegroups.com<deuce-stm%2Bunsu...@googlegroups.com>

[Guy Korland]

Can you build a test case?

Which version of Deuce are you using?

Regards,
Guy Korland

To unsubscribe from this group, send email to deuce-stm+...@googlegroups.com.

[bien...@googlemail.com]

I am using the release deuceAgent-1.2.0.jar from the download page.

On 9 Feb., 21:18, Guy Korland <gkorl...@gmail.com> wrote:
> Can you build a test case?
> Which version of Deuce are you using?
>
> Regards,
> Guy Korland
>

> On Tue, Feb 9, 2010 at 10:17 PM, bieni...@googlemail.com <

> > <deuce-stm%2Bunsu...@googlegroups.com<deuce-stm%252Buns...@googlegroups.com>

[bien...@googlemail.com]

I am using the release deuceAgent-1.2.0.jar from the download page.

On 9 Feb., 21:18, Guy Korland <gkorl...@gmail.com> wrote:

> Can you build a test case?
> Which version of Deuce are you using?
>
> Regards,
> Guy Korland
>

> On Tue, Feb 9, 2010 at 10:17 PM, bieni...@googlemail.com <

> > <deuce-stm%2Bunsu...@googlegroups.com<deuce-stm%252Buns...@googlegroups.com>

[Guy Korland]

Can you try adding java.lang.Enum to the exclude list?

Regards,
Guy Korland

To unsubscribe from this group, send email to deuce-stm+...@googlegroups.com.

[bien...@googlemail.com]

Thanks, this solved the problem!
But... I ran now into a different issue.
Exception in thread "main" java.lang.IncompatibleClassChangeError:
Expected static method java.io.FileOutputStream.writeBytes([BII)V
at java.io.FileOutputStream.writeBytes(FileOutputStream.java)
at java.io.FileOutputStream.write(FileOutputStream.java:260)
at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:
65)
at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:123)
etc...
At the corresponding location in code, I do a System.out.println()
with some debug information. I know that irreversible I/O is not
"safe" to be performed within transactions, but I thought I could use
it for debugging since Eclipse's debugger gives me wrong/no
information ("com.sun.jdi.InvocationException occurred invoking
method."). Does Deuce disallow using I/O at all?

Best regards,
Annette

On 9 Feb., 21:36, Guy Korland <gkorl...@gmail.com> wrote:
> Can you try adding java.lang.Enum to the exclude list?
>
> Regards,
> Guy Korland
>

> On Tue, Feb 9, 2010 at 10:23 PM, bieni...@googlemail.com <

> > > > <deuce-stm%2Bunsu...@googlegroups.com<deuce-stm%252Buns...@googlegroups.com>
> > <deuce-stm%252Buns...@googlegroups.com<deuce-stm%25252Bun...@googlegroups.com>

[Guy Korland]

Deuce doen't know how to handle native methods.

It should be part of the next version.

For now you can again exclude the java.io.*.

Regards,
Guy Korland

To unsubscribe from this group, send email to deuce-stm+...@googlegroups.com.

[bien...@googlemail.com]

Ah, getting closer.
The problem I now have is that I am using the java.util.HashMap while
overriding the equals() Method for the key. In the specific case, the
HashMap's containsValue() method calls the equals() method.

This is the equals method:
@Override
public boolean equals(Object obj) {
if (obj == null || !getClass().equals(obj.getClass()))
return false;
Entry p = (Entry) obj;
return p.b == b && p.c.equals(c);
}

Calling now

map.put(e,e);
boolean b = map.containsValue(e);

(with no other code inbetween and no concurrency happening!), leads to
a NullPointerException in the equals method at p.c.equals(c).

Any idea?
Best regards,
Annette

On 9 Feb., 22:06, Guy Korland <gkorl...@gmail.com> wrote:
> Deuce doen't know how to handle native methods.
> It should be part of the next version.
>
> For now you can again exclude the java.io.*.
>
> Regards,
> Guy Korland
>

> On Tue, Feb 9, 2010 at 10:53 PM, bieni...@googlemail.com <

> > > > > > <deuce-stm%2Bunsu...@googlegroups.com<deuce-stm%252Buns...@googlegroups.com>
> > <deuce-stm%252Buns...@googlegroups.com<deuce-stm%25252Bun...@googlegroups.com>
>
> > > > <deuce-stm%252Buns...@googlegroups.com<deuce-stm%25252Bun...@googlegroups.com>
> > <deuce-stm%25252Bun...@googlegroups.com<deuce-stm%2525252Bu...@googlegroups.com>

[Guy Korland]

Are you sure p.c != null?

Regards,
Guy Korland

To unsubscribe from this group, send email to deuce-stm+...@googlegroups.com.

[bien...@googlemail.com]

Yes, I am ;). When I remove the @Atomic annotation from the code, it
works perfectly. The application is also non-deterministic, and I did
not introduce concurrency yet.

Regards,
Annette

On 9 Feb., 22:27, Guy Korland <gkorl...@gmail.com> wrote:
> Are you sure p.c != null?
>
> Regards,
> Guy Korland
>

> On Tue, Feb 9, 2010 at 11:19 PM, bieni...@googlemail.com <

> > > > > > <deuce-stm%252Buns...@googlegroups.com<deuce-stm%25252Bun...@googlegroups.com>
> > <deuce-stm%25252Bun...@googlegroups.com<deuce-stm%2525252Bu...@googlegroups.com>
>
> > > > <deuce-stm%25252Bun...@googlegroups.com<deuce-stm%2525252Bu...@googlegroups.com>
> > <deuce-stm%2525252Bu...@googlegroups.com<deuce-stm%252525252B...@googlegroups.com>

> ...
>
> Erfahren Sie mehr »

[bien...@googlemail.com]

I am wondering about another issue.
After instrumenting the rt.jar, I actually expected it to be
approximately to have doubled in size (you also say so in the
MultiProg'10 paper). Instead it got smaller.

Btw, is there any way to see whether the instrumented or original
version of a method is used?

Best regards,
Annette

On 9 Feb., 22:29, "bieni...@googlemail.com" <bieni...@googlemail.com>
wrote:

> ...
>
> Erfahren Sie mehr »

[Guy Korland]

Open the jar and look for classes the that ends with "DeuceFieldsHolder".

Also it seems like in your case the problem is in the equals, the offline mode wasn't tested in this case.

The thing is that the HashMap is calling the equals() method on the Object class, while the Object class is excluded by default.

This is done since the JVM crashes on Object instrumentation. 

In your case it means that the non instrumented version of the equals method is called.

--> Any changes done as part of the transaction before this call are not visible in the equal().

If this is a blocker for you I'll try to fix it tomorrow.

BTW, the former Enum fix was already committed to the trunk.

Regards,
Guy Korland

To unsubscribe from this group, send email to deuce-stm+...@googlegroups.com.

[Guy Korland]

Open the jar and look for classes the that ends with "DeuceFieldsHolder".

Also it seems like in your case the problem is in the equals, the offline mode wasn't tested in this case.

The thing is that the HashMap is calling the equals() method on the Object class, while the Object class is excluded by default.

This is done since the JVM crashes on Object instrumentation. 

In your case it means that the non instrumented version of the equals method is called.

--> Any changes done as part of the transaction before this call are not visible in the equal().

If this is a blocker for you I'll try to fix it tomorrow.

BTW, the former Enum fix was already commited to the trunk.

Regards,
Guy Korland

On Tue, Feb 9, 2010 at 11:42 PM, bien...@googlemail.com <bien...@googlemail.com> wrote:

To unsubscribe from this group, send email to deuce-stm+...@googlegroups.com.

[bien...@googlemail.com]

Looking at the jar tells me what classes were transformed, but how
would I know which one is actually called when running the
application?

Thanks for your help so far! It would be great if you could solve this
issue soon. I will also switch to the svn version, this way I
hopefully will not run again into solved issues.

Best regards,
Annette

On 9 Feb., 22:54, Guy Korland <gkorl...@gmail.com> wrote:
> Open the jar and look for classes the that ends with "DeuceFieldsHolder".
>
> Also it seems like in your case the problem is in the equals, the offline
> mode wasn't tested in this case.
> The thing is that the HashMap is calling the equals() method on the Object
> class, while the Object class is excluded by default.
> This is done since the JVM crashes on Object instrumentation.
>
> In your case it means that the non instrumented version of the equals method
> is called.
> --> Any changes done as part of the transaction before this call are not
> visible in the equal().
>
> If this is a blocker for you I'll try to fix it tomorrow.
> BTW, the former Enum fix was already committed to the trunk.
>
> Regards,
> Guy Korland
>

> On Tue, Feb 9, 2010 at 11:42 PM, bieni...@googlemail.com <

> ...
>
> Erfahren Sie mehr »

[Guy Korland]

You can run in debug and check if the last argument in the function called is a Context. Also if you debug a code that read/write from a field during a transaction you should see that the code is actually call the Context methods on each field access.

Regards,
Guy Korland