HHH-19798 - Graal-VM initialization issues #10964
Conversation
|
Thanks for your pull request! This pull request appears to follow the contribution rules. › This message was automatically generated. |
I don't have rights to create Jira issues, how can I do that?. One college helped me and created the issue https://hibernate.atlassian.net/browse/HHH-19798 |
jbescos
changed the title
jbescos
force-pushed
the
issueNI
branch
2 times, most recently
from
0735309 to
dcfd1a8
Compare
|
Hi hello! If GraalVM is failing on these constants, it means that it determined that these constants are reachable at runtime - otherwise this would be removed by its clever dead-code elimination process, and it wouldn't fail. It would be better to determine why in your case the compiler has determined that this constant is necessary; at the very least you'd need this to determine how it might fail if you decided to apply such a patch. In general we made Hibernate ORM work very well in native-image but the general pattern is to have any code which needs bytebuddy to be executed at build time, as it's not currently possible to generate bytecode during the runtime of native image. So
Perhaps if you could tell me more about what stack you're running I might be able to give some better suggestions. |
Hello, Thanks for responding. This is happening within the stack of Helidon, I wrote before the steps to reproduce it. In that example, we already use build time enhancement with the next, but still bytebuddy gets loaded with the stacktraces I show before: The problem is that the next triggers reflection when classes If lazy load does not work for you, I will try to find out other solution. |
|
I’ve been experimenting with different solutions, but none of them worked so far because they introduced new issues. Since ByteBuddy enhancement shouldn’t be triggered when there are no proxies (as the classes are already enhanced at build time), what kind of error do you think could arise in this situation?. Instead of using LazyValue, we could make the variables final non static. It looks these classes are coming from the service loader |
Signed-off-by: Jorge Bescos Gascon <jorge.bescos.gascon@oracle.com>
|
I managed to fix it in Helidon, doing some class replacements/substitutions. Although the solution I applied there is weak for future changes in Hibernate, so it would be preferable to fix it here. For the record, this is the fix I did in Helidon. |
Can you try figure out why these classes are being loaded at all? Obviously there should be no bytecode processing happening during the runtime execution in native-image. |
Interesting, thanks! I've added some comments on there. |
|
FWIW, I think the better solution would be to implement: In this way, you'd be able to fully exclude the Bytebuddy related code from the application being compiled to native. It's been on my wishlist for some time, but I haven't personally found the time to do it. Perhaps you'd want to try that? |
I am not expert in Graal VM, but it looks to me that it tries to resolve any static field and if that triggers reflection, it fails. Either, don't use static fields related to reflection (you can keep them as not static in factories or service loaders), or not bound hibernate-core to bytebuddy (this can be in a separate jar). An immediate fix is to keep these problematic variables as non-static or static lazy loaded. |
No it will only trigger initialization of constants which it has a (fairly accurate?) reason to believe they will be required at runtime. And it's usually right, that's why I'm suggesting to try figure out why this is being included at all.
The proof is that this isn't a problem in Quarkus, they upgraded to this Hibernate version a long time ago. |
Then Graal VM should show the origin of this, but unfortunately the only stacks I found is what I already printed in my first comment. The origin in those stacks are |
2 participants
https://hibernate.atlassian.net/browse/HHH-19798
There is an stackoverflow question related to this.
I am creating the PR to version 6.6 because we had the issue there. It is likely it will need ot be backported to branch 7 and master.
Running hibernate 6.6.23.Final with Graal-VM throws the next errors:
It seems the issue was added here:
commit e6c106f52796a0065f0181462adc83ec4b52be3c Author: Philippe Marschall <philippe.marschall@gmail.com> 2023-12-28 13:47:24 Committer: Christian Beikov <christian.beikov@gmail.com> 2024-03-14 16:16:52 Parent: 8ebf3c8507bce339bc63cdd76e6869c2fbd975a7 (HHH-15809 Secondary super-type cache pollution mitigations for HibernateBasicProxy) Child: 73c490c37edde44e778eaef5ef709f6821a70094 (HHH-14694 Use stable proxy names to avoid managing proxy state) Child: f805bcec639f99642a7f0d63ee8fb35c989369e0 (cleanups, especially to useless uses of JBoss logging) Branches: 6.6, issueNI, main, origin, hibernate/6.5, hibernate/6.6, hibernate/7.0, hibernate/7.1, hibernate/dependabot/gradle/build-dependencies-7c72a25b7f, hibernate/dependabot/gradle/io.smallrye-jandex-3.5.0, hibernate/dependabot/gradle/jakarta-366b247967, hibernate/main, origin/HEAD, origin/main HHH-17596 Use new Byte Buddy API Update code to replace deprecated Byte Buddy code with replacement.Fix is about making the static fields Lazy. I noticed the class LazyValue was not thread safe. I am fixing that too.
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license
and can be relicensed under the terms of the LGPL v2.1 license in the future at the maintainers' discretion.
For more information on licensing, please check here.