From Derek.White at cavium.com Fri Jun 22 16:05:19 2018 From: Derek.White at cavium.com (White, Derek) Date: Fri, 22 Jun 2018 16:05:19 +0000 Subject: Workshop proposal: Porting in the era of The Fast and The Furious Message-ID: ABSTRACT: The rush of exciting new JVM features combined with the new release tempo makes life for porters a surprising game of Keeping Up with the Joneses. Just when you finish the in-ground pool you look over the fence and see - wait, is that a Helipad? The top-level question for participants is "How can feature developers coordinate better with porters to ensure that new features are available to the widest set of platforms?". More detailed questions listed at end. LENGTH: Long? BIO: Derek White has been working on JVM implementations off-and-on since 1996. You'd think he'd be finished by now. Activities include: Ported the Java-in-Java Squawk JVM to embedded Arm SoC with 32KB Java heap, Optimizing Hotspot for Cavium Arm SoC with 256 hardware threads. http://javathunderx.blogspot.com/ PRESENTATION: I could provide a few slides to show the scope of the issue, but it's not strictly necessary. Some sub-questions could include: * Should JEPs that only include an implementation for one platform have an indication that porting is required? File bugs for missing implementations? * Should JEPs with no porting issues be tagged as such? "Deprecate the Pack200 Tools and API" sounds innocuous to us porters, but we have to look at the implementation to verify this. * Why is Zero always broken? Should JEPs with incomplete implementations always provide a Zero implementation also? I've no idea if this is either difficult or useful. * Are JEPs ever targeted to a release within weeks of that release's feature freeze? Could this ever be a problem? Discuss. * How should we handle porting for features in incubator modules? When is too soon or too late to bring in porting considerations? * Similarly, OpenJDK projects like Valhalla, Panama, and Metropolis are a great source of new features, but tracking porting issues is difficult. Following all of the email lists is not practical, waiting for a JEP may be too late? * Are the solutions process, convention, or something more ad-hoc? Thanks, * Derek White From johan.vos at gluonhq.com Sat Jun 23 15:44:19 2018 From: johan.vos at gluonhq.com (Johan Vos) Date: Sat, 23 Jun 2018 17:44:19 +0200 Subject: Workshop proposal: Porting in the era of The Fast and The Furious In-Reply-To: References: Message-ID: Sounds like an excellent topic. I have similar issues with OpenJFX on mobile/embedded. We're working hard now for getting the important functionality ready for RDP1, and only after that is done I will really start looking at porting OpenJFX 11 to iOS/Android/embedded. As a consequence, the mobile/embedded ports typically are 1 release behind the desktop ports. - Johan On Fri, Jun 22, 2018 at 6:05 PM White, Derek wrote: > ABSTRACT: > The rush of exciting new JVM features combined with the new release tempo > makes life for porters a surprising game of Keeping Up with the Joneses. > Just when you finish the in-ground pool you look over the fence and see - > wait, is that a Helipad? > > The top-level question for participants is "How can feature developers > coordinate better with porters to ensure that new features are available to > the widest set of platforms?". More detailed questions listed at end. > > LENGTH: Long? > > BIO: Derek White has been working on JVM implementations off-and-on since > 1996. You'd think he'd be finished by now. Activities include: Ported the > Java-in-Java Squawk JVM to embedded Arm SoC with 32KB Java heap, Optimizing > Hotspot for Cavium Arm SoC with 256 hardware threads. > http://javathunderx.blogspot.com/ > > PRESENTATION: I could provide a few slides to show the scope of the issue, > but it's not strictly necessary. > > Some sub-questions could include: > > * Should JEPs that only include an implementation for one platform > have an indication that porting is required? File bugs for missing > implementations? > * Should JEPs with no porting issues be tagged as such? "Deprecate the > Pack200 Tools and API" sounds innocuous to us porters, but we have to look > at the implementation to verify this. > * Why is Zero always broken? Should JEPs with incomplete > implementations always provide a Zero implementation also? I've no idea if > this is either difficult or useful. > * Are JEPs ever targeted to a release within weeks of that release's > feature freeze? Could this ever be a problem? Discuss. > * How should we handle porting for features in incubator modules? When > is too soon or too late to bring in porting considerations? > * Similarly, OpenJDK projects like Valhalla, Panama, and Metropolis > are a great source of new features, but tracking porting issues is > difficult. Following all of the email lists is not practical, waiting for a > JEP may be too late? > * Are the solutions process, convention, or something more ad-hoc? > > > Thanks, > > * Derek White >