Old bytecode targets

classic Classic list List threaded Threaded
12 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Old bytecode targets

keeganwitt
I'm working on adding Java 9, 10, and 11 bytecodes to the 2.5 branch, and 9, 10, and 11 bytecodes when using invokedynamic to master, when I noticed we allow the targets to go back quite a ways.

Should we continue to let the Groovy compiler target Java 4, 5, 6, and 7 in master, given that master requires Java 8+?  I can't think of a valid use case where this would be useful.  What do you think of removing them?

-Keegan
Reply | Threaded
Open this post in threaded view
|

Re: Old bytecode targets

Daniel.Sun
+1 for removing the old bytecode versions

Cheers,
Daniel.Sun




-----
Daniel Sun
Apache Groovy committer
Blog: http://blog.sunlan.me 
Twitter: @daniel_sun

--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
Daniel Sun
Apache Groovy committer

Blog: http://blog.sunlan.me
Twitter: @daniel_sun
Reply | Threaded
Open this post in threaded view
|

Re: Old bytecode targets

paulk_asert
I'd leave the 2.5 branch.
+1 for removing everything before JDK7 on master (it's hopefully not too common anymore but it has often been convenient in the past to set the bytecode version to a version less than what you are compiling on)
+0 for removing JDK7 as well on master if others want that

On Mon, Sep 3, 2018 at 11:10 PM Daniel.Sun <[hidden email]> wrote:
+1 for removing the old bytecode versions

Cheers,
Daniel.Sun




-----
Daniel Sun
Apache Groovy committer
Blog: http://blog.sunlan.me
Twitter: @daniel_sun

--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
Reply | Threaded
Open this post in threaded view
|

Re: Old bytecode targets

paulk_asert
Just to clarify, by "leave the 2.5 branch" I mean not removing anything but please add new versions as appropriate.

On Mon, Sep 3, 2018 at 11:58 PM Paul King <[hidden email]> wrote:
I'd leave the 2.5 branch.
+1 for removing everything before JDK7 on master (it's hopefully not too common anymore but it has often been convenient in the past to set the bytecode version to a version less than what you are compiling on)
+0 for removing JDK7 as well on master if others want that

On Mon, Sep 3, 2018 at 11:10 PM Daniel.Sun <[hidden email]> wrote:
+1 for removing the old bytecode versions

Cheers,
Daniel.Sun




-----
Daniel Sun
Apache Groovy committer
Blog: http://blog.sunlan.me
Twitter: @daniel_sun

--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
Reply | Threaded
Open this post in threaded view
|

Re: Old bytecode targets

Jochen Theodorou
In reply to this post by keeganwitt
On 03.09.2018 14:33, Keegan Witt wrote:
> I'm working on adding Java 9, 10, and 11 bytecodes to the 2.5 branch,
> and 9, 10, and 11 bytecodes when using invokedynamic to master, when I
> noticed we allow the targets to go back quite a ways.
>
> Should we continue to let the Groovy compiler target Java 4, 5, 6, and 7
> in master, given that master requires Java 8+?  I can't think of a valid
> use case where this would be useful.  What do you think of removing them?


nobody needs to target 4 or 5 really any more I think. 6 has the nice
advantage of not requiring the stack map frames. The stackmap frame
calculation support in asm is a bit.. lets say, it comes not for free.

So otherwise I see no problem in targeting Java8

bye Jochen
Reply | Threaded
Open this post in threaded view
|

Re: Old bytecode targets

keeganwitt
Would it make sense then to add that as a compiler argument instead of relying on bytecode version?  From a user's perspective, that relationship isn't clear.

On Mon, Sep 3, 2018 at 4:34 PM Jochen Theodorou <[hidden email]> wrote:
On 03.09.2018 14:33, Keegan Witt wrote:
> I'm working on adding Java 9, 10, and 11 bytecodes to the 2.5 branch,
> and 9, 10, and 11 bytecodes when using invokedynamic to master, when I
> noticed we allow the targets to go back quite a ways.
>
> Should we continue to let the Groovy compiler target Java 4, 5, 6, and 7
> in master, given that master requires Java 8+?  I can't think of a valid
> use case where this would be useful.  What do you think of removing them?


nobody needs to target 4 or 5 really any more I think. 6 has the nice
advantage of not requiring the stack map frames. The stackmap frame
calculation support in asm is a bit.. lets say, it comes not for free.

So otherwise I see no problem in targeting Java8

bye Jochen
Reply | Threaded
Open this post in threaded view
|

Re: Old bytecode targets

Jochen Theodorou


Am 05.09.2018 um 01:17 schrieb Keegan Witt:
> Would it make sense then to add that as a compiler argument instead of
> relying on bytecode version?  From a user's perspective, that
> relationship isn't clear.

such parameters normally for to the compiler configuration, which is
exactly where a commandline would write them too and already does.

What we could do is to block earlier bytecode versions from the command
line. But frankly... what is the actual gain?

bye Jochen
Reply | Threaded
Open this post in threaded view
|

Re: Old bytecode targets

Remi Forax
In reply to this post by Jochen Theodorou
Hi jochen,

----- Mail original -----
> De: "Jochen Theodorou" <[hidden email]>
> À: "dev" <[hidden email]>, "Keegan Witt" <[hidden email]>
> Envoyé: Lundi 3 Septembre 2018 22:34:01
> Objet: Re: Old bytecode targets

> On 03.09.2018 14:33, Keegan Witt wrote:
>> I'm working on adding Java 9, 10, and 11 bytecodes to the 2.5 branch,
>> and 9, 10, and 11 bytecodes when using invokedynamic to master, when I
>> noticed we allow the targets to go back quite a ways.
>>
>> Should we continue to let the Groovy compiler target Java 4, 5, 6, and 7
>> in master, given that master requires Java 8+?  I can't think of a valid
>> use case where this would be useful.  What do you think of removing them?
>
>
> nobody needs to target 4 or 5 really any more I think. 6 has the nice
> advantage of not requiring the stack map frames. The stackmap frame
> calculation support in asm is a bit.. lets say, it comes not for free.

it's not free if you ask ASM (COMPUTE_FRAMES) to do the fix point algorithm (which is not linear) and to infer the common supertype, if you generate the StackFrames in the groovy compiler by calling explicitly visitFrame, the runtime cost is not big (but you need to modify your compiler backend which has development a cost).

>
> So otherwise I see no problem in targeting Java8
>
> bye Jochen

cheers,
Rémi
Reply | Threaded
Open this post in threaded view
|

Re: Old bytecode targets

Jochen Theodorou


Am 05.09.2018 um 12:36 schrieb Remi Forax:
[...]
>
> it's not free if you ask ASM (COMPUTE_FRAMES) to do the fix point algorithm (which is not linear) and to infer the common supertype, if you generate the StackFrames in the groovy compiler by calling explicitly visitFrame, the runtime cost is not big (but you need to modify your compiler backend which has development a cost).


we cannot let asm just do this 100% for us. The classes under
compilation are possibly not available through classloading, and asm
might not even use the right classloader if they would. what we do then
is using COMPUTE_FRAMES, but override

protected String getCommonSuperClass(String arg1, String arg2)

which does a not 100% correct calculation of the common super class.
(not 100% correct means here to claim it is Object in some cases, where
there would be a better fit)

bye Jochen
Reply | Threaded
Open this post in threaded view
|

Re: Old bytecode targets

Remi Forax
COMPUTE_FRAMES + getCommonSuperClass is one option, calling visitFrame by yourself is the other option, for the later usually you have more context to find the super type but it means you have to generate the visitFrame at the right place.

Rémi

----- Mail original -----
> De: "Jochen Theodorou" <[hidden email]>
> À: "dev" <[hidden email]>
> Envoyé: Mercredi 5 Septembre 2018 12:44:45
> Objet: Re: Old bytecode targets

> Am 05.09.2018 um 12:36 schrieb Remi Forax:
> [...]
>>
>> it's not free if you ask ASM (COMPUTE_FRAMES) to do the fix point algorithm
>> (which is not linear) and to infer the common supertype, if you generate the
>> StackFrames in the groovy compiler by calling explicitly visitFrame, the
>> runtime cost is not big (but you need to modify your compiler backend which has
>> development a cost).
>
>
> we cannot let asm just do this 100% for us. The classes under
> compilation are possibly not available through classloading, and asm
> might not even use the right classloader if they would. what we do then
> is using COMPUTE_FRAMES, but override
>
> protected String getCommonSuperClass(String arg1, String arg2)
>
> which does a not 100% correct calculation of the common super class.
> (not 100% correct means here to claim it is Object in some cases, where
> there would be a better fit)
>
> bye Jochen
12