Review of MH/LF patches in the review queue (original) (raw)
Paul Sandoz paul.sandoz at oracle.com
Wed Apr 9 11:08:04 UTC 2014
- Previous message: Review of MH/LF patches in the review queue
- Next message: String.indexOf optimization
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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/
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.
- Previous message: Review of MH/LF patches in the review queue
- Next message: String.indexOf optimization
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]