From iris.clark at oracle.com Mon Jun 1 15:30:53 2020 From: iris.clark at oracle.com (Iris Clark) Date: Mon, 1 Jun 2020 08:30:53 -0700 (PDT) Subject: New Project: Leyden In-Reply-To: <<20200527152448.AC816357D04@eggemoggin.niobe.net>> References: <<20200527152448.AC816357D04@eggemoggin.niobe.net>> Message-ID: <23698c6a-24d1-4941-965c-e2a4a199206a@default> Vote: yes Iris From volker.simonis at gmail.com Mon Jun 1 16:45:08 2020 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 1 Jun 2020 18:45:08 +0200 Subject: CFV: New Project: Leyden In-Reply-To: <20200527152448.AC816357D04@eggemoggin.niobe.net> References: <20200527152448.AC816357D04@eggemoggin.niobe.net> Message-ID: Vote: yes On Wed, May 27, 2020 at 5:26 PM wrote: > > I hereby propose the creation a new Project, Leyden, with me as > the Lead and the Core Libraries and HotSpot Groups as sponsors. > > Leyden?s primary goal will be to address the long-term pain points > of Java?s slow startup time, slow time to peak performance, and large > footprint. Leyden will address these pain points by introducing a > concept of static images to the Java Platform, and to the JDK. > > For further details, please see the call for discussion [1]. > > I propose that the initial Reviewers of this Project include Alex > Buckley, Andrew Dinn, Andrew Haley, Bob Vandette, Claes Redestad, > Igor Veresov, Ioi Lam, Jiangli Zhou, Mandy Chung, Severin Gehwolf, > and Vladimir Kozlov. > > I expect ongoing contributions in the form of experience reports, > advice, and feedback from Christian Wimmer, Thomas Wuerthinger, > Vojin Jovanovic, and other members of Oracle?s GraalVM team. > > Votes are due by 23:59 UTC on Wednesday, 10 June 2020. > > Only current OpenJDK Members [2] are eligible to vote on this motion. > Votes must be cast in the open on the discuss list. Replying to this > message is sufficient if your mail program honors the Reply-To header. > > For Lazy Consensus voting instructions, see [3]. > > - Mark > > > [1] https://mail.openjdk.java.net/pipermail/discuss/2020-April/005429.html > [2] https://openjdk.java.net/census#members > [3] https://openjdk.java.net/projects/#new-project-vote From ioi.lam at oracle.com Wed Jun 3 05:40:23 2020 From: ioi.lam at oracle.com (Ioi Lam) Date: Tue, 2 Jun 2020 22:40:23 -0700 Subject: Call for Discussion: New Project: Leyden In-Reply-To: References: <20200427163855.10D3C32C99F@eggemoggin.niobe.net> <20200428094038.5375939@eggemoggin.niobe.net> <973c2a5f-fe19-b0dd-3b37-ffd59e18fc6e@oracle.com> Message-ID: <6a3293d9-cce5-5c99-40bb-dbfd00a6afac@oracle.com> Hi Mike, Thanks for sharing the concern for the start-up needs for developers. My personal feeling is Leyden will initially focused on production environments. One particular developer experience we need to solve is the build-time of the optimized image. Currently AOT needs lots of time and memory to compile the classes. CDS is also kind of slow (tens of seconds for 20,000 classes). In your edit/compile/run example, how much time are we talking about? Seconds or minuets? I guess one thing that we can consider in Leyden is the ability to partition the application into a "static" part and a "dynamic" part. If you just edit the code in the dynamic part, you can restart the static app quickly, and then just have to load the dynamic part slowly. In my experience with working for cached heap objects, I've found that they are extremely tangled. So we will need a tool similar to jdep, but can analyze the dependencies of the heap objects so that they can be properly partitioned. (Or, we can have design patterns that enforces partitioning -- e.g., cached objects cannot span across modules, or must be organized in a DAG, etc). For example, an app's cached objects can be partitioned into a series of checkpoints. If you have modified a module, we can restore to the last checkpoint that doesn't involve that module, and then resume dynamic class loading. Of course, a completely orthogonal way to solve this is to use edit-and-continue in various IDE offerings :-) Thanks - Ioi On 5/22/20 3:11 AM, Mike Hearn wrote: > Thanks Ioi, and thanks to Jiangli for the interesting presentation. > > Yes, class definition changes are certainly a problem. I spent a bit > of time looking at the AppCDS code a few months ago, back when I > thought the feature seemed not to be receiving much attention (glad to > see now that this was wrong!). I was curious if a customised JDK could > be used to make desktop apps start faster. > > My investigation went down the path of neither an annotation nor > language change but rather a "box api" like this: > > private static final Foo = new Archive<>(() -> > ??? return new Foo("some-expensive-to-load-thing.xml"); > ); > > For example, caching JavaFX scene graphs loaded from FXML. The Archive > class is defined to optionally run the lambda, but it may choose not > to if a prior object graph can be loaded. > > For the classloader situation I was digging in to whether AppCDS > archives could be scoped per module. At the moment OpenJDK seems to be > going down the path of shipping-oriented optimisations e.g. jlink, > "App"CDS. I wanted to see how re-usable the infrastructure was for use > during app development itself, because one area where startup time > really matters, and I don't see it being mentioned as part of Leyden, > is the edit/compile/run cycle. Obviously with an app-centric system > the answer is it can't help because the app is always changing. With a > more module-centric view, if the developer uses JPMS enthusiastically > e.g. one module per screen of the app, then other modules could be > seen as unchanging and have optimisations applied to them, i.e. AppCDS > archives dumped during a prior shutdown could be reused. > > For this to work you have to know if a module has changed, so you can > try to load or discard cached data. In JMOD/JAR form there's a > checksumming mechanism added to provide some basic enforcement of > "exports ? to ?" clauses. So I started looking at whether that could > be used, but during development modules are often in > exploded/directory form. So you'd need to be able to rapidly determine > if an entire directory hierarchy had changed, /or/ monitor it using > something like Facebook Watchman. This took me down the road of > thinking you'd need build system integration, which OpenJDK cannot > have in its current scope. My conclusion was that the Java world would > benefit from some kind of ?ber-project on top of OpenJDK and other > tools that integrated them more tightly together ? and that's where it > ended. > > No specific implementation conclusions, but I hope a more > module-centric vs app-centric set of features is explored - one of the > big wins of the Java platform is the combination of static type > checking /and/?script-like edit/run cycles. It'd be nice if some of > the Leyden work finds ways to be applicable prior to a final > jpackage-for-ship pass is done. > > > > > On Thu, May 21, 2020 at 20:59:09, Ioi Lam > wrote: > > On 5/19/20 7:07 AM, Mike Hearn wrote: > > Although this may be veering into an unwanted "what will it > be" discussion, I'm curious how fundamental it is that an > image must be either static or dynamic. > > HotSpot already does some speculative optimisations on the > assumption that new code isn't loaded e.g. the class hierarchy > analysis. Speculative optimisations do a great job of removing > costs of dynamic language features like class redefinition. > Leyden seems to be proposed as a new 'mode' of the Java > language, but could it also be envisioned as a new set of > optimisations that optimistically assume no dynamic code > loading? For instance, could a module be marked as "available > to dynamically loaded code" and then the points-to analysis / > dead code elimination would pin the public API of the module > before running, and if it's not marked as such, then DCE runs > across the boundaries too? > > A big part of the SubstrateVM startup time win appears to come > from a more aggressive version of the AppCDS heap > serialisation feature, and a general focus on startup time to > the exclusion of other factors (e.g. there's no notion of > module layers or module boundary enforcement). To what extent > is the closed-world assumption contributing to the > footprint/startup time wins vs other spec changes - is that > known? > > These questions aren't rhetorical, I don't have any view on > the answers. After playing around with native-image and seeing > mixed results (e.g. smaller wins than I thought for GUI JavaFX > apps), and looking at the work being done on AppCDS, I started > to wonder if HotSpot can eventually match the startup time and > footprint wins of native-image without the compatibility > breaking changes SVM makes to get there, just through doubling > down on current optimisation techniques like jlink and > speculation. > > Thanks for any insight offered! > > Hi Mike, > > Thanks for mentioning AppCDS. As someone working primarily on > AppCDS, I am happy to hear that you have a good impression on its > current state and potentials. Over the past few years, we have > done many start-up optimizations, in AppCDS and many other parts > of the JDK (core libs, jlink, hotspot, etc). You can see Claes > Redestat's excellent presentation here: > > https://cl4es.github.io/2019/11/20/OpenJDK-Startup-Update.html > > > Since JDK9, we have cut down the HelloWorld start-up time from > about 120ms in JDK 9? to less than 40ms in JDK 14. We will be > eking out a few more ms in JDK 15. > > A large part of the improvement is due to archiving heap objects > into CDS -- mostly related module information. In JDK 16, I hope > to finish JDK-8244778 (Archive complete module graph in CDS). My > prototype shows about 7~10ms improvement in start-up time. > > The problem with archiving heap objects, though, is currently it > requires a lot of manual work and knowledge about the code. I am > spending a lot of effort to take out 7~10ms for JDK-8244778. To be > useful in general applications, we need to make it much easier to > use. > > A key assumption of archiving heap objects is -- part of my > program will always produce the same set of objects, so I can > execute it ahead of time and save the results for later use. Maybe > "closed world" sounds too strong, but at least I need to have a > "stable world", where I am guaranteed to always see the exact same > bytecodes in the exact set of classes, so I can analyze them to > see if they will indeed always produce the same results. > > The problem is Java classes are loosely coupled, and the linking > happens only at execution time. A reference to "Foo" can give you > a completely different class (an app can even define classes > dynamically). I hope we can introduce a new "linking" concept in > the JLS, so Java classes can be more strongly combined together > into a bigger execution unit. > > For example, a "linked" app will already have Foo in the VM's > dictionary before any bytecodes are executed. So the app won't be > able to substitute an different Foo. I think this will help not > only AppCDS but also AOT compilation. > > I don't think speculation can help here -- if we have archived a > set of objects that involves Foo, and have used these objects part > away during execution, and (assuming we have not yet touched any > archived Foo objects yet) the app defines a new Foo class, we are > stuck. It would take tremendous effort to look at the archived > objects to patch the new version of the Foo objects, and this > won't be possible if you add or remove fields in Foo. We would > also need to add a lot of run time checks at every step to > guarantee that we indeed load the same classes. All these checks > will be counterproductive to start-up. > > Thanks > - Ioi > > From erik.helin at oracle.com Wed Jun 3 08:05:13 2020 From: erik.helin at oracle.com (Erik Helin) Date: Wed, 3 Jun 2020 10:05:13 +0200 Subject: CFV: New Project: Leyden In-Reply-To: <20200527152448.AC816357D04@eggemoggin.niobe.net> References: <20200527152448.AC816357D04@eggemoggin.niobe.net> Message-ID: <5a099ef8-a028-f4b3-b986-929ae3937cd8@oracle.com> Vote: yes Thanks, Erik On 5/27/20 5:24 PM, mark.reinhold at oracle.com wrote: > I hereby propose the creation a new Project, Leyden, with me as > the Lead and the Core Libraries and HotSpot Groups as sponsors. > > Leyden?s primary goal will be to address the long-term pain points > of Java?s slow startup time, slow time to peak performance, and large > footprint. Leyden will address these pain points by introducing a > concept of static images to the Java Platform, and to the JDK. > > For further details, please see the call for discussion [1]. > > I propose that the initial Reviewers of this Project include Alex > Buckley, Andrew Dinn, Andrew Haley, Bob Vandette, Claes Redestad, > Igor Veresov, Ioi Lam, Jiangli Zhou, Mandy Chung, Severin Gehwolf, > and Vladimir Kozlov. > > I expect ongoing contributions in the form of experience reports, > advice, and feedback from Christian Wimmer, Thomas Wuerthinger, > Vojin Jovanovic, and other members of Oracle?s GraalVM team. > > Votes are due by 23:59 UTC on Wednesday, 10 June 2020. > > Only current OpenJDK Members [2] are eligible to vote on this motion. > Votes must be cast in the open on the discuss list. Replying to this > message is sufficient if your mail program honors the Reply-To header. > > For Lazy Consensus voting instructions, see [3]. > > - Mark > > > [1] https://mail.openjdk.java.net/pipermail/discuss/2020-April/005429.html > [2] https://openjdk.java.net/census#members > [3] https://openjdk.java.net/projects/#new-project-vote > From mike at plan99.net Wed Jun 3 14:22:00 2020 From: mike at plan99.net (Mike Hearn) Date: Wed, 3 Jun 2020 07:22:00 -0700 Subject: Call for Discussion: New Project: Leyden In-Reply-To: <6a3293d9-cce5-5c99-40bb-dbfd00a6afac@oracle.com> References: <20200427163855.10D3C32C99F@eggemoggin.niobe.net> <20200428094038.5375939@eggemoggin.niobe.net> <973c2a5f-fe19-b0dd-3b37-ffd59e18fc6e@oracle.com> <6a3293d9-cce5-5c99-40bb-dbfd00a6afac@oracle.com> Message-ID: Thanks. I didn't quite follow the question about seconds or minutes. When iterating on code that's easily unit tested the JVM manages to provide a turnaround time of a few seconds, at least it does for me when incremental compilation is available. It gets more painful with app servers of course, hence the popularity of JRebel. Yes partitioning the app sounds like a great balance. It's the only way I can see for AppCDS/AOT type optimisations to be applicable during development, where otherwise JITC will continue to dominate despite that developers probably start their app more than anyone else! Usually only a tiny part of the app is changing and all the libraries are static, so build systems could figure out a semi-static set of modules pretty easily. Just assume anything pulled from a repository is static and eligible for optimisations. Heap archiving can be seen as a serialisation scheme, just one with an unusually unstable data format. I wonder if it helps to look at it like that - perhaps a lot of the logic can be moved into Java? For instance, do the AppCDS archives *have* to be generated by C++ looking for magic annotations/iterating the heap, or could some privileged Java code just walk the graph, doing whatever checks are considered useful and building a simple Object[] which is then passed into the VM for the GC to format a heap region and return it as a byte buffer? Then build system authors, app containers etc can take over management of AppCDS files, like deciding when to [re]generate them and for which modules it's worth doing. I've tried using the DCEVM in the past, which has better edit and continue. It sounds good but I found that I very rarely edited *only* post-initialisation code and so editing classes in place just ended up being kind of useless, as there was no way to force re-construction and no obvious semantics for how it could work. Especially problematic for GUI apps, which is the kind of app where you really benefit from fast iteration times but most of the iteration is in the code that constructs the GUI. I looked a bit at how to resolve that. I toyed a bit with adding a notification queue to classloaders, that lets app code learn when a class has been redefined, and some APIs on top that would automatically track dependencies and trigger re-construction of object graphs at various user-defined points. Because DCEVM uses a rather large and complex patch I ended up looking more into whether it'd be possible to do this with just classloaders, perhaps in combination with a much smaller JVM patch, as if you're rebuilding object graphs anyway then most of the magic class redefinition does isn't actually useful. From ioi.lam at oracle.com Thu Jun 4 06:10:18 2020 From: ioi.lam at oracle.com (Ioi Lam) Date: Wed, 3 Jun 2020 23:10:18 -0700 Subject: Call for Discussion: New Project: Leyden In-Reply-To: References: <20200427163855.10D3C32C99F@eggemoggin.niobe.net> <20200428094038.5375939@eggemoggin.niobe.net> <973c2a5f-fe19-b0dd-3b37-ffd59e18fc6e@oracle.com> <6a3293d9-cce5-5c99-40bb-dbfd00a6afac@oracle.com> Message-ID: On 6/3/20 7:22 AM, Mike Hearn wrote: > Thanks. > > I didn't quite follow the question about seconds or minutes. When > iterating on code that's easily unit tested the JVM manages to provide > a turnaround time of a few seconds, at least it does for me when > incremental compilation is available. It gets more painful with app > servers of course, hence the popularity of JRebel. > > Yes partitioning the app sounds like a great balance. It's the only > way I can see for AppCDS/AOT type optimisations to be applicable > during development, where otherwise JITC will continue to dominate > despite that developers probably start their app more than anyone > else! Usually only a tiny part of the app is changing and all the > libraries are static, so build systems could figure out a semi-static > set of modules pretty easily. Just assume anything pulled from a > repository is static and eligible for optimisations. > > Heap archiving can be seen as a serialisation scheme, just one with an > unusually unstable data format. I wonder if it helps to look at it > like that - perhaps a lot of the logic can be moved into Java? For > instance, do the AppCDS archives /have/ to be generated by C++ looking > for magic annotations/iterating the heap, or could some privileged > Java code just walk the graph, doing whatever checks are considered > useful and building a simple Object[] which is then passed into the VM > for the GC to format a heap region and return it as a byte buffer? > Then build system authors, app containers etc can take over management > of AppCDS files, like deciding when to [re]generate them and for which > modules it's worth doing. The current way for AppCDS for archiving heap objects is certainly too restricted. I think we'll probably allow a subset of classes to be initialized ahead of time, and the static fields of those classes will be archived into the heap. There are challenges -- picking the correct/optimal subset many require substantial work; we also need to make sure we don't archive the wrong things (ephemeral resources, environment dependencies, etc). Thanks - Ioi > > I've tried using the DCEVM in the past, which has better edit and > continue. It sounds good but I found that I very rarely edited /only/ > post-initialisation code and so editing classes in place just ended up > being kind of useless, as there was no way to force re-construction > and no obvious semantics for how it could work. Especially problematic > for GUI apps, which is the kind of app where you really benefit from > fast iteration times but most of the iteration is in the code that > constructs the GUI. > > I looked a bit at how to resolve that. I toyed a bit with adding a > notification queue to classloaders, that lets app code learn when a > class has been redefined, and some APIs on top that would > automatically track dependencies and trigger re-construction of object > graphs at various user-defined points. Because DCEVM uses a rather > large and complex patch I ended up looking more into whether it'd be > possible to do this with?just classloaders, perhaps in combination > with a much smaller JVM patch, as if you're rebuilding object graphs > anyway then most of the magic class redefinition does isn't actually > useful. > > From adinn at redhat.com Thu Jun 4 09:17:38 2020 From: adinn at redhat.com (Andrew Dinn) Date: Thu, 4 Jun 2020 10:17:38 +0100 Subject: Call for Discussion: New Project: Leyden In-Reply-To: References: <20200427163855.10D3C32C99F@eggemoggin.niobe.net> <20200428094038.5375939@eggemoggin.niobe.net> <973c2a5f-fe19-b0dd-3b37-ffd59e18fc6e@oracle.com> <6a3293d9-cce5-5c99-40bb-dbfd00a6afac@oracle.com> Message-ID: <35c26428-5f1e-c59c-67a9-8f16d4579f10@redhat.com> I would like to throw in a general point here based on my experience of working with Graal and the SubstrateVM for some time, perhaps at the risk of hijacking this current direction of travel (for which, apologies). In my experience the notion of a 'static' image which provides the sort of footprint and startup improvements that Graal has shown to be possible while still retaining the dynamic load/link capabilities that the JVM provides (i.e. discarding the closed world assumption) appears to reside in the same ontological category as the King of France or the unicorn horn. Indeed, I suspect it may even be a square, round cupola. Graal derives almost all of its space/time reductions relative to the dynamic JVM from being able to discard great swathes of class metadata and class initialization. A closed world assumption is critical to the validity and comprehensive applicability of both those dietary regimes. Under that assumption almost all of the details of the loaded class base are simply not needed at runtime. All decisions which depend on what classes are present and how they are structured are baked in at compile time. A great deal of initialization code and resulting static data can be compressed out of VM startup by performing the necessary init at build-time and embedding only the (runtime-) referenced static field values and objects in a pre-populated heap, some of that data read-only, some of it read-write. n.b. that's just as much an option for app data as it is for JDK data. With a dynamic runtime it is much harder to determine 1) whether or not a static field might be referenced and (worse) 2) whether it's value might get computed differently from the value derivable at build-time, due to intermediate loading of dynamic code. The Graal 'static' image compiler also contributes significantly to improvement of image code size and speed when compared to the OpenJDK AOT compiler (also, at present, the Graal compiler in a very different configuration). The former can almost always employ direct linkage, the latter has to use copious amounts of indirection to allow for later update to the class base. The Graal 'static' image compiler obviously cannot rely on runtime feedback to improve code performance but neither can an OpenJDK AOT compiler when generating the initial AOT code. However, the former compiler can profit from the closed world assumption to perform a few AOT optimizations that can only be performed speculatively on OpenJDK if dynamic loading is to be allowed. Not all such speculative opportunities are currently taken, mainly because not all application classes are normally included in the compiled AppCDS suite. Of course, if OpenJDK AOT implemented a more comprehensive reachability analysis then it might be able to embrace many of the same speculative optimization opportunities over a more full, known application class suite. However, it would still need to employ more metadata and a more indirect linkage model in order to allow for dynamic loading. On 04/06/2020 07:10, Ioi Lam wrote: > > > On 6/3/20 7:22 AM, Mike Hearn wrote: >> Thanks. >> >> I didn't quite follow the question about seconds or minutes. When >> iterating on code that's easily unit tested the JVM manages to provide >> a turnaround time of a few seconds, at least it does for me when >> incremental compilation is available. It gets more painful with app >> servers of course, hence the popularity of JRebel. >> >> Yes partitioning the app sounds like a great balance. It's the only >> way I can see for AppCDS/AOT type optimisations to be applicable >> during development, where otherwise JITC will continue to dominate >> despite that developers probably start their app more than anyone >> else! Usually only a tiny part of the app is changing and all the >> libraries are static, so build systems could figure out a semi-static >> set of modules pretty easily. Just assume anything pulled from a >> repository is static and eligible for optimisations. >> >> Heap archiving can be seen as a serialisation scheme, just one with an >> unusually unstable data format. I wonder if it helps to look at it >> like that - perhaps a lot of the logic can be moved into Java? For >> instance, do the AppCDS archives /have/ to be generated by C++ looking >> for magic annotations/iterating the heap, or could some privileged >> Java code just walk the graph, doing whatever checks are considered >> useful and building a simple Object[] which is then passed into the VM >> for the GC to format a heap region and return it as a byte buffer? >> Then build system authors, app containers etc can take over management >> of AppCDS files, like deciding when to [re]generate them and for which >> modules it's worth doing. > > The current way for AppCDS for archiving heap objects is certainly too > restricted. I think we'll probably allow a subset of classes to be > initialized ahead of time, and the static fields of those classes will > be archived into the heap. There are challenges -- picking the > correct/optimal subset many require substantial work; we also need to > make sure we don't archive the wrong things (ephemeral resources, > environment dependencies, etc). > > Thanks > - Ioi > >> >> I've tried using the DCEVM in the past, which has better edit and >> continue. It sounds good but I found that I very rarely edited /only/ >> post-initialisation code and so editing classes in place just ended up >> being kind of useless, as there was no way to force re-construction >> and no obvious semantics for how it could work. Especially problematic >> for GUI apps, which is the kind of app where you really benefit from >> fast iteration times but most of the iteration is in the code that >> constructs the GUI. >> >> I looked a bit at how to resolve that. I toyed a bit with adding a >> notification queue to classloaders, that lets app code learn when a >> class has been redefined, and some APIs on top that would >> automatically track dependencies and trigger re-construction of object >> graphs at various user-defined points. Because DCEVM uses a rather >> large and complex patch I ended up looking more into whether it'd be >> possible to do this with?just classloaders, perhaps in combination >> with a much smaller JVM patch, as if you're rebuilding object graphs >> anyway then most of the magic class redefinition does isn't actually >> useful. >> >> > -- 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 From mike at plan99.net Thu Jun 4 10:11:38 2020 From: mike at plan99.net (Mike Hearn) Date: Thu, 4 Jun 2020 03:11:38 -0700 Subject: Call for Discussion: New Project: Leyden In-Reply-To: <35c26428-5f1e-c59c-67a9-8f16d4579f10@redhat.com> References: <20200427163855.10D3C32C99F@eggemoggin.niobe.net> <20200428094038.5375939@eggemoggin.niobe.net> <973c2a5f-fe19-b0dd-3b37-ffd59e18fc6e@oracle.com> <6a3293d9-cce5-5c99-40bb-dbfd00a6afac@oracle.com> <35c26428-5f1e-c59c-67a9-8f16d4579f10@redhat.com> Message-ID: Graal derives almost all of its space/time reductions relative to the > dynamic JVM from being able to discard great swathes of class metadata and > class initialization. A closed world assumption is critical to the validity > and comprehensive applicability of both those dietary regimes. > The argument makes sense. Still, AppCDS makes images bigger and also start faster. A CRUI of the JVM after reaching a startup checkpoint would be bigger still. So I wonder if there's a risk of conflating space and time optimisations more than is strictly necessary? The big win for developer iteration is coming only from startup times. Image size doesn't matter at all. Likewise for apps like IDEs and build tools as developer machines usually have plenty of free disk space. Is that also true for cloud/containers? Sure, less disk space usage is nice and obviously caches mean size and speed are interrelated, but a stock JVM with jlink gets disk size down pretty far already and native code is quite verbose. I found that for even toy "real apps" the native images could quickly get as large as a regular JDK, simply because x86 machine code for every possible code path vs compressed bytecode added up quickly. Demand for instant startup isn't only driven by demand for dynamic scaling but also avoiding complex deployments, where newly started servers need to perform a self-driving warm up on test data as otherwise users who hit a cold server get request timeouts. We had some nasty outages back in the day at Google caused by the massive speed difference between cold and warm servers; native images get rid of that as a concern completely (at the cost of a more complex build/deploy loop). If people had to pick smaller containers size-wise *or* fast startup and weren't allowed both, I bet nearly all would go for the fast startup. If your hypothesis about the benefits primarily coming from discarding data is correct (vs the more direct linkage forms the different AOT compiler can use), is it strictly necessary to discard the data or just not load it on the hot paths? How much research is done on which benefits users are most sensitive to and to what extent it's the closed world optimisations that are driving them, vs all the pre-initialisation and heap snapshotting? Losing open world is quite painful from a frameworks perspective. A lot of projects that are startup-time sensitive will be unable to go closed world easily or at all, because they are heavily plugin based. Many projects will be forced to pick between convenience and footprint. If it's truly unavoidable then so be it. From adinn at redhat.com Thu Jun 4 10:32:12 2020 From: adinn at redhat.com (Andrew Dinn) Date: Thu, 4 Jun 2020 11:32:12 +0100 Subject: Call for Discussion: New Project: Leyden In-Reply-To: References: <20200427163855.10D3C32C99F@eggemoggin.niobe.net> <20200428094038.5375939@eggemoggin.niobe.net> <973c2a5f-fe19-b0dd-3b37-ffd59e18fc6e@oracle.com> <6a3293d9-cce5-5c99-40bb-dbfd00a6afac@oracle.com> <35c26428-5f1e-c59c-67a9-8f16d4579f10@redhat.com> Message-ID: On 04/06/2020 11:11, Mike Hearn wrote: > If your hypothesis about the benefits primarily coming from discarding > data is correct (vs the more direct linkage forms the different AOT > compiler can use), is it strictly necessary to discard?the data or just > not load it on the hot paths? How much research is done on which > benefits users are most sensitive to and to what extent it's the closed > world optimisations that are driving them, vs all the pre-initialisation > and heap snapshotting? Reorganizing the data so that hot and cold elements were not interleaved on the same page would be a help. However. that means you need to know what is hot and what is cold. So, yes a different metadata partitioning would win back some of the image size reductions. It's harder to do with static field data. You could put the stuff you know for sure gets referenced into one segment and stuff that you don't know about into another but that's about it. > Losing open world is quite painful from a frameworks perspective. A lot > of projects that are startup-time sensitive will be unable to go closed > world easily or at all, because they are heavily plugin based. Many > projects will be forced to pick between convenience and footprint. If > it's truly unavoidable then so be it. Yes, that's true for some users and some uses. However, I think the need for dynamic capabilities is over-estimated. In many cases they are used simply because they were there without consideration as to the cost. For example, Red Hat's Quarkus product has made it possible to to remove many unnecessary uses of dynamic capabilities from most of the common enterprise middleware libraries. An enormous number of applications have been able to benefit from that to improve footprint and startup time. Note those benefits arise when deploying both on the dynamic JVM and as native images using Graal Native, although obviusly the JVM savings are not as down to the bone as those for Graal (for the reasons I outlined earlier). n.b. Quarkus operates largely as a build preprocessor that explicitly unpicks and substitutes build-time alternatives to replace uses of dynamic capabilities (using a variety of code analyses and bytecode transformations). Quarkus was not originally developed in order to profit from Graal Native deployment. It was developed in response to the significant costs that were observed from using dynamic capablilities in Java frameworks when a static model was actually all that was really needed. n.b. apologies if this comes across as a blurb for a Red Hat product -- it's not intended to be that. 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 From claes.redestad at oracle.com Thu Jun 4 11:27:17 2020 From: claes.redestad at oracle.com (Claes Redestad) Date: Thu, 4 Jun 2020 13:27:17 +0200 Subject: Call for Discussion: New Project: Leyden In-Reply-To: References: <20200427163855.10D3C32C99F@eggemoggin.niobe.net> <20200428094038.5375939@eggemoggin.niobe.net> <973c2a5f-fe19-b0dd-3b37-ffd59e18fc6e@oracle.com> <6a3293d9-cce5-5c99-40bb-dbfd00a6afac@oracle.com> <35c26428-5f1e-c59c-67a9-8f16d4579f10@redhat.com> Message-ID: I think it's important to remember that while leyden is about static, closed world images, this doesn't preclude work on optimizations that help full, open world JVM deployments. Just that such work will most likely be out of scope for _this_ project. Ideally I think we'd all like to see some cross-pollination where improvements done to help deliver leyden can also be made to benefit full JVM deployments - if only partially. /Claes On 2020-06-04 12:32, Andrew Dinn wrote: > On 04/06/2020 11:11, Mike Hearn wrote: >> If your hypothesis about the benefits primarily coming from discarding >> data is correct (vs the more direct linkage forms the different AOT >> compiler can use), is it strictly necessary to discard?the data or just >> not load it on the hot paths? How much research is done on which >> benefits users are most sensitive to and to what extent it's the closed >> world optimisations that are driving them, vs all the pre-initialisation >> and heap snapshotting? > > Reorganizing the data so that hot and cold elements were not interleaved > on the same page would be a help. However. that means you need to know > what is hot and what is cold. So, yes a different metadata partitioning > would win back some of the image size reductions. It's harder to do with > static field data. You could put the stuff you know for sure gets > referenced into one segment and stuff that you don't know about into > another but that's about it. > >> Losing open world is quite painful from a frameworks perspective. A lot >> of projects that are startup-time sensitive will be unable to go closed >> world easily or at all, because they are heavily plugin based. Many >> projects will be forced to pick between convenience and footprint. If >> it's truly unavoidable then so be it. > Yes, that's true for some users and some uses. However, I think the need > for dynamic capabilities is over-estimated. In many cases they are used > simply because they were there without consideration as to the cost. > > For example, Red Hat's Quarkus product has made it possible to to remove > many unnecessary uses of dynamic capabilities from most of the common > enterprise middleware libraries. An enormous number of applications have > been able to benefit from that to improve footprint and startup time. > Note those benefits arise when deploying both on the dynamic JVM and as > native images using Graal Native, although obviusly the JVM savings are > not as down to the bone as those for Graal (for the reasons I outlined > earlier). > > n.b. Quarkus operates largely as a build preprocessor that explicitly > unpicks and substitutes build-time alternatives to replace uses of > dynamic capabilities (using a variety of code analyses and bytecode > transformations). Quarkus was not originally developed in order to > profit from Graal Native deployment. It was developed in response to the > significant costs that were observed from using dynamic capablilities in > Java frameworks when a static model was actually all that was really needed. > > n.b. apologies if this comes across as a blurb for a Red Hat product -- > it's not intended to be that. > > 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 > From mohammed.moayed at gmail.com Thu Jun 4 16:27:14 2020 From: mohammed.moayed at gmail.com (Mohammed Al-Moayed) Date: Thu, 4 Jun 2020 19:27:14 +0300 Subject: Call for Discussion: New Project: Leyden In-Reply-To: <20200427163855.10D3C32C99F@eggemoggin.niobe.net> References: <20200427163855.10D3C32C99F@eggemoggin.niobe.net> Message-ID: <26062C3A-9E0F-4483-A1BA-85D5F17526DD@gmail.com> Interested Please, consider me, to participate in this project Regards Almo > On Apr 27, 2020, at 7:40 PM, mark.reinhold at oracle.com wrote: > > ?I hereby invite discussion of a new Project, Leyden, whose primary goal > will be to address the long-term pain points of Java?s slow startup time, > slow time to peak performance, and large footprint. > > Leyden will address these pain points by introducing a concept of _static > images_ to the Java Platform, and to the JDK. > > - A static image is a standalone program, derived from an application, > which runs that application -- and no other. > > - A static image is a closed world: It cannot load classes from outside > the image, nor can it spin new bytecodes at run time. > > These two constraints enable build-time analyses that can remove unused > classes and identify class initializers which can be run at build time, > thereby reducing both the size of the image and its startup time. These > constraints also enable aggressive ahead-of-time compilation, thereby > reducing the image?s time to peak performance. > > Static images are not for everyone, due to the closed-world constraint, > nor are they for every type of application. They often require manual > configuration in order to achieve the best results. We do, however, > expect the results to be worthwhile in important deployment scenarios > such as small embedded devices and the cloud. > > Project Leyden will take inspiration from past efforts to explore this > space, including the GNU Compiler for Java [1] and the Native Image > feature of GraalVM [2]. Leyden will add static images to the Java > Platform Specification, and we expect that GraalVM will evolve to > implement that Specification. Developers who use only the standard, > specified static-image feature will then be able to switch with ease > between Leyden (in the JDK), Native Image (in GraalVM), and whatever > other conforming implementations may arise, choosing amongst tradeoffs > of compile time, startup time, and image size. > > We do not intend to implement Leyden by merging the Native Image code > from GraalVM into the JDK. Leyden will, rather, be based upon existing > components in the JDK such as the HotSpot JVM, the `jaotc` ahead-of-time > compiler [3], application class-data sharing [4], and the `jlink` linking > tool [5]. > > I propose to lead this Project with an initial set of Reviewers that > includes, but is not limited to, Alex Buckley, Bob Vandette, Claes > Redestad, Igor Veresov, Ioi Lam, Mandy Chung, and Vladimir Kozlov. > > This Project will start with a clone of the current JDK main-line > release, JDK 15, and track main-line releases going forward. We expect > to deliver Leyden over time, in a series of JEPs that will likely span > multiple feature releases. > > Comments? > > - Mark > > > [1] https://en.wikipedia.org/wiki/GNU_Compiler_for_Java > [2] https://www.graalvm.org/docs/reference-manual/native-image/ > [3] https://openjdk.java.net/jeps/295 > [4] https://openjdk.java.net/jeps/310 > [5] https://openjdk.java.net/jeps/282 From mike at plan99.net Thu Jun 4 10:57:22 2020 From: mike at plan99.net (Mike Hearn) Date: Thu, 4 Jun 2020 03:57:22 -0700 Subject: Call for Discussion: New Project: Leyden In-Reply-To: References: <20200427163855.10D3C32C99F@eggemoggin.niobe.net> <20200428094038.5375939@eggemoggin.niobe.net> <973c2a5f-fe19-b0dd-3b37-ffd59e18fc6e@oracle.com> <6a3293d9-cce5-5c99-40bb-dbfd00a6afac@oracle.com> <35c26428-5f1e-c59c-67a9-8f16d4579f10@redhat.com> Message-ID: Not a problem! It's very interesting to learn that Quarkus was conceived independently of native-image. Agree there's a lot of abuse of dynamic features in the Java ecosystem. Much seems to be driven by lack of familiarity with annotation processors. The reflection APIs are well understood and widely used so everyone knows them, they're language independent, using ASM to generate some bytecode isn't that hard and then classloaders are right there, waiting to be used. There are way fewer examples of how to write an annotation processor out there, especially if you want to support Java, Kotlin, Scala etc all together. Some good tutorials and a framework or two would help a lot. As for systems that make everything a plugin, well ? from a usability perspective alone I'd like to see the back of that trend. Having to Google for the latest version of the plugin that checks for the latest versions of the plugins has been a lowlight. From ioi.lam at oracle.com Thu Jun 4 18:03:09 2020 From: ioi.lam at oracle.com (Ioi Lam) Date: Thu, 4 Jun 2020 11:03:09 -0700 Subject: Call for Discussion: New Project: Leyden In-Reply-To: <35c26428-5f1e-c59c-67a9-8f16d4579f10@redhat.com> References: <20200427163855.10D3C32C99F@eggemoggin.niobe.net> <20200428094038.5375939@eggemoggin.niobe.net> <973c2a5f-fe19-b0dd-3b37-ffd59e18fc6e@oracle.com> <6a3293d9-cce5-5c99-40bb-dbfd00a6afac@oracle.com> <35c26428-5f1e-c59c-67a9-8f16d4579f10@redhat.com> Message-ID: On 6/4/20 2:17 AM, Andrew Dinn wrote: > I would like to throw in a general point here based on my experience of > working with Graal and the SubstrateVM for some time, perhaps at the > risk of hijacking this current direction of travel (for which, apologies). > > In my experience the notion of a 'static' image which provides the sort > of footprint and startup improvements that Graal has shown to be > possible while still retaining the dynamic load/link capabilities that > the JVM provides (i.e. discarding the closed world assumption) appears > to reside in the same ontological category as the King of France or the > unicorn horn. Indeed, I suspect it may even be a square, round cupola. My hypothesis is: you can have fast start-up speed,? small image size, and correctness -- just pick any two. Sure, for trivial programs that can be fully analyzed, you can get all 3 of them. However, once you're using (legacy) libraries that use reflection, it becomes extremely difficult. > Graal derives almost all of its space/time reductions relative to the > dynamic JVM from being able to discard great swathes of class metadata > and class initialization. A closed world assumption is critical to the > validity and comprehensive applicability of both those dietary regimes. > > Under that assumption almost all of the details of the loaded class base > are simply not needed at runtime. All decisions which depend on what > classes are present and how they are structured are baked in at compile > time. A great deal of initialization code and resulting static data can > be compressed out of VM startup by performing the necessary init at > build-time and embedding only the (runtime-) referenced static field > values and objects in a pre-populated heap, some of that data read-only, > some of it read-write. n.b. that's just as much an option for app data > as it is for JDK data. With a dynamic runtime it is much harder to > determine 1) whether or not a static field might be referenced and > (worse) 2) whether it's value might get computed differently from the > value derivable at build-time, due to intermediate loading of dynamic code. > > The Graal 'static' image compiler also contributes significantly to > improvement of image code size and speed when compared to the OpenJDK > AOT compiler (also, at present, the Graal compiler in a very different > configuration). The former can almost always employ direct linkage, the > latter has to use copious amounts of indirection to allow for later > update to the class base. > > The Graal 'static' image compiler obviously cannot rely on runtime > feedback to improve code performance but neither can an OpenJDK AOT > compiler when generating the initial AOT code. However, the former > compiler can profit from the closed world assumption to perform a few > AOT optimizations that can only be performed speculatively on OpenJDK if > dynamic loading is to be allowed. Not all such speculative opportunities > are currently taken, mainly because not all application classes are > normally included in the compiled AppCDS suite. > > Of course, if OpenJDK AOT implemented a more comprehensive reachability > analysis then it might be able to embrace many of the same speculative > optimization opportunities over a more full, known application class > suite. However, it would still need to employ more metadata and a more > indirect linkage model in order to allow for dynamic loading. We have one problem in AppCDS and AOT that costs us dearly in speed and size -- we have lots of checks for class shape changes. That's because a class named "Foo" can have completely different bytecodes and class hierarchy a run time, so we must invalidate the caches when that happens. If we can have a way to guarantee that the classes will not change, we can optimize much better. For example, we can run with a special flag that will cause ???? ClassLoader.defineClass("Foo", .....) to throw an UnsupportedOperationException Or, we start the VM in such a way that a known version of Foo is already "loaded" before any bytecode is executed, so there's no way for the app to plug in a different Foo. Such restrictions can help with image size as well -- if Foo is rarely used, we can actually exclude it from the CDS image, and decode it from compressed classfile only when needed. Thanks - Ioi > > On 04/06/2020 07:10, Ioi Lam wrote: >> >> On 6/3/20 7:22 AM, Mike Hearn wrote: >>> Thanks. >>> >>> I didn't quite follow the question about seconds or minutes. When >>> iterating on code that's easily unit tested the JVM manages to provide >>> a turnaround time of a few seconds, at least it does for me when >>> incremental compilation is available. It gets more painful with app >>> servers of course, hence the popularity of JRebel. >>> >>> Yes partitioning the app sounds like a great balance. It's the only >>> way I can see for AppCDS/AOT type optimisations to be applicable >>> during development, where otherwise JITC will continue to dominate >>> despite that developers probably start their app more than anyone >>> else! Usually only a tiny part of the app is changing and all the >>> libraries are static, so build systems could figure out a semi-static >>> set of modules pretty easily. Just assume anything pulled from a >>> repository is static and eligible for optimisations. >>> >>> Heap archiving can be seen as a serialisation scheme, just one with an >>> unusually unstable data format. I wonder if it helps to look at it >>> like that - perhaps a lot of the logic can be moved into Java? For >>> instance, do the AppCDS archives /have/ to be generated by C++ looking >>> for magic annotations/iterating the heap, or could some privileged >>> Java code just walk the graph, doing whatever checks are considered >>> useful and building a simple Object[] which is then passed into the VM >>> for the GC to format a heap region and return it as a byte buffer? >>> Then build system authors, app containers etc can take over management >>> of AppCDS files, like deciding when to [re]generate them and for which >>> modules it's worth doing. >> The current way for AppCDS for archiving heap objects is certainly too >> restricted. I think we'll probably allow a subset of classes to be >> initialized ahead of time, and the static fields of those classes will >> be archived into the heap. There are challenges -- picking the >> correct/optimal subset many require substantial work; we also need to >> make sure we don't archive the wrong things (ephemeral resources, >> environment dependencies, etc). >> >> Thanks >> - Ioi >> >>> I've tried using the DCEVM in the past, which has better edit and >>> continue. It sounds good but I found that I very rarely edited /only/ >>> post-initialisation code and so editing classes in place just ended up >>> being kind of useless, as there was no way to force re-construction >>> and no obvious semantics for how it could work. Especially problematic >>> for GUI apps, which is the kind of app where you really benefit from >>> fast iteration times but most of the iteration is in the code that >>> constructs the GUI. >>> >>> I looked a bit at how to resolve that. I toyed a bit with adding a >>> notification queue to classloaders, that lets app code learn when a >>> class has been redefined, and some APIs on top that would >>> automatically track dependencies and trigger re-construction of object >>> graphs at various user-defined points. Because DCEVM uses a rather >>> large and complex patch I ended up looking more into whether it'd be >>> possible to do this with?just classloaders, perhaps in combination >>> with a much smaller JVM patch, as if you're rebuilding object graphs >>> anyway then most of the magic class redefinition does isn't actually >>> useful. >>> >>> From rasbold at google.com Thu Jun 4 21:36:54 2020 From: rasbold at google.com (Chuck Rasbold) Date: Thu, 4 Jun 2020 14:36:54 -0700 Subject: CFV: New Project: Leyden In-Reply-To: <20200527152448.AC816357D04@eggemoggin.niobe.net> References: <20200527152448.AC816357D04@eggemoggin.niobe.net> Message-ID: Vote: yes On Wed, May 27, 2020 at 8:26 AM wrote: > I hereby propose the creation a new Project, Leyden, with me as > the Lead and the Core Libraries and HotSpot Groups as sponsors. > > Leyden?s primary goal will be to address the long-term pain points > of Java?s slow startup time, slow time to peak performance, and large > footprint. Leyden will address these pain points by introducing a > concept of static images to the Java Platform, and to the JDK. > > For further details, please see the call for discussion [1]. > > I propose that the initial Reviewers of this Project include Alex > Buckley, Andrew Dinn, Andrew Haley, Bob Vandette, Claes Redestad, > Igor Veresov, Ioi Lam, Jiangli Zhou, Mandy Chung, Severin Gehwolf, > and Vladimir Kozlov. > > I expect ongoing contributions in the form of experience reports, > advice, and feedback from Christian Wimmer, Thomas Wuerthinger, > Vojin Jovanovic, and other members of Oracle?s GraalVM team. > > Votes are due by 23:59 UTC on Wednesday, 10 June 2020. > > Only current OpenJDK Members [2] are eligible to vote on this motion. > Votes must be cast in the open on the discuss list. Replying to this > message is sufficient if your mail program honors the Reply-To header. > > For Lazy Consensus voting instructions, see [3]. > > - Mark > > > [1] https://mail.openjdk.java.net/pipermail/discuss/2020-April/005429.html > [2] https://openjdk.java.net/census#members > [3] https://openjdk.java.net/projects/#new-project-vote > From christoph.langer at sap.com Mon Jun 8 12:49:59 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 8 Jun 2020 12:49:59 +0000 Subject: CFV: New Project: Leyden In-Reply-To: <20200527152448.AC816357D04@eggemoggin.niobe.net> References: <20200527152448.AC816357D04@eggemoggin.niobe.net> Message-ID: Vote: yes /Christoph > -----Original Message----- > From: announce On Behalf Of > mark.reinhold at oracle.com > Sent: Mittwoch, 27. Mai 2020 17:25 > To: announce at openjdk.java.net > Subject: CFV: New Project: Leyden > > I hereby propose the creation a new Project, Leyden, with me as > the Lead and the Core Libraries and HotSpot Groups as sponsors. > > Leyden?s primary goal will be to address the long-term pain points > of Java?s slow startup time, slow time to peak performance, and large > footprint. Leyden will address these pain points by introducing a > concept of static images to the Java Platform, and to the JDK. > > For further details, please see the call for discussion [1]. > > I propose that the initial Reviewers of this Project include Alex > Buckley, Andrew Dinn, Andrew Haley, Bob Vandette, Claes Redestad, > Igor Veresov, Ioi Lam, Jiangli Zhou, Mandy Chung, Severin Gehwolf, > and Vladimir Kozlov. > > I expect ongoing contributions in the form of experience reports, > advice, and feedback from Christian Wimmer, Thomas Wuerthinger, > Vojin Jovanovic, and other members of Oracle?s GraalVM team. > > Votes are due by 23:59 UTC on Wednesday, 10 June 2020. > > Only current OpenJDK Members [2] are eligible to vote on this motion. > Votes must be cast in the open on the discuss list. Replying to this > message is sufficient if your mail program honors the Reply-To header. > > For Lazy Consensus voting instructions, see [3]. > > - Mark > > > [1] https://mail.openjdk.java.net/pipermail/discuss/2020-April/005429.html > [2] https://openjdk.java.net/census#members > [3] https://openjdk.java.net/projects/#new-project-vote From paul.sandoz at oracle.com Mon Jun 8 15:49:43 2020 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 8 Jun 2020 08:49:43 -0700 Subject: CFV: New Project: Leyden In-Reply-To: <20200527152448.AC816357D04@eggemoggin.niobe.net> References: <20200527152448.AC816357D04@eggemoggin.niobe.net> Message-ID: Vote: yes Paul. From esteban.ginez at oracle.com Mon Jun 8 16:59:31 2020 From: esteban.ginez at oracle.com (Esteban Ginez) Date: Mon, 8 Jun 2020 09:59:31 -0700 Subject: Call for Discussion: New Project: Leyden In-Reply-To: References: <20200521154809.788017090@eggemoggin.niobe.net> Message-ID: <8E178FCC-D98E-4BB3-9564-D835F947459B@oracle.com> Hi Jiangli I took some time to review some of the docs you sent about class initialization, and I would like to highlight one key thing we have been observing in the Graalvm team. The usage of annotations to mark classes as ?pre-initializable? is insufficient. The java community relies on well known, time tested, java libraries. It is often the case that the application owner relies on dependencies he does not even know (or care to know) about . Restricting the capacity to pre-initialize an application via annotations, at minimum, will leave behind code that can not be annotated due to lack of ownership. Further, as we have been experiencing in the GraalVM team, it has been challenge for lower level libraries, to a-priory decide the set of code that can be pre-initialized, without taking into consideration the particular usage of the library. That being said, it is great to see other teams in the community working on similar problems, so thanks a lot of sharing your work Warmly E. > On May 21, 2020, at 5:23 PM, Jiangli Zhou wrote: > > On Thu, May 21, 2020 at 3:48 PM > wrote: > >> 2020/5/18 15:43:34 -0700, jianglizhou at google.com : >>> Didn't see this discussion until today. I think this will be welcomed by >>> Java developers! How do we participate in the project and coordinate? >> >> I?ll shortly start the CFV to create the Project. Once the Project >> exists, your participation will be most welcome! >> > > Sounds great! > > >> >>> I have been experimenting with preserving pre-initialized classes (at >> build >>> time) as part of the CDS archive image. Class pre-initialization can help >>> field and method pre-resolution and generate better AOT code. Here is a >> class >>> pre-resolution & pre-initialization proposal >>> < >> https://docs.google.com/document/d/17RV8W6iqJj9HhjGSO9k1IXfs_9lvHDNgxxr8pFoeDys/edit?usp=sharing >>> >>> that enhances >>> the existing Hotspot heap archiving and provides more general support to >>> pre-initialize classes and preserve static field values for both JDK >>> classes and application classes (loaded by system class loader). >> >> Sorry, but for IP clarity could you please either post that document to >> cr.openjdk.java.net or enter it into a JBS issue? (Likewise for the >> slides that you mention later on.) >> > > I've posted the docs to cr.openjdk.java.net : > > Design doc: > http://cr.openjdk.java.net/~jiangli/Leyden/Java%20Class%20Pre-resolution%20and%20Pre-initialization%20(OpenJDK).pdf > Slides: > http://cr.openjdk.java.net/~jiangli/Leyden/Selectively%20Pre-initializing%20and%20Preserving%20Java%20Classes%20(OpenJDK).pdf > > Will also attach them to JBS as suggested. > > >>> I >> adopted >>> the annotation approach in the proposal, after comparing it to other >>> alternatives, please see details in the design doc. >> >> In a prototype, using an annotation to identify pre-initializable >> classes is fine. In the long run, however, we?ll likely wind up with a >> keyword since annotations must not be used to change language semantics. >> > > That sounds workable. The underlying heap object archiving mechanism can > support different approaches (list, interface, annotation, keyword, etc) as > an 'indicator' for pre-initializing & preserving classes and static fields. > > Really excited about the project! > > Best regards, > Jiangli > > >> - Mark From jianglizhou at google.com Mon Jun 8 23:59:51 2020 From: jianglizhou at google.com (Jiangli Zhou) Date: Mon, 8 Jun 2020 16:59:51 -0700 Subject: Call for Discussion: New Project: Leyden In-Reply-To: <8E178FCC-D98E-4BB3-9564-D835F947459B@oracle.com> References: <20200521154809.788017090@eggemoggin.niobe.net> <8E178FCC-D98E-4BB3-9564-D835F947459B@oracle.com> Message-ID: Hi Esteban, Thank you for the feedback! Very happy to see the involvement from you and others from GraalVM (based on Mark's CFV email)! Freeing developers from having to do any manual configuration (or having to write any scripts to semi-automate the configuration) in order to use the image during deployment would be very important. The adoption of a static image solution will likely be higher when that barrier is gone. Developers may be more willing to do source level change in the following case: - anticipated benefit is clear - easy to use/no manual configuration Would it be possible to do an incremental and divide & conquer approach? JDK library, app library, and application developers/experts may add the 'marker' in their own domain, and the savings would be higher with more Java code adopting this new feature. Another possible approach is using the 'marker' solution together with static analysis (brought up by another member during an internal discussion). It may be possible to provide two different usage modes, power mode and marker-only mode. If static analysis can sufficiently tell us which are the good candidates for pre-initialization at build time, we can pre-initialize more classes without relying on the 'marker'. That would be a 'power' mode. Static analysis does cost CPU cycles at build time and may require more memory. In many cases, developers may opt-in for the 'marker-only' mode to avoid higher CPU/memory cost at build time, when sufficient Java sources are marked for class pre-initialization... Looking forward to seeing more inputs/advice. Best, Jiangli On Mon, Jun 8, 2020 at 10:00 AM Esteban Ginez wrote: > > Hi Jiangli > > I took some time to review some of the docs you sent about class initialization, and I would like to highlight one key thing we have been observing in the Graalvm team. > > The usage of annotations to mark classes as ?pre-initializable? is insufficient. > The java community relies on well known, time tested, java libraries. It is often the case that the application owner relies on dependencies he does not even know (or care to know) about . Restricting the capacity to pre-initialize an application via annotations, at minimum, will leave behind code that can not be annotated due to lack of ownership. Further, as we have been experiencing in the GraalVM team, it has been challenge for lower level libraries, to a-priory decide the set of code that can be pre-initialized, without taking into consideration the particular usage of the library. > > That being said, it is great to see other teams in the community working on similar problems, so thanks a lot of sharing your work > Warmly > E. > > On May 21, 2020, at 5:23 PM, Jiangli Zhou wrote: > > On Thu, May 21, 2020 at 3:48 PM wrote: > > 2020/5/18 15:43:34 -0700, jianglizhou at google.com: > > Didn't see this discussion until today. I think this will be welcomed by > Java developers! How do we participate in the project and coordinate? > > > I?ll shortly start the CFV to create the Project. Once the Project > exists, your participation will be most welcome! > > > Sounds great! > > > > I have been experimenting with preserving pre-initialized classes (at > > build > > time) as part of the CDS archive image. Class pre-initialization can help > field and method pre-resolution and generate better AOT code. Here is a > > class > > pre-resolution & pre-initialization proposal > < > > https://docs.google.com/document/d/17RV8W6iqJj9HhjGSO9k1IXfs_9lvHDNgxxr8pFoeDys/edit?usp=sharing > > > that enhances > the existing Hotspot heap archiving and provides more general support to > pre-initialize classes and preserve static field values for both JDK > classes and application classes (loaded by system class loader). > > > Sorry, but for IP clarity could you please either post that document to > cr.openjdk.java.net or enter it into a JBS issue? (Likewise for the > slides that you mention later on.) > > > I've posted the docs to cr.openjdk.java.net: > > Design doc: > http://cr.openjdk.java.net/~jiangli/Leyden/Java%20Class%20Pre-resolution%20and%20Pre-initialization%20(OpenJDK).pdf > Slides: > http://cr.openjdk.java.net/~jiangli/Leyden/Selectively%20Pre-initializing%20and%20Preserving%20Java%20Classes%20(OpenJDK).pdf > > Will also attach them to JBS as suggested. > > > I > > adopted > > the annotation approach in the proposal, after comparing it to other > alternatives, please see details in the design doc. > > > In a prototype, using an annotation to identify pre-initializable > classes is fine. In the long run, however, we?ll likely wind up with a > keyword since annotations must not be used to change language semantics. > > > That sounds workable. The underlying heap object archiving mechanism can > support different approaches (list, interface, annotation, keyword, etc) as > an 'indicator' for pre-initializing & preserving classes and static fields. > > Really excited about the project! > > Best regards, > Jiangli > > > - Mark > > From behrangsa at gmail.com Wed Jun 10 14:27:27 2020 From: behrangsa at gmail.com (Behrang Saeedzadeh) Date: Thu, 11 Jun 2020 00:27:27 +1000 Subject: Add an option to javac to disable inlining of static final variables (to be used by programmers during development phase) Message-ID: Hi, I guess inlining of static variables [1] is one of the main causes that during our day to day coding activities, we have to do a full recompile (e.g. `mvn clean ...`) every time a constant that is referenced throughout the code is changed. There are a few ugly tricks to prevent the constants from getting inlined, but a compiler option that we can pass to javac that produces a warning message that can be used while we program locally could reduce the need to run `mvn clean ...`, `gradle clean ...`, etc. Another option could be [2] adding some metadata to classes that reference constants to record where the constant is coming from that could allow build tools recompile all such classes when the constant changes. [1] https://docs.oracle.com/javase/specs/jls/se14/html/jls-13.html#jls-13.4.9. [2] If the class file format permits that. -- Best regards, Behrang Saeedzadeh From forax at univ-mlv.fr Wed Jun 10 15:04:10 2020 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 10 Jun 2020 17:04:10 +0200 (CEST) Subject: Add an option to javac to disable inlining of static final variables (to be used by programmers during development phase) In-Reply-To: References: Message-ID: <1818852709.2015969.1591801450448.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Behrang Saeedzadeh" > ?: "compiler-dev" , "discuss" > Envoy?: Mercredi 10 Juin 2020 16:27:27 > Objet: Add an option to javac to disable inlining of static final variables (to be used by programmers during > development phase) > Hi, Hi, > > I guess inlining of static variables [1] is one of the main causes that > during our day to day coding activities, we have to do a full recompile > (e.g. `mvn clean ...`) every time a constant that is referenced throughout > the code is changed. > > There are a few ugly tricks to prevent the constants from getting inlined, > but a compiler option that we can pass to javac that produces a warning > message that can be used while we program locally could reduce the need to > run `mvn clean ...`, `gradle clean ...`, etc. > > Another option could be [2] adding some metadata to classes that reference > constants to record where the constant is coming from that could allow > build tools recompile all such classes when the constant changes. > [1] > https://docs.oracle.com/javase/specs/jls/se14/html/jls-13.html#jls-13.4.9. > [2] If the class file format permits that. It's already done by javac, it register all the classes of the static final fields it depends in the constant pool (the dictionary pat of the classfile format). Gradle (the recent versions) uses this information but not Maven, so the question is more how to improve Maven to compute the graph of dependencies at the file level. There is also a kind of quick hack if you have a multi-modules project, you can read the module-info.java to get the graph of modules to find the dependency at module level, you can then use javac to read the module-info.java and the JDK API to create the module and let the JDK resolve the graph for you. The build of the OpenJDK does that with great success. > > > -- > Best regards, > Behrang Saeedzadeh regards, R?mi From john.bergin at gmail.com Wed Jun 10 20:03:36 2020 From: john.bergin at gmail.com (john bergin) Date: Wed, 10 Jun 2020 21:03:36 +0100 Subject: MetaSpace and StackMapTable Message-ID: Hi all. I'm generating a bunch of classes at run-time with ASM (which automatically generates StackMapTable attributes) and when all the classes are loaded the *MethodAll *(bytecodes, StackMapTable, ...) column from *jmap -clstats *tells me that all classes account for about 100MB. When I generate the same classes with ASM but tell it *not* to compute the StackMapTable attributes and I switch class verification off (-noverify) *MethodAll* reduces to 55MB. I'm interested to know: - does the JVM free memory held in MetaSpace by StackMapTable attributes after class verification and a full GC? My testing shows it doesn't. - is it possible to generate one StackMapTable entry for each method that would satisfy the verifier? I had a quick look at the code and it doesn't seem possible *ClassVerifier::verify_stackmap_table * http://hg.openjdk.java.net/jdk8/jdk8/hotspot/file/87ee5ee27509/src/share/vm/classfile/verifier.cpp Thanks, John. From behrangsa at gmail.com Thu Jun 11 07:07:10 2020 From: behrangsa at gmail.com (Behrang Saeedzadeh) Date: Thu, 11 Jun 2020 17:07:10 +1000 Subject: Add an option to javac to disable inlining of static final variables (to be used by programmers during development phase) In-Reply-To: <1818852709.2015969.1591801450448.JavaMail.zimbra@u-pem.fr> References: <1818852709.2015969.1591801450448.JavaMail.zimbra@u-pem.fr> Message-ID: I see. Thanks for the information. Best regards, Behrang Saeedzadeh (Sent from my cellphone.) On Thu, Jun 11, 2020, 1:04 AM Remi Forax wrote: > ----- Mail original ----- > > De: "Behrang Saeedzadeh" > > ?: "compiler-dev" , "discuss" < > discuss at openjdk.java.net> > > Envoy?: Mercredi 10 Juin 2020 16:27:27 > > Objet: Add an option to javac to disable inlining of static final > variables (to be used by programmers during > > development phase) > > > Hi, > > Hi, > > > > > I guess inlining of static variables [1] is one of the main causes that > > during our day to day coding activities, we have to do a full recompile > > (e.g. `mvn clean ...`) every time a constant that is referenced > throughout > > the code is changed. > > > > There are a few ugly tricks to prevent the constants from getting > inlined, > > but a compiler option that we can pass to javac that produces a warning > > message that can be used while we program locally could reduce the need > to > > run `mvn clean ...`, `gradle clean ...`, etc. > > > > Another option could be [2] adding some metadata to classes that > reference > > constants to record where the constant is coming from that could allow > > build tools recompile all such classes when the constant changes. > > [1] > > > https://docs.oracle.com/javase/specs/jls/se14/html/jls-13.html#jls-13.4.9. > > [2] If the class file format permits that. > > It's already done by javac, it register all the classes of the static > final fields it depends in the constant pool (the dictionary pat of the > classfile format). > Gradle (the recent versions) uses this information but not Maven, so the > question is more how to improve Maven to compute the graph of dependencies > at the file level. > > There is also a kind of quick hack if you have a multi-modules project, > you can read the module-info.java to get the graph of modules to find the > dependency at module level, > you can then use javac to read the module-info.java and the JDK API to > create the module and let the JDK resolve the graph for you. > The build of the OpenJDK does that with great success. > > > > > > > -- > > Best regards, > > Behrang Saeedzadeh > > regards, > R?mi > From ioi.lam at oracle.com Mon Jun 22 20:26:42 2020 From: ioi.lam at oracle.com (Ioi Lam) Date: Mon, 22 Jun 2020 13:26:42 -0700 Subject: Call for Discussion: New Project: Leyden In-Reply-To: References: <20200521154809.788017090@eggemoggin.niobe.net> <8E178FCC-D98E-4BB3-9564-D835F947459B@oracle.com> Message-ID: I think at this point, it's too early for the "what to do, how to do it" type of discussions. Let's focus on the fundamental issues first and consider the possible programming models. One fundamental issue with the current CDS archived heap implementation, which Jiangli's proposal is based on, is its inability to handle changes in program execution order: https://bugs.openjdk.java.net/browse/JDK-8248046 The fundamental problem is that when running with CDS, we start with a empty VM with no loaded classes. Classes are incrementally loaded and initialized only when they are referenced. When each class is initialized, we will try to load its static fields from the CDS archived heap. However, the values of the static fields can vary depending on program execution order: ?? class A {static int x = 0:} ?? class B {static int y = A.x; } ?? class Test { ?? ? ? public static void main(String args) { ????? ? ?? System.out.println("A.x = " + A.x); ?????????? if (args.length > 0) { ????????? ? ?? A.x ++; ?????????? } ?????????? System.out.println("B.y = " + B.y); ?????? } ?? } ?? # Output (without CDS heap archiving) ?? $ java -cp . Test ?? A.x = 0; ?? B.y = 0; ?? $ java -cp . Test foo ?? A.x = 0; ?? B.y = 1; The problem is that we can only save the results of ONE particular execution order. So if we save B.y into the CDS archive, no matter what value is stored, at least one of the two above program invocations will produce an unexpected result. ===== I think Graal/NativeImage provides a better/simpler model -- a selected set of class initializers are executed during the "image build" stage. At the end of this stage, the entire VM's state is saved into a snapshot. At program "run time", the VM resumes at the snapshot. All classes that are already initialized during "image build" cannot be initialized again, so there's no way for the program to force a different execution order that would disagree with the values stored the snapshot. Conceptually, the program's entry point is rewritten as: ?????? public static void main(String args) { ?????????? init(A.class); // @synthetic ?????????? init(B.class); // @synthetic ?????????? .... original bytecodes ?????? } Now, running the app in graal with produce these results: ?? $ java -cp . Test ?? A.x = 0; ?? B.y = 0; ?? $ java -cp . Test foo ?? A.x = 0; ?? B.y = 0; It will still be "unexpected" by programs that don't know anything about graal (or snapshots in general). However, I think at least we have a programming model that's more understandable than what we have in CDS today. Also, today CDS performs a lot of checks to ensure "things are happening exactly the same way as during archive dump time". If we switch to the snapshot model, these checks can be eliminated and start-up will be more efficient. ====== I think we have several options: [1] Introduce a snapshot model into the Java Language Spec and clearly define the behavior -- or, in general, some sort of "early binding" that combines multiple classes into a single unit, and restrict what can happen with this single unit. I.e., "a jlink that actually links classes ....". [2] Introduce a new construct for order-independent initialization. For [2], maybe we can *finally* have a *const* keyword :-) ?? class A {static const int x = 0:} ?? class B {static const int y = A.x; } This way we can safely store B.y == 1 without worrying that its value may change. E.g., ?? class A {static int x = 0:} ?? class B {static const int y = A.x; } ?? Error: const B.y depends on non-const value A.x ?? --- ?? class A {static const int x = 0:} ?? class B {static const int y = A.x ++; } ?? Error: const A.x cannot be modified I'd say [1] is easier for up-take, but more messy. It can also be more error-prone when bolted on top of existing code. [2] is cleaner, but probably will have slow uptake and narrower use cases. Thanks - Ioi On 6/8/20 4:59 PM, Jiangli Zhou wrote: > Hi Esteban, > > Thank you for the feedback! Very happy to see the involvement from you > and others from GraalVM (based on Mark's CFV email)! > > Freeing developers from having to do any manual configuration (or > having to write any scripts to semi-automate the configuration) in > order to use the image during deployment would be very important. The > adoption of a static image solution will likely be higher when that > barrier is gone. Developers may be more willing to do source level > change in the following case: > > - anticipated benefit is clear > - easy to use/no manual configuration > > Would it be possible to do an incremental and divide & conquer > approach? JDK library, app library, and application developers/experts > may add the 'marker' in their own domain, and the savings would be > higher with more Java code adopting this new feature. > > Another possible approach is using the 'marker' solution together with > static analysis (brought up by another member during an internal > discussion). It may be possible to provide two different usage modes, > power mode and marker-only mode. If static analysis can sufficiently > tell us which are the good candidates for pre-initialization at build > time, we can pre-initialize more classes without relying on the > 'marker'. That would be a 'power' mode. Static analysis does cost CPU > cycles at build time and may require more memory. In many cases, > developers may opt-in for the 'marker-only' mode to avoid higher > CPU/memory cost at build time, when sufficient Java sources are marked > for class pre-initialization... > > Looking forward to seeing more inputs/advice. > > Best, > > Jiangli > > > On Mon, Jun 8, 2020 at 10:00 AM Esteban Ginez wrote: >> Hi Jiangli >> >> I took some time to review some of the docs you sent about class initialization, and I would like to highlight one key thing we have been observing in the Graalvm team. >> >> The usage of annotations to mark classes as ?pre-initializable? is insufficient. >> The java community relies on well known, time tested, java libraries. It is often the case that the application owner relies on dependencies he does not even know (or care to know) about . Restricting the capacity to pre-initialize an application via annotations, at minimum, will leave behind code that can not be annotated due to lack of ownership. Further, as we have been experiencing in the GraalVM team, it has been challenge for lower level libraries, to a-priory decide the set of code that can be pre-initialized, without taking into consideration the particular usage of the library. >> >> That being said, it is great to see other teams in the community working on similar problems, so thanks a lot of sharing your work >> Warmly >> E. >> >> On May 21, 2020, at 5:23 PM, Jiangli Zhou wrote: >> >> On Thu, May 21, 2020 at 3:48 PM wrote: >> >> 2020/5/18 15:43:34 -0700, jianglizhou at google.com: >> >> Didn't see this discussion until today. I think this will be welcomed by >> Java developers! How do we participate in the project and coordinate? >> >> >> I?ll shortly start the CFV to create the Project. Once the Project >> exists, your participation will be most welcome! >> >> >> Sounds great! >> >> >> >> I have been experimenting with preserving pre-initialized classes (at >> >> build >> >> time) as part of the CDS archive image. Class pre-initialization can help >> field and method pre-resolution and generate better AOT code. Here is a >> >> class >> >> pre-resolution & pre-initialization proposal >> < >> >> https://docs.google.com/document/d/17RV8W6iqJj9HhjGSO9k1IXfs_9lvHDNgxxr8pFoeDys/edit?usp=sharing >> >> >> that enhances >> the existing Hotspot heap archiving and provides more general support to >> pre-initialize classes and preserve static field values for both JDK >> classes and application classes (loaded by system class loader). >> >> >> Sorry, but for IP clarity could you please either post that document to >> cr.openjdk.java.net or enter it into a JBS issue? (Likewise for the >> slides that you mention later on.) >> >> >> I've posted the docs to cr.openjdk.java.net: >> >> Design doc: >> http://cr.openjdk.java.net/~jiangli/Leyden/Java%20Class%20Pre-resolution%20and%20Pre-initialization%20(OpenJDK).pdf >> Slides: >> http://cr.openjdk.java.net/~jiangli/Leyden/Selectively%20Pre-initializing%20and%20Preserving%20Java%20Classes%20(OpenJDK).pdf >> >> Will also attach them to JBS as suggested. >> >> >> I >> >> adopted >> >> the annotation approach in the proposal, after comparing it to other >> alternatives, please see details in the design doc. >> >> >> In a prototype, using an annotation to identify pre-initializable >> classes is fine. In the long run, however, we?ll likely wind up with a >> keyword since annotations must not be used to change language semantics. >> >> >> That sounds workable. The underlying heap object archiving mechanism can >> support different approaches (list, interface, annotation, keyword, etc) as >> an 'indicator' for pre-initializing & preserving classes and static fields. >> >> Really excited about the project! >> >> Best regards, >> Jiangli >> >> >> - Mark >> >> From neugens at redhat.com Tue Jun 23 15:02:46 2020 From: neugens at redhat.com (Mario Torre) Date: Tue, 23 Jun 2020 17:02:46 +0200 Subject: Call for Discussion: New Project: Hamburg Message-ID: Hello OpenJDK developers. [I apologise, this is a long email, but I thought sharing more details would be useful for the discussion.] I would like to start a discussion for a new Project, Project Hamburg [1], whose primary goal is to address the issue of exposing and organising JFR recordings within a container setup, where direct access to the target JVM is not possible. The recent discussion about the tentative backport of the Streaming API for JFR to 11u and 8u has highlighted the desire to have a standardised way to easily obtain the JFR recordings not only for (quasi) real time monitoring but also as a mean of accessing event metrics from OpenJDKs within remote installations, like those in servers deployments and specifically from within containers - for example Kubernetes/OpenShift-managed cloud. In the last few months, some of us have been working on a project that aims to make it easier to use JFR and JDK Mission Control in those contexts, and I would like to start a discussion about potentially promoting our code as an official OpenJDK Project, where it may be useful for a larger community of developers. At the current state, Project Hamburg lives in a github repository under the name ?Container-JFR?, and has several components designed to work together at various [optional] levels of integration, the proposed Project will maintain overall the same layout. [Container JFR - https://github.com/rh-jmc-team/container-jfr] A containerized web service that communicates with JVMs in the same Kubernetes namespace. This communication involves invoking JFR operations over remote JMX, which is made available by the VMs' corresponding Kubernetes Services, and does not need to be exposed to the external world. Instead, clients can interact with Container JFR via a WebSocket command-based interface. These commands include operations like starting and stopping recordings with given options, listing in-memory recordings, listing event types, and saving a recording to persistent storage, etc... This web service also serves raw JFR files for download and analysis with JMC, and generates HTML reports identical to JMC's automated analysis. [Container JFR Core - https://github.com/rh-jmc-team/container-jfr-core] This project is a dependency of Container JFR. It contains interfaces and utilities for calling JMC code to establish remote JMX connections and communicate with JFR. The JMC dependencies are abstracted so we can replace this module without requiring access to the JMC API (although since JMC is also an OpenJDK Project we think this is not a problem). [Container JFR Web - https://github.com/rh-jmc-team/container-jfr-web] A front-end to graphically communicate with Container JFR via web browser. It allows the user to connect to a JVM from a drop down list of available JVMs. Once connected, Container JFR Web displays a table of available event types and their options. Users can then use a wizard to create a recording, and see a list of recordings present in that JVM. For each recording, the user can see the automated analysis results provided by JMC code, save the recording to persistent in-cluster storage, download the recording to local disk, or view compatible metrics in a Grafana dashboard. This mimics some of the functionality of JMC to provide an overview of the target JVM and offers the option to download the JFR file further analysis in JMC. [JFR Datasource - https://github.com/rh-jmc-team/jfr-datasource] This project parses a provided JFR file and serves it as a Grafana SimpleJson datasource in order to populate a Grafana dashboard with metrics from the JFR file. [Container JFR Operator - https://github.com/rh-jmc-team/container-jfr-operator] A Kubernetes operator that deploys and manages all of the above projects with a Kubernetes/OpenShift cluster. At this stage, this project is built using Operator SDK. In addition to the standard deployment of all Project Hamburg components along with Grafana, the operator also supports a "minimal" option. This deploys only Container JFR, and no web front-end or Grafana components. The operator also provides a Kubernetes API for JFR using Custom Resource Definitions. This API consists of FlightRecorder objects created by the operator for each compatible Kubernetes Service in its namespace. These objects contain information like JFR event types for the target JVM. A consumer of the API can create Recording objects for a FlightRecorder object and view the status of them via kubectl/oc. The operator reconciles these objects with Container JFR to retrieve information and manage JFR recordings. Furthermore, we plan to incorporate over time API to deploy and control the JMC Agent [2], to allow existing applications to be instrumented without the need to specifically write Events in the application code. Not all the components need to be used together, for example one can easily change the Web part for direct integration into their own framework management consoles or skip the Operator completely, but my hope is that this Project will help in two key aspects: provide a stable and standardised API to access Flight Recordings without exposing the underlying JMX connections and offer a cross platform functionality similar to that of the JFR Streaming that works cross platform also for older releases. The Project will live as a separate entity from OpenJDK, and we don't expect changes to the OpenJDK code base to be necessary, although the experience gathered may of course lead to fixes, additional APIs and JFR Events to support a container aware OpenJDK over time; if this happens to be the case, such changes will be discussed as usual on the proper development mailing list and, when necessary, be addressed via JEPs. I propose to lead this Project with me and Elliott Baron as the initial reviewers. Any comments and feedback is welcomed! Cheers, Mario [1] The project is formerly known as container-jfr, and is of course meant to bridge the worlds of containers with the world of JFR. Hamburg is a bridge city, it?s probably the city with the highest number of bridges in the World - or certainly in Europe. It?s also one of the homes for the largest container ship in the World, the HMM Algeciras, so I thought this name would be perfectly fitting! [2] https://wiki.openjdk.java.net/display/jmc/The+JMC+Agent -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From martijnverburg at gmail.com Wed Jun 24 10:30:01 2020 From: martijnverburg at gmail.com (Martijn Verburg) Date: Wed, 24 Jun 2020 11:30:01 +0100 Subject: Call for Discussion: New Project: Hamburg In-Reply-To: References: Message-ID: Hi Mario, Thanks for posting this. Our group (Microsoft Java Engineering) is going to take a look at all the links and info and revert our thoughts back here. It's the end of the quarter for us, so it might be sometime next week in case you're wondering why the silence :-) Cheers, Martijn On Tue, 23 Jun 2020 at 16:09, Mario Torre wrote: > Hello OpenJDK developers. > > [I apologise, this is a long email, but I thought sharing more details > would be useful for the discussion.] > > I would like to start a discussion for a new Project, Project Hamburg > [1], whose primary goal is to address the issue of exposing and > organising JFR recordings within a container setup, where direct > access to the target JVM is not possible. > > The recent discussion about the tentative backport of the Streaming > API for JFR to 11u and 8u has highlighted the desire to have a > standardised way to easily obtain the JFR recordings not only for > (quasi) real time monitoring but also as a mean of accessing event > metrics from OpenJDKs within remote installations, like those in > servers deployments and specifically from within containers - for > example Kubernetes/OpenShift-managed cloud. > > In the last few months, some of us have been working on a project that > aims to make it easier to use JFR and JDK Mission Control in those > contexts, and I would like to start a discussion about potentially > promoting our code as an official OpenJDK Project, where it may be > useful for a larger community of developers. > > At the current state, Project Hamburg lives in a github repository > under the name ?Container-JFR?, and has several components designed to > work together at various [optional] levels of integration, the > proposed Project will maintain overall the same layout. > > [Container JFR - https://github.com/rh-jmc-team/container-jfr] > > A containerized web service that communicates with JVMs in the same > Kubernetes namespace. This communication involves invoking JFR > operations over remote JMX, which is made available by the VMs' > corresponding Kubernetes Services, and does not need to be exposed to > the external world. Instead, clients can interact with Container JFR > via a WebSocket command-based interface. These commands include > operations like starting and stopping recordings with given options, > listing in-memory recordings, listing event types, and saving a > recording to persistent storage, etc... > > This web service also serves raw JFR files for download and analysis > with JMC, and generates HTML reports identical to JMC's automated > analysis. > > [Container JFR Core - https://github.com/rh-jmc-team/container-jfr-core] > > This project is a dependency of Container JFR. It contains interfaces > and utilities for calling JMC code to establish remote JMX connections > and communicate with JFR. The JMC dependencies are abstracted so we > can replace this module without requiring access to the JMC API > (although since JMC is also an OpenJDK Project we think this is not a > problem). > > [Container JFR Web - https://github.com/rh-jmc-team/container-jfr-web] > > A front-end to graphically communicate with Container JFR via web > browser. It allows the user to connect to a JVM from a drop down list > of available JVMs. Once connected, Container JFR Web displays a table > of available event types and their options. Users can then use a > wizard to create a recording, and see a list of recordings present in > that JVM. For each recording, the user can see the automated analysis > results provided by JMC code, save the recording to persistent > in-cluster storage, download the recording to local disk, or view > compatible metrics in a Grafana dashboard. This mimics some of the > functionality of JMC to provide an overview of the target JVM and > offers the option to download the JFR file further analysis in JMC. > > [JFR Datasource - https://github.com/rh-jmc-team/jfr-datasource] > > This project parses a provided JFR file and serves it as a Grafana > SimpleJson datasource in order to populate a Grafana dashboard with > metrics from the JFR file. > > [Container JFR Operator - > https://github.com/rh-jmc-team/container-jfr-operator] > > A Kubernetes operator that deploys and manages all of the above > projects with a Kubernetes/OpenShift cluster. At this stage, this > project is built using Operator SDK. > > In addition to the standard deployment of all Project Hamburg > components along with Grafana, the operator also supports a "minimal" > option. This deploys only Container JFR, and no web front-end or > Grafana components. > > The operator also provides a Kubernetes API for JFR using Custom > Resource Definitions. This API consists of FlightRecorder objects > created by the operator for each compatible Kubernetes Service in its > namespace. These objects contain information like JFR event types for > the target JVM. A consumer of the API can create Recording objects for > a FlightRecorder object and view the status of them via kubectl/oc. > > The operator reconciles these objects with Container JFR to retrieve > information and manage JFR recordings. > > Furthermore, we plan to incorporate over time API to deploy and > control the JMC Agent [2], to allow existing applications to be > instrumented without the need to specifically write Events in the > application code. > > Not all the components need to be used together, for example one can > easily change the Web part for direct integration into their own > framework management consoles or skip the Operator completely, but my > hope is that this Project will help in two key aspects: provide a > stable and standardised API to access Flight Recordings without > exposing the underlying JMX connections and offer a cross platform > functionality similar to that of the JFR Streaming that works cross > platform also for older releases. > > The Project will live as a separate entity from OpenJDK, and we don't > expect changes to the OpenJDK code base to be necessary, although the > experience gathered may of course lead to fixes, additional APIs and > JFR Events to support a container aware OpenJDK over time; if this > happens to be the case, such changes will be discussed as usual on the > proper development mailing list and, when necessary, be addressed via > JEPs. > > I propose to lead this Project with me and Elliott Baron as the > initial reviewers. > > Any comments and feedback is welcomed! > > Cheers, > Mario > > [1] The project is formerly known as container-jfr, and is of course > meant to bridge the worlds of containers with the world of JFR. > Hamburg is a bridge city, it?s probably the city with the highest > number of bridges in the World - or certainly in Europe. It?s also one > of the homes for the largest container ship in the World, the HMM > Algeciras, so I thought this name would be perfectly fitting! > > [2] https://wiki.openjdk.java.net/display/jmc/The+JMC+Agent > > -- > Mario Torre > Associate Manager, Software Engineering > Red Hat GmbH > 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 > > From neugens at redhat.com Wed Jun 24 11:31:35 2020 From: neugens at redhat.com (Mario Torre) Date: Wed, 24 Jun 2020 13:31:35 +0200 Subject: Call for Discussion: New Project: Hamburg In-Reply-To: References: Message-ID: Thanks Martijn! We will also need to find a sponsoring home for this project, so any idea is welcomed ;) Cheers, Mario On Wed, Jun 24, 2020 at 12:30 PM Martijn Verburg wrote: > > Hi Mario, > > Thanks for posting this. Our group (Microsoft Java Engineering) is going to take a look at all the links and info and revert our thoughts back here. It's the end of the quarter for us, so it might be sometime next week in case you're wondering why the silence :-) > > Cheers, > Martijn > > > On Tue, 23 Jun 2020 at 16:09, Mario Torre wrote: >> >> Hello OpenJDK developers. >> >> [I apologise, this is a long email, but I thought sharing more details >> would be useful for the discussion.] >> >> I would like to start a discussion for a new Project, Project Hamburg >> [1], whose primary goal is to address the issue of exposing and >> organising JFR recordings within a container setup, where direct >> access to the target JVM is not possible. >> >> The recent discussion about the tentative backport of the Streaming >> API for JFR to 11u and 8u has highlighted the desire to have a >> standardised way to easily obtain the JFR recordings not only for >> (quasi) real time monitoring but also as a mean of accessing event >> metrics from OpenJDKs within remote installations, like those in >> servers deployments and specifically from within containers - for >> example Kubernetes/OpenShift-managed cloud. >> >> In the last few months, some of us have been working on a project that >> aims to make it easier to use JFR and JDK Mission Control in those >> contexts, and I would like to start a discussion about potentially >> promoting our code as an official OpenJDK Project, where it may be >> useful for a larger community of developers. >> >> At the current state, Project Hamburg lives in a github repository >> under the name ?Container-JFR?, and has several components designed to >> work together at various [optional] levels of integration, the >> proposed Project will maintain overall the same layout. >> >> [Container JFR - https://github.com/rh-jmc-team/container-jfr] >> >> A containerized web service that communicates with JVMs in the same >> Kubernetes namespace. This communication involves invoking JFR >> operations over remote JMX, which is made available by the VMs' >> corresponding Kubernetes Services, and does not need to be exposed to >> the external world. Instead, clients can interact with Container JFR >> via a WebSocket command-based interface. These commands include >> operations like starting and stopping recordings with given options, >> listing in-memory recordings, listing event types, and saving a >> recording to persistent storage, etc... >> >> This web service also serves raw JFR files for download and analysis >> with JMC, and generates HTML reports identical to JMC's automated >> analysis. >> >> [Container JFR Core - https://github.com/rh-jmc-team/container-jfr-core] >> >> This project is a dependency of Container JFR. It contains interfaces >> and utilities for calling JMC code to establish remote JMX connections >> and communicate with JFR. The JMC dependencies are abstracted so we >> can replace this module without requiring access to the JMC API >> (although since JMC is also an OpenJDK Project we think this is not a >> problem). >> >> [Container JFR Web - https://github.com/rh-jmc-team/container-jfr-web] >> >> A front-end to graphically communicate with Container JFR via web >> browser. It allows the user to connect to a JVM from a drop down list >> of available JVMs. Once connected, Container JFR Web displays a table >> of available event types and their options. Users can then use a >> wizard to create a recording, and see a list of recordings present in >> that JVM. For each recording, the user can see the automated analysis >> results provided by JMC code, save the recording to persistent >> in-cluster storage, download the recording to local disk, or view >> compatible metrics in a Grafana dashboard. This mimics some of the >> functionality of JMC to provide an overview of the target JVM and >> offers the option to download the JFR file further analysis in JMC. >> >> [JFR Datasource - https://github.com/rh-jmc-team/jfr-datasource] >> >> This project parses a provided JFR file and serves it as a Grafana >> SimpleJson datasource in order to populate a Grafana dashboard with >> metrics from the JFR file. >> >> [Container JFR Operator - https://github.com/rh-jmc-team/container-jfr-operator] >> >> A Kubernetes operator that deploys and manages all of the above >> projects with a Kubernetes/OpenShift cluster. At this stage, this >> project is built using Operator SDK. >> >> In addition to the standard deployment of all Project Hamburg >> components along with Grafana, the operator also supports a "minimal" >> option. This deploys only Container JFR, and no web front-end or >> Grafana components. >> >> The operator also provides a Kubernetes API for JFR using Custom >> Resource Definitions. This API consists of FlightRecorder objects >> created by the operator for each compatible Kubernetes Service in its >> namespace. These objects contain information like JFR event types for >> the target JVM. A consumer of the API can create Recording objects for >> a FlightRecorder object and view the status of them via kubectl/oc. >> >> The operator reconciles these objects with Container JFR to retrieve >> information and manage JFR recordings. >> >> Furthermore, we plan to incorporate over time API to deploy and >> control the JMC Agent [2], to allow existing applications to be >> instrumented without the need to specifically write Events in the >> application code. >> >> Not all the components need to be used together, for example one can >> easily change the Web part for direct integration into their own >> framework management consoles or skip the Operator completely, but my >> hope is that this Project will help in two key aspects: provide a >> stable and standardised API to access Flight Recordings without >> exposing the underlying JMX connections and offer a cross platform >> functionality similar to that of the JFR Streaming that works cross >> platform also for older releases. >> >> The Project will live as a separate entity from OpenJDK, and we don't >> expect changes to the OpenJDK code base to be necessary, although the >> experience gathered may of course lead to fixes, additional APIs and >> JFR Events to support a container aware OpenJDK over time; if this >> happens to be the case, such changes will be discussed as usual on the >> proper development mailing list and, when necessary, be addressed via >> JEPs. >> >> I propose to lead this Project with me and Elliott Baron as the >> initial reviewers. >> >> Any comments and feedback is welcomed! >> >> Cheers, >> Mario >> >> [1] The project is formerly known as container-jfr, and is of course >> meant to bridge the worlds of containers with the world of JFR. >> Hamburg is a bridge city, it?s probably the city with the highest >> number of bridges in the World - or certainly in Europe. It?s also one >> of the homes for the largest container ship in the World, the HMM >> Algeciras, so I thought this name would be perfectly fitting! >> >> [2] https://wiki.openjdk.java.net/display/jmc/The+JMC+Agent >> >> -- >> Mario Torre >> Associate Manager, Software Engineering >> Red Hat GmbH >> 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 >> -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From behrangsa at gmail.com Tue Jun 30 16:38:07 2020 From: behrangsa at gmail.com (Behrang Saeedzadeh) Date: Wed, 1 Jul 2020 02:38:07 +1000 Subject: Any plans/projects to support OpenJDK on upcoming ARM-based Macs? Message-ID: As you know Apple is planning to release its first ARM based Mac (an iMac) by the end of this year. Are there any plans/projects to support OpenJDK on this platform? -- Best regards, Behrang Saeedzadeh From philip.race at oracle.com Tue Jun 30 17:12:23 2020 From: philip.race at oracle.com (Philip Race) Date: Tue, 30 Jun 2020 10:12:23 -0700 Subject: Any plans/projects to support OpenJDK on upcoming ARM-based Macs? In-Reply-To: References: Message-ID: <5EFB7277.2010102@oracle.com> We are very aware of the announcements and have had informal discussions including some contact with Apple, but it is early days to use the word "plan". Note that using the macOS 11 built-in Rosetta 2 translation software, current OpenJDK built for Intel will work out of the box on Apple Silicon Macs and run very well I am told. -phil. On 6/30/20, 9:38 AM, Behrang Saeedzadeh wrote: > As you know Apple is planning to release its first ARM based Mac (an iMac) > by the end of this year. > > Are there any plans/projects to support OpenJDK on this platform? >