HiddenClassDefiner incorrectly assumes Unsafe.staticFieldBase(Field) returns a real Object about guice

[mcculls]

Hi @breun - I'm not sure I fully agree with that assessment because the code is taking the values returned by staticFieldBase and staticFieldOffset and passing them into unsafe.getObject which is allowed (and intended) according to the Unsafe javadoc:

     * <li>The offset and object reference {@code o} (either null or
     * non-null) were both obtained via {@link #staticFieldOffset}
     * and {@link #staticFieldBase} (respectively) from the
     * reflective {@link Field} representation of some Java field.

But I agree that we're not doing that directly though because of the use of the reflective call, and it appears that Azul Prime is doing something different when reflection is involved.

I believe we can simplify that call to avoid using the value from staticFieldBase because we know that field is a member of Lookup.class - according to the javadoc we can use Lookup.class directly, which should hopefully avoid the issue on Azul Prime:

    Lookup trustedLookup =
        (Lookup) GET_OBJECT_METHOD.invoke(THE_UNSAFE, Lookup.class, TRUSTED_LOOKUP_OFFSET);

I'll try to recreate the original issue to verify this fix.

[mcculls]

@breun PR #1673 has a potential fix - could you build this locally and try it out with your Azul Prime setup?

[breun]

@mcculls I've tried building your branch locally and I believe I need to use Bazel, which I've installed, but I haven't figured out yet what command I need to run to build Guice. Can you tell me how to build Guice or point me to documentation for this?

[mcculls]

You can also build it with Maven - to do a quick build without tests or javadoc use: mvn package -DskipTests -Dmaven.javadoc.skip I'd recommend using one of the releases before 3.9.x, for example 3.8.8, to avoid hitting this issue (assuming you want to build it with Azul Prime)

…

On Tue, 11 Apr 2023 at 14:53, Nils Breunese ***@***.***> wrote: @mcculls <https://github.com/mcculls> I've tried building your branch locally and I believe I need to use Bazel, which I've installed, but I haven't figured out yet what command I need to run to build Guice. Can you tell me how to build Guice or point me to documentation for this? — Reply to this email directly, view it on GitHub <#1672 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABDTO6H3CAI5S7AR6ZD7U3XAVO5FANCNFSM6AAAAAAWST3NJE> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[breun]

I was able to install Guice 5.1.1-SNAPSHOT from your branch, but the next step is building Maven 3.9.1 with this version of Guice, but I various tests fail when building Maven 3.9.1 with Guice 5.1.1-SNAPSHOT due to java.lang.NoSuchMethodError: com.google.common.collect.ImmutableMap$Builder.buildOrThrow()Lcom/google/common/collect/ImmutableMap;. Any ideas? I can build Maven 3.9.1 with Guice 5.1.0 without problems.

[mcculls]

Guice master branch currently depends on Guava 31.0.1-jre whereas Maven 3.9.1 branch depends on Guava 30.1-jre If you upgrade the Guava dependency version in Maven's top-level pom.xml to 31.0.1-jre then it should work fine: diff --git a/pom.xml b/pom.xml index 334c502bd..a3d6eb01a 100644 --- a/pom.xml +++ b/pom.xml @@ -139,3 +139,3 @@ under the License. <guiceVersion>5.1.0</guiceVersion> - <guavaVersion>30.1-jre</guavaVersion> + <guavaVersion>31.0.1-jre</guavaVersion> <guavafailureaccessVersion>1.0.1</guavafailureaccessVersion>

[azul-jf]

Hi @mcculls we at Azul have a change for this issue which we prefer to the one you proposed. I believe we're waiting for Google to approve the paperwork we've submitted that's required to join the project. Is there someone who can help expedite the application?

[sameb]

@azul-jf: Please open a pull request with your proposed change and we can discuss it there. The automated CLA checks will kick in when the PR is open. It looks like Azul already has a corp CLA agreement AFAICT, so so long as the author of the PR is a member of Azul's CLA, it should just work.