On Sep 2, 2014, at 3:59 PM, Vladimir Ivanov <vladimir.x.iva...@oracle.com> wrote:
> Webrev: http://cr.openjdk.java.net/~vlivanov/8057042/webrev.00 > Generally looks good (re: Peter's observation of continue/break). - LambdaFormEditor 61 private static final class Transform { 62 final long packedBytes; 63 final byte[] fullBytes; 64 final LambdaForm result; // result of transform, or null, if there is none available 65 66 private enum Kind { More an oddity really, Transform.Kind is private but exposed via package private methods. 187 static Transform of(Kind k, int b1, byte[] b234) { It might be worthwhile investing in a unit test for LambdaFormEditor to exercise the transform types and transitions, otherwise edge cases might bite us later. I was thinking Transform could be greatly simplified if one just uses byte[], but IIUC (via JOL) that increases the instance size by 16 bytes, although that may be small compared to the LambdaForm result and if say a WekRef is also used to hold that result. Plus if that is the case the transformCache could be simplified by just supporting Transform[] and ConcurrentHashMap. I guess the underlying question i am asking here is do these space savings really give us much over some less complicated code? Paul.
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
