som-st / trufflesom Goto Github PK

Reading of uninitialized variables in methods is likely broken. At least it is in SOMns.

The following test fails with an assertion, because the read evaluates to null:

class Test usingPlatform: platform = Value ()(
  protected foo = (
    | a |
    a println.
    a := 1.
    a println.
  )

  public main: args = (
    foo.
    foo.
    ^ 0
  )
)

A fix could be:

diff --git a/src/som/compiler/MethodBuilder.java b/src/som/compiler/MethodBuilder.java
index 1598a2b..20e8757 100644
--- a/src/som/compiler/MethodBuilder.java
+++ b/src/som/compiler/MethodBuilder.java
@@ -101,7 +102,8 @@ public final class MethodBuilder {
     MethodScope outer = (outerBuilder != null)
         ? outerBuilder.getCurrentMethodScope()
         : null;
-    this.currentScope   = new MethodScope(new FrameDescriptor(), outer, clsScope);
+    assert Nil.nilObject != null;
+    this.currentScope   = new MethodScope(new FrameDescriptor(Nil.nilObject), outer, clsScope);

     accessesVariablesOfOuterScope = false;
     throwsNonLocalReturn          = false;

/cc @charig

See charig@cb28ee4

@eregon found a bug in the AST inlining in SOMns. The following test does not result in the correct output:

class Test usingPlatform: platform = Value (
| private Array = platform kernel Array. |
)(
  public main: args = (
    | arr b |
    arr := Array new: 10.
    args from: 2 to: args size do: [ :arg | arg print. ' ' print ].

    'Correct Semantics' println.
    b := [ :i  |
        arr at: i put: [ i ]].
    1 to: 10 do: b.

    1 to: 10 do: [ :i  |
        (arr at: i) value println ].

    'Broken Semantics' println.
    1 to: 10 do: [ :i  |
        arr at: i put: [ i ]].

    1 to: 10 do: [ :i  |
        (arr at: i) value println ].
    ^ 0
  ) 
)

This issue is very likely to be a problem for TruffleSOM, too.

This is an optimization the AST interpreter has, but we haven't yet added to the bytecode version.

The block dispatch nodes and similar constructs do the cache traversal every time in the interpreter. This is better avoided and the result kept in a local variable in the loop, for easy access.

The script som missed the name change from 'som.vm.Universe' to 'truffles....' in line 121. This line should be changed to 'trufflesom.vm.Universe'.

Should I send a PR?

Since we have inlining of #whileTrue/False now, adding it for #to:do: should be relatively straightforward.

With the latest graal/truffle update, there's a performance regression.

Tracked via oracle/graal#4690

From @charig on December 3, 2015 20:33

charig@f8fff7b

Copied from original issue: smarr/TruffleSOM#7

From @smarr on September 15, 2014 16:30

The hardcoding in MessageSendNode is getting annoying.

We should do something similar to the solution in RTruffleSOM, where each specialization knows the conditions under which it applies. So that it moves to the actual implementation and is not part of the MeSeNode anymore.

Copied from original issue: smarr/TruffleSOM#6

See charig@da10f5f#commitcomment-18420330

SOM accepts writes to method arguments. TruffleSOM throws a runtime exception at compile time. Is this the expected behaviour?

I have written the following attached TestCase ArgumentReadonlyTest.som.txt. The runtime exception is found in the attached file
exception.txt.
('mysom' is 'som' with the change from 'som.vm.Universe' to 'trufflesom.vm.Universe'.)

Maybe the root cause has something to do with the setting von JAVA_HOME and GRAAL_HOME? I'm only able to run the provided samples in truffleSOM if JAVA_HOME is identical to GRAAL_HOME and points to the 'normal' Java VM. If GRAAL_HOME points to '... graalvm-ce-1.0.0-rc8/Contents/Home' I get the exception, that 'Caused by: java.lang.AssertionError: Only one implementation Engine.Impl allowed.'.

In SOMns, the following code is problematic:

  false whileFalse: [
    | resrv |
    critical: [ resrv ] ] ].

The inlining of whileFalse: did not properly initialize the inliner with the local variables of the inlined block. This was covered up by on-demand adding the local information for writes.

A solution and tests are here: smarr/SOMns#72

Normally, we handle overflows with Math.*Exact operations, but we don't have one in this case, because:

In cases where the size is int or long and overflow errors need to be detected, the methods addExact, subtractExact, multiplyExact, and toIntExact throw an ArithmeticException when the results overflow. For other arithmetic operations such as divide, absolute value, increment, decrement, and negation overflow occurs only with a specific minimum or maximum value and should be checked against the minimum or maximum as appropriate.

See https://docs.oracle.com/javase/8/docs/api/java/lang/Math.html

Possible solution proposed by @fniephaus: smarr/SOMns#292