----- Mail original -----
> De: "Claes Redestad" <claes.redes...@oracle.com>
> À: "Remi Forax" <fo...@univ-mlv.fr>
> Cc: "Peter Levart" <peter.lev...@gmail.com>, "Aleksey Shipilev"
> <sh...@redhat.com>, "core-libs-dev"
> <core-libs-dev@openjdk.java.net>
> Envoyé: Lundi 29 Avril 2019 16:57:45
> Objet: Re: RFR: 8222852: Reduce String concat combinator tree shapes by
> folding constants into prependers
> Hi Rémi,
>
> On 2019-04-29 13:36, Remi Forax wrote:
>> That's nice !
>
> thanks for reviewing!
>
>>
>> In StringConcatFactory, i will change
>> prefixConstant + constantValue (resp suffixConstant + constantValue)
>> to
>> prefixConstant.concat(constantValue)
>>
>> to not depend on any string concat implementations of javac.
>
> It has some strange appeal, but it isn't necessary (java.base is
> explicitly excluded from using ISC).
>
> - We use regular concatenation in a few places in StringConcatFactory
> already
> - Removing all cycles (to make it possible to compile java.base with
> ISC enabled?) wouldn't be enough: we'd need to enforce nothing creeps
> back in in all code StringConcatFactory depends on (which includes much
> of java.lang.invoke and ASM). Not impossible, but impractical.
If we add lazy static final fields, we may need to define a subset of
java.base, the set of classes needed to bootstrap the VM until indy/condy are
available.
Clearly java.base is too big and having classes of java.util or
java.util.concurrent not being able to declare their constant lazy is a waste.
I'm dreaming about an annotation that you have to set on classes that are part
of the initialization sequence,
it will be so helpful even if it's just for the documentation purpose.
so you are right that some classes of java.base will never use the
StringConcatFactory but others in java.base may use it in the future.
>
> /Claes
Rémi
