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

Paul Sandoz paul.sandoz at oracle.com
Thu Sep 4 08:43:16 UTC 2014

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
  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?


More information about the core-libs-dev mailing list