From lists at fniephaus.com Mon Nov 11 15:23:48 2019 From: lists at fniephaus.com (Fabio Niephaus) Date: Mon, 11 Nov 2019 16:23:48 +0100 Subject: MoreVMs 2020 : Workshop on Modern Language Runtimes, Ecosystems, and VMs Message-ID: ============================================================================ Call for Extended Abstracts and Talks: MoreVMs?20 4th Workshop on Modern Language Runtimes, Ecosystems, and VMs Co-located with ?Programming??20 March 23rd or 24th, 2020, Porto, Portugal https://2020.programming-conference.org/home/MoreVMs-2020 ============================================================================ Following three previous successful editions, the MoreVMs?20 workshop aims to bring together industrial and academic programmers to discuss the design, implementation, and usage of modern languages and runtimes. This includes aspects such as reuse of language runtimes, modular implementation, language design, and compilation strategies. By bringing together both researchers and practitioners, the workshop aims to enable a diverse discussion on how languages and runtimes are currently being utilized, and where they need to improve further. In addition to conventional workshop-style submissions, MoreVMs also accepts (and encourages) submissions that present early-stage work and emerging ideas. Relevant topics include, but are definitely not limited to, the following: - Extensible VM design (compiler- or interpreter-based VMs) - Reusable components (e.g. interpreters, garbage collectors, ...) - Static and dynamic compilation techniques - Techniques for targeting high-level languages such as JavaScript - Interoperability between languages - Tooling support (e.g. debugging, profiling, etc.) - Programming language development environments - Case studies of existing language implementation approaches - Language implementation challenges and trade-offs - Surveys and usage reports to understand usage in the wild - Ideas for more predictable performance - Ideas for how VMs could take advantage of new hardware features - Ideas for how we should build languages in the future Workshop Format and Submissions ------------------------------- We welcome presentation proposals in the form of extended abstracts (2 to 4 pages long) and talk proposals (title and 400 words abstract) discussing new techniques, insights, experiences, works-in-progress, as well as future visions, from either an academic or industrial perspective. The extended abstracts and talk proposals, and if the speakers wish, their slides, will be published on the workshop's website. Alternatively, extended abstracts can be published as part of the companion of ?Programming??20 in the ACM DL. Publication in the ACM DL is conditional on the acceptance by the program committee. Please note that MoreVMs?20 is organized as an academic workshop, and as such, speakers will be required to register for the workshop. We regret that we are unable to cover registration, travel, or accommodation costs for authors. Author Instructions ------------------- Submissions should use the ACM `acmart` format: https://www.acm.org/publications/proceedings-template If you are using LaTeX, submissions should use the 'acmart' document class with the 'sigconf' option, and with a font size of 9 point. Please use the Libertine/Biolinum font family. Please include page numbers in your submission using the LaTeX command `\settopmatter{printfolios=true}`. All submissions should be in PDF format. Please also ensure that your submission is legible when printed on a black and white printer. In particular, please check that colors remain distinct and font sizes are legible. Submission Site: https://easychair.org/conferences/?conf=morevms20 Important Dates --------------- Extended abstract and talk submissions: 2020-01-10 Author notification: 2020-02-10 Camera Ready: 2020-02-21 Workshop: 2020-03-23 or 2020-03-24 All deadlines are Anywhere on Earth (AoE), i.e. GMT/UTC-12:00 hour. Invited Speakers ----------------- Roman Kennke, Shenandoah GC Project Lead, Red Hat Leszek Swirski, Software Engineer, V8 Team, Google Program Committee ----------------- Nicolas B. Pierron, Mozilla, France Cl?ment B?ra, Google, Denmark Elisa Gonzalez Boix, Vrije Universiteit Brussel, Belgium Stephen Kell, University of Kent, United Kingdom Christoph Kirsch, University of Salzburg, Austria Hidehiko Masuhara, Tokyo Institute of Technology, Japan Gabriela Alexandra Moldovan, Cloudflare, United Kingdom David Pearce, Victoria University of Wellington, New Zealand Manuel Rigger, ETH Zurich, Switzerland Jennifer B. Sartor, Ghent University and Vrije Universiteit Brussel, Belgium Tomoharu Ugawa, Kochi University of Technology, Japan Michael Van De Vanter, Cal Poly, San Luis Obispo, United States Andy Wingo, Igalia, S.L., United States Organizers ---------- Edd Barrett, King's College London, United Kingdom Fabio Niephaus, Hasso Plattner Institute, University of Potsdam, Germany From dean.long at oracle.com Thu Nov 14 17:23:25 2019 From: dean.long at oracle.com (dean.long at oracle.com) Date: Thu, 14 Nov 2019 09:23:25 -0800 Subject: RFR(M) 8233841: Update Graal Message-ID: https://bugs.openjdk.java.net/browse/JDK-8233841 http://cr.openjdk.java.net/~dlong/8233841/webrev/ This is a Graal update.? Changes since the last update (JDK-8231973) are listed in the bug description. dl From vladimir.kozlov at oracle.com Thu Nov 14 17:57:17 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 14 Nov 2019 09:57:17 -0800 Subject: RFR(M) 8233841: Update Graal In-Reply-To: References: Message-ID: <5f3d6026-2bd8-0385-06e1-506c2aad4c7e@oracle.com> Looks good. Tests results good too. Thanks, Vladimir On 11/14/19 9:23 AM, dean.long at oracle.com wrote: > https://bugs.openjdk.java.net/browse/JDK-8233841 > http://cr.openjdk.java.net/~dlong/8233841/webrev/ > > This is a Graal update.? Changes since the last update (JDK-8231973) are listed in the bug description. > > dl From dean.long at oracle.com Thu Nov 14 20:06:54 2019 From: dean.long at oracle.com (dean.long at oracle.com) Date: Thu, 14 Nov 2019 12:06:54 -0800 Subject: RFR(M) 8233841: Update Graal In-Reply-To: <5f3d6026-2bd8-0385-06e1-506c2aad4c7e@oracle.com> References: <5f3d6026-2bd8-0385-06e1-506c2aad4c7e@oracle.com> Message-ID: <86c3c5e6-191e-e92e-df28-52baab350937@oracle.com> Thanks Vladimir. dl On 11/14/19 9:57 AM, Vladimir Kozlov wrote: > Looks good. Tests results good too. > > Thanks, > Vladimir > > On 11/14/19 9:23 AM, dean.long at oracle.com wrote: >> https://bugs.openjdk.java.net/browse/JDK-8233841 >> http://cr.openjdk.java.net/~dlong/8233841/webrev/ >> >> This is a Graal update.? Changes since the last update (JDK-8231973) >> are listed in the bug description. >> >> dl From neugens at redhat.com Fri Nov 15 14:52:56 2019 From: neugens at redhat.com (Mario Torre) Date: Fri, 15 Nov 2019 15:52:56 +0100 Subject: Java DevRoom CFP Message-ID: Hi Everyone! I wanted to point the following CFP for FOSDEM 2020 and see if anyone in the Graal community would be interested in having a short 20/25 minutes talk: https://lists.fosdem.org/pipermail/java-devroom/2019-October/000288.html The talk should focus on the open source version of Graal obviously, but other than that any topic you wish to discuss will be definitely interesting. Cheers, Mario -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From tongbao.ztb at alibaba-inc.com Fri Nov 22 13:24:37 2019 From: tongbao.ztb at alibaba-inc.com (=?UTF-8?B?5byg5ZCM5a6dKOS6leahkCk=?=) Date: Fri, 22 Nov 2019 21:24:37 +0800 Subject: =?UTF-8?B?TXVsdGktc3Vydml2b3Igc3VwcG9ydCBmb3IgU1ZNIEdD?= Message-ID: Dear Graal developers, Substrate VM is a great framework to generate executable native images for Java applications. Thank you for making it open-source. We (Alibaba) are trying to use Substrate VM and native-image to speed up the startup of our cloud-based Java applications. Meantime, we also found problems when running our applications using SVM. The full GC occurred more frequently than the HotSpot VM because there are no object age and survivor spaces in the current SVM GC implementation. We made some improvements to the SVM GC to address these problems, which can significantly decrease the full GC frequency. We would like to contribute a patch to the community, including the multi-survivor support of SVM builtin GC to reduce the frequency of full GC. We have tested this patch thoroughly in our production environment and are glad to contribute it to the Graal community. Look forward to your response. Thanks, Tongbao Zhang From doug.simon at oracle.com Fri Nov 22 13:42:05 2019 From: doug.simon at oracle.com (Doug Simon) Date: Fri, 22 Nov 2019 14:42:05 +0100 Subject: Multi-survivor support for SVM GC In-Reply-To: References: Message-ID: Hi Tongbao, Such a contribution sounds very interesting. Please submit a PR to https://github.com/oracle/graal so we can discuss further. -Doug > On 22 Nov 2019, at 14:24, ???(??) wrote: > > Dear Graal developers, > > Substrate VM is a great framework to generate executable native images for Java applications. Thank you for making it open-source. > We (Alibaba) are trying to use Substrate VM and native-image to speed up the startup of our cloud-based Java applications. > > Meantime, we also found problems when running our applications using SVM. > The full GC occurred more frequently than the HotSpot VM because there are no object age and survivor spaces in the current SVM GC implementation. > > We made some improvements to the SVM GC to address these problems, which can significantly decrease the full GC frequency. > We would like to contribute a patch to the community, including the multi-survivor support of SVM builtin GC to reduce the frequency of full GC. > We have tested this patch thoroughly in our production environment and are glad to contribute it to the Graal community. > > Look forward to your response. > > Thanks, > Tongbao Zhang From adinn at redhat.com Fri Nov 22 13:47:56 2019 From: adinn at redhat.com (Andrew Dinn) Date: Fri, 22 Nov 2019 13:47:56 +0000 Subject: Multi-survivor support for SVM GC In-Reply-To: References: Message-ID: <9ad7c629-26ed-425d-8f60-7564971b3052@redhat.com> Hi Tongbao, On 22/11/2019 13:24, ???(??) wrote: > Substrate VM is a great framework to generate executable native > images for Java applications. Thank you for making it open-source. We > (Alibaba) are trying to use Substrate VM and native-image to speed up > the startup of our cloud-based Java applications. > > Meantime, we also found problems when running our applications using > SVM. The full GC occurred more frequently than the HotSpot VM because > there are no object age and survivor spaces in the current SVM GC > implementation. > > We made some improvements to the SVM GC to address these problems, > which can significantly decrease the full GC frequency. We would like > to contribute a patch to the community, including the multi-survivor > support of SVM builtin GC to reduce the frequency of full GC. We have > tested this patch thoroughly in our production environment and are > glad to contribute it to the Graal community. > > Look forward to your response. This sounds very interesting and exciting. Thank you for offering to contribute your efforts to the Graal community. I would be very interested to see your patch. I know I can also speak on behalf of my Red Hat colleagues who have also been considering opportunities to improve the garbage collector. I hope the Oracle developers will be interested in considering it for inclusion in the community code base. 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 dean.long at oracle.com Sat Nov 23 01:55:36 2019 From: dean.long at oracle.com (Dean Long) Date: Fri, 22 Nov 2019 17:55:36 -0800 Subject: RFR(S) 8234432: AOT tests failing with 'used 'epsilon gc' is different from current 'g1 gc'' after CMS removal Message-ID: https://bugs.openjdk.java.net/browse/JDK-8234432 http://cr.openjdk.java.net/~dlong/8234432/webrev/ The change fixes AOT after CMS was removed.? Previously we relied to a Graal enum matching a JDK enum, but now we map from one to the other. dl From vladimir.kozlov at oracle.com Sat Nov 23 02:37:21 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 22 Nov 2019 18:37:21 -0800 Subject: RFR(S) 8234432: AOT tests failing with 'used 'epsilon gc' is different from current 'g1 gc'' after CMS removal In-Reply-To: References: Message-ID: <5a054eb4-3685-5887-7ea8-6bfb52a56c21@oracle.com> Hmm. I assumed that Graal should have GCs list which is subset of GCs in Hotspot. But it could be not true since GraalVM have to run with JDK 8. May be we should bailout AOT compilation if GC is unknown in Hotspot instead of recording in library enum 'def' from Graal which does not match enum in HotSpot. And check for GC early before we start collecting classes to compile. Thanks, Vladimir On 11/22/19 5:55 PM, Dean Long wrote: > https://bugs.openjdk.java.net/browse/JDK-8234432 > http://cr.openjdk.java.net/~dlong/8234432/webrev/ > > The change fixes AOT after CMS was removed.? Previously we relied to a Graal enum matching a JDK enum, but now we map > from one to the other. > > dl From dean.long at oracle.com Sat Nov 23 02:47:58 2019 From: dean.long at oracle.com (Dean Long) Date: Fri, 22 Nov 2019 18:47:58 -0800 Subject: RFR(S) 8234432: AOT tests failing with 'used 'epsilon gc' is different from current 'g1 gc'' after CMS removal In-Reply-To: <5a054eb4-3685-5887-7ea8-6bfb52a56c21@oracle.com> References: <5a054eb4-3685-5887-7ea8-6bfb52a56c21@oracle.com> Message-ID: <6ec6734c-261b-dc65-095e-ade7dffe4e71@oracle.com> On 11/22/19 6:37 PM, Vladimir Kozlov wrote: > Hmm. I assumed that Graal should have GCs list which is subset of GCs > in Hotspot. But it could be not true since GraalVM have to run with > JDK 8. > > May be we should bailout AOT compilation if GC is unknown in Hotspot > instead of recording in library enum 'def' from Graal which does not > match enum in HotSpot. And check for GC early before we start > collecting classes to compile. > Graal uses the HotSpot flags to determine which GC is being used, so there is no way for AOT to store a GC that the underlying HotSpot doesn't know about.? The default fall-back of ordinal() + 1 is only for pre-JDK14 which doesn't have the CollectedHeap GC constants exported to JVMCI.? We could get rid of that if we backport the vmStructs_jvmci.cpp change to all the JDK versions that Graal supports. There is a separate issue, if you try to use a GC that JVMCI/Graal doesn't support: ?% jaotc -J-XX:+UseZGC java.lang.String JVMCI Compiler does not support selected GC: z gc dl > Thanks, > Vladimir > > On 11/22/19 5:55 PM, Dean Long wrote: >> https://bugs.openjdk.java.net/browse/JDK-8234432 >> http://cr.openjdk.java.net/~dlong/8234432/webrev/ >> >> The change fixes AOT after CMS was removed.? Previously we relied to >> a Graal enum matching a JDK enum, but now we map from one to the other. >> >> dl From vladimir.kozlov at oracle.com Sat Nov 23 02:54:05 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 22 Nov 2019 18:54:05 -0800 Subject: RFR(S) 8234432: AOT tests failing with 'used 'epsilon gc' is different from current 'g1 gc'' after CMS removal In-Reply-To: <6ec6734c-261b-dc65-095e-ade7dffe4e71@oracle.com> References: <5a054eb4-3685-5887-7ea8-6bfb52a56c21@oracle.com> <6ec6734c-261b-dc65-095e-ade7dffe4e71@oracle.com> Message-ID: Got it. My thinking was in reverse ;) Changes are good. Vladimir On 11/22/19 6:47 PM, Dean Long wrote: > On 11/22/19 6:37 PM, Vladimir Kozlov wrote: >> Hmm. I assumed that Graal should have GCs list which is subset of GCs in Hotspot. But it could be not true since >> GraalVM have to run with JDK 8. >> >> May be we should bailout AOT compilation if GC is unknown in Hotspot instead of recording in library enum 'def' from >> Graal which does not match enum in HotSpot. And check for GC early before we start collecting classes to compile. >> > > Graal uses the HotSpot flags to determine which GC is being used, so there is no way for AOT to store a GC that the > underlying HotSpot doesn't know about.? The default fall-back of ordinal() + 1 is only for pre-JDK14 which doesn't have > the CollectedHeap GC constants exported to JVMCI.? We could get rid of that if we backport the vmStructs_jvmci.cpp > change to all the JDK versions that Graal supports. > > There is a separate issue, if you try to use a GC that JVMCI/Graal doesn't support: > > ?% jaotc -J-XX:+UseZGC java.lang.String > > JVMCI Compiler does not support selected GC: z gc > > dl >> Thanks, >> Vladimir >> >> On 11/22/19 5:55 PM, Dean Long wrote: >>> https://bugs.openjdk.java.net/browse/JDK-8234432 >>> http://cr.openjdk.java.net/~dlong/8234432/webrev/ >>> >>> The change fixes AOT after CMS was removed.? Previously we relied to a Graal enum matching a JDK enum, but now we map >>> from one to the other. >>> >>> dl > From dean.long at oracle.com Sat Nov 23 03:22:24 2019 From: dean.long at oracle.com (Dean Long) Date: Fri, 22 Nov 2019 19:22:24 -0800 Subject: RFR(S) 8234432: AOT tests failing with 'used 'epsilon gc' is different from current 'g1 gc'' after CMS removal In-Reply-To: References: <5a054eb4-3685-5887-7ea8-6bfb52a56c21@oracle.com> <6ec6734c-261b-dc65-095e-ade7dffe4e71@oracle.com> Message-ID: <9e790dd3-aba1-ecad-5d72-583613094f2e@oracle.com> Thanks Vladimir! dl On 11/22/19 6:54 PM, Vladimir Kozlov wrote: > Got it. My thinking was in reverse ;) > > Changes are good. > > Vladimir > > On 11/22/19 6:47 PM, Dean Long wrote: >> On 11/22/19 6:37 PM, Vladimir Kozlov wrote: >>> Hmm. I assumed that Graal should have GCs list which is subset of >>> GCs in Hotspot. But it could be not true since GraalVM have to run >>> with JDK 8. >>> >>> May be we should bailout AOT compilation if GC is unknown in Hotspot >>> instead of recording in library enum 'def' from Graal which does not >>> match enum in HotSpot. And check for GC early before we start >>> collecting classes to compile. >>> >> >> Graal uses the HotSpot flags to determine which GC is being used, so >> there is no way for AOT to store a GC that the underlying HotSpot >> doesn't know about.? The default fall-back of ordinal() + 1 is only >> for pre-JDK14 which doesn't have the CollectedHeap GC constants >> exported to JVMCI.? We could get rid of that if we backport the >> vmStructs_jvmci.cpp change to all the JDK versions that Graal supports. >> >> There is a separate issue, if you try to use a GC that JVMCI/Graal >> doesn't support: >> >> ??% jaotc -J-XX:+UseZGC java.lang.String >> >> JVMCI Compiler does not support selected GC: z gc >> >> dl >>> Thanks, >>> Vladimir >>> >>> On 11/22/19 5:55 PM, Dean Long wrote: >>>> https://bugs.openjdk.java.net/browse/JDK-8234432 >>>> http://cr.openjdk.java.net/~dlong/8234432/webrev/ >>>> >>>> The change fixes AOT after CMS was removed.? Previously we relied >>>> to a Graal enum matching a JDK enum, but now we map from one to the >>>> other. >>>> >>>> dl >> From tongbao.ztb at alibaba-inc.com Mon Nov 25 02:23:11 2019 From: tongbao.ztb at alibaba-inc.com (=?UTF-8?B?5byg5ZCM5a6dKOS6leahkCk=?=) Date: Mon, 25 Nov 2019 10:23:11 +0800 Subject: =?UTF-8?B?UmU6IE11bHRpLXN1cnZpdm9yIHN1cHBvcnQgZm9yIFNWTSBHQw==?= In-Reply-To: References: , Message-ID: <32a68a4b-4b4f-48bd-b04a-e1bcca8b4274.tongbao.ztb@alibaba-inc.com> Thanks for your reply, I will submit a PR soon. Thanks, Tongbao ------------------------------------------------------------------ From:Doug Simon Sent At:2019 Nov. 22 (Fri.) 21:42 To:ZHANG Tongbao Cc:graal-dev Subject:Re: Multi-survivor support for SVM GC Hi Tongbao, Such a contribution sounds very interesting. Please submit a PR to https://github.com/oracle/graal so we can discuss further. -Doug > On 22 Nov 2019, at 14:24, ???(??) wrote: > > Dear Graal developers, > > Substrate VM is a great framework to generate executable native images for Java applications. Thank you for making it open-source. > We (Alibaba) are trying to use Substrate VM and native-image to speed up the startup of our cloud-based Java applications. > > Meantime, we also found problems when running our applications using SVM. > The full GC occurred more frequently than the HotSpot VM because there are no object age and survivor spaces in the current SVM GC implementation. > > We made some improvements to the SVM GC to address these problems, which can significantly decrease the full GC frequency. > We would like to contribute a patch to the community, including the multi-survivor support of SVM builtin GC to reduce the frequency of full GC. > We have tested this patch thoroughly in our production environment and are glad to contribute it to the Graal community. > > Look forward to your response. > > Thanks, > Tongbao Zhang