CompareAndSwapNode support

[Deneau, Tom]

And Unsafe.getAndAddInt in is the following in 8:
 
   public final int getAndAddInt(Object o, long offset, int delta) {
        int v;
        do {
            v = getIntVolatile(o, offset);
        } while (!compareAndSwapInt(o, offset, v, v + delta));
        return v;
    }


So I guess the volatile read is the difference.

As further information on this, at the time I was getting this error on 8, I was only enabling Math and Unsafe substitutions in the HSAIL backend.  When I enabled the fuller set of substitutions from GraalMethodSubstitutions, etc, the error on 8 went away.

-- Tom


-----Original Message-----
From: Christian Thalinger [mailto:christian.thalinger at oracle.com] 
Sent: Sunday, October 27, 2013 1:18 PM
To: Deneau, Tom
Cc: graal-dev at openjdk.java.net
Subject: Re: CompareAndSwapNode support


On Oct 25, 2013, at 6:07 AM, Deneau, Tom <tom.deneau at amd.com> wrote:

> Just to further clarify...
> 
> We had a HSAIL  junit test that called AtomicInteger.getAndAddInt from a lambda.  This made it java 8 specific.  This test worked fine (building and running graal with java 8) up until we started doing this merge with the new infrastructure changes.
> 
> We now have a version of this test that does the same thing but does not use lambdas.

By "does the same thing" you mean calling AtomicInteger.getAndAdd?  The code for AtomicInteger.getAndAdd is different on 7 and 8:

http://hg.openjdk.java.net/jdk7u/jdk7u/jdk/raw-file/tip/src/share/classes/java/util/concurrent/atomic/AtomicInteger.java

    public final int getAndAdd(int delta) {
        for (;;) {
            int current = get();
            int next = current + delta;
            if (compareAndSet(current, next))
                return current;
        }
    }

http://hg.openjdk.java.net/jdk8/jdk8/jdk/raw-file/tip/src/share/classes/java/util/concurrent/atomic/AtomicInteger.java

    public final int getAndAdd(int delta) {
        return unsafe.getAndAddInt(this, valueOffset, delta);
    }

That's why you get different code in the compiler.

>  So this new version can be invoked from java 7.   This new java7-style junit test still fails when we build our newly merged graal (newly merged with the new infrastructure) with java 8-b109 and try to run the test.  The top of the stack trace is shown below.
> 
> But if I build our merged graal with java7 b21 this new junit test succeeds.
> 
> -- Toim
> 
> ________________________________________
> From: Christian Thalinger [christian.thalinger at oracle.com]
> Sent: Thursday, October 24, 2013 8:00 PM
> To: Deneau, Tom
> Cc: graal-dev at openjdk.java.net
> Subject: Re: CompareAndSwapNode support
> 
> On Oct 24, 2013, at 3:24 PM, Deneau, Tom <tom.deneau at amd.com> wrote:
> 
>> Some additional information on this...
>> 
>> The original junit test was written using lambdas and so could not be run under java 7.  Since our junit framework also supports java7 style tests, I rewrote the test to be java 7, and rebuilt graal with java 7.  And with no other changes to graal, the test now passes.
>> 
>> Does this make any sense?
>> 
>> -- Tom
>> 
>> From: Deneau, Tom
>> Sent: Thursday, October 24, 2013 3:21 PM
>> To: graal-dev at openjdk.java.net
>> Subject: CompareAndSwapNode support
>> 
>> In the HSAIL backend, we had support for CompareAndSwapNode.  (we had not pushed this out to the trunk yet).
>> 
>> As part of the merge with the new runtime infrastructure changes, I see that our CompareAndSwapNode  support is broken.
>> I'm trying to understand how to get it working again.
>> 
>> In the particular test I'm looking at the java code calls atomicInt.getAndAdd(constant)
> 
> Do you mean getAndAddInt?  If you are talking about the Unsafe guys these exist since 1.8.  So compiling (and running) with 7 or 8 definitely makes a difference.
> 
>> 
>> First I noticed that we were getting Invoke nodes for things like getIntVolatile and compareAndSwapInt.
>> So I assumed the UnsafeSubstitutions needed to be enabled for our backend.
>> 
>> When I enabled these, I got the following error which doesn't mean anything to me...
>> 
>> java.lang.AssertionError: <unknown> has unexpected usage 20|LoadField#value of checkcast 19|GuardingPi at <unknown>
>>               at com.oracle.graal.replacements.NodeIntrinsificationPhase.checkCheckCastUsage(NodeIntrinsificationPhase.java:387)
>>               at com.oracle.graal.replacements.NodeIntrinsificationPhase.checkCheckCastUsage(NodeIntrinsificationPhase.java:382)
>>               at com.oracle.graal.replacements.NodeIntrinsificationPhase.cleanUpReturnCheckCast(NodeIntrinsificationPhase.java:328)
>>               at com.oracle.graal.replacements.NodeIntrinsificationPhase.run(NodeIntrinsificationPhase.java:67)
>> 
>> Any suggestions?
>> 
>> -- Tom
>> 
> 
> 
>