Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Language IDEs » Objectteams » Change code generated for base call in callin
Change code generated for base call in callin [message #1791082] Fri, 22 June 2018 14:07 Go to next message
Lars Schütze is currently offline Lars SchützeFriend
Messages: 43
Registered: March 2012
Location: Germany
Member

Hi,

I want to change the code generated by the otj adoption of the JDT for a basecall in a callin.
Currently, it will be generated as this$0._OT$callNext(...);

I want to generate something different and I am looking for the place where this happens. I am currently looking at o.e.o.o.i.core.compiler.ast.BaseCallMessageSend#prepareSuperAccess which prepares the arguments for the base call.

I think I did not discovered where directly the callNext() is generated, or am I already at the right spot? Maybe, I just have a knot in my head.

Cheers,
Lars

[Updated on: Mon, 25 June 2018 07:51]

Report message to a moderator

Re: Change code generated for base call in callin [message #1791362 is a reply to message #1791082] Thu, 28 June 2018 11:53 Go to previous messageGo to next message
Stephan Herrmann is currently offline Stephan HerrmannFriend
Messages: 1650
Registered: July 2009
Senior Member
This is a bit hidden, I agree.

BaseCallMessageSend is of course a good place to look.

From "base.thisMethod(arg1)" we go to "this$0._OT$callNext(_OT$baseArg, _OT$teams, _OT$index, _OT$callinIds, _OT$boundMethodId, _OT$args, new Object[] { arg1 }, 1)" in several steps:
- Re-arrange (pack) arguments in BCMS.prepareSuperAccess() (name of the method is no longer accurate, I admit)
- "Enhance" this signature, i.e., prepend the _OT$... arguments in TransformStatementsVisitor.visit(MessageSend,BlockScope).
- Adjust the receiver in BaseReference.adjustReceiver() to become "MyTeam.this" (from where codegen creates this$0)
- Replace the selector in BCMS.resolveType() to go from "thisMethod" to "_OT$callNext".
- Finally, if the method is non-void, the message send is wrapped in an assignment "_OT$result = ..."

Does this help?
Stephan
Re: Change code generated for base call in callin [message #1793661 is a reply to message #1791362] Mon, 13 August 2018 12:32 Go to previous messageGo to next message
Lars Schütze is currently offline Lars SchützeFriend
Messages: 8
Registered: June 2018
Junior Member
Seems like I also have to change MessageSend to generate an invokedynamic for my base call.
Re: Change code generated for base call in callin [message #1794093 is a reply to message #1793661] Thu, 23 August 2018 12:14 Go to previous messageGo to next message
Lars Schütze is currently offline Lars SchützeFriend
Messages: 8
Registered: June 2018
Junior Member
Okay, now it gets little bit interesting.
Before, BCMS put into the wrappee the qualified this reference of the receiver type (i.e., the role type name) to become R.this or MyTeam.this (BCMS#81, BCMS#89) I want to point to another class (namely holding the bootstrap method of the invokedynamic).

this._wrappee = gen.qualifiedTypeReference(new char[][] { dynamicCallinBootstrapTypeName });

When running the code, it cannot resolve the mentioned type

[javac] ----------
[javac] 12. ERROR in /Users/lschuetze/Development/repos/role-benchmarks/benchmarks/objectteams-compiler-work/invy/src/benchmark/bank/CallinTransaction.java (at line 30)
[javac] base.deposit(amount);
[javac] ^^^^^^^^^^^^^^^^^^^^
[javac] org.eclipse.objectteams.otredyn.runtime.dynamic.CallinBootstrap cannot be resolved toa type
[javac] ----------

How can I add that type to the scope to be resolved? I already tried to add it to the runtime (via ant class path) during javac.
I was now trying different possible methods of the generator without any success.

I also have the feeling, because BaseReference inherits from ThisReference, that I have to change that to become a subclass of NameReference and everything that follows from that refactoring.

[Updated on: Thu, 23 August 2018 13:56]

Report message to a moderator

Re: Change code generated for base call in callin [message #1794104 is a reply to message #1794093] Thu, 23 August 2018 14:58 Go to previous messageGo to next message
Stephan Herrmann is currently offline Stephan HerrmannFriend
Messages: 1650
Registered: July 2009
Senior Member
You are using a qualified name, so it's not a matter of missing imports.

I can't really comment on the role of ant.

But every OT/J project already depends on org.eclipse.objectteams.runtime.jar, so perhaps you want to add your class to it?

Quote:
I also have the feeling, because BaseReference inherits from ThisReference, that I have to change that to become a subclass of NameReference.

Since BaseReference overrides essential methods and only in exceptional cases delegates to super, this change may not be necessary. The _wrappee will be a QualifiedTypeReference, which might suffice.
Re: Change code generated for base call in callin [message #1794143 is a reply to message #1794104] Fri, 24 August 2018 10:00 Go to previous messageGo to next message
Lars Schütze is currently offline Lars SchützeFriend
Messages: 8
Registered: June 2018
Junior Member
It seems to be a class path problem. For the sake of finding the cause I even added a local variable of the type plus its import to BaseReference::adjustReceiver
CallinBootstrap c = new CallinBootstrap();
but neither when running the test cases inside Eclipse nor when running ejc with ant or from command line it can be found.
I start compilation with ant
    <target name="compile" depends="clean">
        <mkdir dir="bin" />
        <javac srcdir="src" destdir="bin" source="${target}" target="${target}" debug="true" fork="true"
            includeantruntime="false">
            <classpath refid="project.classpath" />
            <compilerarg value="-ot.weaving:otdre" />
            <compilerarg value="-proc:none" />
        </javac>
    </target>
where project.classpath is a jar which includes CallinBootstrap. I verified it. ant -debug also states that is loaded
    [javac] Using JDT compiler (with extension for OT/J)
    [javac] Since compiler setting isn't classic or modern, ignoring fork setting.
fileset: Setup scanner in dir /Users/lschuetze/Development/repos/role-benchmarks/benchmarks/objectteams-compiler-work/invy/lib with patternSet{ includes: [otre_min.jar] excludes: [] }
fileset: Setup scanner in dir /Users/lschuetze/Development/repos/role-benchmarks/benchmarks/objectteams-compiler-work/invy/lib/cp with patternSet{ includes: [otredyn.jar] excludes: [] }
    [javac] Compilation arguments:
    [javac] '-noExit'
    [javac] '-classpath'
    [javac] '/Users/lschuetze/Development/repos/role-benchmarks/benchmarks/objectteams-compiler-work/invy/bin:/Users/lschuetze/Development/repos/role-benchmarks/benchmarks/objectteams-compiler-work/invy/lib/otre_min.jar:/Users/lschuetze/Development/repos/role-benchmarks/benchmarks/objectteams-compiler-work/invy/lib/cp/otredyn.jar'
    [javac] '-sourcepath'
    [javac] '/Users/lschuetze/Development/repos/role-benchmarks/benchmarks/objectteams-compiler-work/invy/src'
    [javac] '-d'
    [javac] '/Users/lschuetze/Development/repos/role-benchmarks/benchmarks/objectteams-compiler-work/invy/bin'
    [javac] '-ot.weaving:otdre'
    [javac] '-proc:none'
But still it results in the ClassNoDefErrorFound exception.
It does not seem to have problems with Java 9 modules. As I am not using modules all will be compiled into the unnamed module. But, even when adding --add-reads for all modules used it does not resolve the problem.

Maybe you do have any further hint?
Re: Change code generated for base call in callin [message #1794314 is a reply to message #1794143] Tue, 28 August 2018 19:38 Go to previous messageGo to next message
Stephan Herrmann is currently offline Stephan HerrmannFriend
Messages: 1650
Registered: July 2009
Senior Member
Quote:
For the sake of finding the cause I even added a local variable of the type plus its import to BaseReference::adjustReceiver
CallinBootstrap c = new CallinBootstrap();


Did you add that line to the compiler class BaseReference or did you let the compiler generate this into the target code?

Quote:
But still it results in the ClassNoDefErrorFound exception.


In your post from Aug 23 you mentioned a compile error, but this now looks like a runtime exception. Which is it? Or is it a runtime exception of the compiler? ;p

Re: Change code generated for base call in callin [message #1794316 is a reply to message #1794314] Tue, 28 August 2018 19:53 Go to previous messageGo to next message
Lars Schütze is currently offline Lars SchützeFriend
Messages: 8
Registered: June 2018
Junior Member
I think I have to work out some class loader problem in combination with Java 9, or with class path things and ant.
Quote:
Did you add that line to the compiler class BaseReference or did you let the compiler generate this into the target code?

I added that line to the compiler class to be sure that it is present when ant javac task tries to compile code. But, that also fails at runtime.
Adding a class from the same package works using
TestBootstrap t = new TestBootstrap();
, but referencing a class as base-reference from the same package via in BaseReference
this._wrappee = gen.qualifiedTypeReference(new char[][] { "org.eclipse.objectteams.otdt.internal.core.compiler.ast.TestBootstrap".toCharArray() });
also results in a
[javac] org.eclipse.objectteams.otdt.internal.core.compiler.ast.TestBootstrap cannot be resolved to a type

[Updated on: Tue, 28 August 2018 19:56]

Report message to a moderator

Re: Change code generated for base call in callin [message #1794317 is a reply to message #1794316] Tue, 28 August 2018 20:04 Go to previous messageGo to next message
Stephan Herrmann is currently offline Stephan HerrmannFriend
Messages: 1650
Registered: July 2009
Senior Member
OK, the last two snippets tell me you're not fighting a ClassLoader issue, but a case of JDT's NameEnvironment not finding a type at compile time.
The gate between compiler and NameEnvironment are the functions LookupEnvironment.askForType(..) (two overloads).
That NameEnvironment is the compile time representation of the -classpath argument passed to the compiler. From your previous post, I would expect, e.g., classes from otre_min.jar and otredyn.jar to be found during LE.askForType, no?
Re: Change code generated for base call in callin [message #1794416 is a reply to message #1794317] Thu, 30 August 2018 11:40 Go to previous messageGo to next message
Lars Schütze is currently offline Lars SchützeFriend
Messages: 8
Registered: June 2018
Junior Member
Quote:
That NameEnvironment is the compile time representation of the -classpath argument passed to the compiler. From your previous post, I would expect, e.g., classes from otre_min.jar and otredyn.jar to be found during LE.askForType, no?

The LookupEnvironment::nameEnvironment contains both jars, askForType also is called with things like Team, Confined etc., but it seems to be just classes from runtime plugin from org.objectteams and nothing from org.eclipse.objectteams.*

Also, when I change the qualified base reference to
this._wrappee = gen.qualifiedTypeReference(CharOperation.splitOn('.', "org.eclipse.objectteams.otdt.internal.core.compiler.ast.TestBootstrap".toCharArray()));
the error is
    [javac]     base.limited(20.0f);
    [javac]     ^^^^^^^^^^^^^^^^^^^
    [javac] org.eclipse.objectteams.otdt cannot be resolved to a type
    [javac] ----------

[Updated on: Thu, 30 August 2018 11:50]

Report message to a moderator

Re: Change code generated for base call in callin [message #1794428 is a reply to message #1794416] Thu, 30 August 2018 13:53 Go to previous messageGo to next message
Stephan Herrmann is currently offline Stephan HerrmannFriend
Messages: 1650
Registered: July 2009
Senior Member
Quote:
The LookupEnvironment::nameEnvironment contains both jars

good.
Quote:
askForType also is called with things like Team, Confined etc., but it seems to be just classes from runtime plugin from org.objectteams and nothing from org.eclipse.objectteams.*


You should be able to debug right from BaseReference.resolveType(), right where it says "this._wrappee.resolveType(scope)" up until LE.askForType(), right? One implicit assumption: _wrappee is set before resolveTypes(), is it?

Quote:
Also, when I change the qualified base reference to ... "org.eclipse.objectteams.otdt.internal.core.compiler.ast.TestBootstrap"


this shouldn't surprise, since that would need org.eclipse.jdt.core on the build path in the current compiler invocation, and from the above I assume it isn't. Somehow, you seem to assume that the compiler can always find its own classes during compilation, which it can't. Classes loaded into the JVM have no relation to the set of classes observable via NameEnvironment.

So, why don't you go back to org.eclipse.objectteams.otredyn.runtime.dynamic.CallinBootstrap, ensure it is contained in one of the jars visible to NameEnvironment. Then see if NameEnvironment can find the type during compilation (via askForType of course).
Re: Change code generated for base call in callin [message #1794432 is a reply to message #1794428] Thu, 30 August 2018 14:36 Go to previous messageGo to next message
Lars Schütze is currently offline Lars SchützeFriend
Messages: 8
Registered: June 2018
Junior Member
Quote:
You should be able to debug right from BaseReference.resolveType(), right where it says "this._wrappee.resolveType(scope)" up until LE.askForType(), right? One implicit assumption: _wrappee is set before resolveTypes(), is it?
Yes, I AM ! :-) It is set and it also find it now. So, classpath works and also the QualifiedReference is set now in the right way! Thanks.
Quote:
this shouldn't surprise, since that would need org.eclipse.jdt.core on the build path in the current compiler invocation, and from the above I assume it isn't. Somehow, you seem to assume that the compiler can always find its own classes during compilation, which it can't. Classes loaded into the JVM have no relation to the set of classes observable via NameEnvironment.
Yeah, I was assuming that somehow.
    [javac]     base.deposit(amount);
    [javac]     ^^^^^^^^^^^^^^^^^^^^
    [javac] Illegal method in base call, can only call base version of the enclosing method deposit(float) (OTJLD 4.3(a)).
Now I have to work me through the static semantics checks. I've already seen that you sometimes switch between the "shadow" AST. I'll have t debug where it fails and then adapt these parts.

Thanks anyway for your help!
Re: Change code generated for base call in callin [message #1794436 is a reply to message #1794432] Thu, 30 August 2018 14:57 Go to previous messageGo to next message
Stephan Herrmann is currently offline Stephan HerrmannFriend
Messages: 1650
Registered: July 2009
Senior Member
Quote:
    [javac]     base.deposit(amount);
    [javac]     ^^^^^^^^^^^^^^^^^^^^
    [javac] Illegal method in base call, can only call base version of the enclosing method deposit(float) (OTJLD 4.3(a)).


I recently noticed that this message can be misleading (in case of a compiler bug, that is :) ). It is produced by
org.eclipse.objectteams.otdt.internal.core.compiler.problem.BaseCallProblemReporterWrapper.invalidMethod(MessageSend, MethodBinding, Scope). First thing to check: what is the problemId in the given ProblemMethodBinding?
Re: Change code generated for base call in callin [message #1794453 is a reply to message #1794436] Thu, 30 August 2018 18:48 Go to previous messageGo to next message
Lars Schütze is currently offline Lars SchützeFriend
Messages: 8
Registered: June 2018
Junior Member
Quote:
First thing to check: what is the problemId in the given ProblemMethodBinding
In MethodBinding::problemReason there is a 1 (ProblemReasons.NotFound) and in ProblemReporter::handle the problemId is IProblem.BaseCallNotSameMethod.
In BaseCallProblemReporterWrapper::invalidMethod it goes into this._wrappee.baseCallNotSameMethod(enclosingMethodDecl, messageSend); because problemMethod.closestMatch is null.

Now I have to adjust the generated arguments, because they differ to _OT$callNext.
The interesting part will be that I have to pack some arguments on the stack where part of it will be consumed by invoking the static bootstrap method and the others by invoking the resulting callsite.

Since InvokeDynamic is a little bit different than normal virtual method calls I am a little bit puzzled how I am approaching this from the compiler POV. Using ASM library it is quite easy
<put runtime arguments on stack>
<mDescr:= create a type descriptor of the method that should result from the bootstrap>
newInstructions.add(new InvokeDynamicInsnNode(method.name.replaceAll("[<>]", ""), mDescr /* method.descr */, bootstrapHandle, joinpointDescr));

However, it fails already before even generating code. So, how can I make it treat that reference and selector special in the sense of an invokedynamic?

[Updated on: Mon, 03 September 2018 09:52]

Report message to a moderator

Re: Change code generated for base call in callin [message #1795085 is a reply to message #1794453] Fri, 14 September 2018 08:25 Go to previous message
Lars Schütze is currently offline Lars SchützeFriend
Messages: 8
Registered: June 2018
Junior Member
For now, base calls will be expanded to point to the bootstrap method (which I now named CallinBootstrap::callNext). Therefore, I changed MethodSignatureEnhancer to add the j.l.invoke.MethodHandles.Lookup, String, j.l.invoke.MethodType plus the old enhanced arguments to those base calls.
However, I noticed that this code is shared among replace callin methods that are enhanced. The compiler does work for now, but now role methods signature will be enhanced to
MethodHandle(__OT__Source,Lookup,String,MethodType,IBoundBase2,ITeam[],int,int[],int,Object[],float)Object

The idea was to change base calls to point to the invokedynamic bootstrap and leave role methods untouched. Now I have to understand all the places where MSE::ENHANCING_ARG_LENGTH and MSE::enhanceArguments() and MSE::enhanceParameters() is used and substitute those places with a method which qualifies on if it is concerned with a base call or not.

For now I just NOP the extra arguments in the first bootstrap method with MethodHandles.inserArguments(roleMethod, 1, null, null, null) which kind of deletes these unused arguments.

I still did not find out how to change the former base call to an invokedynamic. For now, it just calls the static bootstrap method. Can you help me and point me to the location where those decisions are done?

[Updated on: Fri, 14 September 2018 09:20]

Report message to a moderator

Previous Topic:LIBPATH issue with GTK+ on AIX
Next Topic:OTJ related JDT patch offered as update on clean 4.8.0 M4 w/o OTJ installed
Goto Forum:
  


Current Time: Wed Nov 14 15:06:14 GMT 2018

Powered by FUDForum. Page generated in 0.03201 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top