RFD: ArrayDeque bulk adds and lambda
Chen Liang
chen.l.liang at oracle.com
Mon Feb 23 16:02:19 UTC 2026
Hi Eirik, this looks like a standard set of classes that should be loaded for lambda expression generation at early bootstrap.
If this particular site does not trigger such loading, any lambda use in user code would still trigger all these.
I think the loop version is only better for bootstrap. Otherwise, in terms of hotspot compilation abilities, these two pieces of code suffer from the same profile pollution problem.
But given that collections are used in early bootstrap in general, I think being bootstrap-proof might be a good idea.
________________________________
From: core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of Eirik Bjørsnøs <eirbjo at gmail.com>
Sent: Saturday, February 21, 2026 4:45 AM
To: core-libs-dev <core-libs-dev at openjdk.org>
Subject: Re: RFD: ArrayDeque bulk adds and lambda
On Sat, Feb 21, 2026 at 11:08 AM Eirik Bjørsnøs <eirbjo at gmail.com<mailto:eirbjo at gmail.com>> wrote:
Can this make ArrayDeque somewhat safer to use in early bootstrap code?
Adding some context from testing:
When modifying the mentioned code to not avoid the lambda bulk operation, nothing crashes but the number of loaded classes during 'java -cp hello.jar' is increased from 576 to 663. Here's a full list of extra classes loaded:
88a89
> java.lang.NoSuchMethodException
148a150,170
> java.lang.classfile.Annotation
> java.lang.classfile.AnnotationElement
> java.lang.classfile.Attribute
> java.lang.classfile.AttributeMapper
> java.lang.classfile.AttributeMapper$AttributeStability
> java.lang.classfile.Attributes
> java.lang.classfile.BootstrapMethodEntry
> java.lang.classfile.ClassElement
> java.lang.classfile.ClassFileElement
> java.lang.classfile.FieldElement
> java.lang.classfile.MethodElement
> java.lang.classfile.TypeKind
> java.lang.classfile.attribute.RuntimeVisibleAnnotationsAttribute
> java.lang.classfile.constantpool.AnnotationConstantValueEntry
> java.lang.classfile.constantpool.ClassEntry
> java.lang.classfile.constantpool.ConstantPool
> java.lang.classfile.constantpool.ConstantPoolBuilder
> java.lang.classfile.constantpool.LoadableConstantEntry
> java.lang.classfile.constantpool.PoolEntry
> java.lang.classfile.constantpool.Utf8Entry
> java.lang.constant.ClassDesc
150a173,182
> java.lang.constant.ConstantDescs
> java.lang.constant.DirectMethodHandleDesc
> java.lang.constant.DirectMethodHandleDesc$Kind
> java.lang.constant.DynamicConstantDesc
> java.lang.constant.DynamicConstantDesc$AnonymousDynamicConstantDesc
> java.lang.constant.MethodHandleDesc
> java.lang.constant.MethodHandleDesc$1
> java.lang.constant.MethodTypeDesc
> java.lang.invoke.AbstractValidatingLambdaMetafactory
> java.lang.invoke.BootstrapMethodInvoker
153a186,193
> java.lang.invoke.DirectMethodHandle$Constructor
> java.lang.invoke.DirectMethodHandle$Holder
> java.lang.invoke.InfoFromMemberName
> java.lang.invoke.InnerClassLambdaMetafactory
> java.lang.invoke.InvokerBytecodeGenerator
> java.lang.invoke.InvokerBytecodeGenerator$8
> java.lang.invoke.Invokers
> java.lang.invoke.Invokers$Holder
154a195,201
> java.lang.invoke.LambdaForm$BasicType
> java.lang.invoke.LambdaForm$Holder
> java.lang.invoke.LambdaForm$Kind
> java.lang.invoke.LambdaForm$Name
> java.lang.invoke.LambdaForm$NamedFunction
> java.lang.invoke.LambdaMetafactory
> java.lang.invoke.LambdaProxyClassArchive
158a206,208
> java.lang.invoke.MethodHandleImpl$1
> java.lang.invoke.MethodHandleImpl$Intrinsic
> java.lang.invoke.MethodHandleInfo
163a214,215
> java.lang.invoke.MethodType$1
> java.lang.invoke.MethodTypeForm
169a222,223
> java.lang.invoke.VarHandle$AccessMode
> java.lang.invoke.VarHandle$AccessType
199a254
> java.lang.reflect.Array
270a326
> java.util.ArrayDeque$$Lambda/0x800000001
273d328
< java.util.ArrayList$Itr
359a415
> java.util.function.Consumer
393a450
> jdk.internal.access.JavaLangInvokeAccess
402a460,484
> jdk.internal.classfile.impl.AbstractAttributeMapper
> jdk.internal.classfile.impl.AbstractAttributeMapper$RuntimeVisibleAnnotationsMapper
> jdk.internal.classfile.impl.AbstractElement
> jdk.internal.classfile.impl.AbstractPoolEntry
> jdk.internal.classfile.impl.AbstractPoolEntry$AbstractNamedEntry
> jdk.internal.classfile.impl.AbstractPoolEntry$AbstractRefEntry
> jdk.internal.classfile.impl.AbstractPoolEntry$ClassEntryImpl
> jdk.internal.classfile.impl.AbstractPoolEntry$Utf8EntryImpl
> jdk.internal.classfile.impl.AbstractPoolEntry$Utf8EntryImpl$State
> jdk.internal.classfile.impl.AnnotationImpl
> jdk.internal.classfile.impl.BootstrapMethodEntryImpl
> jdk.internal.classfile.impl.EntryMap
> jdk.internal.classfile.impl.SplitConstantPool
> jdk.internal.classfile.impl.TemporaryConstantPool
> jdk.internal.classfile.impl.UnboundAttribute
> jdk.internal.classfile.impl.UnboundAttribute$UnboundRuntimeVisibleAnnotationsAttribute
> jdk.internal.classfile.impl.Util
> jdk.internal.classfile.impl.Util$Writable
> jdk.internal.constant.ArrayClassDescImpl
> jdk.internal.constant.ClassOrInterfaceDescImpl
> jdk.internal.constant.ConstantUtils
> jdk.internal.constant.DirectMethodHandleDescImpl
> jdk.internal.constant.DirectMethodHandleDescImpl$1
> jdk.internal.constant.MethodTypeDescImpl
> jdk.internal.constant.PrimitiveClassDescImpl
512a595
> jdk.internal.util.WeakReferenceKey
524a608
> sun.invoke.util.ValueConversions
525a610,612
> sun.invoke.util.VerifyType
> sun.invoke.util.Wrapper
> sun.invoke.util.Wrapper$Format
Eirik.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20260223/5361c505/attachment-0001.htm>
More information about the core-libs-dev
mailing list