Calling a method directly on the Context interface

[Sasha Bermeister]

Hi all,

I'm working on an honours project trying to implement nested transactions. To do this with DeuceSTM, I have added two methods to the Context interface, startNested and endNested, with the following signatures:

    /**

     * Starts/ends a nested transaction.

     * Called by the user; can pass information through metainf.

     * @param metainf meta information on the current atomic block.

     */

    void startNested(String metainf);

    /**

     * Ends a nested transaction. Should validate the tx and abort if necessary.

     *

     * Needed since commit() terminates the transaction when it finishes, whereas we want the parent tx to continue.

     */

    void endNested();

To call these methods, I am using ContextDelegator.getInstance():

import org.deuce.transaction.ContextDelegator;

public class MyClass {

public static Context context = ContextDelegator.getInstance();

}

However, when calling context.startNested("") inside a transaction, I get a "NoSuchMethodError" on startNested.

So I tried re-getting the context inside each transaction:

        @Atomic(metainf = "normal")

        public boolean add(int key) {

context = ContextDelegator.getInstance();

                                context.startNested("");

                                context.endNested("");

        }

But I still get the "NoSuchMethodError", this time on getInstance().

Am I misunderstanding the way these internal methods work? Any help would be greatly appreciated.

Thanks,

Sasha

[Guy Korland]

You're not suppose to call ContextDelegator.getInstance() explicitly in your code.

This class is added to your code in the instrumentation process.

For more information check the coede: https://github.com/DeuceSTM/DeuceSTM/tree/master/src/java/org/deuce/transform/asm

[Sasha Bermeister]

Then is there any way to call methods directly on the Context interface? (Or somehow communicate with the transaction manager in any way?)

Sasha

[Sasha Bermeister]

I'm guessing the answer is no?

If not, I'll investigate adding a bytecode call to this method in asm.

[Guy Korland]

I'm sorry for the probably stupid question did you add these methods 

"void startNested(String metainf); void endNested();"

also to the TL2, LSA or any of the other context implementations? 

Regards,
Guy Korland

--
You received this message because you are subscribed to the Google Groups "Deuce-STM developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to deuce-stm-develo...@googlegroups.com.
To post to this group, send email to deuce-stm-...@googlegroups.com.
Visit this group at http://groups.google.com/group/deuce-stm-developers.
For more options, visit https://groups.google.com/groups/opt_out.

[Sasha Bermeister]

Haha that's not a stupid question, but yes of course I did (the code compiled fine).

Interestingly, I got this to work before (I was able to call the methods successfully with the ContextDelegator.getContext() method) without using the offline instrumentation (I was only passing the -javaAgent parameter to the VM). Although this appeared to work, it may have not been using transactions correctly.

Now, with the offline instrumentation (instrumented rt.jar), I get the NoMethodFound exception as before.

Sasha

--
You received this message because you are subscribed to a topic in the Google Groups "Deuce-STM developers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/deuce-stm-developers/FwTPuKCmAeM/unsubscribe.
To unsubscribe from this group and all its topics, send an email to deuce-stm-develo...@googlegroups.com.

[Sasha Bermeister]

Here's what I've managed to do:

I made two projects in Eclipse: one for Deuce (which builds the agent jar) and one for my own project (which calls ContextDelegator.getContext().startNested()). I've added the Deuce project to the build path of my own project, and added -javaagent:../../DeuceSTM/bin/deuceAgent.jar to the params.

Doing a bit of introspection with Class.getMethods() and things, here's what I get:

- ContextDelegator.getContext() returns a Context object of the class I expect (mystm.Context)

- this object has the methods startNested() and endNested()

- startNested() is a public method, which expects a single argument (a String)

- startNested() has an "accessible" flag of 0 (m.isAccessible() returns false)

- If I set the "accessible" flag to true (m.setAccessible(true)), I can now invoke it with m.invoke()

- However, the arguments are not passed correctly (startNested() receives 'null' as the argument, even when called with m.invoke(context, "test"))

I should also note that I can call ContextDelegator.getContext().startNested() anywhere outside a transaction, and it works perfectly fine. However, inside an @Atomic method, I get MethodNotFoundException (and these strange introspection results).

Any ideas? Feeling a bit stuck. I really need to call startNested() and endNested() inside a transaction though so I'm just throwing around ideas :)

Sasha

Regards,
Guy Korland

To unsubscribe from this group and stop receiving emails from it, send an email to deuce-stm-developers+unsub...@googlegroups.com.

To post to this group, send email to deuce-stm-developers@googlegroups.com.

Visit this group at http://groups.google.com/group/deuce-stm-developers.
For more options, visit https://groups.google.com/groups/opt_out.

--
You received this message because you are subscribed to a topic in the Google Groups "Deuce-STM developers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/deuce-stm-developers/FwTPuKCmAeM/unsubscribe.

To unsubscribe from this group and all its topics, send an email to deuce-stm-developers+unsub...@googlegroups.com.
To post to this group, send email to deuce-stm-developers@googlegroups.com.

[Miguel Carvalho]

Did you annotate your Context implementation with @Exclude ? Moreover,
did you exclude all the classes of your own project?

On 26 Aug, 2013, at 3:22, "Sasha Bermeister" <sberm...@gmail.com>
wrote:

[Sasha Bermeister]

Yes to the first question, but no to the second. Why do I need to exclude the classes of my own project? They actually use transactions (i.e. have atomic methods).

Sasha

[Miguel Carvalho]

> Why do I need to exclude the classes of my own project?
> They actually use transactions (i.e. have atomic methods).

In that case you do not need it. I thought your own project contained
your Context implementation. So, I was referring to the Context
dependencies, which should be excluded too.

[Sasha Bermeister]

Ahh yes, no, there are none of those.

My method basically looks like this:

@Atomic
public void foo() {
     ContextDelegator.getInstance().startNested("");
     // transaction stuff here

     ContextDelegator.getInstance().endNested();

}

And I have added startNested() and endNested() as public methods to both the Context interface and my own mystm.Context implementation.

Interestingly, the following code above works fine when there is no @Atomic decorator (that is, the code is not executed in a function). When the @Atomic decorator is there, I get a NoMethodFound exception.

Any ideas are greatly appreciated.

Sasha

[Miguel Carvalho]

As GK said you are not suppose to directly access ContextDelegator and
Context in the domain application.

Nevertheless if you want to proceed with your approach at least you must
specify the Context interface and other classes in the runtime parameter
org.deuce.exclude (see documentation in Deuce page).

It will solve your problem.

[Sasha Bermeister]

Thanks for this Miguel.

For this argument, I originally passed:

-Dorg.deuce.exclude="java.*,sun.*,org.eclipse.*,org.junit.*,junit.*"

Then I added my own classes:

-Dorg.deuce.exclude="java.*,sun.*,org.eclipse.*,org.junit.*,junit.*,mylinkedlisttest.*"

and got the error:

attempted duplicate class definition for name: "org/deuce/transaction/ContextDelegator"

So I added all of Deuce as well:

-Dorg.deuce.exclude="java.*,sun.*,org.eclipse.*,org.junit.*,junit.*,mylinkedlisttest.*,org.deuce.*"

And it worked! :D

But when I remove my own classes (ie just exclude Deuce):

-Dorg.deuce.exclude="java.*,sun.*,org.eclipse.*,org.junit.*,junit.*,org.deuce.*"

I get NoSuchMethodException again.

Interesting. So thank you for fixing my problem, but am I excluding it correctly? Is it really safe to exclude all of org.deuce.*? What does excluding even mean?

I feel the transactions may not execute correctly now that I am excluding not only my class, but all of DeuceSTM.

Thanks again for all your help though :)

Sasha

[Miguel Carvalho]

> but am I excluding it correctly?

> What does excluding even mean?

"Excluding" means "do not instrument", which in turns means do not
"duplicate methods" (for more information about "Duplicate methods" see
the GK paper of Multiprog 2010)

> Is it really safe to exclude all of org.deuce.*?

org.deuce.* classes are already excluded because they are annotated with
@Exclude.

Yet, Deuce runtime cannot predict beforehand if a class was
instrumented, or not. So by default, Deuce invokes the "duplicated
method" on every invocation from within an atomic method.

That is the reason why your invocation ctx.startNested(""); works fine
OUT OF an atomic method, but fails inside an atomic method. Because in
the latter case, Deuce will invoke ctx.startNested("", currentContext).
Yet, since the Context interface is correctly annotated with @Exclude it
does not provide a duplicate method startNested(String, Context) and
thus, you will get a NoSuchMethodException.

Note that every time you invoke: obj.m(), inside an Atomic method, this
invocation will be replaced by: obj.m(currentContext), where
currentContext is got from the ContextDelegator.getInstance().

Nevertheless, if you "say" to Deuce runtime that the obj class was
excluded (through the org.deuce.exclude parameter) then Deuce will not
instrument the invocation to the methods of this class.

Finally, and again, I must remember you that you should not directly use
the Contex and ContextDelegator in the domain application. That is only
acceptable for testing purposes.

[Sasha Bermeister]

Perhaps I can write a version of startNested that takes the current context as an argument (i.e. signature Context.startNested(String s, Context c) )?

Or perhaps write a context class that is NOT excluded from instrumentation (so that an instrumented version of startNested() is available)?

Yes, I only need to use Context and ContextDelegator for testing purposes. Actually, I am using them to benchmark some ideas I have about nested transactions for a paper I am working on.

Sasha

[Miguel Carvalho]

> Perhaps I can write a version of startNested that takes
> the current context as an argument
> (i.e. signature Context.startNested(String s, Context c) )?
> Or perhaps write a context class that is NOT excluded
> from instrumentation (so that an instrumented version
> of startNested() is available)?

Do you think that it makes sense? Do you know the goal of the
“duplicated” method?

Even if it was possible, can you realize that will cause an infinite
recursion?

If you don’t see why, I think it will be a good exercise to understand
that.

Regards,

[Sasha Bermeister]

I could have this method in the Context interface:

Context.startNested(String s, Context c)

Then I could call the method like so:

Context.startNested("foo")

This should call the method with the other signature, which should work.