release 1.1?

[Guy Korland]

Hello,

I was deferring a deeper investigation of Deuce STM awaiting the 1.1
release and now the "release time counter" shows 4 days past 1.1
release, but there is no other indication on the website that the
release 1.1 actually happened (e.g., the download section still points
to a 1.0 release file from June). Could you please tell me what the
status of the 1.1 release is?

Thank you,

Adam Welc

[Guy Korland]

Hi Adam,

There was a slit delay in version 1.1, you can use version 1.0 for
now.
I forgot to update the counter in the website, I hope the new version
will be available by the end of next week.

Are you waiting for a specific bug fix?

Regards,
Guy

[Guy Korland]

Hi Guy,

I was waiting to see if the interface between the bytecode rewriter
and the runtime is going to change significantly (though I think
probably not). Perhaps you can comment on what kind of changes you are
planning to have in the new release?

Thank you

Adam

[Guy Korland]

Hi Adam,

The changes are going to include:
1. New contention manager for LSA.
2. Full offline bytecode manipulation that can work with online
bytecode manipulation.
3. Few bugs fix.

We might add fee bytecode optimizations to reduce the STM overhead.

BTW, are you using Deuce one of your projects?

[Guy Korland]

Hi Guy,

Yes, I am considering using Deuce for a project. What we are trying to
do, though, is to implement the transactional barrier insertion (and,
most likely, the transactional loop insertion) in a compiler and
simply call to Deuce's runtime to tap into your implementation of the
STM algorithms. That is why I am interested in the changes to the
runtime interface. Does bullet 2 you mention in your previous email
have anything to do with it?

Also, since you are so kind and answer my emails so quickly :-), I
thought that perhaps you could help me understand three aspects of
Deuce's implementation (possibly by pointing me to the right files in
the source tree):
1. Where do the "shadow" fields (those that store field indexes) get
initialized?
2. How do you handle nesting? It's not obvious from the analysis of
the code for the transactional loop or the code from transaction start/
commit. Is it somehow handled by the bytecode rewriter?
3. How do you handle static fields? It seems that the same
transactional barriers are used for "regular" and static field
accesses, but the actual bytecode for them differs enough (the former
gets an object reference on the Java stack as an argument whereas the
latter simply gets an index to Java's constant pool) that it's not
immediately obvious to me how this is done...

Thank you!

Adam

[Guy Korland]

>Does bullet 2 you mention in your previous email have anything to do with it?

The big change is that when we instrument classes offline the added
fields are not added to the class but a new classes is created to hold
the new fields.

>1. Where do the "shadow" fields (those that store field indexes) get initialized?

In the class static block, meaning in load time.

>2. How do you handle nesting? It's not obvious from the analysis of the code for the transactional loop or the code from >transaction start/commit. Is it somehow handled by the bytecode rewriter?
Nested transactions are committed as part of the big transaction.

>3. How do you handle static fields? It seems that the same transactional barriers are used for "regular" and static field >accesses, but the actual bytecode for them differs enough (the former gets an object reference on the Java stack as an >argument whereas the latter simply gets an index to Java's constant pool) that it's not immediately obvious to me how this is >done...

The different between them is only the way they are assigned using the
sun.misc.Unsafe.

BTW, do you care if I'll put your question on the forum?

Guy

[Guy Korland]

>Does bullet 2 you mention in your previous email have anything to do with it?
The big change is that when we instrument classes offline the added
fields are not added to the class but a new classes is created to hold
the new fields.

>1. Where do the "shadow" fields (those that store field indexes) get initialized?
In the class static block, meaning in load time.

>2. How do you handle nesting? It's not obvious from the analysis of the code for the transactional loop or the code from >transaction start/commit. Is it somehow handled by the bytecode rewriter?
Nested transactions are committed as part of the big transaction.

[Adam] I couldn't find anything in the source code about what happens
if a nested transaction aborts, though... From the description of how
the atomic method gets rewritten, it seems that if
TransactionException is thrown by the nested transaction than this
transaction will handle that abort and re-execute. Is this the case? I
suppose that your counter mechanism for the max number of aborts will
guarantee that the outer level will ultimately be reached, but is it
really your intention?

[Guy Korland]

> TransactionException is thrown by the nested transaction than this
> transaction will handle that abort and re-execute. Is this the case?

No, currently the outer transaction will abort also.

[Adam]

I dug a little deeper into the code and I still don't quite understand
how nested transaction abort is done if not in the way I described
before. I will try to be more explicit in describing my current
understanding of how this procedure works, and I would really
appreciate it if someone could correct me (or not, if I am right :-).

First of all, transaction abort is signaled by throwing a
TransactionException. If that happens at the level of a nested
transaction, then we will have two atomic methods enclosing the point
of throw. Lets call them outer() and inner().

A simplified code for (transactionalized) inner() looks as follows:

... inner(...) {
...
boolean commit = true;
for (int i=10; i>0; --i) {
try {
inner(..., context);
}
catch (TransactionException x) {
commit = false;
}
...
if (!commit) {
context.rollback();
commit = true;
}
...
}
throw new TransactionException();
...
}


As I mentioned before, from analysis of the code above it seems to me
like inner() has to loop 10 times before TransactionException is
propagated to outer().

Is this how the abort of an outer transaction will happen or am I
missing something?

Thank you.

Adam

[Guy Korland]

Deuce supports - Closed Nested Transaction.

Currently what Deuce is doing (and I'm open to suggestion) is:
When an inner transaction is called from an outer transaction this
inner transaction is called as a regular method.
Meaning, it won't create a new context and won't loop, but keep using
the outer transaction context.

Meaning when you exit the inner transaction block deuce won't call the
commit method but only when you exit the outer transaction.

In general it means that Deuce flatten the inner transaction into the
outer.

Guy