Re: [9] RFR (M): 8027827: Improve performance of catchException combinator

2014-02-28 Thread Vladimir Ivanov
Thanks for review, John!

Best regards,
Vladimir Ivanov

On 2/28/14 12:39 AM, John Rose wrote:
 On Feb 26, 2014, at 3:44 AM, Vladimir Ivanov
 vladimir.x.iva...@oracle.com mailto:vladimir.x.iva...@oracle.com wrote:


 Maybe use invokeWithArguments with target and catcher?  That at least is
 a one-liner, and probably more efficient.

 Yes, that's a good idea! At least, it considerably simplifies the code.

 Updated webrev:
 http://cr.openjdk.java.net/~vlivanov/8027827/final/webrev.03/

 Thumbs up.

 Your use of invokeWithArguments in the unspecialized code is a good
 design pattern.  The semantics are clear in the original method.  This
 in turn gives a clear basis for specializing for each combination of
 argument arities and types.  Specialization should be done using
 low-level, high-leverage mechanisms like bytecode spinning or even JIT
 optimizations.

 Put another way, if we have reasonable bytecode-generation intrinsics,
 feeding to good JIT optimizations, we don't need top-level
 specializations in the source code.  The need for those has always been
 a mark of weakness in the HotSpot implementation of MHs.  (Fredrik's
 JRockit implementation did it all in the JIT!)  We will continue to push
 down specializations to lower layers.

 — John
___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev


Re: Signature of MethodHandleInfo.reflectAs is not specific enough

2014-02-28 Thread John Rose
On Feb 25, 2014, at 3:13 AM, Ali Ebrahimi ali.ebrahimi1...@gmail.com wrote:

 I know, this is too late, but I want to share my suggestion:
 
 public T extends AccessibleObjectAnnotatedElement T reflectAs(Class? 
 super T expected, MethodHandles.Lookup lookup)

Isn't this the same as 

public T extends AccessibleObject T reflectAs...

?

I think we considered AccessibleObject but rejected it as not buying anything 
significant compared with Member which is an interface.

Perhaps 

public T extends Member  AnnotatedElement T reflectAs...

with both interfaces, would have been slightly better.

As the API is written (and yes it is too late to change) I don't think there 
are any use cases (at least with ground types) which require an extra cast.

Thank you for looking at it.

— John___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev