You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@groovy.apache.org by Keegan Witt <ke...@gmail.com> on 2018/09/03 12:33:26 UTC
Old bytecode targets
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
Re: Old bytecode targets
Posted by Paul King <pa...@asert.com.au>.
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 <pa...@asert.com.au> 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 <su...@apache.org> 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
>>
>
Re: Old bytecode targets
Posted by Paul King <pa...@asert.com.au>.
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 <su...@apache.org> 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
>
Re: Old bytecode targets
Posted by "Daniel.Sun" <su...@apache.org>.
+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
Re: Old bytecode targets
Posted by Keegan Witt <ke...@gmail.com>.
I've decided to just leave the old bytecode targets alone for now. I
created https://issues.apache.org/jira/browse/GROOVY-8783 for the addition
of the new bytecode targets.
On Wed, Sep 12, 2018 at 5:16 AM Paul King <pa...@asert.com.au> wrote:
> Was there a Jira issue for this yet?
>
> Thanks, Paul.
>
> On Mon, Sep 3, 2018 at 10:33 PM Keegan Witt <ke...@gmail.com> 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?
>>
>> -Keegan
>>
>
Re: Old bytecode targets
Posted by Paul King <pa...@asert.com.au>.
Was there a Jira issue for this yet?
Thanks, Paul.
On Mon, Sep 3, 2018 at 10:33 PM Keegan Witt <ke...@gmail.com> 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?
>
> -Keegan
>
Re: Old bytecode targets
Posted by Remi Forax <fo...@univ-mlv.fr>.
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" <bl...@gmx.org>
> À: "dev" <de...@groovy.apache.org>
> 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
Re: Old bytecode targets
Posted by Jochen Theodorou <bl...@gmx.org>.
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
Re: Old bytecode targets
Posted by Remi Forax <fo...@univ-mlv.fr>.
Hi jochen,
----- Mail original -----
> De: "Jochen Theodorou" <bl...@gmx.org>
> À: "dev" <de...@groovy.apache.org>, "Keegan Witt" <ke...@gmail.com>
> 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
Re: Old bytecode targets
Posted by Jochen Theodorou <bl...@gmx.org>.
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
Re: Old bytecode targets
Posted by Keegan Witt <ke...@gmail.com>.
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 <bl...@gmx.org> 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
>
Re: Old bytecode targets
Posted by Jochen Theodorou <bl...@gmx.org>.
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