this is not really a critical issue. As for the second return, it is dead code, it won't have any reasonable effect. The big IF you are wondering about, is the guard for the primitive optimization code, and it cannot be cached, unless you habe a suggestion. A better strategy would be to not to issue the optimization in this case. I have not yet added code that tests if the optimizations make sense in that case at all. Just returning a constant is maybe not a case in which we should do this kind of thing.

Part of the optimizations I added is to gradually change values from being always boxed to be used native as they are. This is currently implemented only for int and double, but not for boolean. That is why you see the unboxing.

Jochen Theodorou
added a comment - 19/Oct/11 08:53 this is not really a critical issue. As for the second return, it is dead code, it won't have any reasonable effect. The big IF you are wondering about, is the guard for the primitive optimization code, and it cannot be cached, unless you habe a suggestion. A better strategy would be to not to issue the optimization in this case. I have not yet added code that tests if the optimizations make sense in that case at all. Just returning a constant is maybe not a case in which we should do this kind of thing.
Part of the optimizations I added is to gradually change values from being always boxed to be used native as they are. This is currently implemented only for int and double, but not for boolean. That is why you see the unboxing.

Thanks for the answer. It would be cool to get the boolean optimizations too. Groovy doesn't look very clean when you go to the bytecode level without fixing this issue. Please schedule the change so that it gets fixed some time in the near future (1.8.4 / 1.8.5 ?).

A more critical issue is GROOVY-5090 . I was actually hunting for that one (debugger showed "false" for a boolean value dispite the real value) when I noticed this unboxing/boxing redundancy.

Lari Hotari
added a comment - 19/Oct/11 09:01 Thanks for the answer. It would be cool to get the boolean optimizations too. Groovy doesn't look very clean when you go to the bytecode level without fixing this issue. Please schedule the change so that it gets fixed some time in the near future (1.8.4 / 1.8.5 ?).
A more critical issue is GROOVY-5090 . I was actually hunting for that one (debugger showed "false" for a boolean value dispite the real value) when I noticed this unboxing/boxing redundancy.

Nikolaj Jorgensen
added a comment - 02/Nov/11 04:35 Is it possible to add code to test if the optimizations make sense in order to remove unecessary if statements:
if ((!BytecodeInterface8.isOrigZ()) || (__$stMC) || (BytecodeInterface8.disabledStandardMetaClass())) {
I see this in situations where I do simple String assignments.
Also it confuses Cobertura to think that the assignment is actually a branch condition.

We have now tests that test that check the generated bytecode, so we can surely write tests. More important is to get a list of situations in which thee should be no optimization guard. String assignments normally don't trigger that.

Maybe I should introduce some kind of optimization weight and a threshold, so that I optimize only if the weight is higher than the threshold. But even then I first need to know when it does not make sense.

Jochen Theodorou
added a comment - 02/Nov/11 05:08 We have now tests that test that check the generated bytecode, so we can surely write tests. More important is to get a list of situations in which thee should be no optimization guard. String assignments normally don't trigger that.
Maybe I should introduce some kind of optimization weight and a threshold, so that I optimize only if the weight is higher than the threshold. But even then I first need to know when it does not make sense.