[Jastadd] [feature suggest] global attributes

From: Na, Hyunik <hina_at_kaist.ac.kr>
Date: Sun, 29 Apr 2012 12:41:02 +0900

Hello JastAddJ developers,

 

Compiling attached IBM1383.java with JastAddJ (rev. 9238) produces a stack
overflow as follows:

 

.

Exception in thread "main" java.lang.StackOverflowError

  at AST.ASTNode.Define_TypeDecl_typeString(ASTNode.java:1585)

  at AST.ASTNode.Define_TypeDecl_typeString(ASTNode.java:1585)

  at AST.ASTNode.Define_TypeDecl_typeString(ASTNode.java:1585)

  at AST.ASTNode.Define_TypeDecl_typeString(ASTNode.java:1585)

  at AST.ASTNode.Define_TypeDecl_typeString(ASTNode.java:1585)

  at AST.ASTNode.Define_TypeDecl_typeString(ASTNode.java:1585)

  at AST.ASTNode.Define_TypeDecl_typeString(ASTNode.java:1585)

  at AST.ASTNode.Define_TypeDecl_typeString(ASTNode.java:1585)

  at AST.ASTNode.Define_TypeDecl_typeString(ASTNode.java:1585)

  at AST.ASTNode.Define_TypeDecl_typeString(ASTNode.java:1585)

  at AST.ASTNode.Define_TypeDecl_typeString(ASTNode.java:1585)

  at AST.ASTNode.Define_TypeDecl_typeString(ASTNode.java:1585)

  at AST.ASTNode.Define_TypeDecl_typeString(ASTNode.java:1585)

  at AST.ASTNode.Define_TypeDecl_typeString(ASTNode.java:1585)

at AST.ASTNode.Define_TypeDecl_typeString(ASTNode.java:1585)

.

 

The cause of this stack overflow is that some of class fields are
initialized with over 1000 string literals added together

which produce an extremely big and nested subtree of the abstract syntax
tree.

(see, for example, mappingTableG1 field of class Decoder in the attached
file. )

It seems that the request of the inherited attribute typeString() causes a
stack overflow before reaching its handler, Program.

This is a very unusual case and a solution is to simply make the stack size
bigger.

 

But, I made a "shortcut" to the topmost ASTNode, Program, to avoid

traversing the AST to get the typeString() attribute as follows:

 

1. define a static field 'topmost' in a ASTNode class and also define its
setter.

 

-=-=-=

           private static Program ASTNode.topmost = null;

           static void ASTNode.setTopmost( Program p ) { topmost = p; }

-=-=-=

 

2. call the setter at an appropriate place

(for my case, in the constructor of Frontend class defined in
FrontendMain.jrag as follows ):

 

-=-=-=

           protected Frontend() {

                     program = new Program();

                     program.state().reset();

                     ASTNode.setTopmost( program ); // added

           }

-=-=-=

 

3. define typeString as a static field of the ASTNode class and also define
its getter:

 

-=-=-=

           private static TypeDecl ASTNode.typeString = null;

           static TypeDecl ASTNode.typeString() {

                     if ( typeString == null ) {

                                //assert topmost != null : "topmost should
be set first";

                                typeString = topmost.lookupType("java.lang",
"String");

                     }

                     return typeString;

           }

-=-=-=

 

  This getter replaces the existing inherited attribute typeString().

 

4. Erase all the inh attribute typeString declaration from the compiler
code.

 

 

 

 

By doing this, the typeString() becomes visible to every ASTNode directly

rather than by traversing upward the AST looking for the handler, the
topmost node Program.

I believe that one can apply this trick to any inherited attribute which
only the topmost node can give the value.

 

In current implementation of JastAddJ, looking up typeString()

( or similarly, typeObject(), typeCloneable(), typeSerializable(),
typeBoolean(), typeByte(), typeShort(), etc )

will cause upward tree traversal to reach the topmost node, unless it is
declared lazy for a class.

I wonder how big the performance overhead of this tree traversals is,

let alone the stack overflows problem occurring in peculiar cases such as
the one described above.

 

Another point is that it seems that this 'trick' can be a 'feature' of
JastAdd.

I imagine the following scenario:

 

a. A programmer declares Program as topmost in an .ast file:

 

           topmost Program ::= CompilationUnit*;

 

b. He/she declares a 'global' attribute typeString()

 

           global TypeDecl typeString() = topmost.lookupType("java.lang",
"String");

 

c. JastAdd do the above 1, 2 and 3 for the programmer.

 

What do you think about this?

 

- Hyunik

 

 

 






Received on Sun Apr 29 2012 - 05:41:11 CEST

This archive was generated by hypermail 2.3.0 : Wed Apr 16 2014 - 17:19:06 CEST