Looks much better now. Reviewed. Best regards, Vladimir Ivanov
On 11/9/15 4:36 PM, Claes Redestad wrote:
Vladimir, thanks for asserting this. The j.l.invoke code is still rather foreign to me, so I took extreme precautions to not change any semantics. Simplified thusly: http://cr.openjdk.java.net/~redestad/8141678/webrev.03/ Effects remain largely the same. Thanks! /Claes On 2015-11-09 13:13, Vladimir Ivanov wrote:Claes, I don't think Wrapper.zero identity matters (e.g. see MethodHandles.constant [1] or InvokerBytecodeGenerator.emitConst). So, you can considerably simplify your code by allocating fresh wrapper instances. Best regards, Vladimir Ivanov [1] public static MethodHandle constant(Class<?> type, Object value) { ... if (w.zero().equals(value)) return zero(w, type); On 11/8/15 4:43 PM, Claes Redestad wrote:Hi, indy eagerly creates and initializes all integral type caches (Byte$ByteCache, Short$ShortCache) which has a small, measurable impact to jake startup and footprint. Exposing ZERO constants from Byte, Character, etc which are guaranteed to be identical to what's returned from each respective valueOf(0) enables j.l.i. to initialize without eagerly creating these caches: webrev: http://cr.openjdk.java.net/~redestad/8141678/webrev.01 bug: https://bugs.openjdk.java.net/browse/JDK-8141678 Making these constants public would allow us to not fetch them via reflection for a tiny, incremental startup improvement, but I don't think the constants carry their own weight to motivate them becoming part of public API. Testing: verified startup/footprint improvement, various jtreg tests /Claes
