Static forwarders in separate compiler phase

On Sun, Jun 19, 2011 at 11:02 PM, Grzegorz Kossakowski <grzegorz.kossakowski@gmail.com> wrote:

Hi,
It happens that backend I'm working on needs to replicate the same logic for static forwarders as GenJVM contains (search for addForwarders method). I'd prefer to keep this logic in just one place so it makes sense to move it to separate phase that both GenJVM and GenJribble can share.
Any objections to such an idea? I'm happy to introduce a new phase and refactor GenJVM's code.

It's a good idea to factor it out. I am less keen on creating new phases, if you can just have a common module, that's better. Phases do have a performance overhead. It's small, but we should all be concerned in making the compiler faster, not slower.

Cheers

 -- Martin

On Tue, Jun 28, 2011 at 11:12 PM, martin odersky <martin.odersky@epfl.ch> wrote:

On Sun, Jun 19, 2011 at 11:02 PM, Grzegorz Kossakowski <grzegorz.kossakowski@gmail.com> wrote:

Hi,
It happens that backend I'm working on needs to replicate the same logic for static forwarders as GenJVM contains (search for addForwarders method). I'd prefer to keep this logic in just one place so it makes sense to move it to separate phase that both GenJVM and GenJribble can share.
Any objections to such an idea? I'm happy to introduce a new phase and refactor GenJVM's code.

It's a good idea to factor it out. I am less keen on creating new phases, if you can just have a common module, that's better. Phases do have a performance overhead. It's small, but we should all be concerned in making the compiler faster, not slower.

Sorry, I missed this email. Yes, it's a good idea. At the time, there was no way to express static initializers at the AST level, therefore it had to be done at code generation time. I believe now it could be done, Aleks added support for initializing scala.Symbol literals in the static initializer. Let me know if you have any questions, I may be able to help.
iulian 

Cheers

 -- Martin

--
« Je déteste la montagne, ça cache le paysage »
Alphonse Allais

On 28 June 2011 23:12, martin odersky <martin.odersky@epfl.ch> wrote:

It's a good idea to factor it out. I am less keen on creating new phases, if you can just have a common module, that's better. Phases do have a performance overhead. It's small, but we should all be concerned in making the compiler faster, not slower.

In order to make logic reusable I'd need to define at least AST transformer, right? Is overhead of introducing a new phase that is using that transformer really big? I'd expect that overhead of a new phase comes from the fact that phase is doing deep traversal of ASTs.
In this case deep traversal is not needed. We just need to scan for DefDefs defined directly in Template.
--
Grzegorz Kossakowski

On 29 June 2011 11:30, iulian dragos <jaguarul@gmail.com> wrote:

Sorry, I missed this email. Yes, it's a good idea. At the time, there was no way to express static initializers at the AST level, therefore it had to be done at code generation time. I believe now it could be done, Aleks added support for initializing scala.Symbol literals in the static initializer. Let me know if you have any questions, I may be able to help.

Iulian, I'm not sure if we are talking about the same thing. I have static forwarders in mind and you mention static initializers. I'm bit confused.
--
Grzegorz Kossakowski

On Wed, Jun 29, 2011 at 1:20 PM, Grzegorz Kossakowski <grzegorz.kossakowski@gmail.com> wrote:

On 29 June 2011 11:30, iulian dragos <jaguarul@gmail.com> wrote:

Sorry, I missed this email. Yes, it's a good idea. At the time, there was no way to express static initializers at the AST level, therefore it had to be done at code generation time. I believe now it could be done, Aleks added support for initializing scala.Symbol literals in the static initializer. Let me know if you have any questions, I may be able to help.

Iulian, I'm not sure if we are talking about the same thing. I have static forwarders in mind and you mention static initializers. I'm bit confused.

Oh, right. You don't need the top-level object instance creation?
iulian 

--
Grzegorz Kossakowski

--
« Je déteste la montagne, ça cache le paysage »
Alphonse Allais

On 29 June 2011 13:38, iulian dragos <jaguarul@gmail.com> wrote:

Oh, right. You don't need the top-level object instance creation?

You mean logic responsible for introduction of $MODULE field, right?
If so, yes. I'd need that too. I guess that once I dive into refactoring work I'll understand your comment better. In any case, I'll start working on this soon.
--
Grzegorz Kossakowski

On Wednesday, June 29, 2011, Grzegorz Kossakowski
wrote:
> On 28 June 2011 23:12, martin odersky wrote:
>
> It's a good idea to factor it out. I am less keen on creating new phases, if you can just have a common module, that's better. Phases do have a performance overhead. It's small, but we should all be concerned in making the compiler faster, not slower.
>
> In order to make logic reusable I'd need to define at least AST transformer, right? Is overhead of introducing a new phase that is using that transformer really big? I'd expect that overhead of a new phase comes from the fact that phase is doing deep traversal of ASTs.
>
>
> In this case deep traversal is not needed. We just need to scan for DefDefs defined directly in Template.

i also think a phase like this can be cheap. look at the
"packageobjects" phase for an example, it also doesn't traverse the
whole program.

lukas

> --
> Grzegorz Kossakowski
>
>
>