Re: [hibernate-dev] Bad boot performance since 5.4 switched to ByteBuddy
> Does anyone know if there is a known performance issue [...] I'm aware that loading Byte Buddy takes a little longer than Javassist to initialize: it's a larger library and it needs to load a significantly larger number of classes, including ASM, but this comes with several benefits so as long as the cost is not disproportionate, I wouldn't see it as a performance issue. How bad is it in absolute numbers? Is the highlighted problem specific to a particular bootstrap configuration, such as a particular container or a particular way of booting it? Lots of entities, or very few of them? Also, are you concerned about "cold boot" as in bootstrapping a new JVM+Hibernate, or about (re)starting an ORM instance in a running JVM? +1 to Guillaume's suggestions: if you can point a finger to a specific problematic area we might be able to do something about it. Tangentially: having to currently support both ByteBuddy and Javassist complicates things quite a bit, and complications also come at a performance cost. I wish to fully remove Javassist in 6 - for other reasons as well - and I believe that doing so will allow us to improve some integration with BB. But it would be interesting to know more about this problem, so to make sure we go into the right direction. Thanks On Tue, 4 Aug 2020 at 19:15, Guillaume Smet wrote: > > If you can get some SVG profiles from Async Profiler, that would help to > determine what we can do to improve things. > > And yes, we don't want the BB state to be static again. We had a hard time > avoiding the static here and I don't remember exactly why but it was for > sure worth it or I wouldn't have spent time on it :). > > -- > Guillaume > > On Tue, Aug 4, 2020 at 6:28 PM Yoann Rodiere wrote: > > > > @Yoann: It seems the commit you posted is about supporting a > > > SecurityManager environment, but I'm not sure how making the state an > > > instance variable rather than static helps with this. What kind of > > > buggyness are you referring to? > > > > Not sure what the bug was; I just remember there was a problem (multiple > > problems?) related to the bytebuddy state being static. Maybe the bytebuddy > > state does change from one execution to the other, depending on the > > classpath, security manager, or whatever. Maybe it was just a problem when > > running tests and changing some classes from one test to another, or > > changing the security manager. To be honest I don't remember. Maybe > > @Guillaume > > Smet remembers, but that was two years ago... > > > > Yoann Rodière > > Hibernate Team > > yo...@hibernate.org > > > > > > On Tue, 4 Aug 2020 at 18:17, Christian Beikov > > wrote: > > > >> Hey, > >> > >> sorry for the confusion. "Apparently" was the wrong word I guess, my > >> colleague Moritz Becker ran a few CPU sampling rounds with JFR which is > >> how we found out about this, so this is more like "the data suggests" > >> that the problem is in ByteBuddy. > >> > >> I can do some profiling with the async-profiler as well, but I the issue > >> definitely is the proxy building code. > >> > >> @Yoann: It seems the commit you posted is about supporting a > >> SecurityManager environment, but I'm not sure how making the state an > >> instance variable rather than static helps with this. What kind of > >> buggyness are you referring to? > >> > >> Am 04.08.2020 um 17:56 schrieb Guillaume Smet: > >> > Hi Christian, > >> > > >> > I don't like "apparently" when talking about performances :). > >> > > >> > I would advise to use async profiler > >> > (https://github.com/jvm-profiling-tools/async-profiler, also see > >> > https://github.com/quarkusio/quarkus/blob/master/TROUBLESHOOTING.md to > >> > learn more on how to use it) to try to understand what's going wrong > >> > and how we could improve things. > >> > > >> > I remember things were very slow with the initial ByteBuddy > >> > implementation Rafael did and we got much better results by caching > >> > the ByteBuddy transformations. In particular the calls to the > >> > ByteBuddy DSL are quite expensive in terms of allocations because they > >> > are creating a ton of objects. > >> > > >> > Once we have some profiling results, we can talk. > >> > > >> > -- > >> > Guillaume > >> > > >> > On Tue, Aug 4, 2020 at 5:26 PM Christian Beikov > >> > mailto:christian.bei...@gmail.com>> wrote: > >> > > >> > I'm moving this discussion from Zulip to the mailing list as > >> > Rafael does > >> > not seem to be on Zulip. Here a little context: > >> > > >> > > Does anyone know if there is a known performance issue with > >> > Bytebuddy > >> > during boot in 5.4? I noticed that 5.4 takes about 25%, sometimes > >> > up to > >> > 30% percent longer to boot, even when using a prebuilt Jandex index, > >> > apparently due to the use of Bytebuddy > >> > > >> > > @Moritz Becker found the issue while trying to find out why our > >> > Blaze-Persistence testsuite runs into CI timeouts with 5.4 but not > >>
Re: [hibernate-dev] Dropping support for Java 8 in Hibernate ORM (Search) v6 ?
Sure, we can wait to drop Java 8 if you all feel strongly about it, but give my proposal a chance :) Let me address a couple random points: Java version 9 and 10 are not useful versions to support: only 8 and 11 have long term support, so 9 and 10 are already out of support. All surveys I've seen show that 9 and 10 have been largely ignored by production users and enterprise professionals: they either use 8 or 11, or occasionally people the very latest. So if there's any interest in taking advantage from any benefit which came in 9 onward (such as multi-release jars as mentioned by Steve), you might as well skip to 11. Specifically, multi-release jars have loads of tooling issues still, both for us and our end users (e.g. the IDE to show source code), and a big problem to support as people might end up using mismatched versions of the code. As I mentioned there are no extremely compelling reasons to jump to 11, but it does simplify some things, which - when used pervasively - simplify our own code and maintenance while introducing small runtime benefits as well, such as consuming slightly less memory with the improvements to collections and streams. Regarding users, I'm simply fine with letting people use our 5.x series for as long as they wish. You should all keep in mind that we have a very high number of users, and with a small team it's just not smart from our part to have them all try to jump on our latest: we risk getting drowned in feedback, it's better to be selective with our users and "pick" the ones which are more innovative. The ones still requiring Java 8 will eventually upgrade as well, I'm just not worried that we need to encourage them to upgrade right away. Last but not least, even if supporting Java 8 comes relatively easy for us, it's an additional burden and it's one we could avoid. Certainly easier to drop it than starting to waste our time on obscure issues caused by multi-release jars and such tools, or having to maintain compatibility including at dependency tree (xml-bind apis, and all those modules being different). It's an opportunity to simplify, I'd take it. For users, it's more important to set clear expectations and communicate this early. Thanks, Sanne On Fri, 24 Jul 2020 at 17:35, Steve Ebersole wrote: > > I also think ORM 6 is not the time to do this. Especially moving to Java > 11. > > I think it is worthwhile though to discuss possibly moving to Java 9 to > take advantage of multi-release jars as Christian mentioned. But Java 9 > has its own set of difficulties for adoption with modules. It is a > tough call. > > > On Fri, Jul 24, 2020 at 10:09 AM Yoann Rodiere wrote: > > > Hi, > > > > I share Christian's concerns; Hibernate Search 6 is already a huge change > > for users, so I'm not sure reducing our potential user base even further by > > requiring JDK11 is a good idea. > > > > I don't have numbers, but from my understanding a lot of people are still > > on JDK8, be it only because of the whole modulepath mess that scared a lot > > of people off (even though modules are optional...). If someone can prove > > me wrong and show me reliable statistics about JDK8 users being a minority, > > I'd be glad to put JDK8 behind me, but I doubt that's the case... > > > > "Middleware" consumers of our libraries are another problem: > > > > * Infinispan 12, from what I can see, still supports JDK 8. > > * I believe Spring does, too. > > * Quarkus, well... I suppose you know about Quarkus better than me. > > * ... > > > > Regarding benefits: > > > > The only benefit I could see from moving to JDK11 is the availability of > > the Flow interfaces, which would certainly be useful to introduce proper > > Publisher/Subscriber support in Search queries. But then that's not > > something we'll have time to work on anytime soon. > > > > I may be mistaken, but I'm not sure Jigsaw is gaining enough traction to > > justify investing more than just defining automatic modules for the time > > being. > > > > As to multi-tenancy in JDBC... Let's finish ORM6 first? :) Nothing stops us > > from only publishing a 6.1, and then moving immediately to 7, if we really > > end up addressing all the higher-priority items faster than expected and we > > need JDK11 features soon. > > > > Bottom line: maybe we could just deprecate JDK8? Log a warning on startup? > > And yes, ORM7/Search7 may be a better time to move to JDK11. > > > > On a side note, I'm not as enthusiastic as Christian about Moditect; last > > time we tried to use it on Search, it required us to build with JDK11, so > > we couldn't use it, since we were building releases with JDK8. Though > > nowadays we build releases with JDK11 (and -release 8), so it may be an > > option. > > > > > > Yoann Rodière > > Hibernate Team > > yo...@hibernate.org > > > > > > On Fri, 24 Jul 2020 at 16:23, Christian Beikov > > > > wrote: > > > > > Hey, > > > > > > I'm not sure it is a good idea to do this for Hibernate ORM 6 already as > > > that wo
[hibernate-dev] Starting release process for ORM 5.3.18
Please don't push anything to 5.3 branch... Thanks, Gail ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
[hibernate-dev] Hibernate ORM 5.3.18.Final Released
https://in.relation.to/2020/08/05/hibernate-orm-5318-final-out/ ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
