JDK11 & Polyglot

[Bob McWhirter]

Seems like an intermittent/transient failure, as this morning it all built
cleanly.

Good times.

-Bob

On Thu, May 23, 2019 at 6:36 AM Bob McWhirter <bmcwhirt at redhat.com> wrote:

> Thanks Andrew!
>
> I’ll continue to poke around. When I was getting the ObjectIdentifier
> variant there simple aren’t many statics available. There’s a none-static
> stringForm field of type String. Maybe I’m just misunderstanding the error
> message also.
>
> Time to git log.
>
> Bob
>
> On Thu, May 23, 2019 at 5:02 AM Andrew Dinn <adinn at redhat.com> wrote:
>
>> On 22/05/2019 19:20, Bob McWhirter wrote:
>> > With the new JDK11 changes, at one point I could build
>> polyglot/libpolyglot
>> > with JDK11.
>> >
>> > Currently, though, I'm hitting:
>> > . . .
>> > I sense that it might be the transient static boolean COMPACT_STRINGS on
>> > String.class ultimately causing it, but that's not necessarily a
>> warranted
>> > opinion.  It always seems to be a String problem, and COMPACT_STRINGS is
>> > designated as set by the JVM at runtime, not to the true that appears in
>> > the source.
>>
>> I'm not sure how this could be the issue. I say that because I do
>> understand what goes on with this field in the JVM. Here is the context:
>>
>> During JVM startup various Java classes are constructed 'by hand' i.e.
>>
>>   the bytecodes are loaded
>>   the JVM-internal metadata model for the class is created
>>     (C++ object InstanceKlass plus auxiliary objects like Symbol. method
>> etc)
>>   the JVM-heap allocated Class<?> is created
>>   the Class<?>'s <clinit> method is run
>>
>> This is done in a very specific sequence starting with some Exception
>> classes that have no dependencies on supers or linked classes and
>> proceeding to classes like String, Thread, ThreadGroup etc.
>>
>> At certain points during this process a <clinit> run may require
>> creating certain linked Class<?> instances (most obviously supers but
>> also classes referenced from the <clinit> method) and this will initiate
>> the above steps recursively. So, the explicit hand initialization
>> sequence only defines a nominal load+init order. Recursive dependency
>> chasing means that the actual load order may be different.
>>
>> Now as for class String: very early on in this init sequence String gets
>> explicitly loaded. It is one of many classes whose static fields need to
>> be initialized specially to accord with HW, OS or user config setting --
>> String.COMPACT_STRINGS is one such example. In most normal cases where
>> runtime-specific settings need to be detected the <clinit> code calls
>> native methods from <clinit> code to read them. However, for a few of
>> these early-load classes the <clinit> methods instead initialize to a
>> dummy and the C++ code that hand-loads the class then overwrites the
>> correct values into the static field slots immediately after the load
>> and init of the class has completed.
>>
>> So, in the case of String field COMPACT_STRINGS will be updated by the
>> JVM immediately after running its <clinit> method. I don't really see
>> how this can make any difference visible to the Graal native image
>> generator. The change to COMPACT_STRINGS wil have happened long before
>> any of the Graal NativeImageGenerator code could even have started
>> running (indeed well before the JVM runtime code like ForkJoinPool that
>> drives the native image process is loaded). So, sorry Bob, but I think
>> you are probably barking up the wrong tree here.
>>
>> > Anyone have a thought or a pointer on what might've changed in the past
>> 3
>> > weeks, or if I'm completely off base and would be willing to point me
>> in a
>> > more useful direction.
>> Looking at recent changes sounds to me like the best approach.
>>
>> regards,
>>
>>
>> Andrew Dinn
>> -----------
>> Senior Principal Software Engineer
>> Red Hat UK Ltd
>> Registered in England and Wales under Company Registration No. 03798903
>> Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander
>>
>