[9] RFR (L): 8057042: LambdaFormEditor: derive new LFs from a base LF

[Paul Sandoz]

On Sep 2, 2014, at 3:59 PM, Vladimir Ivanov <vladimir.x.ivanov at 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20140904/d09b920d/signature.asc>