JDK11 & Polyglot

[Bob McWhirter]

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
>