JDK11 & Polyglot

[Andrew Dinn]

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