Review of MH/LF patches in the review queue

Paul Sandoz paul.sandoz at oracle.com
Wed Apr 9 11:08:04 UTC 2014


On Apr 8, 2014, at 4:53 PM, Vladimir Ivanov <vladimir.x.ivanov at oracle.com> wrote:

> Paul, thanks for the feedback!
> See my answers inline.
> 
> Updated webrevs:
>  http://cr.openjdk.java.net/~vlivanov/8037209/webrev.03/

>  http://cr.openjdk.java.net/~vlivanov/8038261/webrev.02/
> 

Both look OK.


>> Is it worthwhile introducing such direct coupling for a specific case, as that tends to increase the inter-connective complexity of the code. How much performance gain is achieved?
> Setters/getters for primitive arrays can be special-cased in the same manner, but these special cases don't buy much. Accessors (ArrayAccessor.getElement*/setElement*) are very simple anyway. I haven't seen any significant performance difference on octane.
> 
> I'll experiment with that further.
> 

OK.


>> 
>> The last two re-assigments are never used and are reassigned again at the top of the loop:
>> 
>>             // Update cached form name's info in case an intrinsic spanning multiple names was encountered.
>>             name = lambdaForm.names[i];
>>             member = name.function.member();
>>             rtype = name.function.methodType().returnType();
> I did it intentionally. There were bugs when cached values become stale due to processing of multi-name intrinsics and they were erroneously used. There's a refactoring of how intrinsics are implemented waiting in the queue, so I'd like to leave it as is for now.
> 

OK.

Paul.



More information about the core-libs-dev mailing list