From rkennke at redhat.com Tue Mar 9 14:39:43 2021 From: rkennke at redhat.com (Roman Kennke) Date: Tue, 9 Mar 2021 15:39:43 +0100 Subject: Call for Discussion: New Project: Lilliput Message-ID: <0d396daa-4819-d915-b0e8-f2250370fb4f@redhat.com> We would like to propose a new project called Lilliput, with the goal of exploring ways to shrink the object header. Goal: 1. Reduce the object header to 64 bits. It may be possible to shrink it down to 32 bits as a secondary goal. 2. Make the header layout more flexible, i.e. allow some build-time (possibly even run-time) configuration of how we use the bits. Motivation: In 64-bit Hotspot, Java objects have an object header of 128 bits: a 64 bit multi-purpose header (?mark? or ?lock?) word and a 64-bit class pointer. With typical average object sizes of 5-6 words, this is quite significant: 2 of those words are always taken by the header. If it were possible to reduce the size of the header, we could significantly reduce memory pressure, which directly translates to one or more of (depending what you care about or what your workload does): - Reduced heap usage - Higher object allocation rate - Reduced GC activity - Tighter packing of objects -> better cache locality In other words, we could reduce the overall CPU and/or memory usage of all Java workloads, whether it?s a large in-memory database or a small containerized application. The object header is used (and overloaded) for the following purposes: - Locking: the lower 3 bits are used to indicate the locking state of an object and the higher bits *may* be used to encode a pointer to a stack-allocated monitor or inflated lock object - GC: 4 bits are used for tracking the age of each object (in generational collectors). The whole header *may* be used to store forwarding information, depending on the collector - Identity hash-code: Up to 32 bits are used to store the identity hash-code - Type information: 64 bits are used to point to the Klass that describes the object type We have a wide variety of techniques to explore for allocating and down-sizing header fields: - Pointers can be compressed, e.g. if we expect a maximum of, say, 8192 classes, we could, with some careful alignment of Klass objects, compress the class pointer down to 13 bits: 2^13=8192 addressable Klasses. Similar considerations apply to stack pointers and monitors. - Instead of using pointers, we could use class IDs that index a lookup table - We could backfill fields which are known at compile-time (e.g. alignment gap or hidden fields) - We could use backfill fields appended to an object after the GC moved it (e.g. for hashcode) - We could use side-tables We also have a bewildering number of constraints. To name a few: - Performance - If we limit e.g. number of classes/monitors/etc that we can encode, we need a way to deal with overflow - Requires changes in assembly across all supported platforms (also consider 32 bits) - Interaction with other projects like Panama, Loom, maybe Leyden, etc And a couple of opportunities for further work (possibly outside of this project): - If we leave arraylength in its own 64-bit field, perhaps we should consider 64-bit addressable arrays? - Improvements to hashcode. Maybe salt it to avoid repetition of nursery objects, maybe expand it to 64 or even 128 bit. I would propose myself as the project lead for Lilliput. :-) For initial committers I think we need all expertise in runtime and GC that we can get. From the top of my head I?m thinking of John Rose, Dave Dice, Andrew Dinn, Andrew Haley, Erik ?sterlund, Aleksey Shipilev, Coleen Phillimore, Stefan Karlsson, Per Liden. Please suggest anybody who you think should be involved in this too. (Or yourself if you want to be in, or if you have no interest in it.) My initial work plan is to: - Brainstorm, collect ideas and propose techniques in the Wiki - Come up with a proof of concept as quickly as possible - Use ZGC: no header usage - Use existing class-pointer compression - Shrink hashcode - Work from there, decide-as-we-go with insights from previous steps Please let me know what you think! Thanks, Roman From forax at univ-mlv.fr Tue Mar 9 15:26:33 2021 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 9 Mar 2021 16:26:33 +0100 (CET) Subject: Call for Discussion: New Project: Lilliput In-Reply-To: <0d396daa-4819-d915-b0e8-f2250370fb4f@redhat.com> References: <0d396daa-4819-d915-b0e8-f2250370fb4f@redhat.com> Message-ID: <1673834237.1227952.1615303593692.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Roman Kennke" > ?: "discuss" > Envoy?: Mardi 9 Mars 2021 15:39:43 > Objet: Call for Discussion: New Project: Lilliput > We would like to propose a new project called Lilliput, with the goal of > exploring ways to shrink the object header. > > Goal: > 1. Reduce the object header to 64 bits. It may be possible to shrink it > down to 32 bits as a secondary goal. > 2. Make the header layout more flexible, i.e. allow some build-time > (possibly even run-time) configuration of how we use the bits. > > Motivation: > In 64-bit Hotspot, Java objects have an object header of 128 bits: a 64 > bit multi-purpose header (?mark? or ?lock?) word and a 64-bit class > pointer. With typical average object sizes of 5-6 words, this is quite > significant: 2 of those words are always taken by the header. If it were > possible to reduce the size of the header, we could significantly reduce > memory pressure, which directly translates to one or more of (depending > what you care about or what your workload does): > > - Reduced heap usage > - Higher object allocation rate > - Reduced GC activity > - Tighter packing of objects -> better cache locality > > In other words, we could reduce the overall CPU and/or memory usage of > all Java workloads, whether it?s a large in-memory database or a small > containerized application. > > > The object header is used (and overloaded) for the following purposes: > > - Locking: the lower 3 bits are used to indicate the locking state of an > object and the higher bits *may* be used to encode a pointer to a > stack-allocated monitor or inflated lock object > - GC: 4 bits are used for tracking the age of each object (in > generational collectors). The whole header *may* be used to store > forwarding information, depending on the collector > - Identity hash-code: Up to 32 bits are used to store the identity hash-code > - Type information: 64 bits are used to point to the Klass that > describes the object type > > > We have a wide variety of techniques to explore for allocating and > down-sizing header fields: > > - Pointers can be compressed, e.g. if we expect a maximum of, say, 8192 > classes, we could, with some careful alignment of Klass objects, > compress the class pointer down to 13 bits: 2^13=8192 addressable > Klasses. Similar considerations apply to stack pointers and monitors. > - Instead of using pointers, we could use class IDs that index a lookup > table > - We could backfill fields which are known at compile-time (e.g. > alignment gap or hidden fields) > - We could use backfill fields appended to an object after the GC moved > it (e.g. for hashcode) > - We could use side-tables > > > We also have a bewildering number of constraints. To name a few: > - Performance > - If we limit e.g. number of classes/monitors/etc that we can encode, we > need a way to deal with overflow > - Requires changes in assembly across all supported platforms (also > consider 32 bits) > - Interaction with other projects like Panama, Loom, maybe Leyden, etc > > And a couple of opportunities for further work (possibly outside of this > project): > - If we leave arraylength in its own 64-bit field, perhaps we should > consider 64-bit addressable arrays? > - Improvements to hashcode. Maybe salt it to avoid repetition of nursery > objects, maybe expand it to 64 or even 128 bit. > > > I would propose myself as the project lead for Lilliput. :-) > For initial committers I think we need all expertise in runtime and GC > that we can get. From the top of my head I?m thinking of John Rose, Dave > Dice, Andrew Dinn, Andrew Haley, Erik ?sterlund, Aleksey Shipilev, > Coleen Phillimore, Stefan Karlsson, Per Liden. Please suggest anybody > who you think should be involved in this too. (Or yourself if you want > to be in, or if you have no interest in it.) > > > My initial work plan is to: > > - Brainstorm, collect ideas and propose techniques in the Wiki > - Come up with a proof of concept as quickly as possible > - Use ZGC: no header usage > - Use existing class-pointer compression > - Shrink hashcode > - Work from there, decide-as-we-go with insights from previous steps > > > Please let me know what you think! Hi Roman, you can also reduce the size of the header for certain kind of classes, by example for a record, you know that the field are truly final so you can avoid to compute the hashCode and use the fields to calculate the identity hashCode the same way Valhalla does for the primitive classes. for a primitive class, when they are on the heap, again, you can avoid the identity hashCode (and also the lock bits, but that's less interresting). backfilling the hashCode by forcing an instance to be moved by the GC to use a fat class header (a header with a hashCode zone) also seems a good idea. An a question, for the class pointer, using compact class pointer is not enough to have them using 32 bits instead of 64 bits. For me, having the hashCode optional and having a 32 bits class pointer seems to be a good way to free 64 bits per header. > > Thanks, > Roman R?mi From rkennke at redhat.com Tue Mar 9 18:10:26 2021 From: rkennke at redhat.com (Roman Kennke) Date: Tue, 9 Mar 2021 19:10:26 +0100 Subject: Call for Discussion: New Project: Lilliput In-Reply-To: <1673834237.1227952.1615303593692.JavaMail.zimbra@u-pem.fr> References: <0d396daa-4819-d915-b0e8-f2250370fb4f@redhat.com> <1673834237.1227952.1615303593692.JavaMail.zimbra@u-pem.fr> Message-ID: Hi Remi, >> Please let me know what you think! > > Hi Roman, > you can also reduce the size of the header for certain kind of classes, by example for a record, you know that the field are truly final so you can avoid to compute the hashCode and use the fields to calculate the identity hashCode the same way Valhalla does for the primitive classes. > for a primitive class, when they are on the heap, again, you can avoid the identity hashCode (and also the lock bits, but that's less interresting). Right. That is a great idea! It is interesting to note that we don't ever need a i-hash for most objects. Some experiments have shown that in most workloads, fewer than 1% of all objects are ever i-hashed. And of those 1% it is questionable how many even survive until the GC moves them for the first time. Which means we can recompute i-hash until that first move happens and avoid storing the i-hash for *many* objects this way. Then, as you said, we can avoid even more by considering a number of well-known types. Etc. As mentioned before, we have a huge array of possibilities. > An a question, for the class pointer, using compact class pointer is not enough to have them using 32 bits instead of 64 bits. > For me, having the hashCode optional and having a 32 bits class pointer seems to be a good way to free 64 bits per header. I am not sure what the question is :-) But yes, that seems like a good starting point! Would you like to be included as initial project committer? Thanks Remi! Roman From john.r.rose at oracle.com Tue Mar 9 18:11:12 2021 From: john.r.rose at oracle.com (John Rose) Date: Tue, 9 Mar 2021 10:11:12 -0800 Subject: Call for Discussion: New Project: Lilliput In-Reply-To: <0d396daa-4819-d915-b0e8-f2250370fb4f@redhat.com> References: <0d396daa-4819-d915-b0e8-f2250370fb4f@redhat.com> Message-ID: <0FA1E37F-C100-49C4-BC90-A748F935CB9F@oracle.com> Many people, including myself, have puzzled for years over the problem of header size. I am glad to see a frontal assault being made on it now! There is a bewilderingly complex shadowy thicket of potential partial solutions, including side tables, optional backfill zones (good term, Remi), data compression, bitfields, tagged pointers, and compute vs. store trade-offs, for klass, GC mark, hash, and lock. Welcome to the thicket! I think you have already gathered a list of potential techniques. It would be very good for you to publish your notes somewhere, to help give more shape to the conversation. I personally use my page on cr.ojn for such notes, and that?s what I recommend now. While it would be better to use a wiki somewhere for collaborative edits, there aren?t any good options under ojn for this (due to inconvenient rules for authoring the wiki). So cr.ojn is a good start, and when the project boots up you can have a notes file (or files) in the repo itself. ? John P.S. I want to give a shout-out to Dave and Alex?s paper https://arxiv.org/pdf/2102.04188.pdf about rethinking the lock word. This work would probably give us lots of ?slack? for crunching down the fixed monitor overhead. On Mar 9, 2021, at 6:39 AM, Roman Kennke wrote: > > We would like to propose a new project called Lilliput, with the goal of exploring ways to shrink the object header. > > Goal: > 1. Reduce the object header to 64 bits. It may be possible to shrink it down to 32 bits as a secondary goal. > 2. Make the header layout more flexible, i.e. allow some build-time (possibly even run-time) configuration of how we use the bits. > > Motivation: > In 64-bit Hotspot, Java objects have an object header of 128 bits: a 64 bit multi-purpose header (?mark? or ?lock?) word and a 64-bit class pointer. With typical average object sizes of 5-6 words, this is quite significant: 2 of those words are always taken by the header. If it were possible to reduce the size of the header, we could significantly reduce memory pressure, which directly translates to one or more of (depending what you care about or what your workload does): > > - Reduced heap usage > - Higher object allocation rate > - Reduced GC activity > - Tighter packing of objects -> better cache locality > > In other words, we could reduce the overall CPU and/or memory usage of all Java workloads, whether it?s a large in-memory database or a small containerized application. > > > The object header is used (and overloaded) for the following purposes: > > - Locking: the lower 3 bits are used to indicate the locking state of an object and the higher bits *may* be used to encode a pointer to a stack-allocated monitor or inflated lock object > - GC: 4 bits are used for tracking the age of each object (in generational collectors). The whole header *may* be used to store forwarding information, depending on the collector > - Identity hash-code: Up to 32 bits are used to store the identity hash-code > - Type information: 64 bits are used to point to the Klass that describes the object type > > > We have a wide variety of techniques to explore for allocating and down-sizing header fields: > > - Pointers can be compressed, e.g. if we expect a maximum of, say, 8192 classes, we could, with some careful alignment of Klass objects, compress the class pointer down to 13 bits: 2^13=8192 addressable Klasses. Similar considerations apply to stack pointers and monitors. > - Instead of using pointers, we could use class IDs that index a lookup table > - We could backfill fields which are known at compile-time (e.g. alignment gap or hidden fields) > - We could use backfill fields appended to an object after the GC moved it (e.g. for hashcode) > - We could use side-tables > > > We also have a bewildering number of constraints. To name a few: > - Performance > - If we limit e.g. number of classes/monitors/etc that we can encode, we need a way to deal with overflow > - Requires changes in assembly across all supported platforms (also consider 32 bits) > - Interaction with other projects like Panama, Loom, maybe Leyden, etc > > And a couple of opportunities for further work (possibly outside of this project): > - If we leave arraylength in its own 64-bit field, perhaps we should consider 64-bit addressable arrays? > - Improvements to hashcode. Maybe salt it to avoid repetition of nursery objects, maybe expand it to 64 or even 128 bit. > > > I would propose myself as the project lead for Lilliput. :-) > For initial committers I think we need all expertise in runtime and GC that we can get. From the top of my head I?m thinking of John Rose, Dave Dice, Andrew Dinn, Andrew Haley, Erik ?sterlund, Aleksey Shipilev, Coleen Phillimore, Stefan Karlsson, Per Liden. Please suggest anybody who you think should be involved in this too. (Or yourself if you want to be in, or if you have no interest in it.) > > > My initial work plan is to: > > - Brainstorm, collect ideas and propose techniques in the Wiki > - Come up with a proof of concept as quickly as possible > - Use ZGC: no header usage > - Use existing class-pointer compression > - Shrink hashcode > - Work from there, decide-as-we-go with insights from previous steps > > > Please let me know what you think! > > Thanks, > Roman > From magnus.ihse.bursie at oracle.com Tue Mar 9 18:55:52 2021 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 9 Mar 2021 19:55:52 +0100 Subject: Call for Discussion: New Project: Lilliput In-Reply-To: <0FA1E37F-C100-49C4-BC90-A748F935CB9F@oracle.com> References: <0d396daa-4819-d915-b0e8-f2250370fb4f@redhat.com> <0FA1E37F-C100-49C4-BC90-A748F935CB9F@oracle.com> Message-ID: On 2021-03-09 19:11, John Rose wrote: > While it would be better to use a wiki somewhere > for collaborative edits, there aren?t any good options > under ojn for this (due to inconvenient rules for > authoring the wiki). Which, while being a side-track, is really annoying. How come we cannot setup infrastructure that helps, instead of hinders, the OpenJDK community from making collaborative efforts? :-( > So cr.ojn is a good start, and > when the project boots up you can have a notes > file (or files) in the repo itself. An alternative is to create an empty branch in jdk-sandbox, add a README.md file, and edit it. This way every OpenJDK Author can contribute, changes are attributed to the right person, and you'll get a change history as well. And you get markdown code and realtime html rendering by Github. /Magnus From john.r.rose at oracle.com Tue Mar 9 19:05:36 2021 From: john.r.rose at oracle.com (John Rose) Date: Tue, 9 Mar 2021 11:05:36 -0800 Subject: wiki for me but not for thee (was CFD Project Lilliput) In-Reply-To: References: <0d396daa-4819-d915-b0e8-f2250370fb4f@redhat.com> <0FA1E37F-C100-49C4-BC90-A748F935CB9F@oracle.com> Message-ID: <3D5D1087-D519-4102-90FE-F0010A526C88@oracle.com> On Mar 9, 2021, at 10:55 AM, Magnus Ihse Bursie wrote: > > On 2021-03-09 19:11, John Rose wrote: >> While it would be better to use a wiki somewhere >> for collaborative edits, there aren?t any good options >> under ojn for this (due to inconvenient rules for >> authoring the wiki). > Which, while being a side-track, is really annoying. How come we cannot setup infrastructure that helps, instead of hinders, the OpenJDK community from making collaborative efforts? :-( The wiki rules are unfortunately specified in the oj rules, which themselves are unfortunately hard to change. (That?s my understanding; to be corrected by advice from those who know better.) So now the current workaround is to work hard to make folks into HotSpot group members, one at a time, using the clumsy and time-consuming voting procedure. One might not know it, but one is probably not a HotSpot group member, and that doesn?t matter at all, except for wiki authoring privileges. Every ?new fish? who joins and wants to add their (extremely useful!!) notes to the wiki for the next ?new fish? gets blocked on this and gives up. I?ve seen it happen many times. (Not to be grumpy about it or anything?) So I use my cr.ojn pages vigorously, because as a committer I automatically have editing rights. It?s a glass more than half full, while the wiki is a glass more than half empty, except for those who happen to have been through the one-off voting-in process. >> So cr.ojn is a good start, and >> when the project boots up you can have a notes >> file (or files) in the repo itself. > > An alternative is to create an empty branch in jdk-sandbox, add a README.md file, and edit it. This way every OpenJDK Author can contribute, changes are attributed to the right person, and you'll get a change history as well. And you get markdown code and realtime html rendering by Github. Yes, nice workaround! But, doesn?t the sandbox get cleaned sometimes? ? John From dalibor.topic at oracle.com Tue Mar 9 19:11:17 2021 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Tue, 9 Mar 2021 20:11:17 +0100 Subject: wiki for me but not for thee (was CFD Project Lilliput) In-Reply-To: <3D5D1087-D519-4102-90FE-F0010A526C88@oracle.com> References: <0d396daa-4819-d915-b0e8-f2250370fb4f@redhat.com> <0FA1E37F-C100-49C4-BC90-A748F935CB9F@oracle.com> <3D5D1087-D519-4102-90FE-F0010A526C88@oracle.com> Message-ID: <983ed526-a956-81ca-1cdd-4a855b167385@oracle.com> On 09.03.2021 20:05, John Rose wrote: > The wiki rules are unfortunately specified in the oj > rules, which themselves are unfortunately hard to > change. (That?s my understanding; to be corrected > by advice from those who know better.) So now > the current workaround is to work hard to make > folks into HotSpot group members, one at a time, > using the clumsy and time-consuming voting > procedure. Fwiw, Projects can have wikis too, which tends to be easier to become Committer in (happens all the time) than to become a Group member (happens rarely). So basically, if you move the relevant part of the notes to a Project's wiki, everyone in that Project can edit it. cheers, dalibor topic -- Dalibor Topic Consulting Product Manager Phone: +494089091214 , Mobile: +491737185961 , Video: dalibor.topic at oracle.com Oracle Global Services Germany GmbH Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRB 246209 Gesch?ftsf?hrer: Ralf Herrmann From john.r.rose at oracle.com Tue Mar 9 19:19:41 2021 From: john.r.rose at oracle.com (John Rose) Date: Tue, 9 Mar 2021 11:19:41 -0800 Subject: wiki for me but not for thee (was CFD Project Lilliput) In-Reply-To: <983ed526-a956-81ca-1cdd-4a855b167385@oracle.com> References: <0d396daa-4819-d915-b0e8-f2250370fb4f@redhat.com> <0FA1E37F-C100-49C4-BC90-A748F935CB9F@oracle.com> <3D5D1087-D519-4102-90FE-F0010A526C88@oracle.com> <983ed526-a956-81ca-1cdd-4a855b167385@oracle.com> Message-ID: <62261399-DCB1-4C2A-811B-928D280E0F99@oracle.com> This >>>> > On Mar 9, 2021, at 11:11 AM, Dalibor Topic wrote: > > Fwiw, Projects can have wikis too, which tends to be easier to become Committer in (happens all the time) than to become a Group member (happens rarely). > > So basically, if you move the relevant part of the notes to a Project's wiki, everyone in that Project can edit it. From rkennke at redhat.com Tue Mar 9 19:32:23 2021 From: rkennke at redhat.com (Roman Kennke) Date: Tue, 9 Mar 2021 20:32:23 +0100 Subject: Call for Discussion: New Project: Lilliput In-Reply-To: <1673834237.1227952.1615303593692.JavaMail.zimbra@u-pem.fr> References: <0d396daa-4819-d915-b0e8-f2250370fb4f@redhat.com> <1673834237.1227952.1615303593692.JavaMail.zimbra@u-pem.fr> Message-ID: <1c8d1daf-8aae-05ce-be82-216bfddbd305@redhat.com> Hi Remi, >> Please let me know what you think! > > Hi Roman, > you can also reduce the size of the header for certain kind of classes, by example for a record, you know that the field are truly final so you can avoid to compute the hashCode and use the fields to calculate the identity hashCode the same way Valhalla does for the primitive classes. > for a primitive class, when they are on the heap, again, you can avoid the identity hashCode (and also the lock bits, but that's less interresting). Right. That is a great idea! It is interesting to note that we don't ever need a i-hash for most objects. Some experiments have shown that in most workloads, fewer than 1% of all objects are ever i-hashed. And of those 1% it is questionable how many even survive until the GC moves them for the first time. Which means we can recompute i-hash until that first move happens and avoid storing the i-hash for *many* objects this way. Then, as you said, we can avoid even more by considering a number of well-known types. Etc. As mentioned before, we have a huge array of possibilities. > An a question, for the class pointer, using compact class pointer is not enough to have them using 32 bits instead of 64 bits. > For me, having the hashCode optional and having a 32 bits class pointer seems to be a good way to free 64 bits per header. I am not sure what the question is :-) But yes, that seems like a good starting point! Would you like to be included as initial project committer? Thanks Remi! Roman From dalibor.topic at oracle.com Tue Mar 9 19:46:31 2021 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Tue, 9 Mar 2021 20:46:31 +0100 Subject: wiki for me but not for thee (was CFD Project Lilliput) In-Reply-To: <62261399-DCB1-4C2A-811B-928D280E0F99@oracle.com> References: <0d396daa-4819-d915-b0e8-f2250370fb4f@redhat.com> <0FA1E37F-C100-49C4-BC90-A748F935CB9F@oracle.com> <3D5D1087-D519-4102-90FE-F0010A526C88@oracle.com> <983ed526-a956-81ca-1cdd-4a855b167385@oracle.com> <62261399-DCB1-4C2A-811B-928D280E0F99@oracle.com> Message-ID: On 09.03.2021 20:19, John Rose wrote: > This >>>> > I'll take that as an opportunity to expand my thoughts a bit: In the JDK 7 & 8 Updates Projects, we've used to basically switch the website over to the wiki at the point of handover to the next set of maintainers to make it more convenient for them to maintain the information relevant for the Projects. With the JDK Updates Project, all the relevant information for individual release trains is now in the wikis already, so it's easy for everyone working on the JDK Updates to keep that information updated, and folks like Christoph, Volker, Yuri, etc. do (thanks!), without having to become members of the Build Group first. That's the benefit of having that information in Project Wiki, rather than a Group wiki, as the effort necessary to become a Committer is lower than the effort necessary to become a Group Member, which typically takes a year or longer of sustained contributions, so more people can edit. You can request a wiki to be created for a Project by asking ops to do it for you as a Project Lead. If you need a space for individual notes, then I'd suggest using cr.openjdk.java.net for that, since it can host almost any useful type of file easily. If you need a space for collaborative notes, then Magnus' suggestion of a branch in the jdk-sandbox repo is a good one, as well. In that case I'd suggest moving it to a Project wiki once you've got something you and your collaborators are happy with, since it's easier to search, find and cross-reference there, than in individual Git branches. HTH, dalibor topic >> On Mar 9, 2021, at 11:11 AM, Dalibor Topic > > wrote: >> >> Fwiw, Projects can have wikis too, which tends to be easier to become >> Committer in (happens all the time) than to become a Group member >> (happens rarely). >> >> So basically, if you move the relevant part of the notes to a >> Project's wiki, everyone in that Project can edit it. > -- Dalibor Topic Consulting Product Manager Phone: +494089091214 , Mobile: +491737185961 , Video: dalibor.topic at oracle.com Oracle Global Services Germany GmbH Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRB 246209 Gesch?ftsf?hrer: Ralf Herrmann From rkennke at redhat.com Tue Mar 9 20:54:10 2021 From: rkennke at redhat.com (Roman Kennke) Date: Tue, 9 Mar 2021 21:54:10 +0100 Subject: Call for Discussion: New Project: Lilliput In-Reply-To: <0FA1E37F-C100-49C4-BC90-A748F935CB9F@oracle.com> References: <0d396daa-4819-d915-b0e8-f2250370fb4f@redhat.com> <0FA1E37F-C100-49C4-BC90-A748F935CB9F@oracle.com> Message-ID: > Many people, including myself, have puzzled for years > over the problem of header size. I am glad to see a frontal > assault being made on it now! There is a bewilderingly > complex shadowy thicket of potential partial solutions, > including side tables, optional backfill zones (good term, > Remi), data compression, bitfields, tagged pointers, and > compute vs. store trade-offs, for klass, GC mark, hash, > and lock. Welcome to the thicket! He, thanks! > I think you have already gathered a list of potential > techniques. It would be very good for you to publish > your notes somewhere, to help give more shape to > the conversation. > > I personally use my page on cr.ojn for such notes, > and that?s what I recommend now. Yes, I will do that next. Good suggestion! > While it would be better to use a wiki somewhere > for collaborative edits, there aren?t any good options > under ojn for this (due to inconvenient rules for > authoring the wiki). So cr.ojn is a good start, and > when the project boots up you can have a notes > file (or files) in the repo itself. Once the project is set-up, I'll either move the notes to the project repository or project wiki. According to Dalibor, project wiki should be fine. We're using it in the Shenandoah project too and works so far. > P.S. I want to give a shout-out to Dave and Alex?s > paper https://arxiv.org/pdf/2102.04188.pdf about > rethinking the lock word. This work would > probably give us lots of ?slack? for crunching > down the fixed monitor overhead. Very nice! Thanks, Roman > On Mar 9, 2021, at 6:39 AM, Roman Kennke wrote: >> >> We would like to propose a new project called Lilliput, with the goal of exploring ways to shrink the object header. >> >> Goal: >> 1. Reduce the object header to 64 bits. It may be possible to shrink it down to 32 bits as a secondary goal. >> 2. Make the header layout more flexible, i.e. allow some build-time (possibly even run-time) configuration of how we use the bits. >> >> Motivation: >> In 64-bit Hotspot, Java objects have an object header of 128 bits: a 64 bit multi-purpose header (?mark? or ?lock?) word and a 64-bit class pointer. With typical average object sizes of 5-6 words, this is quite significant: 2 of those words are always taken by the header. If it were possible to reduce the size of the header, we could significantly reduce memory pressure, which directly translates to one or more of (depending what you care about or what your workload does): >> >> - Reduced heap usage >> - Higher object allocation rate >> - Reduced GC activity >> - Tighter packing of objects -> better cache locality >> >> In other words, we could reduce the overall CPU and/or memory usage of all Java workloads, whether it?s a large in-memory database or a small containerized application. >> >> >> The object header is used (and overloaded) for the following purposes: >> >> - Locking: the lower 3 bits are used to indicate the locking state of an object and the higher bits *may* be used to encode a pointer to a stack-allocated monitor or inflated lock object >> - GC: 4 bits are used for tracking the age of each object (in generational collectors). The whole header *may* be used to store forwarding information, depending on the collector >> - Identity hash-code: Up to 32 bits are used to store the identity hash-code >> - Type information: 64 bits are used to point to the Klass that describes the object type >> >> >> We have a wide variety of techniques to explore for allocating and down-sizing header fields: >> >> - Pointers can be compressed, e.g. if we expect a maximum of, say, 8192 classes, we could, with some careful alignment of Klass objects, compress the class pointer down to 13 bits: 2^13=8192 addressable Klasses. Similar considerations apply to stack pointers and monitors. >> - Instead of using pointers, we could use class IDs that index a lookup table >> - We could backfill fields which are known at compile-time (e.g. alignment gap or hidden fields) >> - We could use backfill fields appended to an object after the GC moved it (e.g. for hashcode) >> - We could use side-tables >> >> >> We also have a bewildering number of constraints. To name a few: >> - Performance >> - If we limit e.g. number of classes/monitors/etc that we can encode, we need a way to deal with overflow >> - Requires changes in assembly across all supported platforms (also consider 32 bits) >> - Interaction with other projects like Panama, Loom, maybe Leyden, etc >> >> And a couple of opportunities for further work (possibly outside of this project): >> - If we leave arraylength in its own 64-bit field, perhaps we should consider 64-bit addressable arrays? >> - Improvements to hashcode. Maybe salt it to avoid repetition of nursery objects, maybe expand it to 64 or even 128 bit. >> >> >> I would propose myself as the project lead for Lilliput. :-) >> For initial committers I think we need all expertise in runtime and GC that we can get. From the top of my head I?m thinking of John Rose, Dave Dice, Andrew Dinn, Andrew Haley, Erik ?sterlund, Aleksey Shipilev, Coleen Phillimore, Stefan Karlsson, Per Liden. Please suggest anybody who you think should be involved in this too. (Or yourself if you want to be in, or if you have no interest in it.) >> >> >> My initial work plan is to: >> >> - Brainstorm, collect ideas and propose techniques in the Wiki >> - Come up with a proof of concept as quickly as possible >> - Use ZGC: no header usage >> - Use existing class-pointer compression >> - Shrink hashcode >> - Work from there, decide-as-we-go with insights from previous steps >> >> >> Please let me know what you think! >> >> Thanks, >> Roman >> > From mark.reinhold at oracle.com Tue Mar 9 21:47:57 2021 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Tue, 09 Mar 2021 13:47:57 -0800 Subject: Call for Discussion: New Project: Lilliput In-Reply-To: <0FA1E37F-C100-49C4-BC90-A748F935CB9F@oracle.com> References: <0d396daa-4819-d915-b0e8-f2250370fb4f@redhat.com> <0FA1E37F-C100-49C4-BC90-A748F935CB9F@oracle.com> Message-ID: <20210309134757.638314030@eggemoggin.niobe.net> 2021/3/9 10:11:12 -0800, john.r.rose at oracle.com: > Many people, including myself, have puzzled for years > over the problem of header size. I am glad to see a frontal > assault being made on it now! There is a bewilderingly > complex shadowy thicket of potential partial solutions, > including side tables, optional backfill zones (good term, > Remi), data compression, bitfields, tagged pointers, and > compute vs. store trade-offs, for klass, GC mark, hash, > and lock. Welcome to the thicket! Indeed! This is a tough, tough problem. I look forward to seeing what you can do! - Mark From magnus.ihse.bursie at oracle.com Wed Mar 10 09:53:57 2021 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 10 Mar 2021 10:53:57 +0100 Subject: wiki for me but not for thee (was CFD Project Lilliput) In-Reply-To: <3D5D1087-D519-4102-90FE-F0010A526C88@oracle.com> References: <0d396daa-4819-d915-b0e8-f2250370fb4f@redhat.com> <0FA1E37F-C100-49C4-BC90-A748F935CB9F@oracle.com> <3D5D1087-D519-4102-90FE-F0010A526C88@oracle.com> Message-ID: On 2021-03-09 20:05, John Rose wrote: > On Mar 9, 2021, at 10:55 AM, Magnus Ihse Bursie wrote: >> On 2021-03-09 19:11, John Rose wrote: >>> While it would be better to use a wiki somewhere >>> for collaborative edits, there aren?t any good options >>> under ojn for this (due to inconvenient rules for >>> authoring the wiki). >> Which, while being a side-track, is really annoying. How come we cannot setup infrastructure that helps, instead of hinders, the OpenJDK community from making collaborative efforts? :-( > The wiki rules are unfortunately specified in the oj > rules, which themselves are unfortunately hard to > change. (That?s my understanding; to be corrected > by advice from those who know better.) By "oj rules", do you mean the Bylaws? And even if the rules are hard to change, we should make the effort to do so. After all, the rules are not important in and of themselves -- they are there as a tool to help us achieve our common goal more easily. >> An alternative is to create an empty branch in jdk-sandbox, add a README.md file, and edit it. This way every OpenJDK Author can contribute, changes are attributed to the right person, and you'll get a change history as well. And you get markdown code and realtime html rendering by Github. > Yes, nice workaround! But, doesn?t the sandbox > get cleaned sometimes? No, definitely not. It was originally created as a mercurial variant of the Github "personal fork" idea, but now it has more or less shifted into a lightweight way of quickly setting up collaborative workspaces without the need for OpenJDK formalia and ceremony. /Magnus > > ? John From rkennke at redhat.com Fri Mar 12 17:23:49 2021 From: rkennke at redhat.com (Roman Kennke) Date: Fri, 12 Mar 2021 18:23:49 +0100 Subject: Call for Discussion: New Project: Lilliput In-Reply-To: <0d396daa-4819-d915-b0e8-f2250370fb4f@redhat.com> References: <0d396daa-4819-d915-b0e8-f2250370fb4f@redhat.com> Message-ID: <69f34ccc-32c3-2656-e573-deae89dc603d@redhat.com> Ah btw, according to the bylaw, we need one Group Lead (in this case, I expect Hotspot group, that is Vladimir Kozlov) declare to be sponsor of this project. Thanks, Roman > We would like to propose a new project called Lilliput, with the goal of > exploring ways to shrink the object header. > > Goal: > 1. Reduce the object header to 64 bits. It may be possible to shrink it > down to 32 bits as a secondary goal. > 2. Make the header layout more flexible, i.e. allow some build-time > (possibly even run-time) configuration of how we use the bits. > > Motivation: > In 64-bit Hotspot, Java objects have an object header of 128 bits: a 64 > bit multi-purpose header (?mark? or ?lock?) word and a 64-bit class > pointer. With typical average object sizes of 5-6 words, this is quite > significant: 2 of those words are always taken by the header. If it were > possible to reduce the size of the header, we could significantly reduce > memory pressure, which directly translates to one or more of (depending > what you care about or what your workload does): > > - Reduced heap usage > - Higher object allocation rate > - Reduced GC activity > - Tighter packing of objects -> better cache locality > > In other words, we could reduce the overall CPU and/or memory usage of > all Java workloads, whether it?s a large in-memory database or a small > containerized application. > > > The object header is used (and overloaded) for the following purposes: > > - Locking: the lower 3 bits are used to indicate the locking state of an > object and the higher bits *may* be used to encode a pointer to a > stack-allocated monitor or inflated lock object > - GC: 4 bits are used for tracking the age of each object (in > generational collectors). The whole header *may* be used to store > forwarding information, depending on the collector > - Identity hash-code: Up to 32 bits are used to store the identity > hash-code > - Type information: 64 bits are used to point to the Klass that > describes the object type > > > We have a wide variety of techniques to explore for allocating and > down-sizing header fields: > > - Pointers can be compressed, e.g. if we expect a maximum of, say, 8192 > classes, we could, with some careful alignment of Klass objects, > compress the class pointer down to 13 bits: 2^13=8192 addressable > Klasses. Similar considerations apply to stack pointers and monitors. > - Instead of using pointers, we could use class IDs that index a lookup > table > - We could backfill fields which are known at compile-time (e.g. > alignment gap or hidden fields) > - We could use backfill fields appended to an object after the GC moved > it (e.g. for hashcode) > - We could use side-tables > > > We also have a bewildering number of constraints. To name a few: > - Performance > - If we limit e.g. number of classes/monitors/etc that we can encode, we > need a way to deal with overflow > - Requires changes in assembly across all supported platforms (also > consider 32 bits) > - Interaction with other projects like Panama, Loom, maybe Leyden, etc > > And a couple of opportunities for further work (possibly outside of this > project): > - If we leave arraylength in its own 64-bit field, perhaps we should > consider 64-bit addressable arrays? > - Improvements to hashcode. Maybe salt it to avoid repetition of nursery > objects, maybe expand it to 64 or even 128 bit. > > > I would propose myself as the project lead for Lilliput. :-) > For initial committers I think we need all expertise in runtime and GC > that we can get. From the top of my head I?m thinking of John Rose, Dave > Dice, Andrew Dinn, Andrew Haley, Erik ?sterlund, Aleksey Shipilev, > Coleen Phillimore, Stefan Karlsson, Per Liden. Please suggest anybody > who you think should be involved in this too. (Or yourself if you want > to be in, or if you have no interest in it.) > > > My initial work plan is to: > > - Brainstorm, collect ideas and propose techniques in the Wiki > - Come up with a proof of concept as quickly as possible > ? - Use ZGC: no header usage > ? - Use existing class-pointer compression > ? - Shrink hashcode > - Work from there, decide-as-we-go with insights from previous steps > > > Please let me know what you think! > > Thanks, > Roman From vladimir.kozlov at oracle.com Fri Mar 12 20:01:10 2021 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 12 Mar 2021 12:01:10 -0800 Subject: Call for Discussion: New Project: Lilliput In-Reply-To: <0d396daa-4819-d915-b0e8-f2250370fb4f@redhat.com> References: <0d396daa-4819-d915-b0e8-f2250370fb4f@redhat.com> Message-ID: <6de09858-794c-1b27-c8ad-8c5d2c5741b8@oracle.com> The HotSpot group will gladly participate in sponsoring this project. Regards, Vladimir Kozlov On 3/9/21 6:39 AM, Roman Kennke wrote: > We would like to propose a new project called Lilliput, with the goal of exploring ways to shrink the object header. > > Goal: > 1. Reduce the object header to 64 bits. It may be possible to shrink it down to 32 bits as a secondary goal. > 2. Make the header layout more flexible, i.e. allow some build-time (possibly even run-time) configuration of how we use > the bits. > > Motivation: > In 64-bit Hotspot, Java objects have an object header of 128 bits: a 64 bit multi-purpose header (?mark? or ?lock?) word > and a 64-bit class pointer. With typical average object sizes of 5-6 words, this is quite significant: 2 of those words > are always taken by the header. If it were possible to reduce the size of the header, we could significantly reduce > memory pressure, which directly translates to one or more of (depending what you care about or what your workload does): > > - Reduced heap usage > - Higher object allocation rate > - Reduced GC activity > - Tighter packing of objects -> better cache locality > > In other words, we could reduce the overall CPU and/or memory usage of all Java workloads, whether it?s a large > in-memory database or a small containerized application. > > > The object header is used (and overloaded) for the following purposes: > > - Locking: the lower 3 bits are used to indicate the locking state of an object and the higher bits *may* be used to > encode a pointer to a stack-allocated monitor or inflated lock object > - GC: 4 bits are used for tracking the age of each object (in generational collectors). The whole header *may* be used > to store forwarding information, depending on the collector > - Identity hash-code: Up to 32 bits are used to store the identity hash-code > - Type information: 64 bits are used to point to the Klass that describes the object type > > > We have a wide variety of techniques to explore for allocating and down-sizing header fields: > > - Pointers can be compressed, e.g. if we expect a maximum of, say, 8192 classes, we could, with some careful alignment > of Klass objects, compress the class pointer down to 13 bits: 2^13=8192 addressable Klasses. Similar considerations > apply to stack pointers and monitors. > - Instead of using pointers, we could use class IDs that index a lookup table > - We could backfill fields which are known at compile-time (e.g. alignment gap or hidden fields) > - We could use backfill fields appended to an object after the GC moved it (e.g. for hashcode) > - We could use side-tables > > > We also have a bewildering number of constraints. To name a few: > - Performance > - If we limit e.g. number of classes/monitors/etc that we can encode, we need a way to deal with overflow > - Requires changes in assembly across all supported platforms (also consider 32 bits) > - Interaction with other projects like Panama, Loom, maybe Leyden, etc > > And a couple of opportunities for further work (possibly outside of this project): > - If we leave arraylength in its own 64-bit field, perhaps we should consider 64-bit addressable arrays? > - Improvements to hashcode. Maybe salt it to avoid repetition of nursery objects, maybe expand it to 64 or even 128 bit. > > > I would propose myself as the project lead for Lilliput. :-) > For initial committers I think we need all expertise in runtime and GC that we can get. From the top of my head I?m > thinking of John Rose, Dave Dice, Andrew Dinn, Andrew Haley, Erik ?sterlund, Aleksey Shipilev, Coleen Phillimore, Stefan > Karlsson, Per Liden. Please suggest anybody who you think should be involved in this too. (Or yourself if you want to be > in, or if you have no interest in it.) > > > My initial work plan is to: > > - Brainstorm, collect ideas and propose techniques in the Wiki > - Come up with a proof of concept as quickly as possible > ? - Use ZGC: no header usage > ? - Use existing class-pointer compression > ? - Shrink hashcode > - Work from there, decide-as-we-go with insights from previous steps > > > Please let me know what you think! > > Thanks, > Roman > From coleen.phillimore at oracle.com Fri Mar 12 22:17:37 2021 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 12 Mar 2021 17:17:37 -0500 Subject: Call for Discussion: New Project: Lilliput In-Reply-To: <0d396daa-4819-d915-b0e8-f2250370fb4f@redhat.com> References: <0d396daa-4819-d915-b0e8-f2250370fb4f@redhat.com> Message-ID: <95ad3003-03aa-0dc7-c509-768d7af501fe@oracle.com> On 3/9/21 9:39 AM, Roman Kennke wrote: > We would like to propose a new project called Lilliput, with the goal > of exploring ways to shrink the object header. > > Goal: > 1. Reduce the object header to 64 bits. It may be possible to shrink > it down to 32 bits as a secondary goal. > 2. Make the header layout more flexible, i.e. allow some build-time > (possibly even run-time) configuration of how we use the bits. > > Motivation: > In 64-bit Hotspot, Java objects have an object header of 128 bits: a > 64 bit multi-purpose header (?mark? or ?lock?) word and a 64-bit class > pointer. With typical average object sizes of 5-6 words, this is quite > significant: 2 of those words are always taken by the header. If it > were possible to reduce the size of the header, we could significantly > reduce memory pressure, which directly translates to one or more of > (depending what you care about or what your workload does): > > - Reduced heap usage > - Higher object allocation rate > - Reduced GC activity > - Tighter packing of objects -> better cache locality > > In other words, we could reduce the overall CPU and/or memory usage of > all Java workloads, whether it?s a large in-memory database or a small > containerized application. > > > The object header is used (and overloaded) for the following purposes: > > - Locking: the lower 3 bits are used to indicate the locking state of > an object and the higher bits *may* be used to encode a pointer to a > stack-allocated monitor or inflated lock object > - GC: 4 bits are used for tracking the age of each object (in > generational collectors). The whole header *may* be used to store > forwarding information, depending on the collector > - Identity hash-code: Up to 32 bits are used to store the identity > hash-code > - Type information: 64 bits are used to point to the Klass that > describes the object type > > > We have a wide variety of techniques to explore for allocating and > down-sizing header fields: > > - Pointers can be compressed, e.g. if we expect a maximum of, say, > 8192 classes, we could, with some careful alignment of Klass objects, > compress the class pointer down to 13 bits: 2^13=8192 addressable > Klasses. Similar considerations apply to stack pointers and monitors. > - Instead of using pointers, we could use class IDs that index a > lookup table > - We could backfill fields which are known at compile-time (e.g. > alignment gap or hidden fields) > - We could use backfill fields appended to an object after the GC > moved it (e.g. for hashcode) > - We could use side-tables > > > We also have a bewildering number of constraints. To name a few: > - Performance > - If we limit e.g. number of classes/monitors/etc that we can encode, > we need a way to deal with overflow > - Requires changes in assembly across all supported platforms (also > consider 32 bits) > - Interaction with other projects like Panama, Loom, maybe Leyden, etc > > And a couple of opportunities for further work (possibly outside of > this project): > - If we leave arraylength in its own 64-bit field, perhaps we should > consider 64-bit addressable arrays? > - Improvements to hashcode. Maybe salt it to avoid repetition of > nursery objects, maybe expand it to 64 or even 128 bit. > > > I would propose myself as the project lead for Lilliput. :-) > For initial committers I think we need all expertise in runtime and GC > that we can get. From the top of my head I?m thinking of John Rose, > Dave Dice, Andrew Dinn, Andrew Haley, Erik ?sterlund, Aleksey > Shipilev, Coleen Phillimore, Stefan Karlsson, Per Liden. Please > suggest anybody who you think should be involved in this too. (Or > yourself if you want to be in, or if you have no interest in it.) Yes, please. I'd like to be a committer.? I had done experiments with a klass pointer indirection, which could effectively be a klass index. The performance numbers for throughput weren't that bad, but we didn't have the bandwidth to investigate further at the time. Also I kept running into solaris _sbrk malloc at the time. In JDK 18, we're going to be removing BiasedLocking so that removes one use of the markWord. Thanks, Coleen > > > My initial work plan is to: > > - Brainstorm, collect ideas and propose techniques in the Wiki > - Come up with a proof of concept as quickly as possible > ? - Use ZGC: no header usage > ? - Use existing class-pointer compression > ? - Shrink hashcode > - Work from there, decide-as-we-go with insights from previous steps > > > Please let me know what you think! > > Thanks, > Roman > From rkennke at redhat.com Fri Mar 12 22:50:10 2021 From: rkennke at redhat.com (Roman Kennke) Date: Fri, 12 Mar 2021 23:50:10 +0100 Subject: Call for Discussion: New Project: Lilliput In-Reply-To: <95ad3003-03aa-0dc7-c509-768d7af501fe@oracle.com> References: <0d396daa-4819-d915-b0e8-f2250370fb4f@redhat.com> <95ad3003-03aa-0dc7-c509-768d7af501fe@oracle.com> Message-ID: <0ec23c74-f0a3-1978-a2f1-9be96cdaf9c3@redhat.com> >> I would propose myself as the project lead for Lilliput. :-) >> For initial committers I think we need all expertise in runtime and GC >> that we can get. From the top of my head I?m thinking of John Rose, >> Dave Dice, Andrew Dinn, Andrew Haley, Erik ?sterlund, Aleksey >> Shipilev, Coleen Phillimore, Stefan Karlsson, Per Liden. Please >> suggest anybody who you think should be involved in this too. (Or >> yourself if you want to be in, or if you have no interest in it.) > > Yes, please. I'd like to be a committer. +1 :-) >? I had done experiments with a > klass pointer indirection, which could effectively be a klass index. I had a little exchange with Thomas Stuefe, and we believe we can split Klass into fixed-sized part, and variable-sized part, have the fixed-size base reference the variable-sized part. Then we can allocate the fixed Klass instances into a 'flat' array in a contiguous memory region, and with some smart placement and aligmment we can use a compressed pointer to address it, which will effectively be an index into that array. Which means that with N bits of compressed-class-pointer we could address 2^N Klasses :-) No indirection needed if done so afaict. But hey, let's get the project off the ground asap, and have technical discussions there, yes? :-) > In JDK 18, we're going to be removing BiasedLocking so that removes one > use of the markWord. Great! Cheers, Roman From gil at azul.com Fri Mar 12 23:15:04 2021 From: gil at azul.com (Gil Tene) Date: Fri, 12 Mar 2021 23:15:04 +0000 Subject: Call for Discussion: New Project: Lilliput In-Reply-To: <0d396daa-4819-d915-b0e8-f2250370fb4f@redhat.com> References: <0d396daa-4819-d915-b0e8-f2250370fb4f@redhat.com> Message-ID: <5A4ED3B8-9E99-44F3-8393-FC04A6E7F683@azul.com> One of the first items on the agenda for a project Lilliput should probably be to decide which end of the object the header belongs on [1]. We may also want to adopt terms from that work and name space in describing the main two technical alternative; big-headerness and little-headerness? [2] ;-) I would be happy to participate and bring some real-world experiences to bear, as the Zing JVM has been using one word, 64 bit headers for quite a few years, and we've built up quite a bit of practical experience with them (and probably learned a lot about what not to do). Specifically, in Zing, currently: - We use a kid (klass id) instead of a klass pointer. [e.g. a 23 bit kid]. - The is a straightforward klass table for looking up klass pointers from kids. - We use pre-headers to hold identity hashes. - Identity hashes are computed until an object's first relocation. - The identity hash computation is based on the object's offset within the region it sits in. - Upon relocation of an object that has an established identity hash, pre-header space is allocated and the previously computed has is stored there. - The states associated (has an identity hash or not, and has a pre-header or not are tracked) in bit in the header. - We use a locking scheme that does not involve header word displacement, and instead deals with lock state in the bottom 32 bits of the 64 bit header (owner tid for thin locks, monitor id for inflated locks, state bits). - One key reason for changing from a displaced header locking scheme was the wish to able to (continue to) extract the kid directly from the header, regardless of lock state. This was a key enabler for single word headers. - Background: In current hotspot, the klass pointer can be directly accessed in the header regardless of lock state, because it sits in a word that is separate from the displaced header word. But collapsing the klass ptr (or kid) and lock state into a single word makes it "hard" to keep the object klass identity at a fixed place when using displaced header locking (and 64 bit stack pointers). Conditionally accessing kid (or klass pointer) at different locations depending on locking state brought in a tangle of other issues, including (but not limited to) performance problems. - Pre-headers, once added as a capability, can have other interesting uses. - GC interaction, while fairly straightforward, needs robust rules and invariants, and will have added considerations - E.g. potentially-inflated object size requirements for relocation, coupled with the potential for concurrent (with the collector) first-call-to-identity-hash situations, can mess with things that seem obvious without it. - E.g. "how much empty space do you need available to hold all the objects in this region? becomes much more ?interesting?. ? Gil. [1] https://en.wikipedia.org/wiki/Lilliput_and_Blefuscu [2] https://www.rfc-editor.org/ien/ien137.txt (the actual origin of the terms "Big Endian" and "Little Endian" as used in computer science). > On Mar 9, 2021, at 4:39 AM, Roman Kennke wrote: > > We would like to propose a new project called Lilliput, with the goal of exploring ways to shrink the object header. > > Goal: > 1. Reduce the object header to 64 bits. It may be possible to shrink it down to 32 bits as a secondary goal. > 2. Make the header layout more flexible, i.e. allow some build-time (possibly even run-time) configuration of how we use the bits. > > Motivation: > In 64-bit Hotspot, Java objects have an object header of 128 bits: a 64 bit multi-purpose header (?mark? or ?lock?) word and a 64-bit class pointer. With typical average object sizes of 5-6 words, this is quite significant: 2 of those words are always taken by the header. If it were possible to reduce the size of the header, we could significantly reduce memory pressure, which directly translates to one or more of (depending what you care about or what your workload does): > > - Reduced heap usage > - Higher object allocation rate > - Reduced GC activity > - Tighter packing of objects -> better cache locality > > In other words, we could reduce the overall CPU and/or memory usage of all Java workloads, whether it?s a large in-memory database or a small containerized application. > > > The object header is used (and overloaded) for the following purposes: > > - Locking: the lower 3 bits are used to indicate the locking state of an object and the higher bits *may* be used to encode a pointer to a stack-allocated monitor or inflated lock object > - GC: 4 bits are used for tracking the age of each object (in generational collectors). The whole header *may* be used to store forwarding information, depending on the collector > - Identity hash-code: Up to 32 bits are used to store the identity hash-code > - Type information: 64 bits are used to point to the Klass that describes the object type > > > We have a wide variety of techniques to explore for allocating and down-sizing header fields: > > - Pointers can be compressed, e.g. if we expect a maximum of, say, 8192 classes, we could, with some careful alignment of Klass objects, compress the class pointer down to 13 bits: 2^13=8192 addressable Klasses. Similar considerations apply to stack pointers and monitors. > - Instead of using pointers, we could use class IDs that index a lookup table > - We could backfill fields which are known at compile-time (e.g. alignment gap or hidden fields) > - We could use backfill fields appended to an object after the GC moved it (e.g. for hashcode) > - We could use side-tables > > > We also have a bewildering number of constraints. To name a few: > - Performance > - If we limit e.g. number of classes/monitors/etc that we can encode, we need a way to deal with overflow > - Requires changes in assembly across all supported platforms (also consider 32 bits) > - Interaction with other projects like Panama, Loom, maybe Leyden, etc > > And a couple of opportunities for further work (possibly outside of this project): > - If we leave arraylength in its own 64-bit field, perhaps we should consider 64-bit addressable arrays? > - Improvements to hashcode. Maybe salt it to avoid repetition of nursery objects, maybe expand it to 64 or even 128 bit. > > > I would propose myself as the project lead for Lilliput. :-) > For initial committers I think we need all expertise in runtime and GC that we can get. From the top of my head I?m thinking of John Rose, Dave Dice, Andrew Dinn, Andrew Haley, Erik ?sterlund, Aleksey Shipilev, Coleen Phillimore, Stefan Karlsson, Per Liden. Please suggest anybody who you think should be involved in this too. (Or yourself if you want to be in, or if you have no interest in it.) > > > My initial work plan is to: > > - Brainstorm, collect ideas and propose techniques in the Wiki > - Come up with a proof of concept as quickly as possible > - Use ZGC: no header usage > - Use existing class-pointer compression > - Shrink hashcode > - Work from there, decide-as-we-go with insights from previous steps > > > Please let me know what you think! > > Thanks, > Roman From admin at xakeps.dk Sat Mar 13 18:03:46 2021 From: admin at xakeps.dk (d3coder) Date: Sun, 14 Mar 2021 00:03:46 +0600 Subject: Platform logging for a library Message-ID: <5110116.aXmprrRl3B@arch> Is it good practice to use platform logging api[1] instead of libraries like slf4j or log4j-api in my libraries? [1] https://openjdk.java.net/jeps/264 From john.r.rose at oracle.com Sun Mar 14 04:44:03 2021 From: john.r.rose at oracle.com (John Rose) Date: Sat, 13 Mar 2021 20:44:03 -0800 Subject: Call for Discussion: New Project: Lilliput In-Reply-To: <0ec23c74-f0a3-1978-a2f1-9be96cdaf9c3@redhat.com> References: <0d396daa-4819-d915-b0e8-f2250370fb4f@redhat.com> <95ad3003-03aa-0dc7-c509-768d7af501fe@oracle.com> <0ec23c74-f0a3-1978-a2f1-9be96cdaf9c3@redhat.com> Message-ID: <0AEC929C-EE0A-4E99-9969-0B0F94136422@oracle.com> On Mar 12, 2021, at 2:50 PM, Roman Kennke wrote: > >> >> I had done experiments with a klass pointer indirection, which could effectively be a klass index. > > I had a little exchange with Thomas Stuefe, and we believe we can split Klass into fixed-sized part, and variable-sized part, have the fixed-size base reference the variable-sized part. Then we can allocate the fixed Klass instances into a 'flat' array in a contiguous memory region, and with some smart placement and aligmment we can use a compressed pointer to address it, which will effectively be an index into that array. Which means that with N bits of compressed-class-pointer we could address 2^N Klasses :-) No indirection needed if done so afaict. Coleen and I discussed similar work several years ago. My recollection is that there was a problem (at the time) with v-table access, because of the extra indirection. It may well have gotten worse in recent years. I also think the fixed-part/variable-sized part (aka. near klass and far klass) are likely to be a winning idea, in part because we may wish to have a larger number of near-klasses than far-klasses when we start doing specialized classes. I suggest making the size of the fixed-sized block (near-klass) configurable via a build-time or even run-time parameter. That would allow the first N items in the v-table to spill into the near-class, and avoid the indirection penalty for the first N virtual methods in any given class. I suppose Gil?s team experimented with something like this before settling on ?kids? pointing to pointers, which are the minimum size of a near-klass (64 bits). Maybe they may have some further experience with this. ? John From gil at azul.com Sun Mar 14 05:49:59 2021 From: gil at azul.com (Gil Tene) Date: Sun, 14 Mar 2021 05:49:59 +0000 Subject: Call for Discussion: New Project: Lilliput In-Reply-To: <0AEC929C-EE0A-4E99-9969-0B0F94136422@oracle.com> References: <0d396daa-4819-d915-b0e8-f2250370fb4f@redhat.com> <95ad3003-03aa-0dc7-c509-768d7af501fe@oracle.com> <0ec23c74-f0a3-1978-a2f1-9be96cdaf9c3@redhat.com>, <0AEC929C-EE0A-4E99-9969-0B0F94136422@oracle.com> Message-ID: <06FD0595-721F-414B-8E30-34470C4823A0@azul.com> Sent from Gil's iPhone > On Mar 13, 2021, at 6:44 PM, John Rose wrote: > > ?On Mar 12, 2021, at 2:50 PM, Roman Kennke wrote: >> >>> >>> I had done experiments with a klass pointer indirection, which could effectively be a klass index. >> >> I had a little exchange with Thomas Stuefe, and we believe we can split Klass into fixed-sized part, and variable-sized part, have the fixed-size base reference the variable-sized part. Then we can allocate the fixed Klass instances into a 'flat' array in a contiguous memory region, and with some smart placement and aligmment we can use a compressed pointer to address it, which will effectively be an index into that array. Which means that with N bits of compressed-class-pointer we could address 2^N Klasses :-) No indirection needed if done so afaict. > > Coleen and I discussed similar work several years ago. > My recollection is that there was a problem (at the time) > with v-table access, because of the extra indirection. > It may well have gotten worse in recent years. > > I also think the fixed-part/variable-sized part (aka. near klass > and far klass) are likely to be a winning idea, in part because > we may wish to have a larger number of near-klasses than > far-klasses when we start doing specialized classes. > > I suggest making the size of the fixed-sized block (near-klass) > configurable via a build-time or even run-time parameter. > That would allow the first N items in the v-table to spill > into the near-class, and avoid the indirection penalty for > the first N virtual methods in any given class. > > I suppose Gil?s team experimented with something like > this before settling on ?kids? pointing to pointers, which > are the minimum size of a near-klass (64 bits). Maybe they > may have some further experience with this. Yeah, we played around with all sorts of ?what else, other than a klass pointer, would you want in the klass table (indexed by kid)?? questions for over a decade now. There?s the ?first few vtable entries? thing. And the ?stuff about interface relationships? thing. The ?bit mapped ooptable for the first n words in the object? thing. And lots of other things. In the end, a single 64 bit pointer is where we are at... we do keep playing with aliased tables with such added information, on and off, but nothing huge in those so far. Our preferred approach when doing those experiments is to use an additional flat arrays indexed by kid, rather than extending the ?struct? in the klass table beyond 64 bits per entry. The way I?d summarize our overall empiric observation is that with tier-2 compilers doing stuff like multi-morphic guarded inlining (e.g. bi-morphic, tri-morphic, etc.) and multi-morphic inline caching, the impact of an extra indirection on actual vtable calls in code that is either not hot enough to get those optimizations or too mega-morphic to benefit from them is not big enough to add vtable info at that level... Obviously, all of our type comparisons and checks are done using kids and kid constants, not klass pointers. So no dereferencing is done unless we actually need to get at something in a klass that is not already extracted as a constant and inlined somewhere else. It?s worth noting that in Zing, klasses still live in the heap, in a permgen (much like pre-metaspace hotspot used to do), because with a concurrent compacting collector (C4), off-heaping that stuff was not a benefit, and would have only added downsides (like needing to manage and gc a separate meta space). That means that the ?klass pointers? in the Zing klass table are actually klass references (and proper oops). But this difference should not be material to the subject at hand. Metaspace ?GC? in hotspot would obviously need to be aware of the table, but that?s about it. I think. > > ? John From roger.riggs at oracle.com Mon Mar 15 15:25:08 2021 From: roger.riggs at oracle.com (Roger Riggs) Date: Mon, 15 Mar 2021 11:25:08 -0400 Subject: Platform logging for a library In-Reply-To: <5110116.aXmprrRl3B@arch> References: <5110116.aXmprrRl3B@arch> Message-ID: <3456203f-2693-0470-471c-3ca958716eb5@oracle.com> Hi, The platform logging provides a simple interface that can be configured to delegate to other logging frameworks. Unless you have specific needs for logging, I would say yes, keep the client code simple and unencumbered by specific imports and dependencies. Regards, Roger On 3/13/21 1:03 PM, d3coder wrote: > Is it good practice to use platform logging api[1] instead of libraries like > slf4j or log4j-api in my libraries? > [1] https://openjdk.java.net/jeps/264 > > From rkennke at redhat.com Mon Mar 15 17:46:50 2021 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 15 Mar 2021 18:46:50 +0100 Subject: Call for Discussion: New Project: Lilliput In-Reply-To: <0FA1E37F-C100-49C4-BC90-A748F935CB9F@oracle.com> References: <0d396daa-4819-d915-b0e8-f2250370fb4f@redhat.com> <0FA1E37F-C100-49C4-BC90-A748F935CB9F@oracle.com> Message-ID: <1e6d0b75-f7c8-c6e7-09ff-06d6344480aa@redhat.com> Hi John, as you suggested I collected (that is, started to collect) my notes here: http://cr.openjdk.java.net/~rkennke/lilliput.md If nobody yells at me to stop it, I would go ahead and send the official project proposal for voting. As soon as the project gets off the ground, I would transfer my notes to the project wiki. Please let me know if anybody else should be in the initial committers list. It's easier to add them now rather than later, and it's useful for project wiki access (and code of course). My list so far is: John Rose, Dave Dice, Andrew Dinn, Andrew Haley, Erik ?sterlund, Aleksey Shipilev, Coleen Phillimore, Stefan Karlsson, Per Liden, Thomas Stuefe, Gil Tene, David Holmes, Kim Barrett Cheerio, Roman > Many people, including myself, have puzzled for years > over the problem of header size. I am glad to see a frontal > assault being made on it now! There is a bewilderingly > complex shadowy thicket of potential partial solutions, > including side tables, optional backfill zones (good term, > Remi), data compression, bitfields, tagged pointers, and > compute vs. store trade-offs, for klass, GC mark, hash, > and lock. Welcome to the thicket! > > I think you have already gathered a list of potential > techniques. It would be very good for you to publish > your notes somewhere, to help give more shape to > the conversation. > > I personally use my page on cr.ojn for such notes, > and that?s what I recommend now. > > While it would be better to use a wiki somewhere > for collaborative edits, there aren?t any good options > under ojn for this (due to inconvenient rules for > authoring the wiki). So cr.ojn is a good start, and > when the project boots up you can have a notes > file (or files) in the repo itself. > > ? John > > P.S. I want to give a shout-out to Dave and Alex?s > paper https://arxiv.org/pdf/2102.04188.pdf about > rethinking the lock word. This work would > probably give us lots of ?slack? for crunching > down the fixed monitor overhead. > > On Mar 9, 2021, at 6:39 AM, Roman Kennke wrote: >> >> We would like to propose a new project called Lilliput, with the goal of exploring ways to shrink the object header. >> >> Goal: >> 1. Reduce the object header to 64 bits. It may be possible to shrink it down to 32 bits as a secondary goal. >> 2. Make the header layout more flexible, i.e. allow some build-time (possibly even run-time) configuration of how we use the bits. >> >> Motivation: >> In 64-bit Hotspot, Java objects have an object header of 128 bits: a 64 bit multi-purpose header (?mark? or ?lock?) word and a 64-bit class pointer. With typical average object sizes of 5-6 words, this is quite significant: 2 of those words are always taken by the header. If it were possible to reduce the size of the header, we could significantly reduce memory pressure, which directly translates to one or more of (depending what you care about or what your workload does): >> >> - Reduced heap usage >> - Higher object allocation rate >> - Reduced GC activity >> - Tighter packing of objects -> better cache locality >> >> In other words, we could reduce the overall CPU and/or memory usage of all Java workloads, whether it?s a large in-memory database or a small containerized application. >> >> >> The object header is used (and overloaded) for the following purposes: >> >> - Locking: the lower 3 bits are used to indicate the locking state of an object and the higher bits *may* be used to encode a pointer to a stack-allocated monitor or inflated lock object >> - GC: 4 bits are used for tracking the age of each object (in generational collectors). The whole header *may* be used to store forwarding information, depending on the collector >> - Identity hash-code: Up to 32 bits are used to store the identity hash-code >> - Type information: 64 bits are used to point to the Klass that describes the object type >> >> >> We have a wide variety of techniques to explore for allocating and down-sizing header fields: >> >> - Pointers can be compressed, e.g. if we expect a maximum of, say, 8192 classes, we could, with some careful alignment of Klass objects, compress the class pointer down to 13 bits: 2^13=8192 addressable Klasses. Similar considerations apply to stack pointers and monitors. >> - Instead of using pointers, we could use class IDs that index a lookup table >> - We could backfill fields which are known at compile-time (e.g. alignment gap or hidden fields) >> - We could use backfill fields appended to an object after the GC moved it (e.g. for hashcode) >> - We could use side-tables >> >> >> We also have a bewildering number of constraints. To name a few: >> - Performance >> - If we limit e.g. number of classes/monitors/etc that we can encode, we need a way to deal with overflow >> - Requires changes in assembly across all supported platforms (also consider 32 bits) >> - Interaction with other projects like Panama, Loom, maybe Leyden, etc >> >> And a couple of opportunities for further work (possibly outside of this project): >> - If we leave arraylength in its own 64-bit field, perhaps we should consider 64-bit addressable arrays? >> - Improvements to hashcode. Maybe salt it to avoid repetition of nursery objects, maybe expand it to 64 or even 128 bit. >> >> >> I would propose myself as the project lead for Lilliput. :-) >> For initial committers I think we need all expertise in runtime and GC that we can get. From the top of my head I?m thinking of John Rose, Dave Dice, Andrew Dinn, Andrew Haley, Erik ?sterlund, Aleksey Shipilev, Coleen Phillimore, Stefan Karlsson, Per Liden. Please suggest anybody who you think should be involved in this too. (Or yourself if you want to be in, or if you have no interest in it.) >> >> >> My initial work plan is to: >> >> - Brainstorm, collect ideas and propose techniques in the Wiki >> - Come up with a proof of concept as quickly as possible >> - Use ZGC: no header usage >> - Use existing class-pointer compression >> - Shrink hashcode >> - Work from there, decide-as-we-go with insights from previous steps >> >> >> Please let me know what you think! >> >> Thanks, >> Roman >> > From thomas.schatzl at oracle.com Mon Mar 15 18:13:05 2021 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Mon, 15 Mar 2021 19:13:05 +0100 Subject: Call for Discussion: New Project: Lilliput In-Reply-To: <0ec23c74-f0a3-1978-a2f1-9be96cdaf9c3@redhat.com> References: <0d396daa-4819-d915-b0e8-f2250370fb4f@redhat.com> <95ad3003-03aa-0dc7-c509-768d7af501fe@oracle.com> <0ec23c74-f0a3-1978-a2f1-9be96cdaf9c3@redhat.com> Message-ID: <47306395-9c6b-e7b0-1118-f59049ffa38f@oracle.com> Hi, On 12.03.21 23:50, Roman Kennke wrote: > >>> I would propose myself as the project lead for Lilliput. :-) >>> For initial committers I think we need all expertise in runtime and >>> GC that we can get. From the top of my head I?m thinking of John >>> Rose, Dave Dice, Andrew Dinn, Andrew Haley, Erik ?sterlund, Aleksey >>> Shipilev, Coleen Phillimore, Stefan Karlsson, Per Liden. Please >>> suggest anybody who you think should be involved in this too. (Or >>> yourself if you want to be in, or if you have no interest in it.) >> >> Yes, please. I'd like to be a committer. > > +1 :-) Me too please, if you think you still want somebody with GC experience. Thomas From rkennke at redhat.com Mon Mar 15 18:36:05 2021 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 15 Mar 2021 19:36:05 +0100 Subject: Call for Discussion: New Project: Lilliput In-Reply-To: <47306395-9c6b-e7b0-1118-f59049ffa38f@oracle.com> References: <0d396daa-4819-d915-b0e8-f2250370fb4f@redhat.com> <95ad3003-03aa-0dc7-c509-768d7af501fe@oracle.com> <0ec23c74-f0a3-1978-a2f1-9be96cdaf9c3@redhat.com> <47306395-9c6b-e7b0-1118-f59049ffa38f@oracle.com> Message-ID: <0132a68a-2e7c-8df8-0294-17cc37734b65@redhat.com> >>>> I would propose myself as the project lead for Lilliput. :-) >>>> For initial committers I think we need all expertise in runtime and >>>> GC that we can get. From the top of my head I?m thinking of John >>>> Rose, Dave Dice, Andrew Dinn, Andrew Haley, Erik ?sterlund, Aleksey >>>> Shipilev, Coleen Phillimore, Stefan Karlsson, Per Liden. Please >>>> suggest anybody who you think should be involved in this too. (Or >>>> yourself if you want to be in, or if you have no interest in it.) >>> >>> Yes, please. I'd like to be a committer. >> >> +1 :-) > > Me too please, if you think you still want somebody with GC experience. Absolutely +1! Roman From neugens at redhat.com Tue Mar 16 16:52:55 2021 From: neugens at redhat.com (Mario Torre) Date: Tue, 16 Mar 2021 17:52:55 +0100 Subject: CFV: New Project: Lilliput In-Reply-To: <7be61ffb-666d-1221-7669-d5d9862d1f73@redhat.com> References: <7be61ffb-666d-1221-7669-d5d9862d1f73@redhat.com> Message-ID: Vote: yes! Cheers, Mario On Tue, Mar 16, 2021 at 5:49 PM Roman Kennke wrote: > > I hereby propose the creation of the Lilliput Project with > Roman Kennke as the Lead and Hotspot as the sponsoring > Group(s). > > Lilliput's primary goal is to explore techniques to downsize Java object > headers in the Hotspot JVM from currently 128 bits to 64 bits or even > less. This will reduce Java's memory footprint and we expect it to also > improve performance across most if not all workloads. > > Roman Kennke is a long-time OpenJDK contributor. He started contributing > to Swing and Java2D in 2007 and co-lead the Caciocavallo project (now > de-funct), contributed to Thermostat, and also worked on Zero > interpreter and Shark compiler. His primary occupation since 2013 is the > Shenandoah GC project, which produced the JEP 304: Garbage Collection > Interface and JEP 189: JEP 189: Shenandoah: A Low-Pause-Time Garbage > Collector. > > Suggested initial committers: John Rose, Dave Dice, Andrew Dinn, Andrew > Haley, Erik ?sterlund, Aleksey Shipilev, Coleen Phillimore, Stefan > Karlsson, Per Liden, Thomas Stuefe, Gil Tene, David Holmes, Kim Barrett, > Thomas Schatzl > > Votes are due by March, 31st, 2021. > > Only current OpenJDK Members [1] 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 [2]. > > Roman Kennke > > [1] https://openjdk.java.net/census#members > [2] https://openjdk.java.net/projects/#new-project-vote > -- Mario Torre Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From adinn at redhat.com Tue Mar 16 16:56:02 2021 From: adinn at redhat.com (Andrew Dinn) Date: Tue, 16 Mar 2021 16:56:02 +0000 Subject: CFV: New Project: Lilliput In-Reply-To: <7be61ffb-666d-1221-7669-d5d9862d1f73@redhat.com> References: <7be61ffb-666d-1221-7669-d5d9862d1f73@redhat.com> Message-ID: <9f04ca5c-7a62-e38b-1afd-acb2518fbb21@redhat.com> Vote: yes On 16/03/2021 13:31, Roman Kennke wrote: > I hereby propose the creation of the Lilliput Project with > Roman Kennke as the Lead and Hotspot as the sponsoring > Group(s). > > Lilliput's primary goal is to explore techniques to downsize Java object > headers in the Hotspot JVM from currently 128 bits to 64 bits or even > less. This will reduce Java's memory footprint and we expect it to also > improve performance across most if not all workloads. > > Roman Kennke is a long-time OpenJDK contributor. He started contributing > to Swing and Java2D in 2007 and co-lead the Caciocavallo project (now > de-funct), contributed to Thermostat, and also worked on Zero > interpreter and Shark compiler. His primary occupation since 2013 is the > Shenandoah GC project, which produced the JEP 304: Garbage Collection > Interface and JEP 189: JEP 189: Shenandoah: A Low-Pause-Time Garbage > Collector. > > Suggested initial committers: John Rose, Dave Dice, Andrew Dinn, Andrew > Haley, Erik ?sterlund, Aleksey Shipilev, Coleen Phillimore, Stefan > Karlsson, Per Liden, Thomas Stuefe, Gil Tene, David Holmes, Kim Barrett, > Thomas Schatzl > > Votes are due by March, 31st, 2021. > > Only current OpenJDK Members [1] 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 [2]. > > Roman Kennke > > [1] https://openjdk.java.net/census#members > [2] https://openjdk.java.net/projects/#new-project-vote > -- regards, Andrew Dinn ----------- Red Hat Distinguished Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill From volker.simonis at gmail.com Tue Mar 16 16:57:26 2021 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 16 Mar 2021 17:57:26 +0100 Subject: CFV: New Project: Lilliput In-Reply-To: <7be61ffb-666d-1221-7669-d5d9862d1f73@redhat.com> References: <7be61ffb-666d-1221-7669-d5d9862d1f73@redhat.com> Message-ID: Vote: yes On Tue, Mar 16, 2021 at 5:48 PM Roman Kennke wrote: > > I hereby propose the creation of the Lilliput Project with > Roman Kennke as the Lead and Hotspot as the sponsoring > Group(s). > > Lilliput's primary goal is to explore techniques to downsize Java object > headers in the Hotspot JVM from currently 128 bits to 64 bits or even > less. This will reduce Java's memory footprint and we expect it to also > improve performance across most if not all workloads. > > Roman Kennke is a long-time OpenJDK contributor. He started contributing > to Swing and Java2D in 2007 and co-lead the Caciocavallo project (now > de-funct), contributed to Thermostat, and also worked on Zero > interpreter and Shark compiler. His primary occupation since 2013 is the > Shenandoah GC project, which produced the JEP 304: Garbage Collection > Interface and JEP 189: JEP 189: Shenandoah: A Low-Pause-Time Garbage > Collector. > > Suggested initial committers: John Rose, Dave Dice, Andrew Dinn, Andrew > Haley, Erik ?sterlund, Aleksey Shipilev, Coleen Phillimore, Stefan > Karlsson, Per Liden, Thomas Stuefe, Gil Tene, David Holmes, Kim Barrett, > Thomas Schatzl > > Votes are due by March, 31st, 2021. > > Only current OpenJDK Members [1] 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 [2]. > > Roman Kennke > > [1] https://openjdk.java.net/census#members > [2] https://openjdk.java.net/projects/#new-project-vote > From sgehwolf at redhat.com Tue Mar 16 17:15:07 2021 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 16 Mar 2021 18:15:07 +0100 Subject: CFV: New Project: Lilliput In-Reply-To: <7be61ffb-666d-1221-7669-d5d9862d1f73@redhat.com> References: <7be61ffb-666d-1221-7669-d5d9862d1f73@redhat.com> Message-ID: <0fae15a22aa333344221e4c93e6028ae2db518fc.camel@redhat.com> Vote: yes On Tue, 2021-03-16 at 14:31 +0100, Roman Kennke wrote: > I hereby propose the creation of the Lilliput Project with > Roman Kennke as the Lead and Hotspot as the sponsoring > Group(s). From thomas.stuefe at gmail.com Tue Mar 16 17:21:25 2021 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 16 Mar 2021 18:21:25 +0100 Subject: CFV: New Project: Lilliput In-Reply-To: <7be61ffb-666d-1221-7669-d5d9862d1f73@redhat.com> References: <7be61ffb-666d-1221-7669-d5d9862d1f73@redhat.com> Message-ID: Vote: yes On Tue, Mar 16, 2021 at 5:48 PM Roman Kennke wrote: > I hereby propose the creation of the Lilliput Project with > Roman Kennke as the Lead and Hotspot as the sponsoring > Group(s). > > Lilliput's primary goal is to explore techniques to downsize Java object > headers in the Hotspot JVM from currently 128 bits to 64 bits or even > less. This will reduce Java's memory footprint and we expect it to also > improve performance across most if not all workloads. > > Roman Kennke is a long-time OpenJDK contributor. He started contributing > to Swing and Java2D in 2007 and co-lead the Caciocavallo project (now > de-funct), contributed to Thermostat, and also worked on Zero > interpreter and Shark compiler. His primary occupation since 2013 is the > Shenandoah GC project, which produced the JEP 304: Garbage Collection > Interface and JEP 189: JEP 189: Shenandoah: A Low-Pause-Time Garbage > Collector. > > Suggested initial committers: John Rose, Dave Dice, Andrew Dinn, Andrew > Haley, Erik ?sterlund, Aleksey Shipilev, Coleen Phillimore, Stefan > Karlsson, Per Liden, Thomas Stuefe, Gil Tene, David Holmes, Kim Barrett, > Thomas Schatzl > > Votes are due by March, 31st, 2021. > > Only current OpenJDK Members [1] 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 [2]. > > Roman Kennke > > [1] https://openjdk.java.net/census#members > [2] https://openjdk.java.net/projects/#new-project-vote > > From mark.reinhold at oracle.com Tue Mar 16 17:36:45 2021 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Tue, 16 Mar 2021 10:36:45 -0700 Subject: CFV: New Project: Lilliput In-Reply-To: <7be61ffb-666d-1221-7669-d5d9862d1f73@redhat.com> References: <7be61ffb-666d-1221-7669-d5d9862d1f73@redhat.com> Message-ID: <20210316103645.69650321@eggemoggin.niobe.net> Vote: yes - Mark From vladimir.kozlov at oracle.com Tue Mar 16 17:42:19 2021 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 16 Mar 2021 10:42:19 -0700 Subject: CFV: New Project: Lilliput In-Reply-To: <7be61ffb-666d-1221-7669-d5d9862d1f73@redhat.com> References: <7be61ffb-666d-1221-7669-d5d9862d1f73@redhat.com> Message-ID: <1fcd8461-186d-0040-d7dc-aff14c56dfb4@oracle.com> Vote: yes Thanks, Vladimir K On 3/16/21 6:31 AM, Roman Kennke wrote: > I hereby propose the creation of the Lilliput Project with > Roman Kennke as the Lead and Hotspot as the sponsoring > Group(s). > > Lilliput's primary goal is to explore techniques to downsize Java object headers in the Hotspot JVM from currently 128 > bits to 64 bits or even less. This will reduce Java's memory footprint and we expect it to also improve performance > across most if not all workloads. > > Roman Kennke is a long-time OpenJDK contributor. He started contributing to Swing and Java2D in 2007 and co-lead the > Caciocavallo project (now de-funct), contributed to Thermostat, and also worked on Zero interpreter and Shark compiler. > His primary occupation since 2013 is the Shenandoah GC project, which produced the JEP 304: Garbage Collection Interface > and JEP 189: JEP 189: Shenandoah: A Low-Pause-Time Garbage Collector. > > Suggested initial committers: John Rose, Dave Dice, Andrew Dinn, Andrew Haley, Erik ?sterlund, Aleksey Shipilev, Coleen > Phillimore, Stefan Karlsson, Per Liden, Thomas Stuefe, Gil Tene, David Holmes, Kim Barrett, Thomas Schatzl > > Votes are due by March, 31st, 2021. > > Only current OpenJDK Members [1] 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 [2]. > > Roman Kennke > > [1] https://openjdk.java.net/census#members > [2] https://openjdk.java.net/projects/#new-project-vote > From Alan.Bateman at oracle.com Tue Mar 16 17:46:50 2021 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 16 Mar 2021 17:46:50 +0000 Subject: CFV: New Project: Lilliput In-Reply-To: <7be61ffb-666d-1221-7669-d5d9862d1f73@redhat.com> References: <7be61ffb-666d-1221-7669-d5d9862d1f73@redhat.com> Message-ID: <184c2a89-8f7d-6c78-94a2-cf06e74aefbb@oracle.com> Vote: yes From magnus.ihse.bursie at oracle.com Tue Mar 16 18:08:52 2021 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 16 Mar 2021 19:08:52 +0100 Subject: CFV: New Project: Lilliput In-Reply-To: <7be61ffb-666d-1221-7669-d5d9862d1f73@redhat.com> References: <7be61ffb-666d-1221-7669-d5d9862d1f73@redhat.com> Message-ID: Vote: yes /Magnus On 2021-03-16 14:31, Roman Kennke wrote: > I hereby propose the creation of the Lilliput Project with > Roman Kennke as the Lead and Hotspot as the sponsoring > Group(s). > > Lilliput's primary goal is to explore techniques to downsize Java > object headers in the Hotspot JVM from currently 128 bits to 64 bits > or even less. This will reduce Java's memory footprint and we expect > it to also improve performance across most if not all workloads. > > Roman Kennke is a long-time OpenJDK contributor. He started > contributing to Swing and Java2D in 2007 and co-lead the Caciocavallo > project (now de-funct), contributed to Thermostat, and also worked on > Zero interpreter and Shark compiler. His primary occupation since 2013 > is the Shenandoah GC project, which produced the JEP 304: Garbage > Collection Interface and JEP 189: JEP 189: Shenandoah: A > Low-Pause-Time Garbage Collector. > > Suggested initial committers: John Rose, Dave Dice, Andrew Dinn, > Andrew Haley, Erik ?sterlund, Aleksey Shipilev, Coleen Phillimore, > Stefan Karlsson, Per Liden, Thomas Stuefe, Gil Tene, David Holmes, Kim > Barrett, Thomas Schatzl > > Votes are due by March, 31st, 2021. > > Only current OpenJDK Members [1] 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 [2]. > > Roman Kennke > > [1] https://openjdk.java.net/census#members > [2] https://openjdk.java.net/projects/#new-project-vote > From jesper.wilhelmsson at oracle.com Tue Mar 16 18:11:13 2021 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Tue, 16 Mar 2021 19:11:13 +0100 Subject: CFV: New Project: Lilliput In-Reply-To: <7be61ffb-666d-1221-7669-d5d9862d1f73@redhat.com> References: <7be61ffb-666d-1221-7669-d5d9862d1f73@redhat.com> Message-ID: <0F97AAC3-078F-4CD8-BE14-6605FB3D6060@oracle.com> Vote: Yes /Jesper > On 16 Mar 2021, at 14:31, Roman Kennke wrote: > > I hereby propose the creation of the Lilliput Project with > Roman Kennke as the Lead and Hotspot as the sponsoring > Group(s). > > Lilliput's primary goal is to explore techniques to downsize Java object headers in the Hotspot JVM from currently 128 bits to 64 bits or even less. This will reduce Java's memory footprint and we expect it to also improve performance across most if not all workloads. > > Roman Kennke is a long-time OpenJDK contributor. He started contributing to Swing and Java2D in 2007 and co-lead the Caciocavallo project (now de-funct), contributed to Thermostat, and also worked on Zero interpreter and Shark compiler. His primary occupation since 2013 is the Shenandoah GC project, which produced the JEP 304: Garbage Collection Interface and JEP 189: JEP 189: Shenandoah: A Low-Pause-Time Garbage Collector. > > Suggested initial committers: John Rose, Dave Dice, Andrew Dinn, Andrew Haley, Erik ?sterlund, Aleksey Shipilev, Coleen Phillimore, Stefan Karlsson, Per Liden, Thomas Stuefe, Gil Tene, David Holmes, Kim Barrett, Thomas Schatzl > > Votes are due by March, 31st, 2021. > > Only current OpenJDK Members [1] 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 [2]. > > Roman Kennke > > [1] https://openjdk.java.net/census#members > [2] https://openjdk.java.net/projects/#new-project-vote > From erik.osterlund at oracle.com Tue Mar 16 18:16:14 2021 From: erik.osterlund at oracle.com (Erik Osterlund) Date: Tue, 16 Mar 2021 18:16:14 +0000 Subject: CFV: New Project: Lilliput In-Reply-To: <7be61ffb-666d-1221-7669-d5d9862d1f73@redhat.com> References: <7be61ffb-666d-1221-7669-d5d9862d1f73@redhat.com> Message-ID: Vote: yes /Erik > On 16 Mar 2021, at 17:48, Roman Kennke wrote: > > ?I hereby propose the creation of the Lilliput Project with > Roman Kennke as the Lead and Hotspot as the sponsoring > Group(s). > > Lilliput's primary goal is to explore techniques to downsize Java object headers in the Hotspot JVM from currently 128 bits to 64 bits or even less. This will reduce Java's memory footprint and we expect it to also improve performance across most if not all workloads. > > Roman Kennke is a long-time OpenJDK contributor. He started contributing to Swing and Java2D in 2007 and co-lead the Caciocavallo project (now de-funct), contributed to Thermostat, and also worked on Zero interpreter and Shark compiler. His primary occupation since 2013 is the Shenandoah GC project, which produced the JEP 304: Garbage Collection Interface and JEP 189: JEP 189: Shenandoah: A Low-Pause-Time Garbage Collector. > > Suggested initial committers: John Rose, Dave Dice, Andrew Dinn, Andrew Haley, Erik ?sterlund, Aleksey Shipilev, Coleen Phillimore, Stefan Karlsson, Per Liden, Thomas Stuefe, Gil Tene, David Holmes, Kim Barrett, Thomas Schatzl > > Votes are due by March, 31st, 2021. > > Only current OpenJDK Members [1] 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 [2]. > > Roman Kennke > > [1] https://openjdk.java.net/census#members > [2] https://openjdk.java.net/projects/#new-project-vote > From dalibor.topic at oracle.com Tue Mar 16 18:17:15 2021 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Tue, 16 Mar 2021 19:17:15 +0100 Subject: CFV: New Project: Lilliput In-Reply-To: <7be61ffb-666d-1221-7669-d5d9862d1f73@redhat.com> References: <7be61ffb-666d-1221-7669-d5d9862d1f73@redhat.com> Message-ID: <67c3731b-0add-c0df-4c65-706b8aaa01bf@oracle.com> Vote: Yes. On 16.03.2021 14:31, Roman Kennke wrote: > I hereby propose the creation of the Lilliput Project with > Roman Kennke as the Lead and Hotspot as the sponsoring > Group(s). -- Dalibor Topic Consulting Product Manager Phone: +494089091214 , Mobile: +491737185961 , Video: dalibor.topic at oracle.com Oracle Global Services Germany GmbH Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRB 246209 Gesch?ftsf?hrer: Ralf Herrmann From serguei.spitsyn at oracle.com Tue Mar 16 19:21:28 2021 From: serguei.spitsyn at oracle.com (Serguei Spitsyn) Date: Tue, 16 Mar 2021 19:21:28 +0000 Subject: New Project: Lilliput Message-ID: <9F356689-5D2C-43BC-89E3-70432262213A@oracle.com> Vote: yes From mbalao at redhat.com Tue Mar 16 20:40:06 2021 From: mbalao at redhat.com (Martin Balao) Date: Tue, 16 Mar 2021 17:40:06 -0300 Subject: CFV: New Project: Lilliput In-Reply-To: <7be61ffb-666d-1221-7669-d5d9862d1f73@redhat.com> References: <7be61ffb-666d-1221-7669-d5d9862d1f73@redhat.com> Message-ID: <192aac9a-ff09-eb88-31c7-6d6716e24f2e@redhat.com> On 3/16/21 10:31 AM, Roman Kennke wrote: > I hereby propose the creation of the Lilliput Project with > Roman Kennke as the Lead and Hotspot as the sponsoring > Group(s). > Vote: Yes. From ChrisPhi at LGonQn.Org Tue Mar 16 22:34:38 2021 From: ChrisPhi at LGonQn.Org ("Chris Phillips"@T O) Date: Tue, 16 Mar 2021 18:34:38 -0400 Subject: CFV: New Project: Lilliput In-Reply-To: <7be61ffb-666d-1221-7669-d5d9862d1f73@redhat.com> References: <7be61ffb-666d-1221-7669-d5d9862d1f73@redhat.com> Message-ID: <23bd8c48-ed7b-5207-f58a-22d1fed00faf@LGonQn.Org> Hi Roman, Vote: Yes Cheers! ChrisPhi On 16/03/21 09:31 AM, Roman Kennke wrote: > I hereby propose the creation of the Lilliput Project with > Roman Kennke as the Lead and Hotspot as the sponsoring > Group(s). > > Lilliput's primary goal is to explore techniques to downsize Java > object headers in the Hotspot JVM from currently 128 bits to 64 bits > or even less. This will reduce Java's memory footprint and we expect > it to also improve performance across most if not all workloads. > > Roman Kennke is a long-time OpenJDK contributor. He started > contributing to Swing and Java2D in 2007 and co-lead the Caciocavallo > project (now de-funct), contributed to Thermostat, and also worked on > Zero interpreter and Shark compiler. His primary occupation since 2013 > is the Shenandoah GC project, which produced the JEP 304: Garbage > Collection Interface and JEP 189: JEP 189: Shenandoah: A > Low-Pause-Time Garbage Collector. > > Suggested initial committers: John Rose, Dave Dice, Andrew Dinn, > Andrew Haley, Erik ?sterlund, Aleksey Shipilev, Coleen Phillimore, > Stefan Karlsson, Per Liden, Thomas Stuefe, Gil Tene, David Holmes, Kim > Barrett, Thomas Schatzl > > Votes are due by March, 31st, 2021. > > Only current OpenJDK Members [1] 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 [2]. > > Roman Kennke > > [1] https://openjdk.java.net/census#members > [2] https://openjdk.java.net/projects/#new-project-vote > > > > From christoph.langer at sap.com Tue Mar 16 20:31:21 2021 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 16 Mar 2021 20:31:21 +0000 Subject: CFV: New Project: Lilliput In-Reply-To: <7be61ffb-666d-1221-7669-d5d9862d1f73@redhat.com> References: <7be61ffb-666d-1221-7669-d5d9862d1f73@redhat.com> Message-ID: Vote: yes /Christoph > -----Original Message----- > From: announce On Behalf Of Roman > Kennke > Sent: Dienstag, 16. M?rz 2021 14:31 > To: announce at openjdk.java.net > Subject: CFV: New Project: Lilliput > > I hereby propose the creation of the Lilliput Project with > Roman Kennke as the Lead and Hotspot as the sponsoring > Group(s). > > Lilliput's primary goal is to explore techniques to downsize Java object > headers in the Hotspot JVM from currently 128 bits to 64 bits or even > less. This will reduce Java's memory footprint and we expect it to also > improve performance across most if not all workloads. > > Roman Kennke is a long-time OpenJDK contributor. He started contributing > to Swing and Java2D in 2007 and co-lead the Caciocavallo project (now > de-funct), contributed to Thermostat, and also worked on Zero > interpreter and Shark compiler. His primary occupation since 2013 is the > Shenandoah GC project, which produced the JEP 304: Garbage Collection > Interface and JEP 189: JEP 189: Shenandoah: A Low-Pause-Time Garbage > Collector. > > Suggested initial committers: John Rose, Dave Dice, Andrew Dinn, Andrew > Haley, Erik ?sterlund, Aleksey Shipilev, Coleen Phillimore, Stefan > Karlsson, Per Liden, Thomas Stuefe, Gil Tene, David Holmes, Kim Barrett, > Thomas Schatzl > > Votes are due by March, 31st, 2021. > > Only current OpenJDK Members [1] 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 [2]. > > Roman Kennke > > [1] https://openjdk.java.net/census#members > [2] https://openjdk.java.net/projects/#new-project-vote From david.holmes at oracle.com Tue Mar 16 23:57:30 2021 From: david.holmes at oracle.com (David Holmes) Date: Wed, 17 Mar 2021 09:57:30 +1000 Subject: CFV: New Project: Lilliput In-Reply-To: <7be61ffb-666d-1221-7669-d5d9862d1f73@redhat.com> References: <7be61ffb-666d-1221-7669-d5d9862d1f73@redhat.com> Message-ID: Vote: yes David On 16/03/2021 11:31 pm, Roman Kennke wrote: > I hereby propose the creation of the Lilliput Project with > Roman Kennke as the Lead and Hotspot as the sponsoring > Group(s). > > Lilliput's primary goal is to explore techniques to downsize Java object > headers in the Hotspot JVM from currently 128 bits to 64 bits or even > less. This will reduce Java's memory footprint and we expect it to also > improve performance across most if not all workloads. > > Roman Kennke is a long-time OpenJDK contributor. He started contributing > to Swing and Java2D in 2007 and co-lead the Caciocavallo project (now > de-funct), contributed to Thermostat, and also worked on Zero > interpreter and Shark compiler. His primary occupation since 2013 is the > Shenandoah GC project, which produced the JEP 304: Garbage Collection > Interface and JEP 189: JEP 189: Shenandoah: A Low-Pause-Time Garbage > Collector. > > Suggested initial committers: John Rose, Dave Dice, Andrew Dinn, Andrew > Haley, Erik ?sterlund, Aleksey Shipilev, Coleen Phillimore, Stefan > Karlsson, Per Liden, Thomas Stuefe, Gil Tene, David Holmes, Kim Barrett, > Thomas Schatzl > > Votes are due by March, 31st, 2021. > > Only current OpenJDK Members [1] 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 [2]. > > Roman Kennke > > [1] https://openjdk.java.net/census#members > [2] https://openjdk.java.net/projects/#new-project-vote > From stefan.karlsson at oracle.com Wed Mar 17 08:09:16 2021 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Wed, 17 Mar 2021 09:09:16 +0100 Subject: CFV: New Project: Lilliput In-Reply-To: <7be61ffb-666d-1221-7669-d5d9862d1f73@redhat.com> References: <7be61ffb-666d-1221-7669-d5d9862d1f73@redhat.com> Message-ID: <96251d7b-26fe-2e8e-ab9c-79d5e4a2f14e@oracle.com> Vote: yes StefanK On 2021-03-16 14:31, Roman Kennke wrote: > I hereby propose the creation of the Lilliput Project with > Roman Kennke as the Lead and Hotspot as the sponsoring > Group(s). > > Lilliput's primary goal is to explore techniques to downsize Java > object headers in the Hotspot JVM from currently 128 bits to 64 bits > or even less. This will reduce Java's memory footprint and we expect > it to also improve performance across most if not all workloads. > > Roman Kennke is a long-time OpenJDK contributor. He started > contributing to Swing and Java2D in 2007 and co-lead the Caciocavallo > project (now de-funct), contributed to Thermostat, and also worked on > Zero interpreter and Shark compiler. His primary occupation since 2013 > is the Shenandoah GC project, which produced the JEP 304: Garbage > Collection Interface and JEP 189: JEP 189: Shenandoah: A > Low-Pause-Time Garbage Collector. > > Suggested initial committers: John Rose, Dave Dice, Andrew Dinn, > Andrew Haley, Erik ?sterlund, Aleksey Shipilev, Coleen Phillimore, > Stefan Karlsson, Per Liden, Thomas Stuefe, Gil Tene, David Holmes, Kim > Barrett, Thomas Schatzl > > Votes are due by March, 31st, 2021. > > Only current OpenJDK Members [1] 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 [2]. > > Roman Kennke > > [1] https://openjdk.java.net/census#members > [2] https://openjdk.java.net/projects/#new-project-vote > From thomas.schatzl at oracle.com Wed Mar 17 11:37:29 2021 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Wed, 17 Mar 2021 12:37:29 +0100 Subject: CFV: New Project: Lilliput In-Reply-To: <96251d7b-26fe-2e8e-ab9c-79d5e4a2f14e@oracle.com> References: <7be61ffb-666d-1221-7669-d5d9862d1f73@redhat.com> <96251d7b-26fe-2e8e-ab9c-79d5e4a2f14e@oracle.com> Message-ID: <4b2d4868-d64f-8530-c967-54724b463041@oracle.com> Vote: yes Thomas From coleen.phillimore at oracle.com Wed Mar 17 12:26:12 2021 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 17 Mar 2021 08:26:12 -0400 Subject: CFV: New Project: Lilliput In-Reply-To: <7be61ffb-666d-1221-7669-d5d9862d1f73@redhat.com> References: <7be61ffb-666d-1221-7669-d5d9862d1f73@redhat.com> Message-ID: Vote: yes On 3/16/21 9:31 AM, Roman Kennke wrote: > I hereby propose the creation of the Lilliput Project with > Roman Kennke as the Lead and Hotspot as the sponsoring > Group(s). > > Lilliput's primary goal is to explore techniques to downsize Java > object headers in the Hotspot JVM from currently 128 bits to 64 bits > or even less. This will reduce Java's memory footprint and we expect > it to also improve performance across most if not all workloads. > > Roman Kennke is a long-time OpenJDK contributor. He started > contributing to Swing and Java2D in 2007 and co-lead the Caciocavallo > project (now de-funct), contributed to Thermostat, and also worked on > Zero interpreter and Shark compiler. His primary occupation since 2013 > is the Shenandoah GC project, which produced the JEP 304: Garbage > Collection Interface and JEP 189: JEP 189: Shenandoah: A > Low-Pause-Time Garbage Collector. > > Suggested initial committers: John Rose, Dave Dice, Andrew Dinn, > Andrew Haley, Erik ?sterlund, Aleksey Shipilev, Coleen Phillimore, > Stefan Karlsson, Per Liden, Thomas Stuefe, Gil Tene, David Holmes, Kim > Barrett, Thomas Schatzl > > Votes are due by March, 31st, 2021. > > Only current OpenJDK Members [1] 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 [2]. > > Roman Kennke > > [1] https://openjdk.java.net/census#members > [2] https://openjdk.java.net/projects/#new-project-vote > From admin at xakeps.dk Wed Mar 17 12:30:18 2021 From: admin at xakeps.dk (d3coder) Date: Wed, 17 Mar 2021 18:30:18 +0600 Subject: Platform logging for a library In-Reply-To: <5110116.aXmprrRl3B@arch> References: <5110116.aXmprrRl3B@arch> Message-ID: <2151768.QvFFkprEvU@arch> Thanks for the feedback From richard.reingruber at sap.com Wed Mar 17 15:06:25 2021 From: richard.reingruber at sap.com (Reingruber, Richard) Date: Wed, 17 Mar 2021 15:06:25 +0000 Subject: CFV: New Project: Lilliput In-Reply-To: <7be61ffb-666d-1221-7669-d5d9862d1f73@redhat.com> References: <7be61ffb-666d-1221-7669-d5d9862d1f73@redhat.com> Message-ID: Vote: yes Richard. -----Original Message----- From: announce On Behalf Of Roman Kennke Sent: Dienstag, 16. M?rz 2021 14:31 To: announce at openjdk.java.net Subject: CFV: New Project: Lilliput I hereby propose the creation of the Lilliput Project with Roman Kennke as the Lead and Hotspot as the sponsoring Group(s). Lilliput's primary goal is to explore techniques to downsize Java object headers in the Hotspot JVM from currently 128 bits to 64 bits or even less. This will reduce Java's memory footprint and we expect it to also improve performance across most if not all workloads. Roman Kennke is a long-time OpenJDK contributor. He started contributing to Swing and Java2D in 2007 and co-lead the Caciocavallo project (now de-funct), contributed to Thermostat, and also worked on Zero interpreter and Shark compiler. His primary occupation since 2013 is the Shenandoah GC project, which produced the JEP 304: Garbage Collection Interface and JEP 189: JEP 189: Shenandoah: A Low-Pause-Time Garbage Collector. Suggested initial committers: John Rose, Dave Dice, Andrew Dinn, Andrew Haley, Erik ?sterlund, Aleksey Shipilev, Coleen Phillimore, Stefan Karlsson, Per Liden, Thomas Stuefe, Gil Tene, David Holmes, Kim Barrett, Thomas Schatzl Votes are due by March, 31st, 2021. Only current OpenJDK Members [1] 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 [2]. Roman Kennke [1] https://openjdk.java.net/census#members [2] https://openjdk.java.net/projects/#new-project-vote From john.r.rose at oracle.com Wed Mar 17 16:18:49 2021 From: john.r.rose at oracle.com (John Rose) Date: Wed, 17 Mar 2021 16:18:49 +0000 Subject: CFV: New Project: Lilliput In-Reply-To: <7be61ffb-666d-1221-7669-d5d9862d1f73@redhat.com> References: <7be61ffb-666d-1221-7669-d5d9862d1f73@redhat.com> Message-ID: <25721208-7C48-4629-B9D7-A5F4B35C6795@oracle.com> Vote: yes On Mar 16, 2021, at 6:31 AM, Roman Kennke > wrote: I hereby propose the creation of the Lilliput Project with Roman Kennke as the Lead and Hotspot as the sponsoring Group(s). From rasbold at google.com Wed Mar 17 19:11:02 2021 From: rasbold at google.com (Chuck Rasbold) Date: Wed, 17 Mar 2021 12:11:02 -0700 Subject: CFV: New Project: Lilliput In-Reply-To: <7be61ffb-666d-1221-7669-d5d9862d1f73@redhat.com> References: <7be61ffb-666d-1221-7669-d5d9862d1f73@redhat.com> Message-ID: Vote: yes On Tue, Mar 16, 2021 at 9:48 AM Roman Kennke wrote: > I hereby propose the creation of the Lilliput Project with > Roman Kennke as the Lead and Hotspot as the sponsoring > Group(s). > > Lilliput's primary goal is to explore techniques to downsize Java object > headers in the Hotspot JVM from currently 128 bits to 64 bits or even > less. This will reduce Java's memory footprint and we expect it to also > improve performance across most if not all workloads. > > Roman Kennke is a long-time OpenJDK contributor. He started contributing > to Swing and Java2D in 2007 and co-lead the Caciocavallo project (now > de-funct), contributed to Thermostat, and also worked on Zero > interpreter and Shark compiler. His primary occupation since 2013 is the > Shenandoah GC project, which produced the JEP 304: Garbage Collection > Interface and JEP 189: JEP 189: Shenandoah: A Low-Pause-Time Garbage > Collector. > > Suggested initial committers: John Rose, Dave Dice, Andrew Dinn, Andrew > Haley, Erik ?sterlund, Aleksey Shipilev, Coleen Phillimore, Stefan > Karlsson, Per Liden, Thomas Stuefe, Gil Tene, David Holmes, Kim Barrett, > Thomas Schatzl > > Votes are due by March, 31st, 2021. > > Only current OpenJDK Members [1] 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 [2]. > > Roman Kennke > > [1] https://openjdk.java.net/census#members > [2] https://openjdk.java.net/projects/#new-project-vote > > From mikael.vidstedt at oracle.com Thu Mar 18 05:07:08 2021 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Wed, 17 Mar 2021 22:07:08 -0700 Subject: CFV: New Project: Lilliput In-Reply-To: <7be61ffb-666d-1221-7669-d5d9862d1f73@redhat.com> References: <7be61ffb-666d-1221-7669-d5d9862d1f73@redhat.com> Message-ID: <21EE211F-2AC9-4A1E-B03E-14B1CA575DE5@oracle.com> Vote: yes Cheers, Mikael > On Mar 16, 2021, at 6:31 AM, Roman Kennke wrote: > > I hereby propose the creation of the Lilliput Project with > Roman Kennke as the Lead and Hotspot as the sponsoring > Group(s). > > Lilliput's primary goal is to explore techniques to downsize Java object headers in the Hotspot JVM from currently 128 bits to 64 bits or even less. This will reduce Java's memory footprint and we expect it to also improve performance across most if not all workloads. > > Roman Kennke is a long-time OpenJDK contributor. He started contributing to Swing and Java2D in 2007 and co-lead the Caciocavallo project (now de-funct), contributed to Thermostat, and also worked on Zero interpreter and Shark compiler. His primary occupation since 2013 is the Shenandoah GC project, which produced the JEP 304: Garbage Collection Interface and JEP 189: JEP 189: Shenandoah: A Low-Pause-Time Garbage Collector. > > Suggested initial committers: John Rose, Dave Dice, Andrew Dinn, Andrew Haley, Erik ?sterlund, Aleksey Shipilev, Coleen Phillimore, Stefan Karlsson, Per Liden, Thomas Stuefe, Gil Tene, David Holmes, Kim Barrett, Thomas Schatzl > > Votes are due by March, 31st, 2021. > > Only current OpenJDK Members [1] 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 [2]. > > Roman Kennke > > [1] https://openjdk.java.net/census#members > [2] https://openjdk.java.net/projects/#new-project-vote > From shade at redhat.com Thu Mar 18 07:03:05 2021 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 18 Mar 2021 08:03:05 +0100 Subject: CFV: New Project: Lilliput In-Reply-To: <7be61ffb-666d-1221-7669-d5d9862d1f73@redhat.com> References: <7be61ffb-666d-1221-7669-d5d9862d1f73@redhat.com> Message-ID: Vote: yes. On 3/16/21 2:31 PM, Roman Kennke wrote: > I hereby propose the creation of the Lilliput Project with > Roman Kennke as the Lead and Hotspot as the sponsoring > Group(s). -- Thanks, -Aleksey From stefan.johansson at oracle.com Thu Mar 18 11:02:12 2021 From: stefan.johansson at oracle.com (Stefan Johansson) Date: Thu, 18 Mar 2021 12:02:12 +0100 Subject: CFV: New Project: Lilliput In-Reply-To: <7be61ffb-666d-1221-7669-d5d9862d1f73@redhat.com> References: <7be61ffb-666d-1221-7669-d5d9862d1f73@redhat.com> Message-ID: <6db68753-7bf3-1fb1-5ee2-ab3babde8b0f@oracle.com> Vote: yes On 2021-03-16 14:31, Roman Kennke wrote: > I hereby propose the creation of the Lilliput Project with > Roman Kennke as the Lead and Hotspot as the sponsoring > Group(s). > > Lilliput's primary goal is to explore techniques to downsize Java object > headers in the Hotspot JVM from currently 128 bits to 64 bits or even > less. This will reduce Java's memory footprint and we expect it to also > improve performance across most if not all workloads. > > Roman Kennke is a long-time OpenJDK contributor. He started contributing > to Swing and Java2D in 2007 and co-lead the Caciocavallo project (now > de-funct), contributed to Thermostat, and also worked on Zero > interpreter and Shark compiler. His primary occupation since 2013 is the > Shenandoah GC project, which produced the JEP 304: Garbage Collection > Interface and JEP 189: JEP 189: Shenandoah: A Low-Pause-Time Garbage > Collector. > > Suggested initial committers: John Rose, Dave Dice, Andrew Dinn, Andrew > Haley, Erik ?sterlund, Aleksey Shipilev, Coleen Phillimore, Stefan > Karlsson, Per Liden, Thomas Stuefe, Gil Tene, David Holmes, Kim Barrett, > Thomas Schatzl > > Votes are due by March, 31st, 2021. > > Only current OpenJDK Members [1] 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 [2]. > > Roman Kennke > > [1] https://openjdk.java.net/census#members > [2] https://openjdk.java.net/projects/#new-project-vote > From kim.barrett at oracle.com Sun Mar 21 04:29:57 2021 From: kim.barrett at oracle.com (Kim Barrett) Date: Sun, 21 Mar 2021 04:29:57 +0000 Subject: CFV: New Project: Lilliput In-Reply-To: <7be61ffb-666d-1221-7669-d5d9862d1f73@redhat.com> References: <7be61ffb-666d-1221-7669-d5d9862d1f73@redhat.com> Message-ID: <13E163A6-7605-44BA-899D-20F4BC8D8E7B@oracle.com> vote: yes > On Mar 16, 2021, at 9:31 AM, Roman Kennke wrote: > > I hereby propose the creation of the Lilliput Project with > Roman Kennke as the Lead and Hotspot as the sponsoring > Group(s). > > Lilliput's primary goal is to explore techniques to downsize Java object headers in the Hotspot JVM from currently 128 bits to 64 bits or even less. This will reduce Java's memory footprint and we expect it to also improve performance across most if not all workloads. > > Roman Kennke is a long-time OpenJDK contributor. He started contributing to Swing and Java2D in 2007 and co-lead the Caciocavallo project (now de-funct), contributed to Thermostat, and also worked on Zero interpreter and Shark compiler. His primary occupation since 2013 is the Shenandoah GC project, which produced the JEP 304: Garbage Collection Interface and JEP 189: JEP 189: Shenandoah: A Low-Pause-Time Garbage Collector. > > Suggested initial committers: John Rose, Dave Dice, Andrew Dinn, Andrew Haley, Erik ?sterlund, Aleksey Shipilev, Coleen Phillimore, Stefan Karlsson, Per Liden, Thomas Stuefe, Gil Tene, David Holmes, Kim Barrett, Thomas Schatzl > > Votes are due by March, 31st, 2021. > > Only current OpenJDK Members [1] 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 [2]. > > Roman Kennke > > [1] https://openjdk.java.net/census#members > [2] https://openjdk.java.net/projects/#new-project-vote From per.liden at oracle.com Mon Mar 22 12:40:53 2021 From: per.liden at oracle.com (Per Liden) Date: Mon, 22 Mar 2021 13:40:53 +0100 Subject: CFV: New Project: Lilliput In-Reply-To: <7be61ffb-666d-1221-7669-d5d9862d1f73@redhat.com> References: <7be61ffb-666d-1221-7669-d5d9862d1f73@redhat.com> Message-ID: <8b163e85-8e77-21a2-c5b3-59b1db10686e@oracle.com> Vote: yes /Per On 3/16/21 2:31 PM, Roman Kennke wrote: > I hereby propose the creation of the Lilliput Project with > Roman Kennke as the Lead and Hotspot as the sponsoring > Group(s). > > Lilliput's primary goal is to explore techniques to downsize Java object > headers in the Hotspot JVM from currently 128 bits to 64 bits or even > less. This will reduce Java's memory footprint and we expect it to also > improve performance across most if not all workloads. > > Roman Kennke is a long-time OpenJDK contributor. He started contributing > to Swing and Java2D in 2007 and co-lead the Caciocavallo project (now > de-funct), contributed to Thermostat, and also worked on Zero > interpreter and Shark compiler. His primary occupation since 2013 is the > Shenandoah GC project, which produced the JEP 304: Garbage Collection > Interface and JEP 189: JEP 189: Shenandoah: A Low-Pause-Time Garbage > Collector. > > Suggested initial committers: John Rose, Dave Dice, Andrew Dinn, Andrew > Haley, Erik ?sterlund, Aleksey Shipilev, Coleen Phillimore, Stefan > Karlsson, Per Liden, Thomas Stuefe, Gil Tene, David Holmes, Kim Barrett, > Thomas Schatzl > > Votes are due by March, 31st, 2021. > > Only current OpenJDK Members [1] 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 [2]. > > Roman Kennke > > [1] https://openjdk.java.net/census#members > [2] https://openjdk.java.net/projects/#new-project-vote > From Sergey.Bylokhov at oracle.com Mon Mar 22 22:03:59 2021 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 22 Mar 2021 15:03:59 -0700 Subject: CFV: New Project: Lilliput In-Reply-To: <7be61ffb-666d-1221-7669-d5d9862d1f73@redhat.com> References: <7be61ffb-666d-1221-7669-d5d9862d1f73@redhat.com> Message-ID: Vote: yes On 16.03.2021 06:31, Roman Kennke wrote: > I hereby propose the creation of the Lilliput Project with > Roman Kennke as the Lead and Hotspot as the sponsoring > Group(s). > > Lilliput's primary goal is to explore techniques to downsize Java object headers in the Hotspot JVM from currently 128 bits to 64 bits or even less. This will reduce Java's memory footprint and we expect it to also improve performance across most if not all workloads. > > Roman Kennke is a long-time OpenJDK contributor. He started contributing to Swing and Java2D in 2007 and co-lead the Caciocavallo project (now de-funct), contributed to Thermostat, and also worked on Zero interpreter and Shark compiler. His primary occupation since 2013 is the Shenandoah GC project, which produced the JEP 304: Garbage Collection Interface and JEP 189: JEP 189: Shenandoah: A Low-Pause-Time Garbage Collector. > > Suggested initial committers: John Rose, Dave Dice, Andrew Dinn, Andrew Haley, Erik ?sterlund, Aleksey Shipilev, Coleen Phillimore, Stefan Karlsson, Per Liden, Thomas Stuefe, Gil Tene, David Holmes, Kim Barrett, Thomas Schatzl > > Votes are due by March, 31st, 2021. > > Only current OpenJDK Members [1] 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 [2]. > > Roman Kennke > > [1] https://openjdk.java.net/census#members > [2] https://openjdk.java.net/projects/#new-project-vote > -- Best regards, Sergey. From admin at xakeps.dk Tue Mar 23 08:46:47 2021 From: admin at xakeps.dk (d3coder) Date: Tue, 23 Mar 2021 14:46:47 +0600 Subject: Can't pick right module name Message-ID: <3641882.vc99R8LfB2@arch> I want to add module system support for this library https://github.com/auth0/java-jwt It's published under com.auth0.java-jwt on maven https://mvnrepository.com/artifact/com.auth0/java-jwt According to what i found, https://docs.oracle.com/javase/specs/jls/se16/html/jls-6.html#jls-6.1 right module name would be com.auth0.java_jwt, right? Compiler warns me that module name components can't end with a digit. I'm not sure which module name should i pick com.auth0.java_jwt com.auth0_.java_jwt com.auth_.java_jwt or something else From aph at redhat.com Tue Mar 23 09:48:39 2021 From: aph at redhat.com (Andrew Haley) Date: Tue, 23 Mar 2021 09:48:39 +0000 Subject: CFV: New Project: Lilliput In-Reply-To: <7be61ffb-666d-1221-7669-d5d9862d1f73@redhat.com> References: <7be61ffb-666d-1221-7669-d5d9862d1f73@redhat.com> Message-ID: Vote: yes On 3/16/21 1:31 PM, Roman Kennke wrote: > I hereby propose the creation of the Lilliput Project with > Roman Kennke as the Lead and Hotspot as the sponsoring > Group(s). > > Lilliput's primary goal is to explore techniques to downsize Java object > headers in the Hotspot JVM from currently 128 bits to 64 bits or even > less. This will reduce Java's memory footprint and we expect it to also > improve performance across most if not all workloads. > > Roman Kennke is a long-time OpenJDK contributor. He started contributing > to Swing and Java2D in 2007 and co-lead the Caciocavallo project (now > de-funct), contributed to Thermostat, and also worked on Zero > interpreter and Shark compiler. His primary occupation since 2013 is the > Shenandoah GC project, which produced the JEP 304: Garbage Collection > Interface and JEP 189: JEP 189: Shenandoah: A Low-Pause-Time Garbage > Collector. > > Suggested initial committers: John Rose, Dave Dice, Andrew Dinn, Andrew > Haley, Erik ?sterlund, Aleksey Shipilev, Coleen Phillimore, Stefan > Karlsson, Per Liden, Thomas Stuefe, Gil Tene, David Holmes, Kim Barrett, > Thomas Schatzl > > Votes are due by March, 31st, 2021. > > Only current OpenJDK Members [1] 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 [2]. > > Roman Kennke > > [1] https://openjdk.java.net/census#members > [2] https://openjdk.java.net/projects/#new-project-vote > -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From mp at jugs.org Tue Mar 23 10:40:14 2021 From: mp at jugs.org (Michael Paus) Date: Tue, 23 Mar 2021 11:40:14 +0100 Subject: Can't pick right module name In-Reply-To: <3641882.vc99R8LfB2@arch> References: <3641882.vc99R8LfB2@arch> Message-ID: <0698b636-d9b4-4296-b356-57d6fe2d2ce9@jugs.org> Why not just call it "com.authzero..." ?? Am 23.03.21 um 09:46 schrieb d3coder: > I want to add module system support for this library > https://github.com/auth0/java-jwt > It's published under com.auth0.java-jwt on maven > https://mvnrepository.com/artifact/com.auth0/java-jwt > > According to what i found, > https://docs.oracle.com/javase/specs/jls/se16/html/jls-6.html#jls-6.1 > right module name would be com.auth0.java_jwt, right? > Compiler warns me that module name components can't end with a digit. > I'm not sure which module name should i pick > com.auth0.java_jwt > com.auth0_.java_jwt > com.auth_.java_jwt > or something else > > From Marius at volkhart.com Tue Mar 23 10:57:25 2021 From: Marius at volkhart.com (Marius Volkhart) Date: Tue, 23 Mar 2021 11:57:25 +0100 Subject: Can't pick right module name In-Reply-To: <0698b636-d9b4-4296-b356-57d6fe2d2ce9@jugs.org> References: <3641882.vc99R8LfB2@arch> <0698b636-d9b4-4296-b356-57d6fe2d2ce9@jugs.org> Message-ID: Hi, There was a mailing list discussion about this once. The proposal originally resulted in a compiler error when modules ended with a version. I believe the idea is to dissuade developers from including versions in their module names, the way it often happens with package names like org.apache.commons.collections4. If I recall correctly, the error was reduced to a warning for cases like this, where a brand name ends with a number. I'm having trouble finding the original messages though. -- Cheers, Marius Volkhart On Tue, Mar 23, 2021 at 11:41 AM Michael Paus wrote: > Why not just call it "com.authzero..." ?? > > Am 23.03.21 um 09:46 schrieb d3coder: > > I want to add module system support for this library > > https://github.com/auth0/java-jwt > > It's published under com.auth0.java-jwt on maven > > https://mvnrepository.com/artifact/com.auth0/java-jwt > > > > According to what i found, > > https://docs.oracle.com/javase/specs/jls/se16/html/jls-6.html#jls-6.1 > > right module name would be com.auth0.java_jwt, right? > > Compiler warns me that module name components can't end with a digit. > > I'm not sure which module name should i pick > > com.auth0.java_jwt > > com.auth0_.java_jwt > > com.auth_.java_jwt > > or something else > > > > > > > From Marius at volkhart.com Tue Mar 23 11:02:32 2021 From: Marius at volkhart.com (Marius Volkhart) Date: Tue, 23 Mar 2021 12:02:32 +0100 Subject: Can't pick right module name In-Reply-To: References: <3641882.vc99R8LfB2@arch> <0698b636-d9b4-4296-b356-57d6fe2d2ce9@jugs.org> Message-ID: See http://openjdk.java.net/projects/jigsaw/spec/issues/#VersionsInModuleNames Some further discussion from around the time when this was being developed is available at https://stackoverflow.com/a/41859239/2502247 -- Cheers, Marius Volkhart On Tue, Mar 23, 2021 at 11:57 AM Marius Volkhart wrote: > Hi, > > There was a mailing list discussion about this once. The proposal > originally resulted in a compiler error when modules ended with a version. > I believe the idea is to dissuade developers from including versions in > their module names, the way it often happens with package names like > org.apache.commons.collections4. If I recall correctly, the error was > reduced to a warning for cases like this, where a brand name ends with a > number. > > I'm having trouble finding the original messages though. > > -- > Cheers, > Marius Volkhart > > > > On Tue, Mar 23, 2021 at 11:41 AM Michael Paus wrote: > >> Why not just call it "com.authzero..." ?? >> >> Am 23.03.21 um 09:46 schrieb d3coder: >> > I want to add module system support for this library >> > https://github.com/auth0/java-jwt >> > It's published under com.auth0.java-jwt on maven >> > https://mvnrepository.com/artifact/com.auth0/java-jwt >> > >> > According to what i found, >> > https://docs.oracle.com/javase/specs/jls/se16/html/jls-6.html#jls-6.1 >> > right module name would be com.auth0.java_jwt, right? >> > Compiler warns me that module name components can't end with a digit. >> > I'm not sure which module name should i pick >> > com.auth0.java_jwt >> > com.auth0_.java_jwt >> > com.auth_.java_jwt >> > or something else >> > >> > >> >> >> From rkennke at redhat.com Thu Mar 25 19:12:51 2021 From: rkennke at redhat.com (Roman Kennke) Date: Thu, 25 Mar 2021 20:12:51 +0100 Subject: Call for Discussion: New Project: Lilliput In-Reply-To: <0d396daa-4819-d915-b0e8-f2250370fb4f@redhat.com> References: <0d396daa-4819-d915-b0e8-f2250370fb4f@redhat.com> Message-ID: <96be7e5e-f44f-dfac-f23b-67279f57c562@redhat.com> I wrote down much of my notes here: http://cr.openjdk.java.net/~rkennke/lilliput.md I also did some (somewhat ad-hoc) research about object-sizes, number of hashed/locked objects and some estimates how much improvements we can expect from Lilliput: https://docs.google.com/spreadsheets/d/1ZNvd9YEFza7-UclotNdU7aMm8z9-fpVyBnV9TCbPL8Q/edit?usp=sharing I will upstream the instrumentation code for the JDK to collect this data soon, then everybody can run it on their own workloads. Roman > We would like to propose a new project called Lilliput, with the goal of > exploring ways to shrink the object header. > > Goal: > 1. Reduce the object header to 64 bits. It may be possible to shrink it > down to 32 bits as a secondary goal. > 2. Make the header layout more flexible, i.e. allow some build-time > (possibly even run-time) configuration of how we use the bits. > > Motivation: > In 64-bit Hotspot, Java objects have an object header of 128 bits: a 64 > bit multi-purpose header (?mark? or ?lock?) word and a 64-bit class > pointer. With typical average object sizes of 5-6 words, this is quite > significant: 2 of those words are always taken by the header. If it were > possible to reduce the size of the header, we could significantly reduce > memory pressure, which directly translates to one or more of (depending > what you care about or what your workload does): > > - Reduced heap usage > - Higher object allocation rate > - Reduced GC activity > - Tighter packing of objects -> better cache locality > > In other words, we could reduce the overall CPU and/or memory usage of > all Java workloads, whether it?s a large in-memory database or a small > containerized application. > > > The object header is used (and overloaded) for the following purposes: > > - Locking: the lower 3 bits are used to indicate the locking state of an > object and the higher bits *may* be used to encode a pointer to a > stack-allocated monitor or inflated lock object > - GC: 4 bits are used for tracking the age of each object (in > generational collectors). The whole header *may* be used to store > forwarding information, depending on the collector > - Identity hash-code: Up to 32 bits are used to store the identity > hash-code > - Type information: 64 bits are used to point to the Klass that > describes the object type > > > We have a wide variety of techniques to explore for allocating and > down-sizing header fields: > > - Pointers can be compressed, e.g. if we expect a maximum of, say, 8192 > classes, we could, with some careful alignment of Klass objects, > compress the class pointer down to 13 bits: 2^13=8192 addressable > Klasses. Similar considerations apply to stack pointers and monitors. > - Instead of using pointers, we could use class IDs that index a lookup > table > - We could backfill fields which are known at compile-time (e.g. > alignment gap or hidden fields) > - We could use backfill fields appended to an object after the GC moved > it (e.g. for hashcode) > - We could use side-tables > > > We also have a bewildering number of constraints. To name a few: > - Performance > - If we limit e.g. number of classes/monitors/etc that we can encode, we > need a way to deal with overflow > - Requires changes in assembly across all supported platforms (also > consider 32 bits) > - Interaction with other projects like Panama, Loom, maybe Leyden, etc > > And a couple of opportunities for further work (possibly outside of this > project): > - If we leave arraylength in its own 64-bit field, perhaps we should > consider 64-bit addressable arrays? > - Improvements to hashcode. Maybe salt it to avoid repetition of nursery > objects, maybe expand it to 64 or even 128 bit. > > > I would propose myself as the project lead for Lilliput. :-) > For initial committers I think we need all expertise in runtime and GC > that we can get. From the top of my head I?m thinking of John Rose, Dave > Dice, Andrew Dinn, Andrew Haley, Erik ?sterlund, Aleksey Shipilev, > Coleen Phillimore, Stefan Karlsson, Per Liden. Please suggest anybody > who you think should be involved in this too. (Or yourself if you want > to be in, or if you have no interest in it.) > > > My initial work plan is to: > > - Brainstorm, collect ideas and propose techniques in the Wiki > - Come up with a proof of concept as quickly as possible > ? - Use ZGC: no header usage > ? - Use existing class-pointer compression > ? - Shrink hashcode > - Work from there, decide-as-we-go with insights from previous steps > > > Please let me know what you think! > > Thanks, > Roman From andvasp at gmail.com Tue Mar 30 01:46:30 2021 From: andvasp at gmail.com (Anderson Vasconcelos Pires) Date: Mon, 29 Mar 2021 22:46:30 -0300 Subject: System.Logger API improvements Message-ID: Hi, Java has several libraries for logging (SLF4J, Java.util.logging, Logback, Log4j, Log4j2, FLogger) and I believe We should have a standard for logging like we have for persistence (JPA), Cache (JCache). I recently discovered through this maillist that Java has the System.Logger API. But I think the interface is very limited. It would be good to improve it so developers can adopt it. Would it be possible to improve this api or this api is just for internal jdk use? Could improving it decrease performance? I believe that *FLogger *would be a pretty good example to follow. I tried to find a discussion about this but I did not find one. Thanks, Anderson. From david.holmes at oracle.com Tue Mar 30 01:57:04 2021 From: david.holmes at oracle.com (David Holmes) Date: Tue, 30 Mar 2021 11:57:04 +1000 Subject: System.Logger API improvements In-Reply-To: References: Message-ID: <08c1d961-7f20-97c2-e8fa-1cdc10754fd2@oracle.com> Hi Anderson, Please direct this to core-libs-dev at openjdk.java.net. There is a long history here and I'm certain this has been discussed many times. Thanks, David On 30/03/2021 11:46 am, Anderson Vasconcelos Pires wrote: > Hi, > > Java has several libraries for logging > (SLF4J, Java.util.logging, Logback, Log4j, Log4j2, FLogger) and I believe > We should have a standard for logging like we have for persistence (JPA), > Cache (JCache). > > I recently discovered through this maillist that Java has the System.Logger > API. But I think the interface is very limited. It would be good to improve > it so developers can adopt it. > > Would it be possible to improve this api or this api is just for internal > jdk use? Could improving it decrease performance? I believe that > *FLogger *would > be a pretty good example to follow. > > I tried to find a discussion about this but I did not find one. > > Thanks, > Anderson. > From Alan.Bateman at oracle.com Tue Mar 30 06:07:19 2021 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 30 Mar 2021 07:07:19 +0100 Subject: System.Logger API improvements In-Reply-To: References: Message-ID: <524cb320-ca03-ae29-6517-e5ddfc2f1243@oracle.com> On 30/03/2021 02:46, Anderson Vasconcelos Pires wrote: > Hi, > > Java has several libraries for logging > (SLF4J, Java.util.logging, Logback, Log4j, Log4j2, FLogger) and I believe > We should have a standard for logging like we have for persistence (JPA), > Cache (JCache). > > I recently discovered through this maillist that Java has the System.Logger > API. But I think the interface is very limited. It would be good to improve > it so developers can adopt it. > > Would it be possible to improve this api or this api is just for internal > jdk use? Could improving it decrease performance? I believe that > *FLogger *would > be a pretty good example to follow. > > I tried to find a discussion about this but I did not find one. JEP 264 [1] provides a good description of this API and should help understand why the API is deliberately minimal and intended for platform classes that need to log messages. As David says, use core-libs-dev for follow-up. -Alan [1] http://openjdk.java.net/jeps/264 From amnojeeuw at gmail.com Tue Mar 30 15:33:20 2021 From: amnojeeuw at gmail.com (AmnoJeeuw) Date: Tue, 30 Mar 2021 11:33:20 -0400 Subject: Eclipse and JavaFX - Runnable Jar not running Message-ID: <4d9c53ef-57d2-36be-1e69-2d21c19258d2@gmail.com> I am trying to deploy a runnable jar for my JavaFX project, but after a long research I have not been able to do so. Can anybody suggest a link that shows hot to do create a JavaFX 15.0.1 runnable jar file under Eclipse. This problem did not exist when using JavaFX 8.x, but now the runnable just does not run, what am I doing wrong? I have seen some YouTube videos that show how to successfully do this, but they are using IntelliJ, I would rather not switch to IntelliJ 'cos I am fun of Eclipse. However, if switching to IntelliJ is the only solution, I'd do so. Please see attached file for error report. Thanks in advance -- Does anyone know why JavaFX-9+ jar files are not runnable nowadays? -- This email has been checked for viruses by AVG. https://www.avg.com -------------- next part -------------- Graphics Device initialization failed for : d3d, sw Error initializing QuantumRenderer: no suitable pipeline found java.lang.RuntimeException: java.lang.RuntimeException: Error initializing QuantumRenderer: no suitable pipeline found at com.sun.javafx.tk.quantum.QuantumRenderer.getInstance(QuantumRenderer.java:280) at com.sun.javafx.tk.quantum.QuantumToolkit.init(QuantumToolkit.java:244) at com.sun.javafx.tk.Toolkit.getToolkit(Toolkit.java:261) at com.sun.javafx.application.PlatformImpl.startup(PlatformImpl.java:267) at com.sun.javafx.application.PlatformImpl.startup(PlatformImpl.java:158) at com.sun.javafx.application.LauncherImpl.startToolkit(LauncherImpl.java:658) at com.sun.javafx.application.LauncherImpl.launchApplication1(LauncherImpl.java:678) at com.sun.javafx.application.LauncherImpl.lambda$launchApplication$2(LauncherImpl.java:195) at java.base/java.lang.Thread.run(Thread.java:832) Caused by: java.lang.RuntimeException: Error initializing QuantumRenderer: no suitable pipeline found at com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.init(QuantumRenderer.java:94) at com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:124) ... 1 more Exception in thread "main" java.lang.reflect.InvocationTargetException at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:564) at org.eclipse.jdt.internal.jarinjarloader.JarRsrcLoader.main(JarRsrcLoader.java:61) Caused by: java.lang.RuntimeException: No toolkit found at com.sun.javafx.tk.Toolkit.getToolkit(Toolkit.java:273) at com.sun.javafx.application.PlatformImpl.startup(PlatformImpl.java:267) at com.sun.javafx.application.PlatformImpl.startup(PlatformImpl.java:158) at com.sun.javafx.application.LauncherImpl.startToolkit(LauncherImpl.java:658) at com.sun.javafx.application.LauncherImpl.launchApplication1(LauncherImpl.java:678) at com.sun.javafx.application.LauncherImpl.lambda$launchApplication$2(LauncherImpl.java:195) at java.base/java.lang.Thread.run(Thread.java:832) From Alan.Bateman at oracle.com Tue Mar 30 15:44:30 2021 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 30 Mar 2021 16:44:30 +0100 Subject: Eclipse and JavaFX - Runnable Jar not running In-Reply-To: <4d9c53ef-57d2-36be-1e69-2d21c19258d2@gmail.com> References: <4d9c53ef-57d2-36be-1e69-2d21c19258d2@gmail.com> Message-ID: On 30/03/2021 16:33, AmnoJeeuw wrote: > I am trying to deploy a runnable jar for my JavaFX project, but after > a long research I have not been able to do so. Can anybody suggest a > link that shows hot to do create a JavaFX 15.0.1 runnable jar file > under Eclipse. > This problem did not exist when using JavaFX 8.x, but now the runnable > just does not run, what am I doing wrong? > > I have seen some YouTube videos that show how to successfully do this, > but they are using IntelliJ, I would rather not switch to IntelliJ > 'cos I am fun of Eclipse. However, if switching to IntelliJ is the > only solution, I'd do so. > > Please see attached file for error report. If the stack trace is to believed then it looks like the JavaFX classes are being loaded from the class path. I think the more recent JavaFX release has code to detect that. In any case, it would be better to this to the JavaFX or Eclipse mailing lists as I don't think this is a JDK issue. -Alan. From kevin.rushforth at oracle.com Tue Mar 30 15:49:22 2021 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 30 Mar 2021 08:49:22 -0700 Subject: Eclipse and JavaFX - Runnable Jar not running In-Reply-To: References: <4d9c53ef-57d2-36be-1e69-2d21c19258d2@gmail.com> Message-ID: <90cc924d-b995-1a65-f4da-5c92b129cbff@oracle.com> I'll second Alan's point about redirecting this to a different mailing list. The only thing I'll add is that the exception suggests that the native JavaFX libraries cannot be found. -- Kevin On 3/30/2021 8:44 AM, Alan Bateman wrote: > On 30/03/2021 16:33, AmnoJeeuw wrote: >> I am trying to deploy a runnable jar for my JavaFX project, but after >> a long research I have not been able to do so. Can anybody suggest a >> link that shows hot to do create a JavaFX 15.0.1 runnable jar file >> under Eclipse. >> This problem did not exist when using JavaFX 8.x, but now the >> runnable just does not run, what am I doing wrong? >> >> I have seen some YouTube videos that show how to successfully do >> this, but they are using IntelliJ, I would rather not switch to >> IntelliJ 'cos I am fun of Eclipse. However, if switching to IntelliJ >> is the only solution, I'd do so. >> >> Please see attached file for error report. > > If the stack trace is to believed then it looks like the JavaFX > classes are being loaded from the class path. I think the more recent > JavaFX release has code to detect that. In any case, it would be > better to this to the JavaFX or Eclipse mailing lists as I don't think > this is a JDK issue. > > -Alan.