RFR: 8142487: Cleanup sun.invoke.util.Wrapper zeroes to be both reliable and lazy

Claes Redestad claes.redestad at oracle.com
Thu Nov 12 00:36:37 UTC 2015

On 2015-11-12 01:10, John Rose wrote:
> On Nov 11, 2015, at 11:53 AM, Claes Redestad <claes.redestad at oracle.com> wrote:
>> Hi,
>> following-up on JDK-8141678[1]. So, it appears we want to avoid the fragility of keeping local copies of Byte/Short/Integer in Wrapper, and instead get the boxed zeroes lazily, when we actually need them.
>> It turns out simply fixing Wrapper.zero() would then regress things back a bit, since java.lang.invoke.LambdaForm itself eagerly generates a number of LambdaForms and NamedFunctions that touch a couple of Wrapper.zeros. By making the initialization of these lazy as well we not only avoid regression compared to JDK-8141678, but further remove another 9 LambdaForms from jigsaw startup (down from 74 to 65; down to 37 together with JDK-8142334[2]). An unneeded function (void zero_V) was removed in the process.
> Making them lazy is fine, but this change is buggy, due to a large amount of cut-n-paste.
> For example, this insertion looks wrong:
> +    private static void createZeroForm(BasicType type) {
> +        synchronized (LF_zero) {
> +            final int ord = type.ordinal();
> +            LambdaForm zeForm = LF_identity[ord];  <<< s.b. LF_zero???

Guilty as charged. I found two places and updated in-place. Maybe should 
simply drop the attempt to avoid duplication of effort, since that's 
what adds most of the code duplication.

> For better maintainability, I think the zero and identity forms should be created together, not in separate twin code blocks.
> I think this is a safer, saner way to inject laziness here:
> - private static void createIdentityForms() {
> + // Create LF_zero, LF_identity, etc., for the given type.
> + private static void createIdentityForms(BasicType type) {
> It means that groups of LFs get lazily created; if that is tolerable for the present purpose, it's easier to reason about.

I'll give it a try tomorrow and re-measure.


More information about the core-libs-dev mailing list