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