From magnus.ihse.bursie at oracle.com Mon Jun 1 09:55:40 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 01 Jun 2015 11:55:40 +0200 Subject: RFR(S): 8081037: serviceability/sa/ tests time out on Windows In-Reply-To: <556729F0.70703@oracle.com> References: <5565C048.4050801@oracle.com> <556729F0.70703@oracle.com> Message-ID: <556C2C1C.50900@oracle.com> On 2015-05-28 16:45, Yekaterina Kantserova wrote: > Hi, > > due to https://bugs.openjdk.java.net/browse/JDK-8081381 I wasn't able > to push this fix. The problem is LingeredApp.java contains JDK 9 > feature java.lang.Process.getPid() but the test library is compiled > with JDK 8 today. This issue is not trivial to solve so I suggest a > temporary fix to test/lib/Makefile. > > webrev root: http://cr.openjdk.java.net/~ykantser/8081037/webrev.01 The temporary fix looks good from a build perspective, I guess, as long as you're satisfied with the lib including just the files in hprof. It looks like https://bugs.openjdk.java.net/browse/JDK-8081381 is in the intersection between hotspot testing and the build infrastructure. Please keep us in the loop when discussion solutions to that. /Magnus > > Thanks, > Katja > > > > On 05/27/2015 03:02 PM, Yekaterina Kantserova wrote: >> Hi, >> >> Could I please have a review of this fix. >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8081037 >> webrev root: http://cr.openjdk.java.net/~ykantser/8081037/webrev.00 >> webrev jdk: http://cr.openjdk.java.net/~ykantser/8081037.jdk/webrev.00 >> webrev hotspot: >> http://cr.openjdk.java.net/~ykantser/8081037.hotspot/webrev.00 >> >> From the bug: >> "The problem is most likely that SA will pause the target process >> while it is running. In this case, the target process is the same as >> the process that launched SA. That process is also handling the >> output from SA over a pipe, but when that pipe fills up the process >> cannot empty it and the SA process is blocked because it cannot write >> any more output. Deadlock." >> >> The solutions is to start a separate target process. Dmitry Samersoff >> has already created a test application for such cases so I've decided >> to move it on the top level library instead of duplicating it. The >> test application will reside under >> test/lib/share/classes/jdk/test/lib/apps and the test under >> test/lib-test/jdk/test/lib/apps. >> >> Thanks, >> Katja > From ben at jclarity.com Mon Jun 1 10:36:47 2015 From: ben at jclarity.com (Ben Evans) Date: Mon, 1 Jun 2015 11:36:47 +0100 Subject: JEP 248: Make G1 the Default Garbage Collector In-Reply-To: <55423444.7040009@beckwithclan.com> References: <20150428220211.4355960845@eggemoggin.niobe.net> <5C5564BB-23ED-49AB-81C6-CFF85B56ACA4@kodewerk.com> <5540D689.6020407@oracle.com> <73855087-8BB2-4A8C-B9AD-080CD39FAB7A@kodewerk.com> <55423444.7040009@beckwithclan.com> Message-ID: Hi, I'm somewhat late to this, having missed the original discussion whilst travelling. Mark targeted this JEP to JDK 9 but has since put that on hold to allow more discussion. I made this comment to Mark on jdk9-dev: "I have been working with G1 for ~5 years, ever since it was experimental (& highly crash-prone in JDK 6). In the intervening time, I have seen dozens (if not hundreds) of installations, across a wide range of customers. I have participated in, or been consulted on at least a dozen direct trials of GC alternatives. It is only in the last 18 months that I have seen *any* real-life workload on G1 beat the alternatives, and only in the last 12 months that I've had any customer prepared to go live with G1 in production. >From my experience, I think that G1 is a fine collector, with a bright future that should be pursued. However, I haven't seen anything that would make a switch to it as default collector seem compelling in the JDK 9 timeframe. Obviously, my experience is not universal, so I'd like to ask you / Oracle: 1) Can you explain the survey methodology and customer testing that you performed to arrive at the conclusion that G1 is ready to become default? 2) Can you share aggregate results of the surveying ("We worked with X customers and ran Y tests of G1 vs alternatives, and in Z% of cases, G1 worked better by W margin")? 3) Can you ask some of the customers you worked with to speak publicly about the trials you ran with them?" >From reading this thread, am I right to conclude that no formal study of this issue has been done? If that's the case, then are we really happy to make G1 default without some more systematic efforts and attempts to obtain actual numbers? The questions that I'd like to see answered are: a) How short a pause time can G1 support being tuned to? 50ms? 20? Personally, I haven't seen it getting close to CMS in terms of STW time. b) What is the impact on throughput due to G1? I do like G1 as a collector, but can we really organise enough field tests in the pre-9 timeframe to justify such a large and potentially breaking change? We managed to do some good community compatibility testing for JDK 8, and we could think about a similar effort for "make G1 default". However, with modules, HTTP/2 and JShell all happening for 9, I question whether there is simply enough community bandwidth to do a decent effort for G1 as well, whereas, if we were targeting JDK 10 we'd have a lot more time to plan and to try to improve the quality and range of the field data to hopefully de-risk a potential large, high-profile failure. Thanks, Ben On Thu, Apr 30, 2015 at 2:55 PM, Monica Beckwith wrote: > I am also FOR the change in the default GC. Charlie and Mattis bring up > great points. It's about time G1 gets put out there (as the default GC) > since most of the development work is going into G1. As for documentation, > we not only need to document the change in the default collector but also > the defaults for the collector; that are enabled as soon as G1 is employed - > e.g. MaxGCPauseMillis, IHOP, etc. > > With more and more input coming in, G1 is only going to get better and > hopefully more adaptive :) > > And as for Charlie's question - I don't remember the last time that I didn't > see an explicit GC mentioned on the command line (even if it was the default > GC). > > These are just my two cents. > > -Monica > > > On 4/30/15 8:17 AM, charlie hunt wrote: >> >> Fwiw, we should not forget that anyone who is currently specifying an >> explicit GC to use in his or her JVM command line args will not experience >> any difference in behavior. They will still get the collector they specify >> to use. The (potential) impact will be on those who do not specify a GC to >> use. >> >> What I would like to hear from Kirk and others who frequently work with >> customers on GC, what?s the percentage of Java applications they have worked >> with that do not explicitly specify a GC? And, of those, what percentage of >> those apps fall into the categories of small heap and desire low latency, or >> desire high throughput even at the cost of frequent full GCs? >> >> thanks, >> >> charlie >> >>> On Apr 30, 2015, at 7:27 AM, Mattis Castegren >>> wrote: >>> >>> Hi. >>> >>> I also work with customers but I would like to give an argument FOR >>> changing the default. >>> >>> I don't think we will ever come to a point where G1 is better for ALL >>> users. Even with a near perfect G1 implementation there may be cases where >>> the parallel collector gives better throughput. >>> >>> Right now, I think G1 will be better for most users. There are probably >>> also corner cases where G1 COULD be better, but where small issues reduces >>> performance. By changing the default to G1, we will be able to easier find >>> these as we will expose more users to G1. >>> >>> Finally, there will be a set of users who only care about throughput, and >>> who will see a performance regression. In those cases, they can go back to >>> using parallel. But hopefully, there will be far fewer users who need to >>> tune their application to run with parallel GC than there are users who have >>> to (or should) tune their application to run with G1. >>> >>> In the case of huge, business critical, applications, we will always >>> introduce a risk by changing default collectors. This is true if we change >>> to G1 in JDK 9, 10 or 11. I prefer to just rip the band aid off. We know >>> that the collector we will focus on going forward is G1, so we should let as >>> many people use it as possible. >>> >>> Of course we should document this a lot, so that users who go up to JDK 9 >>> and see performance regressions can at least try to run with Parallel to see >>> if it is due to the GC. >>> >>> Kind Regards >>> /Mattis >>> >>> -----Original Message----- >>> From: Kirk Pepperdine [mailto:kirk at kodewerk.com] >>> Sent: den 30 april 2015 13:18 >>> To: Stefan Johansson >>> Cc: hotspot-dev at openjdk.java.net Source Developers >>> Subject: Re: JEP 248: Make G1 the Default Garbage Collector >>> >>> Hi Stefan, >>> >>> Indeed, the improvements have been amazing. I have been getting many >>> clients to bench with it and although the results have been mixed, overall >>> many have been able to move forward. However I still would not recommend G1 >>> to anyone who can't move to 1.8.0_40. Of course this change will obviously >>> come post _40 but still, the recent emergence of the G1 as a viable >>> production ready collector suggests that making it a default maybe a wee bit >>> optimistic. >>> >>> The change is based on the assumption that limiting latency is often more >>> important than maximizing throughput. If this assumption is incorrect then >>> this change might need to be reconsidered. >>> >>> I would agree with this assumption. In most cases latency is more >>> important. However G1 doesn't always provide lowest latency especially in >>> smaller heaps. >>> >>> >>> G1 is seen as a robust and well-tested collector. It is not expected to >>> have stability problems, but becoming the default collector will increase >>> its visibility and may reveal previously-unknown issues. >>> I not sure it's prudent to treat the entire Java eco-system as guinea >>> pigs. I believe it's more prudent to have the willing take that first step >>> rather than have it unwittingly dropped on everyone >>> >>> >>> >>> At the end of the day, I don't have any say in any of this (as it should >>> be). All I can do is let you know what I'm seeing through my straw with the >>> hope that you'll find the information useful. From what I see, there is not >>> nearly enough experience in the tuning the G1 in that is especially true in >>> the general population to make this type of change at this point in time. >>> I'm also not sure that we have all the tuning options we need to ensure >>> "happy apps" in the wild. For example, I think the incremental accumulated >>> waste in tenured regions is a problem that I'm not sure we have the tools to >>> solve. I'm not even sure if it's a recognized problem. In fact I'm not even >>> sure it's a real problem as at the moment it's only a theory based on >>> observations I'm making by looking at numbers of GC logs produced by >>> applications using recent releases of the G1. >>> >>> I would suggest that for Tiered the default config for 8 is was also a >>> bit premature. I've had to have a number of clients have to roll back off of >>> it. >>> >>> - Kirk >>> >>> On Apr 29, 2015, at 3:03 PM, Stefan Johansson >>> wrote: >>> >>>> Hi Kirk, >>>> >>>> A lot of effort is put into G1, it has been continuously improving over >>>> the last couple of years and we now believe that G1 is ready to become the >>>> default. G1 will not improve all use case, but the same is true for the >>>> other collectors. For users where throughput is the main concern, Parallel >>>> GC can still be used by specifying -XX:+UseParallelGC on the command-line. >>>> >>>> Regards, >>>> Stefan >>>> >>>> On 2015-04-29 09:10, Kirk Pepperdine wrote: >>>>> >>>>> Hi all, >>>>> >>>>> Is the G1 ready for this? I see many people moving to G1 but also I'm >>>>> not sure that we've got the tunable correct. I've been sorting through a >>>>> number of recent tuning engagements and my conclusion is that I would like >>>>> the collector to be aggressive about collecting tenured regions at the >>>>> beginning of a JVM's life time but then become less aggressive over time. >>>>> The reason is the residual waste that I see left behind because certain >>>>> regions never hit the threshold needed to be included in the CSET. But, on >>>>> aggregate, the number of regions in this state does start to retain a >>>>> significant about of dead data. The only way to see the effects is to run >>>>> regular Full GCs.. which of course you don't really want to do. However, the >>>>> problem seems to settle down a wee bit over time which is why I was thinking >>>>> that being aggressive about what is collected in the early stages of a JVMs >>>>> life should lead to better packing and hence less waste. >>>>> >>>>> Note, I don't really care about the memory waste, only it's effect on >>>>> cycle frequencies and pause times. >>>>> >>>>> Sorry but I don't have anything formal about this as I (and I believe >>>>> many others) are still sorting out what to make of the G1 in prod. Generally >>>>> the overall results are good but sometimes it's not that way up front and >>>>> how to improve things is sometimes challenging. >>>>> >>>>> On a side note, the move to Tiered in 8 has also caused a bit of grief. >>>>> Metaspace has caused a bit of grief and even parallelStream, which works, >>>>> has come with some interesting side effect. Everyone has been so enamored >>>>> with Lambdas (rightfully so) that the other stuff has been completely >>>>> forgotten and some of it has surprised people. I guess I'll be submitting a >>>>> talk for J1 on some of the field experience I've had with the other stuff. >>>>> >>>>> Regards, >>>>> Kirk >>>>> >>>>> >>>>> On Apr 28, 2015, at 11:02 PM, mark.reinhold at oracle.com wrote: >>>>> >>>>>> New JEP Candidate: http://openjdk.java.net/jeps/248 >>>>>> >>>>>> - Mark >>>> >>>> > > -- Ben Evans, Co-founder jClarity @jclarity From vitalyd at gmail.com Mon Jun 1 13:05:48 2015 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Mon, 1 Jun 2015 09:05:48 -0400 Subject: JEP 248: Make G1 the Default Garbage Collector In-Reply-To: References: <20150428220211.4355960845@eggemoggin.niobe.net> <5C5564BB-23ED-49AB-81C6-CFF85B56ACA4@kodewerk.com> <5540D689.6020407@oracle.com> <73855087-8BB2-4A8C-B9AD-080CD39FAB7A@kodewerk.com> <55423444.7040009@beckwithclan.com> Message-ID: Ben, The customers using CMS won't be impacted since they're explicitly specifying the GC. Java 9 will already require extensive testing for people, and GC performance is luckily one of the more introspectable facilities. Furthermore, people who are keen on staying with the default collector should/can lock that in before moving to Java 9 since presumably there will be enough visibility of this change in release notes and such. Personally, I find changing default JIT compilation policy to tiered in java 8 a more risky change, but I don't recall seeing such fervor around it :). sent from my phone On Jun 1, 2015 6:37 AM, "Ben Evans" wrote: > Hi, > > I'm somewhat late to this, having missed the original discussion > whilst travelling. > > Mark targeted this JEP to JDK 9 but has since put that on hold to > allow more discussion. > > I made this comment to Mark on jdk9-dev: > > "I have been working with G1 for ~5 years, ever since it was > experimental (& highly crash-prone in JDK 6). > > In the intervening time, I have seen dozens (if not hundreds) of > installations, across a wide range of customers. I have participated > in, or been consulted on at least a dozen direct trials of GC > alternatives. > > It is only in the last 18 months that I have seen *any* real-life > workload on G1 beat the alternatives, and only in the last 12 months > that I've had any customer prepared to go live with G1 in production. > > From my experience, I think that G1 is a fine collector, with a bright > future that should be pursued. However, I haven't seen anything that > would make a switch to it as default collector seem compelling in the > JDK 9 timeframe. > > Obviously, my experience is not universal, so I'd like to ask you / Oracle: > > 1) Can you explain the survey methodology and customer testing that > you performed to arrive at the conclusion that G1 is ready to become > default? > > 2) Can you share aggregate results of the surveying ("We worked with X > customers and ran Y tests of G1 vs alternatives, and in Z% of cases, > G1 worked better by W margin")? > > 3) Can you ask some of the customers you worked with to speak publicly > about the trials you ran with them?" > > From reading this thread, am I right to conclude that no formal study > of this issue has been done? > > If that's the case, then are we really happy to make G1 default > without some more systematic efforts and attempts to obtain actual > numbers? > > The questions that I'd like to see answered are: > > a) How short a pause time can G1 support being tuned to? 50ms? 20? > Personally, I haven't seen it getting close to CMS in terms of STW > time. > > b) What is the impact on throughput due to G1? > > I do like G1 as a collector, but can we really organise enough field > tests in the pre-9 timeframe to justify such a large and potentially > breaking change? We managed to do some good community compatibility > testing for JDK 8, and we could think about a similar effort for "make > G1 default". However, with modules, HTTP/2 and JShell all happening > for 9, I question whether there is simply enough community bandwidth > to do a decent effort for G1 as well, whereas, if we were targeting > JDK 10 we'd have a lot more time to plan and to try to improve the > quality and range of the field data to hopefully de-risk a potential > large, high-profile failure. > > Thanks, > > Ben > > > > > > > > > On Thu, Apr 30, 2015 at 2:55 PM, Monica Beckwith > wrote: > > I am also FOR the change in the default GC. Charlie and Mattis bring up > > great points. It's about time G1 gets put out there (as the default GC) > > since most of the development work is going into G1. As for > documentation, > > we not only need to document the change in the default collector but also > > the defaults for the collector; that are enabled as soon as G1 is > employed - > > e.g. MaxGCPauseMillis, IHOP, etc. > > > > With more and more input coming in, G1 is only going to get better and > > hopefully more adaptive :) > > > > And as for Charlie's question - I don't remember the last time that I > didn't > > see an explicit GC mentioned on the command line (even if it was the > default > > GC). > > > > These are just my two cents. > > > > -Monica > > > > > > On 4/30/15 8:17 AM, charlie hunt wrote: > >> > >> Fwiw, we should not forget that anyone who is currently specifying an > >> explicit GC to use in his or her JVM command line args will not > experience > >> any difference in behavior. They will still get the collector they > specify > >> to use. The (potential) impact will be on those who do not specify a GC > to > >> use. > >> > >> What I would like to hear from Kirk and others who frequently work with > >> customers on GC, what?s the percentage of Java applications they have > worked > >> with that do not explicitly specify a GC? And, of those, what > percentage of > >> those apps fall into the categories of small heap and desire low > latency, or > >> desire high throughput even at the cost of frequent full GCs? > >> > >> thanks, > >> > >> charlie > >> > >>> On Apr 30, 2015, at 7:27 AM, Mattis Castegren > >>> wrote: > >>> > >>> Hi. > >>> > >>> I also work with customers but I would like to give an argument FOR > >>> changing the default. > >>> > >>> I don't think we will ever come to a point where G1 is better for ALL > >>> users. Even with a near perfect G1 implementation there may be cases > where > >>> the parallel collector gives better throughput. > >>> > >>> Right now, I think G1 will be better for most users. There are probably > >>> also corner cases where G1 COULD be better, but where small issues > reduces > >>> performance. By changing the default to G1, we will be able to easier > find > >>> these as we will expose more users to G1. > >>> > >>> Finally, there will be a set of users who only care about throughput, > and > >>> who will see a performance regression. In those cases, they can go > back to > >>> using parallel. But hopefully, there will be far fewer users who need > to > >>> tune their application to run with parallel GC than there are users > who have > >>> to (or should) tune their application to run with G1. > >>> > >>> In the case of huge, business critical, applications, we will always > >>> introduce a risk by changing default collectors. This is true if we > change > >>> to G1 in JDK 9, 10 or 11. I prefer to just rip the band aid off. We > know > >>> that the collector we will focus on going forward is G1, so we should > let as > >>> many people use it as possible. > >>> > >>> Of course we should document this a lot, so that users who go up to > JDK 9 > >>> and see performance regressions can at least try to run with Parallel > to see > >>> if it is due to the GC. > >>> > >>> Kind Regards > >>> /Mattis > >>> > >>> -----Original Message----- > >>> From: Kirk Pepperdine [mailto:kirk at kodewerk.com] > >>> Sent: den 30 april 2015 13:18 > >>> To: Stefan Johansson > >>> Cc: hotspot-dev at openjdk.java.net Source Developers > >>> Subject: Re: JEP 248: Make G1 the Default Garbage Collector > >>> > >>> Hi Stefan, > >>> > >>> Indeed, the improvements have been amazing. I have been getting many > >>> clients to bench with it and although the results have been mixed, > overall > >>> many have been able to move forward. However I still would not > recommend G1 > >>> to anyone who can't move to 1.8.0_40. Of course this change will > obviously > >>> come post _40 but still, the recent emergence of the G1 as a viable > >>> production ready collector suggests that making it a default maybe a > wee bit > >>> optimistic. > >>> > >>> The change is based on the assumption that limiting latency is often > more > >>> important than maximizing throughput. If this assumption is incorrect > then > >>> this change might need to be reconsidered. > >>> > >>> I would agree with this assumption. In most cases latency is more > >>> important. However G1 doesn't always provide lowest latency especially > in > >>> smaller heaps. > >>> > >>> > >>> G1 is seen as a robust and well-tested collector. It is not expected to > >>> have stability problems, but becoming the default collector will > increase > >>> its visibility and may reveal previously-unknown issues. > >>> I not sure it's prudent to treat the entire Java eco-system as guinea > >>> pigs. I believe it's more prudent to have the willing take that first > step > >>> rather than have it unwittingly dropped on everyone > >>> > >>> > >>> > >>> At the end of the day, I don't have any say in any of this (as it > should > >>> be). All I can do is let you know what I'm seeing through my straw > with the > >>> hope that you'll find the information useful. From what I see, there > is not > >>> nearly enough experience in the tuning the G1 in that is especially > true in > >>> the general population to make this type of change at this point in > time. > >>> I'm also not sure that we have all the tuning options we need to ensure > >>> "happy apps" in the wild. For example, I think the incremental > accumulated > >>> waste in tenured regions is a problem that I'm not sure we have the > tools to > >>> solve. I'm not even sure if it's a recognized problem. In fact I'm not > even > >>> sure it's a real problem as at the moment it's only a theory based on > >>> observations I'm making by looking at numbers of GC logs produced by > >>> applications using recent releases of the G1. > >>> > >>> I would suggest that for Tiered the default config for 8 is was also a > >>> bit premature. I've had to have a number of clients have to roll back > off of > >>> it. > >>> > >>> - Kirk > >>> > >>> On Apr 29, 2015, at 3:03 PM, Stefan Johansson > >>> wrote: > >>> > >>>> Hi Kirk, > >>>> > >>>> A lot of effort is put into G1, it has been continuously improving > over > >>>> the last couple of years and we now believe that G1 is ready to > become the > >>>> default. G1 will not improve all use case, but the same is true for > the > >>>> other collectors. For users where throughput is the main concern, > Parallel > >>>> GC can still be used by specifying -XX:+UseParallelGC on the > command-line. > >>>> > >>>> Regards, > >>>> Stefan > >>>> > >>>> On 2015-04-29 09:10, Kirk Pepperdine wrote: > >>>>> > >>>>> Hi all, > >>>>> > >>>>> Is the G1 ready for this? I see many people moving to G1 but also I'm > >>>>> not sure that we've got the tunable correct. I've been sorting > through a > >>>>> number of recent tuning engagements and my conclusion is that I > would like > >>>>> the collector to be aggressive about collecting tenured regions at > the > >>>>> beginning of a JVM's life time but then become less aggressive over > time. > >>>>> The reason is the residual waste that I see left behind because > certain > >>>>> regions never hit the threshold needed to be included in the CSET. > But, on > >>>>> aggregate, the number of regions in this state does start to retain a > >>>>> significant about of dead data. The only way to see the effects is > to run > >>>>> regular Full GCs.. which of course you don't really want to do. > However, the > >>>>> problem seems to settle down a wee bit over time which is why I was > thinking > >>>>> that being aggressive about what is collected in the early stages of > a JVMs > >>>>> life should lead to better packing and hence less waste. > >>>>> > >>>>> Note, I don't really care about the memory waste, only it's effect on > >>>>> cycle frequencies and pause times. > >>>>> > >>>>> Sorry but I don't have anything formal about this as I (and I believe > >>>>> many others) are still sorting out what to make of the G1 in prod. > Generally > >>>>> the overall results are good but sometimes it's not that way up > front and > >>>>> how to improve things is sometimes challenging. > >>>>> > >>>>> On a side note, the move to Tiered in 8 has also caused a bit of > grief. > >>>>> Metaspace has caused a bit of grief and even parallelStream, which > works, > >>>>> has come with some interesting side effect. Everyone has been so > enamored > >>>>> with Lambdas (rightfully so) that the other stuff has been completely > >>>>> forgotten and some of it has surprised people. I guess I'll be > submitting a > >>>>> talk for J1 on some of the field experience I've had with the other > stuff. > >>>>> > >>>>> Regards, > >>>>> Kirk > >>>>> > >>>>> > >>>>> On Apr 28, 2015, at 11:02 PM, mark.reinhold at oracle.com wrote: > >>>>> > >>>>>> New JEP Candidate: http://openjdk.java.net/jeps/248 > >>>>>> > >>>>>> - Mark > >>>> > >>>> > > > > > > > > -- > Ben Evans, Co-founder jClarity @jclarity > From ben at jclarity.com Mon Jun 1 14:42:36 2015 From: ben at jclarity.com (Ben Evans) Date: Mon, 1 Jun 2015 15:42:36 +0100 Subject: JEP 248: Make G1 the Default Garbage Collector In-Reply-To: References: <20150428220211.4355960845@eggemoggin.niobe.net> <5C5564BB-23ED-49AB-81C6-CFF85B56ACA4@kodewerk.com> <5540D689.6020407@oracle.com> <73855087-8BB2-4A8C-B9AD-080CD39FAB7A@kodewerk.com> <55423444.7040009@beckwithclan.com> Message-ID: Hi Vitaly, (I've added hotspot-dev back on to the To: line as I think it's important this discussion is had in public). In general, Mark has outlined a design philosophy for the platform that is conservative, and where, if features are not ready, then they are slipped to the next major release. Features shouldn't be rushed or releases delayed, instead production quality features should be shipped when done. So, to my mind, this issue comes down to whether the proposed benefit is such that it outweighs the risks of changing the behaviour of millions upon millions of installations. We don't have any systematic data (which I argue should be a huge red flag in itself), and the experience of consultants and performance engineers, including Kirk and myself, is not exactly encouraging. So, does this change really justify the risk? I would also question the conclusion that all we can organise before Java 10 is: "some reports from the field". For Java 8, the community was able to engage with a pretty good group of F/OSS libraries & help them to test on betas of 8, so they (& their users) could have confidence that they would "just work" with 8 straight out of the box. I see no reason why a similar approach could not work for G1 becoming default - we can approach relevant partners in the ecosystem (e.g. Cloudbees, Blazemeter, etc) and see if they can help, and we can directly reach out and get people testing with G1. However, there is an issue of timing and available resources here - there's a lot going on for JDK 9 as it is, and I don't know how easy it would be to get this programme running as well. Finally, the other issue that I'd like to address is that of scope creep. I'd always been under the impression that G1 was thought of as the CMS replacement. However, (and admittedly a lot of the systems I see are either financial or gaming) in its current state there is no way that G1 is a general replacement for CMS. The pauses for G1 are simply too long for a big class of low-latency systems. Instead, G1 is now being talked of as a replacement for the default collector. If that's the case, then I think we need to acknowledge it, and have a conversation about where G1 is actually supposed to be used. Are we saying we want a "reasonably high throughput with reduced STW, but not low pause time" collector? If we are, that's fine, but that's not where we started. Thanks, Ben On Mon, Jun 1, 2015 at 3:05 PM, Vitaly Davidovich wrote: > Kirk, > > I don't dispute that some people aren't tuning/touching the GC controls, and > may get negatively impacted (but perhaps positively too). My main point, > however, is I don't see waiting until java 10 as adding sufficient safety > guards; certainly there will be more lab time and benchmarking at oracle, > some reports from the field but inevitably there will be unknown workloads > in the wild that still don't work well even after more "due diligence". If > G1 is truly the successor to CMS, kicking the can further down the road > isn't helping achieve that. Anyone seeing a regression has an easy way to > opt out. Any such change will always weed out some outliers, java 9, 10 or > 15. The longer we wait, the harder it may be to fix some of them. > > sent from my phone > > On Jun 1, 2015 9:43 AM, "Kirk Pepperdine" wrote: >> >> Hi Vitaly, >> >> Ben has only re-iterated what I?ve already said but in a more concise way. >> And, I don?t mean to be insulting but I don?t really buy into the argument >> that people will be specifying a collector anyways because there are still a >> significant number that use the parallel collector. In fact, just today, I >> recommended that someone move away from G1 to the parallel collector as that >> use case clearly favored the recommendation. >> >> And I should add, I?ve now backed a number of deployments off of >> tiered-compilation as IME it is impacting performance in a negative way. >> >> Regards, >> Kirk >> >> On Jun 1, 2015, at 3:05 PM, Vitaly Davidovich wrote: >> >> > Ben, >> > >> > The customers using CMS won't be impacted since they're explicitly >> > specifying the GC. Java 9 will already require extensive testing for >> > people, and GC performance is luckily one of the more introspectable >> > facilities. Furthermore, people who are keen on staying with the >> > default >> > collector should/can lock that in before moving to Java 9 since >> > presumably >> > there will be enough visibility of this change in release notes and >> > such. >> > >> > Personally, I find changing default JIT compilation policy to tiered in >> > java 8 a more risky change, but I don't recall seeing such fervor around >> > it >> > :). >> > >> > sent from my phone >> > On Jun 1, 2015 6:37 AM, "Ben Evans" wrote: >> > >> >> Hi, >> >> >> >> I'm somewhat late to this, having missed the original discussion >> >> whilst travelling. >> >> >> >> Mark targeted this JEP to JDK 9 but has since put that on hold to >> >> allow more discussion. >> >> >> >> I made this comment to Mark on jdk9-dev: >> >> >> >> "I have been working with G1 for ~5 years, ever since it was >> >> experimental (& highly crash-prone in JDK 6). >> >> >> >> In the intervening time, I have seen dozens (if not hundreds) of >> >> installations, across a wide range of customers. I have participated >> >> in, or been consulted on at least a dozen direct trials of GC >> >> alternatives. >> >> >> >> It is only in the last 18 months that I have seen *any* real-life >> >> workload on G1 beat the alternatives, and only in the last 12 months >> >> that I've had any customer prepared to go live with G1 in production. >> >> >> >> From my experience, I think that G1 is a fine collector, with a bright >> >> future that should be pursued. However, I haven't seen anything that >> >> would make a switch to it as default collector seem compelling in the >> >> JDK 9 timeframe. >> >> >> >> Obviously, my experience is not universal, so I'd like to ask you / >> >> Oracle: >> >> >> >> 1) Can you explain the survey methodology and customer testing that >> >> you performed to arrive at the conclusion that G1 is ready to become >> >> default? >> >> >> >> 2) Can you share aggregate results of the surveying ("We worked with X >> >> customers and ran Y tests of G1 vs alternatives, and in Z% of cases, >> >> G1 worked better by W margin")? >> >> >> >> 3) Can you ask some of the customers you worked with to speak publicly >> >> about the trials you ran with them?" >> >> >> >> From reading this thread, am I right to conclude that no formal study >> >> of this issue has been done? >> >> >> >> If that's the case, then are we really happy to make G1 default >> >> without some more systematic efforts and attempts to obtain actual >> >> numbers? >> >> >> >> The questions that I'd like to see answered are: >> >> >> >> a) How short a pause time can G1 support being tuned to? 50ms? 20? >> >> Personally, I haven't seen it getting close to CMS in terms of STW >> >> time. >> >> >> >> b) What is the impact on throughput due to G1? >> >> >> >> I do like G1 as a collector, but can we really organise enough field >> >> tests in the pre-9 timeframe to justify such a large and potentially >> >> breaking change? We managed to do some good community compatibility >> >> testing for JDK 8, and we could think about a similar effort for "make >> >> G1 default". However, with modules, HTTP/2 and JShell all happening >> >> for 9, I question whether there is simply enough community bandwidth >> >> to do a decent effort for G1 as well, whereas, if we were targeting >> >> JDK 10 we'd have a lot more time to plan and to try to improve the >> >> quality and range of the field data to hopefully de-risk a potential >> >> large, high-profile failure. >> >> >> >> Thanks, >> >> >> >> Ben >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> On Thu, Apr 30, 2015 at 2:55 PM, Monica Beckwith >> >> wrote: >> >>> I am also FOR the change in the default GC. Charlie and Mattis bring >> >>> up >> >>> great points. It's about time G1 gets put out there (as the default >> >>> GC) >> >>> since most of the development work is going into G1. As for >> >> documentation, >> >>> we not only need to document the change in the default collector but >> >>> also >> >>> the defaults for the collector; that are enabled as soon as G1 is >> >> employed - >> >>> e.g. MaxGCPauseMillis, IHOP, etc. >> >>> >> >>> With more and more input coming in, G1 is only going to get better and >> >>> hopefully more adaptive :) >> >>> >> >>> And as for Charlie's question - I don't remember the last time that I >> >> didn't >> >>> see an explicit GC mentioned on the command line (even if it was the >> >> default >> >>> GC). >> >>> >> >>> These are just my two cents. >> >>> >> >>> -Monica >> >>> >> >>> >> >>> On 4/30/15 8:17 AM, charlie hunt wrote: >> >>>> >> >>>> Fwiw, we should not forget that anyone who is currently specifying an >> >>>> explicit GC to use in his or her JVM command line args will not >> >> experience >> >>>> any difference in behavior. They will still get the collector they >> >> specify >> >>>> to use. The (potential) impact will be on those who do not specify a >> >>>> GC >> >> to >> >>>> use. >> >>>> >> >>>> What I would like to hear from Kirk and others who frequently work >> >>>> with >> >>>> customers on GC, what?s the percentage of Java applications they have >> >> worked >> >>>> with that do not explicitly specify a GC? And, of those, what >> >> percentage of >> >>>> those apps fall into the categories of small heap and desire low >> >> latency, or >> >>>> desire high throughput even at the cost of frequent full GCs? >> >>>> >> >>>> thanks, >> >>>> >> >>>> charlie >> >>>> >> >>>>> On Apr 30, 2015, at 7:27 AM, Mattis Castegren >> >>>>> wrote: >> >>>>> >> >>>>> Hi. >> >>>>> >> >>>>> I also work with customers but I would like to give an argument FOR >> >>>>> changing the default. >> >>>>> >> >>>>> I don't think we will ever come to a point where G1 is better for >> >>>>> ALL >> >>>>> users. Even with a near perfect G1 implementation there may be cases >> >> where >> >>>>> the parallel collector gives better throughput. >> >>>>> >> >>>>> Right now, I think G1 will be better for most users. There are >> >>>>> probably >> >>>>> also corner cases where G1 COULD be better, but where small issues >> >> reduces >> >>>>> performance. By changing the default to G1, we will be able to >> >>>>> easier >> >> find >> >>>>> these as we will expose more users to G1. >> >>>>> >> >>>>> Finally, there will be a set of users who only care about >> >>>>> throughput, >> >> and >> >>>>> who will see a performance regression. In those cases, they can go >> >> back to >> >>>>> using parallel. But hopefully, there will be far fewer users who >> >>>>> need >> >> to >> >>>>> tune their application to run with parallel GC than there are users >> >> who have >> >>>>> to (or should) tune their application to run with G1. >> >>>>> >> >>>>> In the case of huge, business critical, applications, we will always >> >>>>> introduce a risk by changing default collectors. This is true if we >> >> change >> >>>>> to G1 in JDK 9, 10 or 11. I prefer to just rip the band aid off. We >> >> know >> >>>>> that the collector we will focus on going forward is G1, so we >> >>>>> should >> >> let as >> >>>>> many people use it as possible. >> >>>>> >> >>>>> Of course we should document this a lot, so that users who go up to >> >> JDK 9 >> >>>>> and see performance regressions can at least try to run with >> >>>>> Parallel >> >> to see >> >>>>> if it is due to the GC. >> >>>>> >> >>>>> Kind Regards >> >>>>> /Mattis >> >>>>> >> >>>>> -----Original Message----- >> >>>>> From: Kirk Pepperdine [mailto:kirk at kodewerk.com] >> >>>>> Sent: den 30 april 2015 13:18 >> >>>>> To: Stefan Johansson >> >>>>> Cc: hotspot-dev at openjdk.java.net Source Developers >> >>>>> Subject: Re: JEP 248: Make G1 the Default Garbage Collector >> >>>>> >> >>>>> Hi Stefan, >> >>>>> >> >>>>> Indeed, the improvements have been amazing. I have been getting many >> >>>>> clients to bench with it and although the results have been mixed, >> >> overall >> >>>>> many have been able to move forward. However I still would not >> >> recommend G1 >> >>>>> to anyone who can't move to 1.8.0_40. Of course this change will >> >> obviously >> >>>>> come post _40 but still, the recent emergence of the G1 as a viable >> >>>>> production ready collector suggests that making it a default maybe a >> >> wee bit >> >>>>> optimistic. >> >>>>> >> >>>>> The change is based on the assumption that limiting latency is often >> >> more >> >>>>> important than maximizing throughput. If this assumption is >> >>>>> incorrect >> >> then >> >>>>> this change might need to be reconsidered. >> >>>>> >> >>>>> I would agree with this assumption. In most cases latency is more >> >>>>> important. However G1 doesn't always provide lowest latency >> >>>>> especially >> >> in >> >>>>> smaller heaps. >> >>>>> >> >>>>> >> >>>>> G1 is seen as a robust and well-tested collector. It is not expected >> >>>>> to >> >>>>> have stability problems, but becoming the default collector will >> >> increase >> >>>>> its visibility and may reveal previously-unknown issues. >> >>>>> I not sure it's prudent to treat the entire Java eco-system as >> >>>>> guinea >> >>>>> pigs. I believe it's more prudent to have the willing take that >> >>>>> first >> >> step >> >>>>> rather than have it unwittingly dropped on everyone >> >>>>> >> >>>>> >> >>>>> >> >>>>> At the end of the day, I don't have any say in any of this (as it >> >> should >> >>>>> be). All I can do is let you know what I'm seeing through my straw >> >> with the >> >>>>> hope that you'll find the information useful. From what I see, there >> >> is not >> >>>>> nearly enough experience in the tuning the G1 in that is especially >> >> true in >> >>>>> the general population to make this type of change at this point in >> >> time. >> >>>>> I'm also not sure that we have all the tuning options we need to >> >>>>> ensure >> >>>>> "happy apps" in the wild. For example, I think the incremental >> >> accumulated >> >>>>> waste in tenured regions is a problem that I'm not sure we have the >> >> tools to >> >>>>> solve. I'm not even sure if it's a recognized problem. In fact I'm >> >>>>> not >> >> even >> >>>>> sure it's a real problem as at the moment it's only a theory based >> >>>>> on >> >>>>> observations I'm making by looking at numbers of GC logs produced by >> >>>>> applications using recent releases of the G1. >> >>>>> >> >>>>> I would suggest that for Tiered the default config for 8 is was also >> >>>>> a >> >>>>> bit premature. I've had to have a number of clients have to roll >> >>>>> back >> >> off of >> >>>>> it. >> >>>>> >> >>>>> - Kirk >> >>>>> >> >>>>> On Apr 29, 2015, at 3:03 PM, Stefan Johansson >> >>>>> wrote: >> >>>>> >> >>>>>> Hi Kirk, >> >>>>>> >> >>>>>> A lot of effort is put into G1, it has been continuously improving >> >> over >> >>>>>> the last couple of years and we now believe that G1 is ready to >> >> become the >> >>>>>> default. G1 will not improve all use case, but the same is true for >> >> the >> >>>>>> other collectors. For users where throughput is the main concern, >> >> Parallel >> >>>>>> GC can still be used by specifying -XX:+UseParallelGC on the >> >> command-line. >> >>>>>> >> >>>>>> Regards, >> >>>>>> Stefan >> >>>>>> >> >>>>>> On 2015-04-29 09:10, Kirk Pepperdine wrote: >> >>>>>>> >> >>>>>>> Hi all, >> >>>>>>> >> >>>>>>> Is the G1 ready for this? I see many people moving to G1 but also >> >>>>>>> I'm >> >>>>>>> not sure that we've got the tunable correct. I've been sorting >> >> through a >> >>>>>>> number of recent tuning engagements and my conclusion is that I >> >> would like >> >>>>>>> the collector to be aggressive about collecting tenured regions at >> >> the >> >>>>>>> beginning of a JVM's life time but then become less aggressive >> >>>>>>> over >> >> time. >> >>>>>>> The reason is the residual waste that I see left behind because >> >> certain >> >>>>>>> regions never hit the threshold needed to be included in the CSET. >> >> But, on >> >>>>>>> aggregate, the number of regions in this state does start to >> >>>>>>> retain a >> >>>>>>> significant about of dead data. The only way to see the effects is >> >> to run >> >>>>>>> regular Full GCs.. which of course you don't really want to do. >> >> However, the >> >>>>>>> problem seems to settle down a wee bit over time which is why I >> >>>>>>> was >> >> thinking >> >>>>>>> that being aggressive about what is collected in the early stages >> >>>>>>> of >> >> a JVMs >> >>>>>>> life should lead to better packing and hence less waste. >> >>>>>>> >> >>>>>>> Note, I don't really care about the memory waste, only it's effect >> >>>>>>> on >> >>>>>>> cycle frequencies and pause times. >> >>>>>>> >> >>>>>>> Sorry but I don't have anything formal about this as I (and I >> >>>>>>> believe >> >>>>>>> many others) are still sorting out what to make of the G1 in prod. >> >> Generally >> >>>>>>> the overall results are good but sometimes it's not that way up >> >> front and >> >>>>>>> how to improve things is sometimes challenging. >> >>>>>>> >> >>>>>>> On a side note, the move to Tiered in 8 has also caused a bit of >> >> grief. >> >>>>>>> Metaspace has caused a bit of grief and even parallelStream, which >> >> works, >> >>>>>>> has come with some interesting side effect. Everyone has been so >> >> enamored >> >>>>>>> with Lambdas (rightfully so) that the other stuff has been >> >>>>>>> completely >> >>>>>>> forgotten and some of it has surprised people. I guess I'll be >> >> submitting a >> >>>>>>> talk for J1 on some of the field experience I've had with the >> >>>>>>> other >> >> stuff. >> >>>>>>> >> >>>>>>> Regards, >> >>>>>>> Kirk >> >>>>>>> >> >>>>>>> >> >>>>>>> On Apr 28, 2015, at 11:02 PM, mark.reinhold at oracle.com wrote: >> >>>>>>> >> >>>>>>>> New JEP Candidate: http://openjdk.java.net/jeps/248 >> >>>>>>>> >> >>>>>>>> - Mark >> >>>>>> >> >>>>>> >> >>> >> >>> >> >> >> >> >> >> >> >> -- >> >> Ben Evans, Co-founder jClarity @jclarity >> >> >> > -- Ben Evans, Co-founder jClarity @jclarity From charlie.hunt at oracle.com Mon Jun 1 15:25:10 2015 From: charlie.hunt at oracle.com (charlie hunt) Date: Mon, 1 Jun 2015 10:25:10 -0500 Subject: JEP 248: Make G1 the Default Garbage Collector In-Reply-To: References: <20150428220211.4355960845@eggemoggin.niobe.net> <5C5564BB-23ED-49AB-81C6-CFF85B56ACA4@kodewerk.com> <5540D689.6020407@oracle.com> <73855087-8BB2-4A8C-B9AD-080CD39FAB7A@kodewerk.com> <55423444.7040009@beckwithclan.com> Message-ID: Hi Ben, A couple things to keep in mind. 1.) The impact of this JEP is limited to those Java applications that currently do not set a GC explicitly at the JVM command line. I think this is important to keep in mind as a starting point. A data point you may be able to help with is a survey of applications that do not set a GC explicit as a JVM command line option. I recall only seeing one Java application over the last 15 years that did not set a GC as a JVM command line option, and it was a Java GUI app. 2.) This JEP?s intent is not to replace the throughput collector (Parallel[Old]GC). The same applies to CMS GC. Folks who want to use, and do use the throughput collector or CMS GC can still use them. 3.) One might argue that if a GC is not explicitly specified at the JVM command line, then tuning GC may not be important for that application. In the event an application that does not set a GC explicitly at the command line experiences an observable performance regression, it would be able to restore its performance by setting -XX:+UseParallelOldGC on the JVM command line. To summarize, this JEP is about what GC to use when none is specified at the JVM command line. Hence its impact is limited to those configurations. To me it becomes a question of how many Java applications do not set an explicit GC at the command line, and how many of those want peak throughput performance with little concern of (occasional high) latency? This is a question I think the community could help us with. hths, charlie > On Jun 1, 2015, at 9:42 AM, Ben Evans wrote: > > Hi Vitaly, > > (I've added hotspot-dev back on to the To: line as I think it's > important this discussion is had in public). > > In general, Mark has outlined a design philosophy for the platform > that is conservative, and where, if features are not ready, then they > are slipped to the next major release. Features shouldn't be rushed or > releases delayed, instead production quality features should be > shipped when done. > > So, to my mind, this issue comes down to whether the proposed benefit > is such that it outweighs the risks of changing the behaviour of > millions upon millions of installations. We don't have any systematic > data (which I argue should be a huge red flag in itself), and the > experience of consultants and performance engineers, including Kirk > and myself, is not exactly encouraging. So, does this change really > justify the risk? > > I would also question the conclusion that all we can organise before > Java 10 is: "some reports from the field". For Java 8, the community > was able to engage with a pretty good group of F/OSS libraries & help > them to test on betas of 8, so they (& their users) could have > confidence that they would "just work" with 8 straight out of the box. > > I see no reason why a similar approach could not work for G1 becoming > default - we can approach relevant partners in the ecosystem (e.g. > Cloudbees, Blazemeter, etc) and see if they can help, and we can > directly reach out and get people testing with G1. However, there is > an issue of timing and available resources here - there's a lot going > on for JDK 9 as it is, and I don't know how easy it would be to get > this programme running as well. > > Finally, the other issue that I'd like to address is that of scope > creep. I'd always been under the impression that G1 was thought of as > the CMS replacement. However, (and admittedly a lot of the systems I > see are either financial or gaming) in its current state there is no > way that G1 is a general replacement for CMS. The pauses for G1 are > simply too long for a big class of low-latency systems. > > Instead, G1 is now being talked of as a replacement for the default > collector. If that's the case, then I think we need to acknowledge it, > and have a conversation about where G1 is actually supposed to be > used. Are we saying we want a "reasonably high throughput with reduced > STW, but not low pause time" collector? If we are, that's fine, but > that's not where we started. > > Thanks, > > Ben > > On Mon, Jun 1, 2015 at 3:05 PM, Vitaly Davidovich wrote: >> Kirk, >> >> I don't dispute that some people aren't tuning/touching the GC controls, and >> may get negatively impacted (but perhaps positively too). My main point, >> however, is I don't see waiting until java 10 as adding sufficient safety >> guards; certainly there will be more lab time and benchmarking at oracle, >> some reports from the field but inevitably there will be unknown workloads >> in the wild that still don't work well even after more "due diligence". If >> G1 is truly the successor to CMS, kicking the can further down the road >> isn't helping achieve that. Anyone seeing a regression has an easy way to >> opt out. Any such change will always weed out some outliers, java 9, 10 or >> 15. The longer we wait, the harder it may be to fix some of them. >> >> sent from my phone >> >> On Jun 1, 2015 9:43 AM, "Kirk Pepperdine" wrote: >>> >>> Hi Vitaly, >>> >>> Ben has only re-iterated what I?ve already said but in a more concise way. >>> And, I don?t mean to be insulting but I don?t really buy into the argument >>> that people will be specifying a collector anyways because there are still a >>> significant number that use the parallel collector. In fact, just today, I >>> recommended that someone move away from G1 to the parallel collector as that >>> use case clearly favored the recommendation. >>> >>> And I should add, I?ve now backed a number of deployments off of >>> tiered-compilation as IME it is impacting performance in a negative way. >>> >>> Regards, >>> Kirk >>> >>> On Jun 1, 2015, at 3:05 PM, Vitaly Davidovich wrote: >>> >>>> Ben, >>>> >>>> The customers using CMS won't be impacted since they're explicitly >>>> specifying the GC. Java 9 will already require extensive testing for >>>> people, and GC performance is luckily one of the more introspectable >>>> facilities. Furthermore, people who are keen on staying with the >>>> default >>>> collector should/can lock that in before moving to Java 9 since >>>> presumably >>>> there will be enough visibility of this change in release notes and >>>> such. >>>> >>>> Personally, I find changing default JIT compilation policy to tiered in >>>> java 8 a more risky change, but I don't recall seeing such fervor around >>>> it >>>> :). >>>> >>>> sent from my phone >>>> On Jun 1, 2015 6:37 AM, "Ben Evans" wrote: >>>> >>>>> Hi, >>>>> >>>>> I'm somewhat late to this, having missed the original discussion >>>>> whilst travelling. >>>>> >>>>> Mark targeted this JEP to JDK 9 but has since put that on hold to >>>>> allow more discussion. >>>>> >>>>> I made this comment to Mark on jdk9-dev: >>>>> >>>>> "I have been working with G1 for ~5 years, ever since it was >>>>> experimental (& highly crash-prone in JDK 6). >>>>> >>>>> In the intervening time, I have seen dozens (if not hundreds) of >>>>> installations, across a wide range of customers. I have participated >>>>> in, or been consulted on at least a dozen direct trials of GC >>>>> alternatives. >>>>> >>>>> It is only in the last 18 months that I have seen *any* real-life >>>>> workload on G1 beat the alternatives, and only in the last 12 months >>>>> that I've had any customer prepared to go live with G1 in production. >>>>> >>>>> From my experience, I think that G1 is a fine collector, with a bright >>>>> future that should be pursued. However, I haven't seen anything that >>>>> would make a switch to it as default collector seem compelling in the >>>>> JDK 9 timeframe. >>>>> >>>>> Obviously, my experience is not universal, so I'd like to ask you / >>>>> Oracle: >>>>> >>>>> 1) Can you explain the survey methodology and customer testing that >>>>> you performed to arrive at the conclusion that G1 is ready to become >>>>> default? >>>>> >>>>> 2) Can you share aggregate results of the surveying ("We worked with X >>>>> customers and ran Y tests of G1 vs alternatives, and in Z% of cases, >>>>> G1 worked better by W margin")? >>>>> >>>>> 3) Can you ask some of the customers you worked with to speak publicly >>>>> about the trials you ran with them?" >>>>> >>>>> From reading this thread, am I right to conclude that no formal study >>>>> of this issue has been done? >>>>> >>>>> If that's the case, then are we really happy to make G1 default >>>>> without some more systematic efforts and attempts to obtain actual >>>>> numbers? >>>>> >>>>> The questions that I'd like to see answered are: >>>>> >>>>> a) How short a pause time can G1 support being tuned to? 50ms? 20? >>>>> Personally, I haven't seen it getting close to CMS in terms of STW >>>>> time. >>>>> >>>>> b) What is the impact on throughput due to G1? >>>>> >>>>> I do like G1 as a collector, but can we really organise enough field >>>>> tests in the pre-9 timeframe to justify such a large and potentially >>>>> breaking change? We managed to do some good community compatibility >>>>> testing for JDK 8, and we could think about a similar effort for "make >>>>> G1 default". However, with modules, HTTP/2 and JShell all happening >>>>> for 9, I question whether there is simply enough community bandwidth >>>>> to do a decent effort for G1 as well, whereas, if we were targeting >>>>> JDK 10 we'd have a lot more time to plan and to try to improve the >>>>> quality and range of the field data to hopefully de-risk a potential >>>>> large, high-profile failure. >>>>> >>>>> Thanks, >>>>> >>>>> Ben >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Thu, Apr 30, 2015 at 2:55 PM, Monica Beckwith >>>>> wrote: >>>>>> I am also FOR the change in the default GC. Charlie and Mattis bring >>>>>> up >>>>>> great points. It's about time G1 gets put out there (as the default >>>>>> GC) >>>>>> since most of the development work is going into G1. As for >>>>> documentation, >>>>>> we not only need to document the change in the default collector but >>>>>> also >>>>>> the defaults for the collector; that are enabled as soon as G1 is >>>>> employed - >>>>>> e.g. MaxGCPauseMillis, IHOP, etc. >>>>>> >>>>>> With more and more input coming in, G1 is only going to get better and >>>>>> hopefully more adaptive :) >>>>>> >>>>>> And as for Charlie's question - I don't remember the last time that I >>>>> didn't >>>>>> see an explicit GC mentioned on the command line (even if it was the >>>>> default >>>>>> GC). >>>>>> >>>>>> These are just my two cents. >>>>>> >>>>>> -Monica >>>>>> >>>>>> >>>>>> On 4/30/15 8:17 AM, charlie hunt wrote: >>>>>>> >>>>>>> Fwiw, we should not forget that anyone who is currently specifying an >>>>>>> explicit GC to use in his or her JVM command line args will not >>>>> experience >>>>>>> any difference in behavior. They will still get the collector they >>>>> specify >>>>>>> to use. The (potential) impact will be on those who do not specify a >>>>>>> GC >>>>> to >>>>>>> use. >>>>>>> >>>>>>> What I would like to hear from Kirk and others who frequently work >>>>>>> with >>>>>>> customers on GC, what?s the percentage of Java applications they have >>>>> worked >>>>>>> with that do not explicitly specify a GC? And, of those, what >>>>> percentage of >>>>>>> those apps fall into the categories of small heap and desire low >>>>> latency, or >>>>>>> desire high throughput even at the cost of frequent full GCs? >>>>>>> >>>>>>> thanks, >>>>>>> >>>>>>> charlie >>>>>>> >>>>>>>> On Apr 30, 2015, at 7:27 AM, Mattis Castegren >>>>>>>> wrote: >>>>>>>> >>>>>>>> Hi. >>>>>>>> >>>>>>>> I also work with customers but I would like to give an argument FOR >>>>>>>> changing the default. >>>>>>>> >>>>>>>> I don't think we will ever come to a point where G1 is better for >>>>>>>> ALL >>>>>>>> users. Even with a near perfect G1 implementation there may be cases >>>>> where >>>>>>>> the parallel collector gives better throughput. >>>>>>>> >>>>>>>> Right now, I think G1 will be better for most users. There are >>>>>>>> probably >>>>>>>> also corner cases where G1 COULD be better, but where small issues >>>>> reduces >>>>>>>> performance. By changing the default to G1, we will be able to >>>>>>>> easier >>>>> find >>>>>>>> these as we will expose more users to G1. >>>>>>>> >>>>>>>> Finally, there will be a set of users who only care about >>>>>>>> throughput, >>>>> and >>>>>>>> who will see a performance regression. In those cases, they can go >>>>> back to >>>>>>>> using parallel. But hopefully, there will be far fewer users who >>>>>>>> need >>>>> to >>>>>>>> tune their application to run with parallel GC than there are users >>>>> who have >>>>>>>> to (or should) tune their application to run with G1. >>>>>>>> >>>>>>>> In the case of huge, business critical, applications, we will always >>>>>>>> introduce a risk by changing default collectors. This is true if we >>>>> change >>>>>>>> to G1 in JDK 9, 10 or 11. I prefer to just rip the band aid off. We >>>>> know >>>>>>>> that the collector we will focus on going forward is G1, so we >>>>>>>> should >>>>> let as >>>>>>>> many people use it as possible. >>>>>>>> >>>>>>>> Of course we should document this a lot, so that users who go up to >>>>> JDK 9 >>>>>>>> and see performance regressions can at least try to run with >>>>>>>> Parallel >>>>> to see >>>>>>>> if it is due to the GC. >>>>>>>> >>>>>>>> Kind Regards >>>>>>>> /Mattis >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Kirk Pepperdine [mailto:kirk at kodewerk.com] >>>>>>>> Sent: den 30 april 2015 13:18 >>>>>>>> To: Stefan Johansson >>>>>>>> Cc: hotspot-dev at openjdk.java.net Source Developers >>>>>>>> Subject: Re: JEP 248: Make G1 the Default Garbage Collector >>>>>>>> >>>>>>>> Hi Stefan, >>>>>>>> >>>>>>>> Indeed, the improvements have been amazing. I have been getting many >>>>>>>> clients to bench with it and although the results have been mixed, >>>>> overall >>>>>>>> many have been able to move forward. However I still would not >>>>> recommend G1 >>>>>>>> to anyone who can't move to 1.8.0_40. Of course this change will >>>>> obviously >>>>>>>> come post _40 but still, the recent emergence of the G1 as a viable >>>>>>>> production ready collector suggests that making it a default maybe a >>>>> wee bit >>>>>>>> optimistic. >>>>>>>> >>>>>>>> The change is based on the assumption that limiting latency is often >>>>> more >>>>>>>> important than maximizing throughput. If this assumption is >>>>>>>> incorrect >>>>> then >>>>>>>> this change might need to be reconsidered. >>>>>>>> >>>>>>>> I would agree with this assumption. In most cases latency is more >>>>>>>> important. However G1 doesn't always provide lowest latency >>>>>>>> especially >>>>> in >>>>>>>> smaller heaps. >>>>>>>> >>>>>>>> >>>>>>>> G1 is seen as a robust and well-tested collector. It is not expected >>>>>>>> to >>>>>>>> have stability problems, but becoming the default collector will >>>>> increase >>>>>>>> its visibility and may reveal previously-unknown issues. >>>>>>>> I not sure it's prudent to treat the entire Java eco-system as >>>>>>>> guinea >>>>>>>> pigs. I believe it's more prudent to have the willing take that >>>>>>>> first >>>>> step >>>>>>>> rather than have it unwittingly dropped on everyone >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> At the end of the day, I don't have any say in any of this (as it >>>>> should >>>>>>>> be). All I can do is let you know what I'm seeing through my straw >>>>> with the >>>>>>>> hope that you'll find the information useful. From what I see, there >>>>> is not >>>>>>>> nearly enough experience in the tuning the G1 in that is especially >>>>> true in >>>>>>>> the general population to make this type of change at this point in >>>>> time. >>>>>>>> I'm also not sure that we have all the tuning options we need to >>>>>>>> ensure >>>>>>>> "happy apps" in the wild. For example, I think the incremental >>>>> accumulated >>>>>>>> waste in tenured regions is a problem that I'm not sure we have the >>>>> tools to >>>>>>>> solve. I'm not even sure if it's a recognized problem. In fact I'm >>>>>>>> not >>>>> even >>>>>>>> sure it's a real problem as at the moment it's only a theory based >>>>>>>> on >>>>>>>> observations I'm making by looking at numbers of GC logs produced by >>>>>>>> applications using recent releases of the G1. >>>>>>>> >>>>>>>> I would suggest that for Tiered the default config for 8 is was also >>>>>>>> a >>>>>>>> bit premature. I've had to have a number of clients have to roll >>>>>>>> back >>>>> off of >>>>>>>> it. >>>>>>>> >>>>>>>> - Kirk >>>>>>>> >>>>>>>> On Apr 29, 2015, at 3:03 PM, Stefan Johansson >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Hi Kirk, >>>>>>>>> >>>>>>>>> A lot of effort is put into G1, it has been continuously improving >>>>> over >>>>>>>>> the last couple of years and we now believe that G1 is ready to >>>>> become the >>>>>>>>> default. G1 will not improve all use case, but the same is true for >>>>> the >>>>>>>>> other collectors. For users where throughput is the main concern, >>>>> Parallel >>>>>>>>> GC can still be used by specifying -XX:+UseParallelGC on the >>>>> command-line. >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> Stefan >>>>>>>>> >>>>>>>>> On 2015-04-29 09:10, Kirk Pepperdine wrote: >>>>>>>>>> >>>>>>>>>> Hi all, >>>>>>>>>> >>>>>>>>>> Is the G1 ready for this? I see many people moving to G1 but also >>>>>>>>>> I'm >>>>>>>>>> not sure that we've got the tunable correct. I've been sorting >>>>> through a >>>>>>>>>> number of recent tuning engagements and my conclusion is that I >>>>> would like >>>>>>>>>> the collector to be aggressive about collecting tenured regions at >>>>> the >>>>>>>>>> beginning of a JVM's life time but then become less aggressive >>>>>>>>>> over >>>>> time. >>>>>>>>>> The reason is the residual waste that I see left behind because >>>>> certain >>>>>>>>>> regions never hit the threshold needed to be included in the CSET. >>>>> But, on >>>>>>>>>> aggregate, the number of regions in this state does start to >>>>>>>>>> retain a >>>>>>>>>> significant about of dead data. The only way to see the effects is >>>>> to run >>>>>>>>>> regular Full GCs.. which of course you don't really want to do. >>>>> However, the >>>>>>>>>> problem seems to settle down a wee bit over time which is why I >>>>>>>>>> was >>>>> thinking >>>>>>>>>> that being aggressive about what is collected in the early stages >>>>>>>>>> of >>>>> a JVMs >>>>>>>>>> life should lead to better packing and hence less waste. >>>>>>>>>> >>>>>>>>>> Note, I don't really care about the memory waste, only it's effect >>>>>>>>>> on >>>>>>>>>> cycle frequencies and pause times. >>>>>>>>>> >>>>>>>>>> Sorry but I don't have anything formal about this as I (and I >>>>>>>>>> believe >>>>>>>>>> many others) are still sorting out what to make of the G1 in prod. >>>>> Generally >>>>>>>>>> the overall results are good but sometimes it's not that way up >>>>> front and >>>>>>>>>> how to improve things is sometimes challenging. >>>>>>>>>> >>>>>>>>>> On a side note, the move to Tiered in 8 has also caused a bit of >>>>> grief. >>>>>>>>>> Metaspace has caused a bit of grief and even parallelStream, which >>>>> works, >>>>>>>>>> has come with some interesting side effect. Everyone has been so >>>>> enamored >>>>>>>>>> with Lambdas (rightfully so) that the other stuff has been >>>>>>>>>> completely >>>>>>>>>> forgotten and some of it has surprised people. I guess I'll be >>>>> submitting a >>>>>>>>>> talk for J1 on some of the field experience I've had with the >>>>>>>>>> other >>>>> stuff. >>>>>>>>>> >>>>>>>>>> Regards, >>>>>>>>>> Kirk >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Apr 28, 2015, at 11:02 PM, mark.reinhold at oracle.com wrote: >>>>>>>>>> >>>>>>>>>>> New JEP Candidate: http://openjdk.java.net/jeps/248 >>>>>>>>>>> >>>>>>>>>>> - Mark >>>>>>>>> >>>>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Ben Evans, Co-founder jClarity @jclarity >>>>> >>> >> > > > > -- > Ben Evans, Co-founder jClarity @jclarity From vitalyd at gmail.com Mon Jun 1 15:32:50 2015 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Mon, 1 Jun 2015 11:32:50 -0400 Subject: JEP 248: Make G1 the Default Garbage Collector In-Reply-To: References: <20150428220211.4355960845@eggemoggin.niobe.net> <5C5564BB-23ED-49AB-81C6-CFF85B56ACA4@kodewerk.com> <5540D689.6020407@oracle.com> <73855087-8BB2-4A8C-B9AD-080CD39FAB7A@kodewerk.com> <55423444.7040009@beckwithclan.com> Message-ID: Hi Ben, So, to my mind, this issue comes down to whether the proposed benefit > is such that it outweighs the risks of changing the behaviour of > millions upon millions of installations. We don't have any systematic > data (which I argue should be a huge red flag in itself), and the > experience of consultants and performance engineers, including Kirk > and myself, is not exactly encouraging. So, does this change really > justify the risk? Perhaps it's "millions upon millions", but I don't know and I'm not sure how anyone else can know what GC configs are out there. Again, the assumption here is that anyone who's been bitten by GC and had some tuning done (beyond heap sizing) has already selected the GC they want, in which case they're not affected at all. For the others, it's simply too vague to say, no? Is G1 flat out unstable to the point where it's causing crashes? I know there have been a few bug reports in the context of Lucene, I believe, where there was poor interaction between JIT and G1, but I don't recall seeing this being attributed to G1 specifically. I will agree that G1 cannot be made default until all G1 related bug reports with crashes are resolved, even if ultimate blame lies elsewhere (e.g. compiler). I would also question the conclusion that all we can organise before > Java 10 is: "some reports from the field". For Java 8, the community > was able to engage with a pretty good group of F/OSS libraries & help > them to test on betas of 8, so they (& their users) could have > confidence that they would "just work" with 8 straight out of the box. I think you guys are doing a good job of recruiting outside parties in vetting/testing java releases, but I specifically mentioned tiered compilation being made default in my previous email because it's known to have caused performance regressions. However, I don't think it's necessarily a bad thing *if* people experiencing regressions are funneling feedback back to Oracle -- it's just the nature of complex systems, and the earlier the problems are exposed, the easier it is to fix them. So, although asking the community to participate in more java 10 testing of G1 may yield additional things Oracle could fix/improve before release, nobody quite knows for sure and then one has to also consider the fact that G1 may simply not accommodate their load as well (i.e. nothing wrong with implementation, just not a good fit -- in that case, select the explicit GC and don't be subject to default changes). Instead, G1 is now being talked of as a replacement for the default > collector. If that's the case, then I think we need to acknowledge it, > and have a conversation about where G1 is actually supposed to be > used. Are we saying we want a "reasonably high throughput with reduced > STW, but not low pause time" collector? If we are, that's fine, but > that's not where we started. That's a fair point, and one I'd be interesting in hearing an answer to as well. FWIW, the only GC I know of that's actually used in low latency systems is Azul's C4, so I'm not even sure Oracle is trying to target the same use cases. So when we talk about "low latency" GCs, we should probably also be clear on what "low" actually means. Vitaly On Mon, Jun 1, 2015 at 10:42 AM, Ben Evans wrote: > Hi Vitaly, > > (I've added hotspot-dev back on to the To: line as I think it's > important this discussion is had in public). > > In general, Mark has outlined a design philosophy for the platform > that is conservative, and where, if features are not ready, then they > are slipped to the next major release. Features shouldn't be rushed or > releases delayed, instead production quality features should be > shipped when done. > > So, to my mind, this issue comes down to whether the proposed benefit > is such that it outweighs the risks of changing the behaviour of > millions upon millions of installations. We don't have any systematic > data (which I argue should be a huge red flag in itself), and the > experience of consultants and performance engineers, including Kirk > and myself, is not exactly encouraging. So, does this change really > justify the risk? > > I would also question the conclusion that all we can organise before > Java 10 is: "some reports from the field". For Java 8, the community > was able to engage with a pretty good group of F/OSS libraries & help > them to test on betas of 8, so they (& their users) could have > confidence that they would "just work" with 8 straight out of the box. > > I see no reason why a similar approach could not work for G1 becoming > default - we can approach relevant partners in the ecosystem (e.g. > Cloudbees, Blazemeter, etc) and see if they can help, and we can > directly reach out and get people testing with G1. However, there is > an issue of timing and available resources here - there's a lot going > on for JDK 9 as it is, and I don't know how easy it would be to get > this programme running as well. > > Finally, the other issue that I'd like to address is that of scope > creep. I'd always been under the impression that G1 was thought of as > the CMS replacement. However, (and admittedly a lot of the systems I > see are either financial or gaming) in its current state there is no > way that G1 is a general replacement for CMS. The pauses for G1 are > simply too long for a big class of low-latency systems. > > Instead, G1 is now being talked of as a replacement for the default > collector. If that's the case, then I think we need to acknowledge it, > and have a conversation about where G1 is actually supposed to be > used. Are we saying we want a "reasonably high throughput with reduced > STW, but not low pause time" collector? If we are, that's fine, but > that's not where we started. > > Thanks, > > Ben > > On Mon, Jun 1, 2015 at 3:05 PM, Vitaly Davidovich > wrote: > > Kirk, > > > > I don't dispute that some people aren't tuning/touching the GC controls, > and > > may get negatively impacted (but perhaps positively too). My main point, > > however, is I don't see waiting until java 10 as adding sufficient safety > > guards; certainly there will be more lab time and benchmarking at oracle, > > some reports from the field but inevitably there will be unknown > workloads > > in the wild that still don't work well even after more "due diligence". > If > > G1 is truly the successor to CMS, kicking the can further down the road > > isn't helping achieve that. Anyone seeing a regression has an easy way > to > > opt out. Any such change will always weed out some outliers, java 9, 10 > or > > 15. The longer we wait, the harder it may be to fix some of them. > > > > sent from my phone > > > > On Jun 1, 2015 9:43 AM, "Kirk Pepperdine" wrote: > >> > >> Hi Vitaly, > >> > >> Ben has only re-iterated what I?ve already said but in a more concise > way. > >> And, I don?t mean to be insulting but I don?t really buy into the > argument > >> that people will be specifying a collector anyways because there are > still a > >> significant number that use the parallel collector. In fact, just > today, I > >> recommended that someone move away from G1 to the parallel collector as > that > >> use case clearly favored the recommendation. > >> > >> And I should add, I?ve now backed a number of deployments off of > >> tiered-compilation as IME it is impacting performance in a negative way. > >> > >> Regards, > >> Kirk > >> > >> On Jun 1, 2015, at 3:05 PM, Vitaly Davidovich > wrote: > >> > >> > Ben, > >> > > >> > The customers using CMS won't be impacted since they're explicitly > >> > specifying the GC. Java 9 will already require extensive testing for > >> > people, and GC performance is luckily one of the more introspectable > >> > facilities. Furthermore, people who are keen on staying with the > >> > default > >> > collector should/can lock that in before moving to Java 9 since > >> > presumably > >> > there will be enough visibility of this change in release notes and > >> > such. > >> > > >> > Personally, I find changing default JIT compilation policy to tiered > in > >> > java 8 a more risky change, but I don't recall seeing such fervor > around > >> > it > >> > :). > >> > > >> > sent from my phone > >> > On Jun 1, 2015 6:37 AM, "Ben Evans" wrote: > >> > > >> >> Hi, > >> >> > >> >> I'm somewhat late to this, having missed the original discussion > >> >> whilst travelling. > >> >> > >> >> Mark targeted this JEP to JDK 9 but has since put that on hold to > >> >> allow more discussion. > >> >> > >> >> I made this comment to Mark on jdk9-dev: > >> >> > >> >> "I have been working with G1 for ~5 years, ever since it was > >> >> experimental (& highly crash-prone in JDK 6). > >> >> > >> >> In the intervening time, I have seen dozens (if not hundreds) of > >> >> installations, across a wide range of customers. I have participated > >> >> in, or been consulted on at least a dozen direct trials of GC > >> >> alternatives. > >> >> > >> >> It is only in the last 18 months that I have seen *any* real-life > >> >> workload on G1 beat the alternatives, and only in the last 12 months > >> >> that I've had any customer prepared to go live with G1 in production. > >> >> > >> >> From my experience, I think that G1 is a fine collector, with a > bright > >> >> future that should be pursued. However, I haven't seen anything that > >> >> would make a switch to it as default collector seem compelling in the > >> >> JDK 9 timeframe. > >> >> > >> >> Obviously, my experience is not universal, so I'd like to ask you / > >> >> Oracle: > >> >> > >> >> 1) Can you explain the survey methodology and customer testing that > >> >> you performed to arrive at the conclusion that G1 is ready to become > >> >> default? > >> >> > >> >> 2) Can you share aggregate results of the surveying ("We worked with > X > >> >> customers and ran Y tests of G1 vs alternatives, and in Z% of cases, > >> >> G1 worked better by W margin")? > >> >> > >> >> 3) Can you ask some of the customers you worked with to speak > publicly > >> >> about the trials you ran with them?" > >> >> > >> >> From reading this thread, am I right to conclude that no formal study > >> >> of this issue has been done? > >> >> > >> >> If that's the case, then are we really happy to make G1 default > >> >> without some more systematic efforts and attempts to obtain actual > >> >> numbers? > >> >> > >> >> The questions that I'd like to see answered are: > >> >> > >> >> a) How short a pause time can G1 support being tuned to? 50ms? 20? > >> >> Personally, I haven't seen it getting close to CMS in terms of STW > >> >> time. > >> >> > >> >> b) What is the impact on throughput due to G1? > >> >> > >> >> I do like G1 as a collector, but can we really organise enough field > >> >> tests in the pre-9 timeframe to justify such a large and potentially > >> >> breaking change? We managed to do some good community compatibility > >> >> testing for JDK 8, and we could think about a similar effort for > "make > >> >> G1 default". However, with modules, HTTP/2 and JShell all happening > >> >> for 9, I question whether there is simply enough community bandwidth > >> >> to do a decent effort for G1 as well, whereas, if we were targeting > >> >> JDK 10 we'd have a lot more time to plan and to try to improve the > >> >> quality and range of the field data to hopefully de-risk a potential > >> >> large, high-profile failure. > >> >> > >> >> Thanks, > >> >> > >> >> Ben > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> On Thu, Apr 30, 2015 at 2:55 PM, Monica Beckwith > >> >> wrote: > >> >>> I am also FOR the change in the default GC. Charlie and Mattis bring > >> >>> up > >> >>> great points. It's about time G1 gets put out there (as the default > >> >>> GC) > >> >>> since most of the development work is going into G1. As for > >> >> documentation, > >> >>> we not only need to document the change in the default collector but > >> >>> also > >> >>> the defaults for the collector; that are enabled as soon as G1 is > >> >> employed - > >> >>> e.g. MaxGCPauseMillis, IHOP, etc. > >> >>> > >> >>> With more and more input coming in, G1 is only going to get better > and > >> >>> hopefully more adaptive :) > >> >>> > >> >>> And as for Charlie's question - I don't remember the last time that > I > >> >> didn't > >> >>> see an explicit GC mentioned on the command line (even if it was the > >> >> default > >> >>> GC). > >> >>> > >> >>> These are just my two cents. > >> >>> > >> >>> -Monica > >> >>> > >> >>> > >> >>> On 4/30/15 8:17 AM, charlie hunt wrote: > >> >>>> > >> >>>> Fwiw, we should not forget that anyone who is currently specifying > an > >> >>>> explicit GC to use in his or her JVM command line args will not > >> >> experience > >> >>>> any difference in behavior. They will still get the collector they > >> >> specify > >> >>>> to use. The (potential) impact will be on those who do not specify > a > >> >>>> GC > >> >> to > >> >>>> use. > >> >>>> > >> >>>> What I would like to hear from Kirk and others who frequently work > >> >>>> with > >> >>>> customers on GC, what?s the percentage of Java applications they > have > >> >> worked > >> >>>> with that do not explicitly specify a GC? And, of those, what > >> >> percentage of > >> >>>> those apps fall into the categories of small heap and desire low > >> >> latency, or > >> >>>> desire high throughput even at the cost of frequent full GCs? > >> >>>> > >> >>>> thanks, > >> >>>> > >> >>>> charlie > >> >>>> > >> >>>>> On Apr 30, 2015, at 7:27 AM, Mattis Castegren > >> >>>>> wrote: > >> >>>>> > >> >>>>> Hi. > >> >>>>> > >> >>>>> I also work with customers but I would like to give an argument > FOR > >> >>>>> changing the default. > >> >>>>> > >> >>>>> I don't think we will ever come to a point where G1 is better for > >> >>>>> ALL > >> >>>>> users. Even with a near perfect G1 implementation there may be > cases > >> >> where > >> >>>>> the parallel collector gives better throughput. > >> >>>>> > >> >>>>> Right now, I think G1 will be better for most users. There are > >> >>>>> probably > >> >>>>> also corner cases where G1 COULD be better, but where small issues > >> >> reduces > >> >>>>> performance. By changing the default to G1, we will be able to > >> >>>>> easier > >> >> find > >> >>>>> these as we will expose more users to G1. > >> >>>>> > >> >>>>> Finally, there will be a set of users who only care about > >> >>>>> throughput, > >> >> and > >> >>>>> who will see a performance regression. In those cases, they can go > >> >> back to > >> >>>>> using parallel. But hopefully, there will be far fewer users who > >> >>>>> need > >> >> to > >> >>>>> tune their application to run with parallel GC than there are > users > >> >> who have > >> >>>>> to (or should) tune their application to run with G1. > >> >>>>> > >> >>>>> In the case of huge, business critical, applications, we will > always > >> >>>>> introduce a risk by changing default collectors. This is true if > we > >> >> change > >> >>>>> to G1 in JDK 9, 10 or 11. I prefer to just rip the band aid off. > We > >> >> know > >> >>>>> that the collector we will focus on going forward is G1, so we > >> >>>>> should > >> >> let as > >> >>>>> many people use it as possible. > >> >>>>> > >> >>>>> Of course we should document this a lot, so that users who go up > to > >> >> JDK 9 > >> >>>>> and see performance regressions can at least try to run with > >> >>>>> Parallel > >> >> to see > >> >>>>> if it is due to the GC. > >> >>>>> > >> >>>>> Kind Regards > >> >>>>> /Mattis > >> >>>>> > >> >>>>> -----Original Message----- > >> >>>>> From: Kirk Pepperdine [mailto:kirk at kodewerk.com] > >> >>>>> Sent: den 30 april 2015 13:18 > >> >>>>> To: Stefan Johansson > >> >>>>> Cc: hotspot-dev at openjdk.java.net Source Developers > >> >>>>> Subject: Re: JEP 248: Make G1 the Default Garbage Collector > >> >>>>> > >> >>>>> Hi Stefan, > >> >>>>> > >> >>>>> Indeed, the improvements have been amazing. I have been getting > many > >> >>>>> clients to bench with it and although the results have been mixed, > >> >> overall > >> >>>>> many have been able to move forward. However I still would not > >> >> recommend G1 > >> >>>>> to anyone who can't move to 1.8.0_40. Of course this change will > >> >> obviously > >> >>>>> come post _40 but still, the recent emergence of the G1 as a > viable > >> >>>>> production ready collector suggests that making it a default > maybe a > >> >> wee bit > >> >>>>> optimistic. > >> >>>>> > >> >>>>> The change is based on the assumption that limiting latency is > often > >> >> more > >> >>>>> important than maximizing throughput. If this assumption is > >> >>>>> incorrect > >> >> then > >> >>>>> this change might need to be reconsidered. > >> >>>>> > >> >>>>> I would agree with this assumption. In most cases latency is more > >> >>>>> important. However G1 doesn't always provide lowest latency > >> >>>>> especially > >> >> in > >> >>>>> smaller heaps. > >> >>>>> > >> >>>>> > >> >>>>> G1 is seen as a robust and well-tested collector. It is not > expected > >> >>>>> to > >> >>>>> have stability problems, but becoming the default collector will > >> >> increase > >> >>>>> its visibility and may reveal previously-unknown issues. > >> >>>>> I not sure it's prudent to treat the entire Java eco-system as > >> >>>>> guinea > >> >>>>> pigs. I believe it's more prudent to have the willing take that > >> >>>>> first > >> >> step > >> >>>>> rather than have it unwittingly dropped on everyone > >> >>>>> > >> >>>>> > >> >>>>> > >> >>>>> At the end of the day, I don't have any say in any of this (as it > >> >> should > >> >>>>> be). All I can do is let you know what I'm seeing through my straw > >> >> with the > >> >>>>> hope that you'll find the information useful. From what I see, > there > >> >> is not > >> >>>>> nearly enough experience in the tuning the G1 in that is > especially > >> >> true in > >> >>>>> the general population to make this type of change at this point > in > >> >> time. > >> >>>>> I'm also not sure that we have all the tuning options we need to > >> >>>>> ensure > >> >>>>> "happy apps" in the wild. For example, I think the incremental > >> >> accumulated > >> >>>>> waste in tenured regions is a problem that I'm not sure we have > the > >> >> tools to > >> >>>>> solve. I'm not even sure if it's a recognized problem. In fact I'm > >> >>>>> not > >> >> even > >> >>>>> sure it's a real problem as at the moment it's only a theory based > >> >>>>> on > >> >>>>> observations I'm making by looking at numbers of GC logs produced > by > >> >>>>> applications using recent releases of the G1. > >> >>>>> > >> >>>>> I would suggest that for Tiered the default config for 8 is was > also > >> >>>>> a > >> >>>>> bit premature. I've had to have a number of clients have to roll > >> >>>>> back > >> >> off of > >> >>>>> it. > >> >>>>> > >> >>>>> - Kirk > >> >>>>> > >> >>>>> On Apr 29, 2015, at 3:03 PM, Stefan Johansson > >> >>>>> wrote: > >> >>>>> > >> >>>>>> Hi Kirk, > >> >>>>>> > >> >>>>>> A lot of effort is put into G1, it has been continuously > improving > >> >> over > >> >>>>>> the last couple of years and we now believe that G1 is ready to > >> >> become the > >> >>>>>> default. G1 will not improve all use case, but the same is true > for > >> >> the > >> >>>>>> other collectors. For users where throughput is the main concern, > >> >> Parallel > >> >>>>>> GC can still be used by specifying -XX:+UseParallelGC on the > >> >> command-line. > >> >>>>>> > >> >>>>>> Regards, > >> >>>>>> Stefan > >> >>>>>> > >> >>>>>> On 2015-04-29 09:10, Kirk Pepperdine wrote: > >> >>>>>>> > >> >>>>>>> Hi all, > >> >>>>>>> > >> >>>>>>> Is the G1 ready for this? I see many people moving to G1 but > also > >> >>>>>>> I'm > >> >>>>>>> not sure that we've got the tunable correct. I've been sorting > >> >> through a > >> >>>>>>> number of recent tuning engagements and my conclusion is that I > >> >> would like > >> >>>>>>> the collector to be aggressive about collecting tenured regions > at > >> >> the > >> >>>>>>> beginning of a JVM's life time but then become less aggressive > >> >>>>>>> over > >> >> time. > >> >>>>>>> The reason is the residual waste that I see left behind because > >> >> certain > >> >>>>>>> regions never hit the threshold needed to be included in the > CSET. > >> >> But, on > >> >>>>>>> aggregate, the number of regions in this state does start to > >> >>>>>>> retain a > >> >>>>>>> significant about of dead data. The only way to see the effects > is > >> >> to run > >> >>>>>>> regular Full GCs.. which of course you don't really want to do. > >> >> However, the > >> >>>>>>> problem seems to settle down a wee bit over time which is why I > >> >>>>>>> was > >> >> thinking > >> >>>>>>> that being aggressive about what is collected in the early > stages > >> >>>>>>> of > >> >> a JVMs > >> >>>>>>> life should lead to better packing and hence less waste. > >> >>>>>>> > >> >>>>>>> Note, I don't really care about the memory waste, only it's > effect > >> >>>>>>> on > >> >>>>>>> cycle frequencies and pause times. > >> >>>>>>> > >> >>>>>>> Sorry but I don't have anything formal about this as I (and I > >> >>>>>>> believe > >> >>>>>>> many others) are still sorting out what to make of the G1 in > prod. > >> >> Generally > >> >>>>>>> the overall results are good but sometimes it's not that way up > >> >> front and > >> >>>>>>> how to improve things is sometimes challenging. > >> >>>>>>> > >> >>>>>>> On a side note, the move to Tiered in 8 has also caused a bit of > >> >> grief. > >> >>>>>>> Metaspace has caused a bit of grief and even parallelStream, > which > >> >> works, > >> >>>>>>> has come with some interesting side effect. Everyone has been so > >> >> enamored > >> >>>>>>> with Lambdas (rightfully so) that the other stuff has been > >> >>>>>>> completely > >> >>>>>>> forgotten and some of it has surprised people. I guess I'll be > >> >> submitting a > >> >>>>>>> talk for J1 on some of the field experience I've had with the > >> >>>>>>> other > >> >> stuff. > >> >>>>>>> > >> >>>>>>> Regards, > >> >>>>>>> Kirk > >> >>>>>>> > >> >>>>>>> > >> >>>>>>> On Apr 28, 2015, at 11:02 PM, mark.reinhold at oracle.com wrote: > >> >>>>>>> > >> >>>>>>>> New JEP Candidate: http://openjdk.java.net/jeps/248 > >> >>>>>>>> > >> >>>>>>>> - Mark > >> >>>>>> > >> >>>>>> > >> >>> > >> >>> > >> >> > >> >> > >> >> > >> >> -- > >> >> Ben Evans, Co-founder jClarity @jclarity > >> >> > >> > > > > > > -- > Ben Evans, Co-founder jClarity @jclarity > From kirk.pepperdine at gmail.com Mon Jun 1 16:18:10 2015 From: kirk.pepperdine at gmail.com (Kirk Pepperdine) Date: Mon, 1 Jun 2015 18:18:10 +0200 Subject: JEP 248: Make G1 the Default Garbage Collector In-Reply-To: References: <20150428220211.4355960845@eggemoggin.niobe.net> <5C5564BB-23ED-49AB-81C6-CFF85B56ACA4@kodewerk.com> <5540D689.6020407@oracle.com> <73855087-8BB2-4A8C-B9AD-080CD39FAB7A@kodewerk.com> <55423444.7040009@beckwithclan.com> Message-ID: <4391D841-07CD-4A37-8092-DABBA3C3A627@gmail.com> Hi Charlie, On Jun 1, 2015, at 5:25 PM, charlie hunt wrote: > Hi Ben, > > A couple things to keep in mind. > > 1.) The impact of this JEP is limited to those Java applications that currently do not set a GC explicitly at the JVM command line. I think this is important to keep in mind as a starting point. A data point you may be able to help with is a survey of applications that do not set a GC explicit as a JVM command line option. I recall only seeing one Java application over the last 15 years that did not set a GC as a JVM command line option, and it was a Java GUI app. 3 of the 5 applications I?m currently tuning did not have the collector set on the command line. Of the 5, G1 should be appropriate for 4 of them bug existing unidentified bugs in G1 knock one off the list. > > 2.) This JEP?s intent is not to replace the throughput collector (Parallel[Old]GC). The same applies to CMS GC. Folks who want to use, and do use the throughput collector or CMS GC can still use them. I?m sorry but as I?ve said before, I don?t find this a compelling argument. > > 3.) One might argue that if a GC is not explicitly specified at the JVM command line, then tuning GC may not be important for that application. In the event an application that does not set a GC explicitly at the command line experiences an observable performance regression, it would be able to restore its performance by setting -XX:+UseParallelOldGC on the JVM command line. Sorry but I don?t buy this argument either. Most of my customers are not well educated in GC tuning. It?s not that they are bad engineers, it?s just a matter of focus. > > To summarize, this JEP is about what GC to use when none is specified at the JVM command line. Hence its impact is limited to those configurations. > > To me it becomes a question of how many Java applications do not set an explicit GC at the command line, and how many of those want peak throughput performance with little concern of (occasional high) latency? This is a question I think the community could help us with. Agreed, the community should help and I?m sure they will/would but only if they know about this issue. As you know, we are both engaged in a lot of educational activities about how the JVM and in particular, GC works. As many as we?ve reached there seems to be 1000sx more that have maybe, maybe a vague idea of how it all works. That, and I still don?t believe we?ve had nearly enough time in the field with a stable version of the collector. I know that everyone in house is excited but I think the prudent thing to do here is hold off until 10. IOWs, out here in the wild, its looking good, very good, but its still not working as well as we hoped it would by now. Regards, Kirk From ben at jclarity.com Mon Jun 1 16:25:22 2015 From: ben at jclarity.com (Ben Evans) Date: Mon, 1 Jun 2015 17:25:22 +0100 Subject: JEP 248: Make G1 the Default Garbage Collector In-Reply-To: References: <20150428220211.4355960845@eggemoggin.niobe.net> <5C5564BB-23ED-49AB-81C6-CFF85B56ACA4@kodewerk.com> <5540D689.6020407@oracle.com> <73855087-8BB2-4A8C-B9AD-080CD39FAB7A@kodewerk.com> <55423444.7040009@beckwithclan.com> Message-ID: Hi Charlie, On Mon, Jun 1, 2015 at 4:25 PM, charlie hunt wrote: > > 1.) The impact of this JEP is limited to those Java applications that currently do not set a GC explicitly at the JVM command line. I think this is important to keep in mind as a starting point. A data point you may be able to help with is a survey of applications that do not set a GC explicit as a JVM command line option. I recall only seeing one Java application over the last 15 years that did not set a GC as a JVM command line option, and it was a Java GUI app. OK - that is substantially at variance with my experience. Whilst the majority of applications that I'm asked to take a look at directly do set a GC explicitly, that is a self-selected sample, as Kirk says - it is precisely the people that are aware of GC that are least likely to have issues with this change, because they have already thought about it, and called us. However, if I look at the reactions & questions after talks I get, a very different picture emerges. My gut feel is that the majority of applications run with a default algorithm. That's just my gut feel, though. I don't think we have to go by that alone. If we look at the JCP members, we have a number of large coroporates with diverse use cases. Can we not just approach them & see if they'd commit a small amount of engineering time to survey their apps & give us some reporting numbers? I can think of at least 2-3 corporates who might well be prepared to help - if it wasn't too onerous, and we could be specific about what we would like them to report on. > 3.) One might argue that if a GC is not explicitly specified at the JVM command line, then tuning GC may not be important for that application. In the event an application that does not set a GC explicitly at the command line experiences an observable performance regression, it would be able to restore its performance by setting -XX:+UseParallelOldGC on the JVM command line. I would worry that faced with such a regression, the team would simply not upgrade to 9. Not everyone is a GC expert or has the experience (or time) to dig into why a regression is happening, and they may simply decide "9 is not for us" - which would be a real shame & detrimental to the platform. > To summarize, this JEP is about what GC to use when none is specified at the JVM command line. Hence its impact is limited to those configurations. > > To me it becomes a question of how many Java applications do not set an explicit GC at the command line, and how many of those want peak throughput performance with little concern of (occasional high) latency? This is a question I think the community could help us with. OK - so if we were able to identify a large pool of users, what exactly would we want to ask them? And what sort of sample sizes (other than the larger the better :) ) would we like? Thanks, Ben From vitalyd at gmail.com Mon Jun 1 16:36:36 2015 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Mon, 1 Jun 2015 12:36:36 -0400 Subject: JEP 248: Make G1 the Default Garbage Collector In-Reply-To: References: <20150428220211.4355960845@eggemoggin.niobe.net> <5C5564BB-23ED-49AB-81C6-CFF85B56ACA4@kodewerk.com> <5540D689.6020407@oracle.com> <73855087-8BB2-4A8C-B9AD-080CD39FAB7A@kodewerk.com> <55423444.7040009@beckwithclan.com> Message-ID: Ben, I would worry that faced with such a regression, the team would simply > not upgrade to 9. Not everyone is a GC expert or has the experience > (or time) to dig into why a regression is happening, and they may > simply decide "9 is not for us" - which would be a real shame & > detrimental to the platform. This is simply irresponsible engineering if that were to happen. You're saying someone can't even be bothered to look at release notes and notice that the GC changed? They would get a regression on a major java release and do *zero* investigation? With all due respect, I find such an argument ridiculous. Don't mean to harp on tiered compilation, but did that prevent java 8 adoption? Did it cause massive pain? And this is an area (JIT) much more opaque to troubleshoot (short of microbenches) than GC. On Mon, Jun 1, 2015 at 12:25 PM, Ben Evans wrote: > Hi Charlie, > > On Mon, Jun 1, 2015 at 4:25 PM, charlie hunt > wrote: > > > > 1.) The impact of this JEP is limited to those Java applications that > currently do not set a GC explicitly at the JVM command line. I think this > is important to keep in mind as a starting point. A data point you may be > able to help with is a survey of applications that do not set a GC explicit > as a JVM command line option. I recall only seeing one Java application > over the last 15 years that did not set a GC as a JVM command line option, > and it was a Java GUI app. > > OK - that is substantially at variance with my experience. Whilst the > majority of applications that I'm asked to take a look at directly do > set a GC explicitly, that is a self-selected sample, as Kirk says - it > is precisely the people that are aware of GC that are least likely to > have issues with this change, because they have already thought about > it, and called us. > > However, if I look at the reactions & questions after talks I get, a > very different picture emerges. My gut feel is that the majority of > applications run with a default algorithm. > > That's just my gut feel, though. I don't think we have to go by that > alone. If we look at the JCP members, we have a number of large > coroporates with diverse use cases. Can we not just approach them & > see if they'd commit a small amount of engineering time to survey > their apps & give us some reporting numbers? > > I can think of at least 2-3 corporates who might well be prepared to > help - if it wasn't too onerous, and we could be specific about what > we would like them to report on. > > > 3.) One might argue that if a GC is not explicitly specified at the JVM > command line, then tuning GC may not be important for that application. In > the event an application that does not set a GC explicitly at the command > line experiences an observable performance regression, it would be able to > restore its performance by setting -XX:+UseParallelOldGC on the JVM command > line. > > I would worry that faced with such a regression, the team would simply > not upgrade to 9. Not everyone is a GC expert or has the experience > (or time) to dig into why a regression is happening, and they may > simply decide "9 is not for us" - which would be a real shame & > detrimental to the platform. > > > To summarize, this JEP is about what GC to use when none is specified at > the JVM command line. Hence its impact is limited to those configurations. > > > > To me it becomes a question of how many Java applications do not set an > explicit GC at the command line, and how many of those want peak throughput > performance with little concern of (occasional high) latency? This is a > question I think the community could help us with. > > OK - so if we were able to identify a large pool of users, what > exactly would we want to ask them? And what sort of sample sizes > (other than the larger the better :) ) would we like? > > Thanks, > > Ben > From ben at jclarity.com Mon Jun 1 16:56:21 2015 From: ben at jclarity.com (Ben Evans) Date: Mon, 1 Jun 2015 17:56:21 +0100 Subject: JEP 248: Make G1 the Default Garbage Collector In-Reply-To: References: <20150428220211.4355960845@eggemoggin.niobe.net> <5C5564BB-23ED-49AB-81C6-CFF85B56ACA4@kodewerk.com> <5540D689.6020407@oracle.com> <73855087-8BB2-4A8C-B9AD-080CD39FAB7A@kodewerk.com> <55423444.7040009@beckwithclan.com> Message-ID: Hi Vitaly, On Mon, Jun 1, 2015 at 5:36 PM, Vitaly Davidovich wrote: > >> I would worry that faced with such a regression, the team would simply >> not upgrade to 9. Not everyone is a GC expert or has the experience >> (or time) to dig into why a regression is happening, and they may >> simply decide "9 is not for us" - which would be a real shame & >> detrimental to the platform. > > This is simply irresponsible engineering if that were to happen. You're > saying someone can't even be bothered to look at release notes and notice > that the GC changed? They would get a regression on a major java release and > do *zero* investigation? With all due respect, I find such an argument > ridiculous. Yes, I would expect the majority of teams to act that way. I am still finding a fair number of teams on JDK 6. If that's not irresponsible engineering, I don't know what is - running your production apps on a totally unsupported platform that has a number of ways in which it cannot be fixed if it breaks. Yet, a surprisingly large number of people do exactly that. We may not like it, but it's what happens, and by forcing a potentially breaking change onto those sort of teams, all we do is hurt the platform's reputation. > Don't mean to harp on tiered compilation, but did that prevent java 8 > adoption? Did it cause massive pain? And this is an area (JIT) much more > opaque to troubleshoot (short of microbenches) than GC. But TieredCompilation is also much less likely to be the kind of issue that gets noticed. Slightly slower performance during startup is "Meh", longer pause times or visibly decreased throughput is the kind of thing that ops teams pay attention to. Ben From vitalyd at gmail.com Mon Jun 1 17:05:12 2015 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Mon, 1 Jun 2015 13:05:12 -0400 Subject: JEP 248: Make G1 the Default Garbage Collector In-Reply-To: References: <20150428220211.4355960845@eggemoggin.niobe.net> <5C5564BB-23ED-49AB-81C6-CFF85B56ACA4@kodewerk.com> <5540D689.6020407@oracle.com> <73855087-8BB2-4A8C-B9AD-080CD39FAB7A@kodewerk.com> <55423444.7040009@beckwithclan.com> Message-ID: > > Yes, I would expect the majority of teams to act that way. I am still > finding a fair number of teams on JDK 6. If that's not irresponsible > engineering, I don't know what is - running your production apps on a > totally unsupported platform that has a number of ways in which it > cannot be fixed if it breaks. > > Yet, a surprisingly large number of people do exactly that. We may not > like it, but it's what happens, and by forcing a potentially breaking > change onto those sort of teams, all we do is hurt the platform's > reputation. At the risk of sounding politically incorrect, I'd say such shops are on their own and their accommodation in decisions like this should be heavily discounted. It's just irresponsible to do otherwise for the health and longevity of the platform. But TieredCompilation is also much less likely to be the kind of issue > that gets noticed. Slightly slower performance during startup is > "Meh", longer pause times or visibly decreased throughput is the kind > of thing that ops teams pay attention to. No, it's the opposite problem - startup tended to improve, but peak perf suffered noticeable regressions, which is exactly the throughput degradation one would notice. On Mon, Jun 1, 2015 at 12:56 PM, Ben Evans wrote: > Hi Vitaly, > > On Mon, Jun 1, 2015 at 5:36 PM, Vitaly Davidovich > wrote: > > > >> I would worry that faced with such a regression, the team would simply > >> not upgrade to 9. Not everyone is a GC expert or has the experience > >> (or time) to dig into why a regression is happening, and they may > >> simply decide "9 is not for us" - which would be a real shame & > >> detrimental to the platform. > > > > This is simply irresponsible engineering if that were to happen. You're > > saying someone can't even be bothered to look at release notes and notice > > that the GC changed? They would get a regression on a major java release > and > > do *zero* investigation? With all due respect, I find such an argument > > ridiculous. > > Yes, I would expect the majority of teams to act that way. I am still > finding a fair number of teams on JDK 6. If that's not irresponsible > engineering, I don't know what is - running your production apps on a > totally unsupported platform that has a number of ways in which it > cannot be fixed if it breaks. > > Yet, a surprisingly large number of people do exactly that. We may not > like it, but it's what happens, and by forcing a potentially breaking > change onto those sort of teams, all we do is hurt the platform's > reputation. > > > Don't mean to harp on tiered compilation, but did that prevent java 8 > > adoption? Did it cause massive pain? And this is an area (JIT) much more > > opaque to troubleshoot (short of microbenches) than GC. > > But TieredCompilation is also much less likely to be the kind of issue > that gets noticed. Slightly slower performance during startup is > "Meh", longer pause times or visibly decreased throughput is the kind > of thing that ops teams pay attention to. > > Ben > From ben at jclarity.com Mon Jun 1 17:06:29 2015 From: ben at jclarity.com (Ben Evans) Date: Mon, 1 Jun 2015 18:06:29 +0100 Subject: JEP 248: Make G1 the Default Garbage Collector In-Reply-To: References: <20150428220211.4355960845@eggemoggin.niobe.net> <5C5564BB-23ED-49AB-81C6-CFF85B56ACA4@kodewerk.com> <5540D689.6020407@oracle.com> <73855087-8BB2-4A8C-B9AD-080CD39FAB7A@kodewerk.com> <55423444.7040009@beckwithclan.com> Message-ID: Hi Vitaly, >> Instead, G1 is now being talked of as a replacement for the default >> collector. If that's the case, then I think we need to acknowledge it, >> and have a conversation about where G1 is actually supposed to be >> used. Are we saying we want a "reasonably high throughput with reduced >> STW, but not low pause time" collector? If we are, that's fine, but >> that's not where we started. > > That's a fair point, and one I'd be interesting in hearing an answer to as > well. FWIW, the only GC I know of that's actually used in low latency > systems is Azul's C4, so I'm not even sure Oracle is trying to target the > same use cases. So when we talk about "low latency" GCs, we should probably > also be clear on what "low" actually means. Well, when I started playing with them, "low latency" meant a sub-10-ms transaction time with 100ms STW as acceptable, if not ideal. These days, the same sort of system needs a sub 500us transaction time, and ideally no GC pause at all. But that leads to Zing, or non-JVM solutions, and I think takes us too far into a specialised use case. Having said that, there is definitely a decent-sized class of systems (not just in finance) that cannot really tolerate any more than about 10-15ms of STW. So, what usually happens is that they live with the young collections, use CMS and tune out the CMFs as best they can (by clustering, rolling restart, etc, etc). I don't see any possibility of G1 becoming a viable solution for those systems any time soon. Thanks, Ben From ben at jclarity.com Mon Jun 1 17:08:08 2015 From: ben at jclarity.com (Ben Evans) Date: Mon, 1 Jun 2015 18:08:08 +0100 Subject: JEP 248: Make G1 the Default Garbage Collector In-Reply-To: References: <20150428220211.4355960845@eggemoggin.niobe.net> <5C5564BB-23ED-49AB-81C6-CFF85B56ACA4@kodewerk.com> <5540D689.6020407@oracle.com> <73855087-8BB2-4A8C-B9AD-080CD39FAB7A@kodewerk.com> <55423444.7040009@beckwithclan.com> Message-ID: >> But TieredCompilation is also much less likely to be the kind of issue >> that gets noticed. Slightly slower performance during startup is >> "Meh", longer pause times or visibly decreased throughput is the kind >> of thing that ops teams pay attention to. > > No, it's the opposite problem - startup tended to improve, but peak perf > suffered noticeable regressions, which is exactly the throughput degradation > one would notice. Interesting. I didn't see any events of that type - and I only saw a couple of the type I alluded to. Got some links? I'd like to read up on this. Thanks, Ben From charlie.hunt at oracle.com Mon Jun 1 17:22:59 2015 From: charlie.hunt at oracle.com (charlie hunt) Date: Mon, 1 Jun 2015 12:22:59 -0500 Subject: JEP 248: Make G1 the Default Garbage Collector In-Reply-To: References: <20150428220211.4355960845@eggemoggin.niobe.net> <5C5564BB-23ED-49AB-81C6-CFF85B56ACA4@kodewerk.com> <5540D689.6020407@oracle.com> <73855087-8BB2-4A8C-B9AD-080CD39FAB7A@kodewerk.com> <55423444.7040009@beckwithclan.com> Message-ID: <8DFF9BB7-3E76-4545-B5D9-07BE0D4693CB@oracle.com> > On Jun 1, 2015, at 12:06 PM, Ben Evans wrote: > > Hi Vitaly, > >>> Instead, G1 is now being talked of as a replacement for the default >>> collector. If that's the case, then I think we need to acknowledge it, >>> and have a conversation about where G1 is actually supposed to be >>> used. Are we saying we want a "reasonably high throughput with reduced >>> STW, but not low pause time" collector? If we are, that's fine, but >>> that's not where we started. >> >> That's a fair point, and one I'd be interesting in hearing an answer to as >> well. FWIW, the only GC I know of that's actually used in low latency >> systems is Azul's C4, so I'm not even sure Oracle is trying to target the >> same use cases. So when we talk about "low latency" GCs, we should probably >> also be clear on what "low" actually means. > > Well, when I started playing with them, "low latency" meant a > sub-10-ms transaction time with 100ms STW as acceptable, if not ideal. > > These days, the same sort of system needs a sub 500us transaction > time, and ideally no GC pause at all. But that leads to Zing, or > non-JVM solutions, and I think takes us too far into a specialised use > case. > > Having said that, there is definitely a decent-sized class of systems > (not just in finance) that cannot really tolerate any more than about > 10-15ms of STW. So, what usually happens is that they live with the > young collections, use CMS and tune out the CMFs as best they can (by > clustering, rolling restart, etc, etc). I don't see any possibility of > G1 becoming a viable solution for those systems any time soon. And, in this case what they do today is no different than what they would do with G1 as the default collector. In either case, they are gonna specify -XX:+UseConcMarkSweepGC as the GC to use because it is not the default GC, now or proposed. So let?s go back to what the JEP is suggesting, (the default GC being changed from Parallel GC to G1 GC), resist the temptation of what the JEP is not suggesting, i.e. a replacement for Parallel GC or CMS GC. When that day comes, (which will very likely be well after JDK 9), there will be distinct JEPs for those changes. The use case we are talking about is the ?out of the box? experience. One question that may be worth pondering ? suppose G1 happened to be the default GC today, and there was a JEP to make Parallel GC the default GC. What would your reaction to that JEP be? I?m asking that question since I?d like to get a sense if your concerns are more about conservatism (not wanting to change behavior), stability of G1 or otherwise. thanks, charlie > > Thanks, > > Ben From vitalyd at gmail.com Mon Jun 1 17:27:17 2015 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Mon, 1 Jun 2015 13:27:17 -0400 Subject: JEP 248: Make G1 the Default Garbage Collector In-Reply-To: References: <20150428220211.4355960845@eggemoggin.niobe.net> <5C5564BB-23ED-49AB-81C6-CFF85B56ACA4@kodewerk.com> <5540D689.6020407@oracle.com> <73855087-8BB2-4A8C-B9AD-080CD39FAB7A@kodewerk.com> <55423444.7040009@beckwithclan.com> Message-ID: > > Interesting. I didn't see any events of that type - and I only saw a > couple of the type I alluded to. > > Got some links? I'd like to read up on this. I don't have any concrete links, unfortunately, and google won't show all that much (you should see a few items though). This is based on my (recent) experience and some conversations with people that I've had. Some themes there were: 1) Extra/longer profiling inadvertently causes more noise in the profile, and less optimal code is generated. 2) Pressure on nmethod sweeper; if your app doesn't induce sufficient # of safepoints on its own, it can fall behind. 3) Some setups required bumping ReservedCodeCacheSize since default (even the bumped default with tiered enabled) didn't suffice 4) Extra VM threads were created (C2 and C1 compiler threads), which caused jitter in places where # of cores available to the JVM is precisely tuned. 5) java 8 keeps all compiled code, across all tiers, in a homogeneous code buffer; there can be i-cache and instruction TLB pressure. I believe java 9 will have the segmented code cache, which aims at addressing this problem. Nobody directly attributed it to this, but it's a known data point in java 8. 6) Unknown/unattributed perf anomalies (i.e. tiered was tried, and there was nothing obviously wrong, but peak perf was worse). Perhaps Charlie & co have more diverse field feedback on this, but this is now straying off-topic, I suspect. I was simply highlighting that tiered compilation was actually quite a substantial change to a core and complex VM facility, and even though there were anomalies, it didn't hurt adoption AFAIK (like with GC, turning off tiered is dead simple -- assuming of course one is willing to experiment and assess their regressions :)). On Mon, Jun 1, 2015 at 1:08 PM, Ben Evans wrote: > >> But TieredCompilation is also much less likely to be the kind of issue > >> that gets noticed. Slightly slower performance during startup is > >> "Meh", longer pause times or visibly decreased throughput is the kind > >> of thing that ops teams pay attention to. > > > > No, it's the opposite problem - startup tended to improve, but peak perf > > suffered noticeable regressions, which is exactly the throughput > degradation > > one would notice. > > Interesting. I didn't see any events of that type - and I only saw a > couple of the type I alluded to. > > Got some links? I'd like to read up on this. > > Thanks, > > Ben > From charlie.hunt at oracle.com Mon Jun 1 17:36:33 2015 From: charlie.hunt at oracle.com (charlie hunt) Date: Mon, 1 Jun 2015 12:36:33 -0500 Subject: JEP 248: Make G1 the Default Garbage Collector In-Reply-To: References: <20150428220211.4355960845@eggemoggin.niobe.net> <5C5564BB-23ED-49AB-81C6-CFF85B56ACA4@kodewerk.com> <5540D689.6020407@oracle.com> <73855087-8BB2-4A8C-B9AD-080CD39FAB7A@kodewerk.com> <55423444.7040009@beckwithclan.com> Message-ID: > On Jun 1, 2015, at 11:25 AM, Ben Evans wrote: > > Hi Charlie, > > On Mon, Jun 1, 2015 at 4:25 PM, charlie hunt wrote: >> >> 1.) The impact of this JEP is limited to those Java applications that currently do not set a GC explicitly at the JVM command line. I think this is important to keep in mind as a starting point. A data point you may be able to help with is a survey of applications that do not set a GC explicit as a JVM command line option. I recall only seeing one Java application over the last 15 years that did not set a GC as a JVM command line option, and it was a Java GUI app. > > OK - that is substantially at variance with my experience. Whilst the > majority of applications that I'm asked to take a look at directly do > set a GC explicitly, that is a self-selected sample, as Kirk says - it > is precisely the people that are aware of GC that are least likely to > have issues with this change, because they have already thought about > it, and called us. > > However, if I look at the reactions & questions after talks I get, a > very different picture emerges. My gut feel is that the majority of > applications run with a default algorithm. That is quite a contrast from my experience. At the end of the day I think JEP is more about the out of the box experience wrt GC. In age where Java heaps are much larger than we saw 5, 10 and 15 years, and there being more of a shift from throughput to latency as area of focus for GC, G1 tends offer a better happy medium between throughput and latency than Parallel GC unless you are lucky enough that the default out of the box heap sizing for Parallel GC allows the app to execute through its lifetime with no Full GC, or they occur at a frequency that can be tolerated, or the Full GC pause time is acceptable. > > That's just my gut feel, though. I don't think we have to go by that > alone. If we look at the JCP members, we have a number of large > coroporates with diverse use cases. Can we not just approach them & > see if they'd commit a small amount of engineering time to survey > their apps & give us some reporting numbers? That?s understood ? I wouldn?t be expecting anyone to set aside engineering time and do a bunch of testing. I think it is a simple question to ask, i.e. how many of your Java apps do you not set an explicit GC on the JVM command line? Those that do set an explicit GC will not be impacted. So they are not of interest. > > I can think of at least 2-3 corporates who might well be prepared to > help - if it wasn't too onerous, and we could be specific about what > we would like them to report on. > >> 3.) One might argue that if a GC is not explicitly specified at the JVM command line, then tuning GC may not be important for that application. In the event an application that does not set a GC explicitly at the command line experiences an observable performance regression, it would be able to restore its performance by setting -XX:+UseParallelOldGC on the JVM command line. > > I would worry that faced with such a regression, the team would simply > not upgrade to 9. Not everyone is a GC expert or has the experience > (or time) to dig into why a regression is happening, and they may > simply decide "9 is not for us" - which would be a real shame & > detrimental to the platform. IMO, such a team / company is going to be their own worst enemy with this kind of strategy / decision making, especially if the Java apps they are running are critical their success. > >> To summarize, this JEP is about what GC to use when none is specified at the JVM command line. Hence its impact is limited to those configurations. >> >> To me it becomes a question of how many Java applications do not set an explicit GC at the command line, and how many of those want peak throughput performance with little concern of (occasional high) latency? This is a question I think the community could help us with. > > OK - so if we were able to identify a large pool of users, what > exactly would we want to ask them? And what sort of sample sizes > (other than the larger the better :) ) would we like? See my comment above ? it?s a simple (survey) question, i.e. How many Java apps do you have that do not set an explicit GC on the JVM command line? It might interesting to also know if these apps also do not care if they have multi-second pause times, i.e. only care about throughput. thanks, charlie > > Thanks, > > Ben From ben at jclarity.com Mon Jun 1 17:46:03 2015 From: ben at jclarity.com (Ben Evans) Date: Mon, 1 Jun 2015 18:46:03 +0100 Subject: JEP 248: Make G1 the Default Garbage Collector In-Reply-To: <8DFF9BB7-3E76-4545-B5D9-07BE0D4693CB@oracle.com> References: <20150428220211.4355960845@eggemoggin.niobe.net> <5C5564BB-23ED-49AB-81C6-CFF85B56ACA4@kodewerk.com> <5540D689.6020407@oracle.com> <73855087-8BB2-4A8C-B9AD-080CD39FAB7A@kodewerk.com> <55423444.7040009@beckwithclan.com> <8DFF9BB7-3E76-4545-B5D9-07BE0D4693CB@oracle.com> Message-ID: On Mon, Jun 1, 2015 at 6:22 PM, charlie hunt wrote: > >> On Jun 1, 2015, at 12:06 PM, Ben Evans wrote: >> >> Having said that, there is definitely a decent-sized class of systems >> (not just in finance) that cannot really tolerate any more than about >> 10-15ms of STW. So, what usually happens is that they live with the >> young collections, use CMS and tune out the CMFs as best they can (by >> clustering, rolling restart, etc, etc). I don't see any possibility of >> G1 becoming a viable solution for those systems any time soon. > > And, in this case what they do today is no different than what they would do with G1 as the default collector. In either case, they are gonna specify -XX:+UseConcMarkSweepGC as the GC to use because it is not the default GC, now or proposed. You're completely right - that was just something of a diversion into low latency. > So let?s go back to what the JEP is suggesting, (the default GC being changed from Parallel GC to G1 GC), resist the temptation of what the JEP is not suggesting, i.e. a replacement for Parallel GC or CMS GC. When that day comes, (which will very likely be well after JDK 9), there will be distinct JEPs for those changes. > > The use case we are talking about is the ?out of the box? experience. Agree 100%. > One question that may be worth pondering ? suppose G1 happened to be the default GC today, and there was a JEP to make Parallel GC the default GC. What would your reaction to that JEP be? I?m asking that question since I?d like to get a sense if your concerns are more about conservatism (not wanting to change behavior), stability of G1 or otherwise. Primarily conservatism. Of course, if G1 had been default, the "unknown unknowns" would have been resolved by now, so there would be no need to worry. I think that if G1 was default, and the platform was as successful across the same range of workloads as it is today, I'd be advocating for no change. Thanks, Ben -- Ben Evans, Co-founder jClarity @jclarity From charlie.hunt at oracle.com Mon Jun 1 17:46:22 2015 From: charlie.hunt at oracle.com (charlie hunt) Date: Mon, 1 Jun 2015 12:46:22 -0500 Subject: JEP 248: Make G1 the Default Garbage Collector In-Reply-To: References: <20150428220211.4355960845@eggemoggin.niobe.net> <5C5564BB-23ED-49AB-81C6-CFF85B56ACA4@kodewerk.com> <5540D689.6020407@oracle.com> <73855087-8BB2-4A8C-B9AD-080CD39FAB7A@kodewerk.com> <55423444.7040009@beckwithclan.com> Message-ID: > On Jun 1, 2015, at 12:27 PM, Vitaly Davidovich wrote: > > Interesting. I didn't see any events of that type - and I only saw a > couple of the type I alluded to. > > > Got some links? I'd like to read up on this. > > I don't have any concrete links, unfortunately, and google won't show all that much (you should see a few items though). This is based on my (recent) experience and some conversations with people that I've had. Some themes there were: > > 1) Extra/longer profiling inadvertently causes more noise in the profile, and less optimal code is generated. > 2) Pressure on nmethod sweeper; if your app doesn't induce sufficient # of safepoints on its own, it can fall behind. > 3) Some setups required bumping ReservedCodeCacheSize since default (even the bumped default with tiered enabled) didn't suffice > 4) Extra VM threads were created (C2 and C1 compiler threads), which caused jitter in places where # of cores available to the JVM is precisely tuned. > 5) java 8 keeps all compiled code, across all tiers, in a homogeneous code buffer; there can be i-cache and instruction TLB pressure. I believe java 9 will have the segmented code cache, which aims at addressing this problem. Nobody directly attributed it to this, but it's a known data point in java 8. > 6) Unknown/unattributed perf anomalies (i.e. tiered was tried, and there was nothing obviously wrong, but peak perf was worse). > > Perhaps Charlie & co have more diverse field feedback on this, but this is now straying off-topic, I suspect. I was simply highlighting that tiered compilation was actually quite a substantial change to a core and complex VM facility, and even though there were anomalies, it didn?t hurt adoption AFAIK (like with GC, turning off tiered is dead simple -- assuming of course one is willing to experiment and assess their regressions :)). Yes, I have seen cases where tiered caused issues. But, it also helped a lot cases too. And, you?ve pretty much summarized the issues. I think there are some parallels here to the JEP at hand too. I agree with Vitaly. IMO, making tiered compilation the default was more risky than what I see with making G1 the default GC. I also think that not many folks paid attention because there is not as much known about the compiler as there is for instance about GC, and there is not as much instrumentation produced by the JVM that tells you if it is the compiler that has caused your application to slow down versus GC that needs tuning. And, the information (currently) produced by the compiler is much harder to read for most (expert) folks too. charlie > > > > > On Mon, Jun 1, 2015 at 1:08 PM, Ben Evans > wrote: > >> But TieredCompilation is also much less likely to be the kind of issue > >> that gets noticed. Slightly slower performance during startup is > >> "Meh", longer pause times or visibly decreased throughput is the kind > >> of thing that ops teams pay attention to. > > > > No, it's the opposite problem - startup tended to improve, but peak perf > > suffered noticeable regressions, which is exactly the throughput degradation > > one would notice. > > Interesting. I didn't see any events of that type - and I only saw a > couple of the type I alluded to. > > Got some links? I'd like to read up on this. > > Thanks, > > Ben > From charlie.hunt at oracle.com Mon Jun 1 17:48:55 2015 From: charlie.hunt at oracle.com (charlie hunt) Date: Mon, 1 Jun 2015 12:48:55 -0500 Subject: JEP 248: Make G1 the Default Garbage Collector In-Reply-To: References: <20150428220211.4355960845@eggemoggin.niobe.net> <5C5564BB-23ED-49AB-81C6-CFF85B56ACA4@kodewerk.com> <5540D689.6020407@oracle.com> <73855087-8BB2-4A8C-B9AD-080CD39FAB7A@kodewerk.com> <55423444.7040009@beckwithclan.com> <8DFF9BB7-3E76-4545-B5D9-07BE0D4693CB@oracle.com> Message-ID: <94973BE6-4FA4-45D9-A2F5-AF2B81226B4D@oracle.com> > On Jun 1, 2015, at 12:46 PM, Ben Evans wrote: > > On Mon, Jun 1, 2015 at 6:22 PM, charlie hunt wrote: >> >>> On Jun 1, 2015, at 12:06 PM, Ben Evans wrote: >>> >>> Having said that, there is definitely a decent-sized class of systems >>> (not just in finance) that cannot really tolerate any more than about >>> 10-15ms of STW. So, what usually happens is that they live with the >>> young collections, use CMS and tune out the CMFs as best they can (by >>> clustering, rolling restart, etc, etc). I don't see any possibility of >>> G1 becoming a viable solution for those systems any time soon. >> >> And, in this case what they do today is no different than what they would do with G1 as the default collector. In either case, they are gonna specify -XX:+UseConcMarkSweepGC as the GC to use because it is not the default GC, now or proposed. > > You're completely right - that was just something of a diversion into > low latency. > >> So let?s go back to what the JEP is suggesting, (the default GC being changed from Parallel GC to G1 GC), resist the temptation of what the JEP is not suggesting, i.e. a replacement for Parallel GC or CMS GC. When that day comes, (which will very likely be well after JDK 9), there will be distinct JEPs for those changes. >> >> The use case we are talking about is the ?out of the box? experience. > > Agree 100%. > >> One question that may be worth pondering ? suppose G1 happened to be the default GC today, and there was a JEP to make Parallel GC the default GC. What would your reaction to that JEP be? I?m asking that question since I?d like to get a sense if your concerns are more about conservatism (not wanting to change behavior), stability of G1 or otherwise. > > Primarily conservatism. Of course, if G1 had been default, the > "unknown unknowns" would have been resolved by now, so there would be > no need to worry. > > I think that if G1 was default, and the platform was as successful > across the same range of workloads as it is today, I'd be advocating > for no change. Is that because you think G1 would offer a better out of the box experience than Parallel GC, or because you would not want to see a change made to the JVM?s default GC? thanks, charlie > > Thanks, > > Ben > -- > Ben Evans, Co-founder jClarity @jclarity From ben at jclarity.com Mon Jun 1 17:54:37 2015 From: ben at jclarity.com (Ben Evans) Date: Mon, 1 Jun 2015 18:54:37 +0100 Subject: JEP 248: Make G1 the Default Garbage Collector In-Reply-To: <94973BE6-4FA4-45D9-A2F5-AF2B81226B4D@oracle.com> References: <20150428220211.4355960845@eggemoggin.niobe.net> <5C5564BB-23ED-49AB-81C6-CFF85B56ACA4@kodewerk.com> <5540D689.6020407@oracle.com> <73855087-8BB2-4A8C-B9AD-080CD39FAB7A@kodewerk.com> <55423444.7040009@beckwithclan.com> <8DFF9BB7-3E76-4545-B5D9-07BE0D4693CB@oracle.com> <94973BE6-4FA4-45D9-A2F5-AF2B81226B4D@oracle.com> Message-ID: >>> One question that may be worth pondering ? suppose G1 happened to be the default GC today, and there was a JEP to make Parallel GC the default GC. What would your reaction to that JEP be? I?m asking that question since I?d like to get a sense if your concerns are more about conservatism (not wanting to change behavior), stability of G1 or otherwise. >> >> Primarily conservatism. Of course, if G1 had been default, the >> "unknown unknowns" would have been resolved by now, so there would be >> no need to worry. >> >> I think that if G1 was default, and the platform was as successful >> across the same range of workloads as it is today, I'd be advocating >> for no change. > > Is that because you think G1 would offer a better out of the box experience than Parallel GC, or because you would not want to see a change made to the JVM?s default GC? I would not want to see a change made to the default behaviour that could potentially negatively affect a large number of apps and in doing so harm the long-term perception of the platform as a "safe pair of hands". Thanks, Ben -- Ben Evans, Co-founder jClarity @jclarity From charlie.hunt at oracle.com Mon Jun 1 18:10:50 2015 From: charlie.hunt at oracle.com (charlie hunt) Date: Mon, 1 Jun 2015 13:10:50 -0500 Subject: JEP 248: Make G1 the Default Garbage Collector In-Reply-To: <4391D841-07CD-4A37-8092-DABBA3C3A627@gmail.com> References: <20150428220211.4355960845@eggemoggin.niobe.net> <5C5564BB-23ED-49AB-81C6-CFF85B56ACA4@kodewerk.com> <5540D689.6020407@oracle.com> <73855087-8BB2-4A8C-B9AD-080CD39FAB7A@kodewerk.com> <55423444.7040009@beckwithclan.com> <4391D841-07CD-4A37-8092-DABBA3C3A627@gmail.com> Message-ID: > On Jun 1, 2015, at 11:18 AM, Kirk Pepperdine wrote: > > Hi Charlie, > > > On Jun 1, 2015, at 5:25 PM, charlie hunt wrote: > >> Hi Ben, >> >> A couple things to keep in mind. >> >> 1.) The impact of this JEP is limited to those Java applications that currently do not set a GC explicitly at the JVM command line. I think this is important to keep in mind as a starting point. A data point you may be able to help with is a survey of applications that do not set a GC explicit as a JVM command line option. I recall only seeing one Java application over the last 15 years that did not set a GC as a JVM command line option, and it was a Java GUI app. > > 3 of the 5 applications I?m currently tuning did not have the collector set on the command line. Of the 5, G1 should be appropriate for 4 of them bug existing unidentified bugs in G1 knock one off the list. At the risk of getting off topic a bit, what is the version of the JDK where you are seeing the one that has an unidentified bug in G1? Any additional description as to the observations, symptoms, etc on that one? > >> >> 2.) This JEP?s intent is not to replace the throughput collector (Parallel[Old]GC). The same applies to CMS GC. Folks who want to use, and do use the throughput collector or CMS GC can still use them. > > I?m sorry but as I?ve said before, I don?t find this a compelling argument. That?s ok, we can agree to disagree. :-) And, just to clarify, the potential impact for this JEP is that population of Java apps that do not set an explicit GC on the command line, and whether those application may see a better out of the box experience in terms of throughput, latency and footprint with G1 than with Parallel GC. > >> >> 3.) One might argue that if a GC is not explicitly specified at the JVM command line, then tuning GC may not be important for that application. In the event an application that does not set a GC explicitly at the command line experiences an observable performance regression, it would be able to restore its performance by setting -XX:+UseParallelOldGC on the JVM command line. > > Sorry but I don?t buy this argument either. Most of my customers are not well educated in GC tuning. It?s not that they are bad engineers, it?s just a matter of focus. I understand that it is a matter of focus. However, if those folks are not calling in an expert to tune GC, then they probably feel that the issue not that important for them address. At the same time, consider there may likely be cases where if G1 was the default collector, the need for calling in an expert to tune GC beyond G1?s defaults setting may not be needed. In other words, they would have a better out of the box experience with G1 than with Parallel GC. > >> >> To summarize, this JEP is about what GC to use when none is specified at the JVM command line. Hence its impact is limited to those configurations. >> >> To me it becomes a question of how many Java applications do not set an explicit GC at the command line, and how many of those want peak throughput performance with little concern of (occasional high) latency? This is a question I think the community could help us with. > > Agreed, the community should help and I?m sure they will/would but only if they know about this issue. As you know, we are both engaged in a lot of educational activities about how the JVM and in particular, GC works. As many as we?ve reached there seems to be 1000sx more that have maybe, maybe a vague idea of how it all works. That, and I still don?t believe we?ve had nearly enough time in the field with a stable version of the collector. I know that everyone in house is excited but I think the prudent thing to do here is hold off until 10. IOWs, out here in the wild, its looking good, very good, but its still not working as well as we hoped it would by now. For this JEP, I don?t think folks have to know how GC works to deal with the change in default collectors. For that population of apps that don?t set an explicit GC, they need to know that if they see a performance regression between a previous JDK to JDK 9, one of the things they should look at is setting / using Parallel GC, which would be in the release notes, or should they call in an expert, it would be one of the first changes suggested. thanks, charlie > > Regards, > Kirk > From vitalyd at gmail.com Mon Jun 1 18:23:50 2015 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Mon, 1 Jun 2015 14:23:50 -0400 Subject: JEP 248: Make G1 the Default Garbage Collector In-Reply-To: References: <20150428220211.4355960845@eggemoggin.niobe.net> <5C5564BB-23ED-49AB-81C6-CFF85B56ACA4@kodewerk.com> <5540D689.6020407@oracle.com> <73855087-8BB2-4A8C-B9AD-080CD39FAB7A@kodewerk.com> <55423444.7040009@beckwithclan.com> <4391D841-07CD-4A37-8092-DABBA3C3A627@gmail.com> Message-ID: Charlie, While we have your attention :), what is the status of the issues the Lucene guys highlighted earlier in this thread? In particular, this bug: https://bugs.openjdk.java.net/browse/JDK-8038348. If there are known miscompilations, I'd say those are showstoppers for this JEP, no? Thanks On Mon, Jun 1, 2015 at 2:10 PM, charlie hunt wrote: > > > On Jun 1, 2015, at 11:18 AM, Kirk Pepperdine > wrote: > > > > Hi Charlie, > > > > > > On Jun 1, 2015, at 5:25 PM, charlie hunt > wrote: > > > >> Hi Ben, > >> > >> A couple things to keep in mind. > >> > >> 1.) The impact of this JEP is limited to those Java applications that > currently do not set a GC explicitly at the JVM command line. I think this > is important to keep in mind as a starting point. A data point you may be > able to help with is a survey of applications that do not set a GC explicit > as a JVM command line option. I recall only seeing one Java application > over the last 15 years that did not set a GC as a JVM command line option, > and it was a Java GUI app. > > > > 3 of the 5 applications I?m currently tuning did not have the collector > set on the command line. Of the 5, G1 should be appropriate for 4 of them > bug existing unidentified bugs in G1 knock one off the list. > > At the risk of getting off topic a bit, what is the version of the JDK > where you are seeing the one that has an unidentified bug in G1? > > Any additional description as to the observations, symptoms, etc on that > one? > > > > >> > >> 2.) This JEP?s intent is not to replace the throughput collector > (Parallel[Old]GC). The same applies to CMS GC. Folks who want to use, and > do use the throughput collector or CMS GC can still use them. > > > > I?m sorry but as I?ve said before, I don?t find this a compelling > argument. > > That?s ok, we can agree to disagree. :-) > > And, just to clarify, the potential impact for this JEP is that population > of Java apps that do not set an explicit GC on the command line, and > whether those application may see a better out of the box experience in > terms of throughput, latency and footprint with G1 than with Parallel GC. > > > > >> > >> 3.) One might argue that if a GC is not explicitly specified at the JVM > command line, then tuning GC may not be important for that application. In > the event an application that does not set a GC explicitly at the command > line experiences an observable performance regression, it would be able to > restore its performance by setting -XX:+UseParallelOldGC on the JVM command > line. > > > > Sorry but I don?t buy this argument either. Most of my customers are not > well educated in GC tuning. It?s not that they are bad engineers, it?s just > a matter of focus. > > I understand that it is a matter of focus. However, if those folks are not > calling in an expert to tune GC, then they probably feel that the issue not > that important for them address. > > At the same time, consider there may likely be cases where if G1 was the > default collector, the need for calling in an expert to tune GC beyond G1?s > defaults setting may not be needed. In other words, they would have a > better out of the box experience with G1 than with Parallel GC. > > > > >> > >> To summarize, this JEP is about what GC to use when none is specified > at the JVM command line. Hence its impact is limited to those > configurations. > >> > >> To me it becomes a question of how many Java applications do not set an > explicit GC at the command line, and how many of those want peak throughput > performance with little concern of (occasional high) latency? This is a > question I think the community could help us with. > > > > Agreed, the community should help and I?m sure they will/would but only > if they know about this issue. As you know, we are both engaged in a lot of > educational activities about how the JVM and in particular, GC works. As > many as we?ve reached there seems to be 1000sx more that have maybe, maybe > a vague idea of how it all works. That, and I still don?t believe we?ve had > nearly enough time in the field with a stable version of the collector. I > know that everyone in house is excited but I think the prudent thing to do > here is hold off until 10. IOWs, out here in the wild, its looking good, > very good, but its still not working as well as we hoped it would by now. > > For this JEP, I don?t think folks have to know how GC works to deal with > the change in default collectors. For that population of apps that don?t > set an explicit GC, they need to know that if they see a performance > regression between a previous JDK to JDK 9, one of the things they should > look at is setting / using Parallel GC, which would be in the release > notes, or should they call in an expert, it would be one of the first > changes suggested. > > thanks, > > charlie > > > > > Regards, > > Kirk > > > > From charlie.hunt at oracle.com Mon Jun 1 18:25:28 2015 From: charlie.hunt at oracle.com (charlie hunt) Date: Mon, 1 Jun 2015 13:25:28 -0500 Subject: JEP 248: Make G1 the Default Garbage Collector In-Reply-To: References: <20150428220211.4355960845@eggemoggin.niobe.net> <5C5564BB-23ED-49AB-81C6-CFF85B56ACA4@kodewerk.com> <5540D689.6020407@oracle.com> <73855087-8BB2-4A8C-B9AD-080CD39FAB7A@kodewerk.com> <55423444.7040009@beckwithclan.com> <8DFF9BB7-3E76-4545-B5D9-07BE0D4693CB@oracle.com> <94973BE6-4FA4-45D9-A2F5-AF2B81226B4D@oracle.com> Message-ID: <7109616A-5C6C-47AA-9EA7-1E026C37D333@oracle.com> > On Jun 1, 2015, at 12:54 PM, Ben Evans wrote: > >>>> One question that may be worth pondering ? suppose G1 happened to be the default GC today, and there was a JEP to make Parallel GC the default GC. What would your reaction to that JEP be? I?m asking that question since I?d like to get a sense if your concerns are more about conservatism (not wanting to change behavior), stability of G1 or otherwise. >>> >>> Primarily conservatism. Of course, if G1 had been default, the >>> "unknown unknowns" would have been resolved by now, so there would be >>> no need to worry. >>> >>> I think that if G1 was default, and the platform was as successful >>> across the same range of workloads as it is today, I'd be advocating >>> for no change. >> >> Is that because you think G1 would offer a better out of the box experience than Parallel GC, or because you would not want to see a change made to the JVM?s default GC? > > I would not want to see a change made to the default behaviour that > could potentially negatively affect a large number of apps and in > doing so harm the long-term perception of the platform as a "safe pair > of hands?. And you also realize there could be a certain number (maybe as many as, or more) applications that could realize a better out of the box experience with G1 as the default versus Parallel GC being the default? Implying of course that the ?safe pair of hands? would have a better experience. thanks, charlie > > Thanks, > > Ben > -- > Ben Evans, Co-founder jClarity @jclarity From yu.zhang at oracle.com Mon Jun 1 18:28:34 2015 From: yu.zhang at oracle.com (Yu Zhang) Date: Mon, 01 Jun 2015 11:28:34 -0700 Subject: JEP 248: Make G1 the Default Garbage Collector In-Reply-To: References: <20150428220211.4355960845@eggemoggin.niobe.net> <5C5564BB-23ED-49AB-81C6-CFF85B56ACA4@kodewerk.com> <5540D689.6020407@oracle.com> <73855087-8BB2-4A8C-B9AD-080CD39FAB7A@kodewerk.com> <55423444.7040009@beckwithclan.com> Message-ID: <556CA452.9040405@oracle.com> Hi, I have done some performance comparison g1/cms/parallelgc internally at Oracle. I would like to post my observations here to get some feedback, as I have limited benchmarks and hardware. These are out of box performance. Memory footprint/startup: g1 has bigger memory footprint and longer start up time. The overhead comes from more gc threads, and internal data structures to keep track of remember set. g1 vs parallelgc: If the workload involves young gc only, g1 could be slightly slower. Also g1 can consume more cpu, which might slow down the benchmark if SUT is cpu saturated. If there are promotions from young to old gen and leads to full gc with parallelgc, for smaller heap, parallel full gc can finish within some range of pause time, still out performs g1. But for bigger heap, g1 mixed gc can clean the heap with pause times a fraction of parallel full gc time, so improve both throughput and response time. Extreme cases are big data workloads(for example ycsb) with 100g heap. g1 vs cms: I will focus on response time type of workloads. Ben mentioned "Having said that, there is definitely a decent-sized class of systems (not just in finance) that cannot really tolerate any more than about 10-15ms of STW. So, what usually happens is that they live with the young collections, use CMS and tune out the CMFs as best they can (by clustering, rolling restart, etc, etc). I don't see any possibility of G1 becoming a viable solution for those systems any time soon." Can you give more details, like what is the live data set size, how big is the heap, etc? I did some cache tests (Oracle coherence) to compare cms vs g1. g1 is better than cms when there are fragmentations. If you tune cms well to have little fragmentation, then g1 is behind cms. But for those cases, they have to tune CMS very well, changing default to g1 won't impact them. For big data kind of workloads (ycsb, spark in memory computing), g1 is much better than cms. Thanks, Jenny On 6/1/2015 10:06 AM, Ben Evans wrote: > Hi Vitaly, > >>> Instead, G1 is now being talked of as a replacement for the default >>> collector. If that's the case, then I think we need to acknowledge it, >>> and have a conversation about where G1 is actually supposed to be >>> used. Are we saying we want a "reasonably high throughput with reduced >>> STW, but not low pause time" collector? If we are, that's fine, but >>> that's not where we started. >> That's a fair point, and one I'd be interesting in hearing an answer to as >> well. FWIW, the only GC I know of that's actually used in low latency >> systems is Azul's C4, so I'm not even sure Oracle is trying to target the >> same use cases. So when we talk about "low latency" GCs, we should probably >> also be clear on what "low" actually means. > Well, when I started playing with them, "low latency" meant a > sub-10-ms transaction time with 100ms STW as acceptable, if not ideal. > > These days, the same sort of system needs a sub 500us transaction > time, and ideally no GC pause at all. But that leads to Zing, or > non-JVM solutions, and I think takes us too far into a specialised use > case. > > Having said that, there is definitely a decent-sized class of systems > (not just in finance) that cannot really tolerate any more than about > 10-15ms of STW. So, what usually happens is that they live with the > young collections, use CMS and tune out the CMFs as best they can (by > clustering, rolling restart, etc, etc). I don't see any possibility of > G1 becoming a viable solution for those systems any time soon. > > Thanks, > > Ben From charlie.hunt at oracle.com Mon Jun 1 18:32:29 2015 From: charlie.hunt at oracle.com (charlie hunt) Date: Mon, 1 Jun 2015 13:32:29 -0500 Subject: JEP 248: Make G1 the Default Garbage Collector In-Reply-To: References: <20150428220211.4355960845@eggemoggin.niobe.net> <5C5564BB-23ED-49AB-81C6-CFF85B56ACA4@kodewerk.com> <5540D689.6020407@oracle.com> <73855087-8BB2-4A8C-B9AD-080CD39FAB7A@kodewerk.com> <55423444.7040009@beckwithclan.com> <4391D841-07CD-4A37-8092-DABBA3C3A627@gmail.com> Message-ID: <26C79C0B-0199-4A3F-8578-78EE703563AC@oracle.com> I would have to defer to the compiler team to offer additional information above what is in the bug report. I see in the bug report that it is currently targeted to be fixed in JDK 9. Sorry, but that?s about all I know for details. charlie > On Jun 1, 2015, at 1:23 PM, Vitaly Davidovich wrote: > > Charlie, > > While we have your attention :), what is the status of the issues the Lucene guys highlighted earlier in this thread? In particular, this bug: https://bugs.openjdk.java.net/browse/JDK-8038348 . If there are known miscompilations, I'd say those are showstoppers for this JEP, no? > > Thanks > > On Mon, Jun 1, 2015 at 2:10 PM, charlie hunt > wrote: > > > On Jun 1, 2015, at 11:18 AM, Kirk Pepperdine > wrote: > > > > Hi Charlie, > > > > > > On Jun 1, 2015, at 5:25 PM, charlie hunt > wrote: > > > >> Hi Ben, > >> > >> A couple things to keep in mind. > >> > >> 1.) The impact of this JEP is limited to those Java applications that currently do not set a GC explicitly at the JVM command line. I think this is important to keep in mind as a starting point. A data point you may be able to help with is a survey of applications that do not set a GC explicit as a JVM command line option. I recall only seeing one Java application over the last 15 years that did not set a GC as a JVM command line option, and it was a Java GUI app. > > > > 3 of the 5 applications I?m currently tuning did not have the collector set on the command line. Of the 5, G1 should be appropriate for 4 of them bug existing unidentified bugs in G1 knock one off the list. > > At the risk of getting off topic a bit, what is the version of the JDK where you are seeing the one that has an unidentified bug in G1? > > Any additional description as to the observations, symptoms, etc on that one? > > > > >> > >> 2.) This JEP?s intent is not to replace the throughput collector (Parallel[Old]GC). The same applies to CMS GC. Folks who want to use, and do use the throughput collector or CMS GC can still use them. > > > > I?m sorry but as I?ve said before, I don?t find this a compelling argument. > > That?s ok, we can agree to disagree. :-) > > And, just to clarify, the potential impact for this JEP is that population of Java apps that do not set an explicit GC on the command line, and whether those application may see a better out of the box experience in terms of throughput, latency and footprint with G1 than with Parallel GC. > > > > >> > >> 3.) One might argue that if a GC is not explicitly specified at the JVM command line, then tuning GC may not be important for that application. In the event an application that does not set a GC explicitly at the command line experiences an observable performance regression, it would be able to restore its performance by setting -XX:+UseParallelOldGC on the JVM command line. > > > > Sorry but I don?t buy this argument either. Most of my customers are not well educated in GC tuning. It?s not that they are bad engineers, it?s just a matter of focus. > > I understand that it is a matter of focus. However, if those folks are not calling in an expert to tune GC, then they probably feel that the issue not that important for them address. > > At the same time, consider there may likely be cases where if G1 was the default collector, the need for calling in an expert to tune GC beyond G1?s defaults setting may not be needed. In other words, they would have a better out of the box experience with G1 than with Parallel GC. > > > > >> > >> To summarize, this JEP is about what GC to use when none is specified at the JVM command line. Hence its impact is limited to those configurations. > >> > >> To me it becomes a question of how many Java applications do not set an explicit GC at the command line, and how many of those want peak throughput performance with little concern of (occasional high) latency? This is a question I think the community could help us with. > > > > Agreed, the community should help and I?m sure they will/would but only if they know about this issue. As you know, we are both engaged in a lot of educational activities about how the JVM and in particular, GC works. As many as we?ve reached there seems to be 1000sx more that have maybe, maybe a vague idea of how it all works. That, and I still don?t believe we?ve had nearly enough time in the field with a stable version of the collector. I know that everyone in house is excited but I think the prudent thing to do here is hold off until 10. IOWs, out here in the wild, its looking good, very good, but its still not working as well as we hoped it would by now. > > For this JEP, I don?t think folks have to know how GC works to deal with the change in default collectors. For that population of apps that don?t set an explicit GC, they need to know that if they see a performance regression between a previous JDK to JDK 9, one of the things they should look at is setting / using Parallel GC, which would be in the release notes, or should they call in an expert, it would be one of the first changes suggested. > > thanks, > > charlie > > > > > Regards, > > Kirk > > > > From charlie.hunt at oracle.com Mon Jun 1 18:53:15 2015 From: charlie.hunt at oracle.com (charlie hunt) Date: Mon, 1 Jun 2015 13:53:15 -0500 Subject: JEP 248: Make G1 the Default Garbage Collector In-Reply-To: <556CA452.9040405@oracle.com> References: <20150428220211.4355960845@eggemoggin.niobe.net> <5C5564BB-23ED-49AB-81C6-CFF85B56ACA4@kodewerk.com> <5540D689.6020407@oracle.com> <73855087-8BB2-4A8C-B9AD-080CD39FAB7A@kodewerk.com> <55423444.7040009@beckwithclan.com> <556CA452.9040405@oracle.com> Message-ID: <7E7759C3-3AF0-4047-9B00-605DBB55DC79@oracle.com> Hi Jenny, A couple questions and comments below. thanks, charlie > On Jun 1, 2015, at 1:28 PM, Yu Zhang wrote: > > Hi, > > I have done some performance comparison g1/cms/parallelgc internally at Oracle. I would like to post my observations here to get some feedback, as I have limited benchmarks and hardware. These are out of box performance. > > Memory footprint/startup: > g1 has bigger memory footprint and longer start up time. The overhead comes from more gc threads, and internal data structures to keep track of remember set. This is the memory footprint of the JVM itself when using the same size Java heap, right? I don?t recall if it has been your observation? One observation I have had with G1 is that it tends to be able to operate within tolerable throughput and latency with a smaller Java heap than with Parallel GC. I have seen cases where G1 may not use the entire Java heap because it was able to keep enough free regions available yet still meet pause time goals. But, Parallel GC always use the entire Java heap, and once its occupancy reach capacity, it would GC. So they are cases where between the JVM?s footprint overhead, and taking into account the amount of Java heap required, G1 may actually require less memory. > > g1 vs parallelgc: > If the workload involves young gc only, g1 could be slightly slower. Also g1 can consume more cpu, which might slow down the benchmark if SUT is cpu saturated. > > If there are promotions from young to old gen and leads to full gc with parallelgc, for smaller heap, parallel full gc can finish within some range of pause time, still out performs g1. But for bigger heap, g1 mixed gc can clean the heap with pause times a fraction of parallel full gc time, so improve both throughput and response time. Extreme cases are big data workloads(for example ycsb) with 100g heap. I think what you are saying here is that it looks like if one can tune Parallel GC such that you can avoid a lengthy collection of old generation, or the live occupancy of old gen is small enough that the time to collect is small enough to be tolerated, then Parallel GC will offer a better experience. However, if the live data in old generation at the time of its collection is large enough such that the time it takes to collect it exceeds a tolerable pause time, then G1 will offer a better experience. Would also say that G1 offers a better experience in the presences of (wide) swings in object allocation rates since there would likely be a larger number of promotions during the allocation spikes? In other words, G1 may offer more predictable pauses. > > g1 vs cms: > I will focus on response time type of workloads. > Ben mentioned > > "Having said that, there is definitely a decent-sized class of systems > (not just in finance) that cannot really tolerate any more than about > 10-15ms of STW. So, what usually happens is that they live with the > young collections, use CMS and tune out the CMFs as best they can (by > clustering, rolling restart, etc, etc). I don't see any possibility of > G1 becoming a viable solution for those systems any time soon." > > Can you give more details, like what is the live data set size, how big is the heap, etc? I did some cache tests (Oracle coherence) to compare cms vs g1. g1 is better than cms when there are fragmentations. If you tune cms well to have little fragmentation, then g1 is behind cms. But for those cases, they have to tune CMS very well, changing default to g1 won't impact them. > > For big data kind of workloads (ycsb, spark in memory computing), g1 is much better than cms. > > Thanks, > Jenny > > On 6/1/2015 10:06 AM, Ben Evans wrote: >> Hi Vitaly, >> >>>> Instead, G1 is now being talked of as a replacement for the default >>>> collector. If that's the case, then I think we need to acknowledge it, >>>> and have a conversation about where G1 is actually supposed to be >>>> used. Are we saying we want a "reasonably high throughput with reduced >>>> STW, but not low pause time" collector? If we are, that's fine, but >>>> that's not where we started. >>> That's a fair point, and one I'd be interesting in hearing an answer to as >>> well. FWIW, the only GC I know of that's actually used in low latency >>> systems is Azul's C4, so I'm not even sure Oracle is trying to target the >>> same use cases. So when we talk about "low latency" GCs, we should probably >>> also be clear on what "low" actually means. >> Well, when I started playing with them, "low latency" meant a >> sub-10-ms transaction time with 100ms STW as acceptable, if not ideal. >> >> These days, the same sort of system needs a sub 500us transaction >> time, and ideally no GC pause at all. But that leads to Zing, or >> non-JVM solutions, and I think takes us too far into a specialised use >> case. >> >> Having said that, there is definitely a decent-sized class of systems >> (not just in finance) that cannot really tolerate any more than about >> 10-15ms of STW. So, what usually happens is that they live with the >> young collections, use CMS and tune out the CMFs as best they can (by >> clustering, rolling restart, etc, etc). I don't see any possibility of >> G1 becoming a viable solution for those systems any time soon. >> >> Thanks, >> >> Ben > From vitalyd at gmail.com Mon Jun 1 19:01:01 2015 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Mon, 1 Jun 2015 15:01:01 -0400 Subject: JEP 248: Make G1 the Default Garbage Collector In-Reply-To: <7E7759C3-3AF0-4047-9B00-605DBB55DC79@oracle.com> References: <20150428220211.4355960845@eggemoggin.niobe.net> <5C5564BB-23ED-49AB-81C6-CFF85B56ACA4@kodewerk.com> <5540D689.6020407@oracle.com> <73855087-8BB2-4A8C-B9AD-080CD39FAB7A@kodewerk.com> <55423444.7040009@beckwithclan.com> <556CA452.9040405@oracle.com> <7E7759C3-3AF0-4047-9B00-605DBB55DC79@oracle.com> Message-ID: Also, G1 also has heavier write barriers than parallel gc, so some existing workloads that don't stress the GC (e.g. code written purposely to avoid GC during uptime by, say, object pooling) and wouldn't have tweaked the default may experience some degradation. On Mon, Jun 1, 2015 at 2:53 PM, charlie hunt wrote: > Hi Jenny, > > A couple questions and comments below. > > thanks, > > charlie > > > On Jun 1, 2015, at 1:28 PM, Yu Zhang wrote: > > > > Hi, > > > > I have done some performance comparison g1/cms/parallelgc internally at > Oracle. I would like to post my observations here to get some feedback, as > I have limited benchmarks and hardware. These are out of box performance. > > > > Memory footprint/startup: > > g1 has bigger memory footprint and longer start up time. The overhead > comes from more gc threads, and internal data structures to keep track of > remember set. > > This is the memory footprint of the JVM itself when using the same size > Java heap, right? > > I don?t recall if it has been your observation? One observation I have > had with G1 is that it tends to be able to operate within tolerable > throughput and latency with a smaller Java heap than with Parallel GC. I > have seen cases where G1 may not use the entire Java heap because it was > able to keep enough free regions available yet still meet pause time goals. > But, Parallel GC always use the entire Java heap, and once its occupancy > reach capacity, it would GC. So they are cases where between the JVM?s > footprint overhead, and taking into account the amount of Java heap > required, G1 may actually require less memory. > > > > > g1 vs parallelgc: > > If the workload involves young gc only, g1 could be slightly slower. > Also g1 can consume more cpu, which might slow down the benchmark if SUT is > cpu saturated. > > > > If there are promotions from young to old gen and leads to full gc with > parallelgc, for smaller heap, parallel full gc can finish within some range > of pause time, still out performs g1. But for bigger heap, g1 mixed gc can > clean the heap with pause times a fraction of parallel full gc time, so > improve both throughput and response time. Extreme cases are big data > workloads(for example ycsb) with 100g heap. > > I think what you are saying here is that it looks like if one can tune > Parallel GC such that you can avoid a lengthy collection of old generation, > or the live occupancy of old gen is small enough that the time to collect > is small enough to be tolerated, then Parallel GC will offer a better > experience. > > However, if the live data in old generation at the time of its collection > is large enough such that the time it takes to collect it exceeds a > tolerable pause time, then G1 will offer a better experience. > > Would also say that G1 offers a better experience in the presences of > (wide) swings in object allocation rates since there would likely be a > larger number of promotions during the allocation spikes? In other words, > G1 may offer more predictable pauses. > > > > > g1 vs cms: > > I will focus on response time type of workloads. > > Ben mentioned > > > > "Having said that, there is definitely a decent-sized class of systems > > (not just in finance) that cannot really tolerate any more than about > > 10-15ms of STW. So, what usually happens is that they live with the > > young collections, use CMS and tune out the CMFs as best they can (by > > clustering, rolling restart, etc, etc). I don't see any possibility of > > G1 becoming a viable solution for those systems any time soon." > > > > Can you give more details, like what is the live data set size, how big > is the heap, etc? I did some cache tests (Oracle coherence) to compare cms > vs g1. g1 is better than cms when there are fragmentations. If you tune cms > well to have little fragmentation, then g1 is behind cms. But for those > cases, they have to tune CMS very well, changing default to g1 won't impact > them. > > > > For big data kind of workloads (ycsb, spark in memory computing), g1 is > much better than cms. > > > > Thanks, > > Jenny > > > > On 6/1/2015 10:06 AM, Ben Evans wrote: > >> Hi Vitaly, > >> > >>>> Instead, G1 is now being talked of as a replacement for the default > >>>> collector. If that's the case, then I think we need to acknowledge it, > >>>> and have a conversation about where G1 is actually supposed to be > >>>> used. Are we saying we want a "reasonably high throughput with reduced > >>>> STW, but not low pause time" collector? If we are, that's fine, but > >>>> that's not where we started. > >>> That's a fair point, and one I'd be interesting in hearing an answer > to as > >>> well. FWIW, the only GC I know of that's actually used in low latency > >>> systems is Azul's C4, so I'm not even sure Oracle is trying to target > the > >>> same use cases. So when we talk about "low latency" GCs, we should > probably > >>> also be clear on what "low" actually means. > >> Well, when I started playing with them, "low latency" meant a > >> sub-10-ms transaction time with 100ms STW as acceptable, if not ideal. > >> > >> These days, the same sort of system needs a sub 500us transaction > >> time, and ideally no GC pause at all. But that leads to Zing, or > >> non-JVM solutions, and I think takes us too far into a specialised use > >> case. > >> > >> Having said that, there is definitely a decent-sized class of systems > >> (not just in finance) that cannot really tolerate any more than about > >> 10-15ms of STW. So, what usually happens is that they live with the > >> young collections, use CMS and tune out the CMFs as best they can (by > >> clustering, rolling restart, etc, etc). I don't see any possibility of > >> G1 becoming a viable solution for those systems any time soon. > >> > >> Thanks, > >> > >> Ben > > > > From charlie.hunt at oracle.com Mon Jun 1 19:12:24 2015 From: charlie.hunt at oracle.com (charlie hunt) Date: Mon, 1 Jun 2015 14:12:24 -0500 Subject: JEP 248: Make G1 the Default Garbage Collector In-Reply-To: References: <20150428220211.4355960845@eggemoggin.niobe.net> <5C5564BB-23ED-49AB-81C6-CFF85B56ACA4@kodewerk.com> <5540D689.6020407@oracle.com> <73855087-8BB2-4A8C-B9AD-080CD39FAB7A@kodewerk.com> <55423444.7040009@beckwithclan.com> <556CA452.9040405@oracle.com> <7E7759C3-3AF0-4047-9B00-605DBB55DC79@oracle.com> Message-ID: <8815A8AF-0C3A-44DD-86BD-18E373ED2C60@oracle.com> Yep, that?s right. I suppose it is worth mentioning that the population of apps that don?t stress GC is pretty small compared to those that do. ;-) > On Jun 1, 2015, at 2:01 PM, Vitaly Davidovich wrote: > > Also, G1 also has heavier write barriers than parallel gc, so some existing workloads that don't stress the GC (e.g. code written purposely to avoid GC during uptime by, say, object pooling) and wouldn't have tweaked the default may experience some degradation. > > On Mon, Jun 1, 2015 at 2:53 PM, charlie hunt > wrote: > Hi Jenny, > > A couple questions and comments below. > > thanks, > > charlie > > > On Jun 1, 2015, at 1:28 PM, Yu Zhang > wrote: > > > > Hi, > > > > I have done some performance comparison g1/cms/parallelgc internally at Oracle. I would like to post my observations here to get some feedback, as I have limited benchmarks and hardware. These are out of box performance. > > > > Memory footprint/startup: > > g1 has bigger memory footprint and longer start up time. The overhead comes from more gc threads, and internal data structures to keep track of remember set. > > This is the memory footprint of the JVM itself when using the same size Java heap, right? > > I don?t recall if it has been your observation? One observation I have had with G1 is that it tends to be able to operate within tolerable throughput and latency with a smaller Java heap than with Parallel GC. I have seen cases where G1 may not use the entire Java heap because it was able to keep enough free regions available yet still meet pause time goals. But, Parallel GC always use the entire Java heap, and once its occupancy reach capacity, it would GC. So they are cases where between the JVM?s footprint overhead, and taking into account the amount of Java heap required, G1 may actually require less memory. > > > > > g1 vs parallelgc: > > If the workload involves young gc only, g1 could be slightly slower. Also g1 can consume more cpu, which might slow down the benchmark if SUT is cpu saturated. > > > > If there are promotions from young to old gen and leads to full gc with parallelgc, for smaller heap, parallel full gc can finish within some range of pause time, still out performs g1. But for bigger heap, g1 mixed gc can clean the heap with pause times a fraction of parallel full gc time, so improve both throughput and response time. Extreme cases are big data workloads(for example ycsb) with 100g heap. > > I think what you are saying here is that it looks like if one can tune Parallel GC such that you can avoid a lengthy collection of old generation, or the live occupancy of old gen is small enough that the time to collect is small enough to be tolerated, then Parallel GC will offer a better experience. > > However, if the live data in old generation at the time of its collection is large enough such that the time it takes to collect it exceeds a tolerable pause time, then G1 will offer a better experience. > > Would also say that G1 offers a better experience in the presences of (wide) swings in object allocation rates since there would likely be a larger number of promotions during the allocation spikes? In other words, G1 may offer more predictable pauses. > > > > > g1 vs cms: > > I will focus on response time type of workloads. > > Ben mentioned > > > > "Having said that, there is definitely a decent-sized class of systems > > (not just in finance) that cannot really tolerate any more than about > > 10-15ms of STW. So, what usually happens is that they live with the > > young collections, use CMS and tune out the CMFs as best they can (by > > clustering, rolling restart, etc, etc). I don't see any possibility of > > G1 becoming a viable solution for those systems any time soon." > > > > Can you give more details, like what is the live data set size, how big is the heap, etc? I did some cache tests (Oracle coherence) to compare cms vs g1. g1 is better than cms when there are fragmentations. If you tune cms well to have little fragmentation, then g1 is behind cms. But for those cases, they have to tune CMS very well, changing default to g1 won't impact them. > > > > For big data kind of workloads (ycsb, spark in memory computing), g1 is much better than cms. > > > > Thanks, > > Jenny > > > > On 6/1/2015 10:06 AM, Ben Evans wrote: > >> Hi Vitaly, > >> > >>>> Instead, G1 is now being talked of as a replacement for the default > >>>> collector. If that's the case, then I think we need to acknowledge it, > >>>> and have a conversation about where G1 is actually supposed to be > >>>> used. Are we saying we want a "reasonably high throughput with reduced > >>>> STW, but not low pause time" collector? If we are, that's fine, but > >>>> that's not where we started. > >>> That's a fair point, and one I'd be interesting in hearing an answer to as > >>> well. FWIW, the only GC I know of that's actually used in low latency > >>> systems is Azul's C4, so I'm not even sure Oracle is trying to target the > >>> same use cases. So when we talk about "low latency" GCs, we should probably > >>> also be clear on what "low" actually means. > >> Well, when I started playing with them, "low latency" meant a > >> sub-10-ms transaction time with 100ms STW as acceptable, if not ideal. > >> > >> These days, the same sort of system needs a sub 500us transaction > >> time, and ideally no GC pause at all. But that leads to Zing, or > >> non-JVM solutions, and I think takes us too far into a specialised use > >> case. > >> > >> Having said that, there is definitely a decent-sized class of systems > >> (not just in finance) that cannot really tolerate any more than about > >> 10-15ms of STW. So, what usually happens is that they live with the > >> young collections, use CMS and tune out the CMFs as best they can (by > >> clustering, rolling restart, etc, etc). I don't see any possibility of > >> G1 becoming a viable solution for those systems any time soon. > >> > >> Thanks, > >> > >> Ben > > > > From yu.zhang at oracle.com Mon Jun 1 19:14:20 2015 From: yu.zhang at oracle.com (Yu Zhang) Date: Mon, 01 Jun 2015 12:14:20 -0700 Subject: JEP 248: Make G1 the Default Garbage Collector In-Reply-To: <7E7759C3-3AF0-4047-9B00-605DBB55DC79@oracle.com> References: <20150428220211.4355960845@eggemoggin.niobe.net> <5C5564BB-23ED-49AB-81C6-CFF85B56ACA4@kodewerk.com> <5540D689.6020407@oracle.com> <73855087-8BB2-4A8C-B9AD-080CD39FAB7A@kodewerk.com> <55423444.7040009@beckwithclan.com> <556CA452.9040405@oracle.com> <7E7759C3-3AF0-4047-9B00-605DBB55DC79@oracle.com> Message-ID: <556CAF0C.50006@oracle.com> Charlie, Thanks for the feedback. Please see my comments in line. Thanks, Jenny On 6/1/2015 11:53 AM, charlie hunt wrote: > Hi Jenny, > > A couple questions and comments below. > > thanks, > > charlie > >> On Jun 1, 2015, at 1:28 PM, Yu Zhang wrote: >> >> Hi, >> >> I have done some performance comparison g1/cms/parallelgc internally at Oracle. I would like to post my observations here to get some feedback, as I have limited benchmarks and hardware. These are out of box performance. >> >> Memory footprint/startup: >> g1 has bigger memory footprint and longer start up time. The overhead comes from more gc threads, and internal data structures to keep track of remember set. > This is the memory footprint of the JVM itself when using the same size Java heap, right? good question. My comments might have caused some confusion here. It is just starting simple applications, with -XX:+UseG1GC/ParallelGC only(no heap size limitation), and measure the RSS size. I only tested on Linux x86_64, other OS might touch the page differently. > > I don?t recall if it has been your observation? One observation I have had with G1 is that it tends to be able to operate within tolerable throughput and latency with a smaller Java heap than with Parallel GC. I have seen cases where G1 may not use the entire Java heap because it was able to keep enough free regions available yet still meet pause time goals. But, Parallel GC always use the entire Java heap, and once its occupancy reach capacity, it would GC. So they are cases where between the JVM?s footprint overhead, and taking into account the amount of Java heap required, G1 may actually require less memory. Since the memory footprint/start up tests just measure RSS without running the benchmark, these comments do not apply to the overall memory footprint for the benchmark. You've brought up an interesting point. I will dig out some of the data I collected for some benchmarks and see if that is the case. > >> g1 vs parallelgc: >> If the workload involves young gc only, g1 could be slightly slower. Also g1 can consume more cpu, which might slow down the benchmark if SUT is cpu saturated. >> >> If there are promotions from young to old gen and leads to full gc with parallelgc, for smaller heap, parallel full gc can finish within some range of pause time, still out performs g1. But for bigger heap, g1 mixed gc can clean the heap with pause times a fraction of parallel full gc time, so improve both throughput and response time. Extreme cases are big data workloads(for example ycsb) with 100g heap. > I think what you are saying here is that it looks like if one can tune Parallel GC such that you can avoid a lengthy collection of old generation, or the live occupancy of old gen is small enough that the time to collect is small enough to be tolerated, then Parallel GC will offer a better experience. > > However, if the live data in old generation at the time of its collection is large enough such that the time it takes to collect it exceeds a tolerable pause time, then G1 will offer a better experience. > > Would also say that G1 offers a better experience in the presences of (wide) swings in object allocation rates since there would likely be a larger number of promotions during the allocation spikes? In other words, G1 may offer more predictable pauses. > >> g1 vs cms: >> I will focus on response time type of workloads. >> Ben mentioned >> >> "Having said that, there is definitely a decent-sized class of systems >> (not just in finance) that cannot really tolerate any more than about >> 10-15ms of STW. So, what usually happens is that they live with the >> young collections, use CMS and tune out the CMFs as best they can (by >> clustering, rolling restart, etc, etc). I don't see any possibility of >> G1 becoming a viable solution for those systems any time soon." >> >> Can you give more details, like what is the live data set size, how big is the heap, etc? I did some cache tests (Oracle coherence) to compare cms vs g1. g1 is better than cms when there are fragmentations. If you tune cms well to have little fragmentation, then g1 is behind cms. But for those cases, they have to tune CMS very well, changing default to g1 won't impact them. >> >> For big data kind of workloads (ycsb, spark in memory computing), g1 is much better than cms. >> >> Thanks, >> Jenny >> >> On 6/1/2015 10:06 AM, Ben Evans wrote: >>> Hi Vitaly, >>> >>>>> Instead, G1 is now being talked of as a replacement for the default >>>>> collector. If that's the case, then I think we need to acknowledge it, >>>>> and have a conversation about where G1 is actually supposed to be >>>>> used. Are we saying we want a "reasonably high throughput with reduced >>>>> STW, but not low pause time" collector? If we are, that's fine, but >>>>> that's not where we started. >>>> That's a fair point, and one I'd be interesting in hearing an answer to as >>>> well. FWIW, the only GC I know of that's actually used in low latency >>>> systems is Azul's C4, so I'm not even sure Oracle is trying to target the >>>> same use cases. So when we talk about "low latency" GCs, we should probably >>>> also be clear on what "low" actually means. >>> Well, when I started playing with them, "low latency" meant a >>> sub-10-ms transaction time with 100ms STW as acceptable, if not ideal. >>> >>> These days, the same sort of system needs a sub 500us transaction >>> time, and ideally no GC pause at all. But that leads to Zing, or >>> non-JVM solutions, and I think takes us too far into a specialised use >>> case. >>> >>> Having said that, there is definitely a decent-sized class of systems >>> (not just in finance) that cannot really tolerate any more than about >>> 10-15ms of STW. So, what usually happens is that they live with the >>> young collections, use CMS and tune out the CMFs as best they can (by >>> clustering, rolling restart, etc, etc). I don't see any possibility of >>> G1 becoming a viable solution for those systems any time soon. >>> >>> Thanks, >>> >>> Ben From vitalyd at gmail.com Mon Jun 1 19:16:50 2015 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Mon, 1 Jun 2015 15:16:50 -0400 Subject: JEP 248: Make G1 the Default Garbage Collector In-Reply-To: <8815A8AF-0C3A-44DD-86BD-18E373ED2C60@oracle.com> References: <20150428220211.4355960845@eggemoggin.niobe.net> <5C5564BB-23ED-49AB-81C6-CFF85B56ACA4@kodewerk.com> <5540D689.6020407@oracle.com> <73855087-8BB2-4A8C-B9AD-080CD39FAB7A@kodewerk.com> <55423444.7040009@beckwithclan.com> <556CA452.9040405@oracle.com> <7E7759C3-3AF0-4047-9B00-605DBB55DC79@oracle.com> <8815A8AF-0C3A-44DD-86BD-18E373ED2C60@oracle.com> Message-ID: > > I suppose it is worth mentioning that the population of apps that don?t > stress GC is pretty small compared to those that do. ;-) Sadly, that's true :). On Mon, Jun 1, 2015 at 3:12 PM, charlie hunt wrote: > Yep, that?s right. > > I suppose it is worth mentioning that the population of apps that don?t > stress GC is pretty small compared to those that do. ;-) > > On Jun 1, 2015, at 2:01 PM, Vitaly Davidovich wrote: > > Also, G1 also has heavier write barriers than parallel gc, so some > existing workloads that don't stress the GC (e.g. code written purposely to > avoid GC during uptime by, say, object pooling) and wouldn't have tweaked > the default may experience some degradation. > > On Mon, Jun 1, 2015 at 2:53 PM, charlie hunt > wrote: > >> Hi Jenny, >> >> A couple questions and comments below. >> >> thanks, >> >> charlie >> >> > On Jun 1, 2015, at 1:28 PM, Yu Zhang wrote: >> > >> > Hi, >> > >> > I have done some performance comparison g1/cms/parallelgc internally at >> Oracle. I would like to post my observations here to get some feedback, as >> I have limited benchmarks and hardware. These are out of box performance. >> > >> > Memory footprint/startup: >> > g1 has bigger memory footprint and longer start up time. The overhead >> comes from more gc threads, and internal data structures to keep track of >> remember set. >> >> This is the memory footprint of the JVM itself when using the same size >> Java heap, right? >> >> I don?t recall if it has been your observation? One observation I have >> had with G1 is that it tends to be able to operate within tolerable >> throughput and latency with a smaller Java heap than with Parallel GC. I >> have seen cases where G1 may not use the entire Java heap because it was >> able to keep enough free regions available yet still meet pause time goals. >> But, Parallel GC always use the entire Java heap, and once its occupancy >> reach capacity, it would GC. So they are cases where between the JVM?s >> footprint overhead, and taking into account the amount of Java heap >> required, G1 may actually require less memory. >> >> > >> > g1 vs parallelgc: >> > If the workload involves young gc only, g1 could be slightly slower. >> Also g1 can consume more cpu, which might slow down the benchmark if SUT is >> cpu saturated. >> > >> > If there are promotions from young to old gen and leads to full gc with >> parallelgc, for smaller heap, parallel full gc can finish within some range >> of pause time, still out performs g1. But for bigger heap, g1 mixed gc can >> clean the heap with pause times a fraction of parallel full gc time, so >> improve both throughput and response time. Extreme cases are big data >> workloads(for example ycsb) with 100g heap. >> >> I think what you are saying here is that it looks like if one can tune >> Parallel GC such that you can avoid a lengthy collection of old generation, >> or the live occupancy of old gen is small enough that the time to collect >> is small enough to be tolerated, then Parallel GC will offer a better >> experience. >> >> However, if the live data in old generation at the time of its collection >> is large enough such that the time it takes to collect it exceeds a >> tolerable pause time, then G1 will offer a better experience. >> >> Would also say that G1 offers a better experience in the presences of >> (wide) swings in object allocation rates since there would likely be a >> larger number of promotions during the allocation spikes? In other words, >> G1 may offer more predictable pauses. >> >> > >> > g1 vs cms: >> > I will focus on response time type of workloads. >> > Ben mentioned >> > >> > "Having said that, there is definitely a decent-sized class of systems >> > (not just in finance) that cannot really tolerate any more than about >> > 10-15ms of STW. So, what usually happens is that they live with the >> > young collections, use CMS and tune out the CMFs as best they can (by >> > clustering, rolling restart, etc, etc). I don't see any possibility of >> > G1 becoming a viable solution for those systems any time soon." >> > >> > Can you give more details, like what is the live data set size, how big >> is the heap, etc? I did some cache tests (Oracle coherence) to compare cms >> vs g1. g1 is better than cms when there are fragmentations. If you tune cms >> well to have little fragmentation, then g1 is behind cms. But for those >> cases, they have to tune CMS very well, changing default to g1 won't impact >> them. >> > >> > For big data kind of workloads (ycsb, spark in memory computing), g1 is >> much better than cms. >> > >> > Thanks, >> > Jenny >> > >> > On 6/1/2015 10:06 AM, Ben Evans wrote: >> >> Hi Vitaly, >> >> >> >>>> Instead, G1 is now being talked of as a replacement for the default >> >>>> collector. If that's the case, then I think we need to acknowledge >> it, >> >>>> and have a conversation about where G1 is actually supposed to be >> >>>> used. Are we saying we want a "reasonably high throughput with >> reduced >> >>>> STW, but not low pause time" collector? If we are, that's fine, but >> >>>> that's not where we started. >> >>> That's a fair point, and one I'd be interesting in hearing an answer >> to as >> >>> well. FWIW, the only GC I know of that's actually used in low latency >> >>> systems is Azul's C4, so I'm not even sure Oracle is trying to target >> the >> >>> same use cases. So when we talk about "low latency" GCs, we should >> probably >> >>> also be clear on what "low" actually means. >> >> Well, when I started playing with them, "low latency" meant a >> >> sub-10-ms transaction time with 100ms STW as acceptable, if not ideal. >> >> >> >> These days, the same sort of system needs a sub 500us transaction >> >> time, and ideally no GC pause at all. But that leads to Zing, or >> >> non-JVM solutions, and I think takes us too far into a specialised use >> >> case. >> >> >> >> Having said that, there is definitely a decent-sized class of systems >> >> (not just in finance) that cannot really tolerate any more than about >> >> 10-15ms of STW. So, what usually happens is that they live with the >> >> young collections, use CMS and tune out the CMFs as best they can (by >> >> clustering, rolling restart, etc, etc). I don't see any possibility of >> >> G1 becoming a viable solution for those systems any time soon. >> >> >> >> Thanks, >> >> >> >> Ben >> > >> >> > > From yu.zhang at oracle.com Mon Jun 1 19:16:58 2015 From: yu.zhang at oracle.com (Yu Zhang) Date: Mon, 01 Jun 2015 12:16:58 -0700 Subject: JEP 248: Make G1 the Default Garbage Collector In-Reply-To: <556CAF0C.50006@oracle.com> References: <20150428220211.4355960845@eggemoggin.niobe.net> <5C5564BB-23ED-49AB-81C6-CFF85B56ACA4@kodewerk.com> <5540D689.6020407@oracle.com> <73855087-8BB2-4A8C-B9AD-080CD39FAB7A@kodewerk.com> <55423444.7040009@beckwithclan.com> <556CA452.9040405@oracle.com> <7E7759C3-3AF0-4047-9B00-605DBB55DC79@oracle.com> <556CAF0C.50006@oracle.com> Message-ID: <556CAFAA.5060202@oracle.com> forgot to mention your comment on g1 vs parallelgc. I think that is a very good summary. Thanks, Jenny On 6/1/2015 12:14 PM, Yu Zhang wrote: > Charlie, > > Thanks for the feedback. Please see my comments in line. > Thanks, > Jenny > On 6/1/2015 11:53 AM, charlie hunt wrote: >> Hi Jenny, >> >> A couple questions and comments below. >> >> thanks, >> >> charlie >> >>> On Jun 1, 2015, at 1:28 PM, Yu Zhang wrote: >>> >>> Hi, >>> >>> I have done some performance comparison g1/cms/parallelgc internally at Oracle. I would like to post my observations here to get some feedback, as I have limited benchmarks and hardware. These are out of box performance. >>> >>> Memory footprint/startup: >>> g1 has bigger memory footprint and longer start up time. The overhead comes from more gc threads, and internal data structures to keep track of remember set. >> This is the memory footprint of the JVM itself when using the same size Java heap, right? > good question. My comments might have caused some confusion here. It > is just starting simple applications, with -XX:+UseG1GC/ParallelGC > only(no heap size limitation), and measure the RSS size. I only > tested on Linux x86_64, other OS might touch the page differently. >> I don?t recall if it has been your observation? One observation I have had with G1 is that it tends to be able to operate within tolerable throughput and latency with a smaller Java heap than with Parallel GC. I have seen cases where G1 may not use the entire Java heap because it was able to keep enough free regions available yet still meet pause time goals. But, Parallel GC always use the entire Java heap, and once its occupancy reach capacity, it would GC. So they are cases where between the JVM?s footprint overhead, and taking into account the amount of Java heap required, G1 may actually require less memory. > Since the memory footprint/start up tests just measure RSS without > running the benchmark, these comments do not apply to the overall > memory footprint for the benchmark. You've brought up an interesting > point. I will dig out some of the data I collected for some > benchmarks and see if that is the case. >>> g1 vs parallelgc: >>> If the workload involves young gc only, g1 could be slightly slower. Also g1 can consume more cpu, which might slow down the benchmark if SUT is cpu saturated. >>> >>> If there are promotions from young to old gen and leads to full gc with parallelgc, for smaller heap, parallel full gc can finish within some range of pause time, still out performs g1. But for bigger heap, g1 mixed gc can clean the heap with pause times a fraction of parallel full gc time, so improve both throughput and response time. Extreme cases are big data workloads(for example ycsb) with 100g heap. >> I think what you are saying here is that it looks like if one can tune Parallel GC such that you can avoid a lengthy collection of old generation, or the live occupancy of old gen is small enough that the time to collect is small enough to be tolerated, then Parallel GC will offer a better experience. >> >> However, if the live data in old generation at the time of its collection is large enough such that the time it takes to collect it exceeds a tolerable pause time, then G1 will offer a better experience. >> >> Would also say that G1 offers a better experience in the presences of (wide) swings in object allocation rates since there would likely be a larger number of promotions during the allocation spikes? In other words, G1 may offer more predictable pauses. >> >>> g1 vs cms: >>> I will focus on response time type of workloads. >>> Ben mentioned >>> >>> "Having said that, there is definitely a decent-sized class of systems >>> (not just in finance) that cannot really tolerate any more than about >>> 10-15ms of STW. So, what usually happens is that they live with the >>> young collections, use CMS and tune out the CMFs as best they can (by >>> clustering, rolling restart, etc, etc). I don't see any possibility of >>> G1 becoming a viable solution for those systems any time soon." >>> >>> Can you give more details, like what is the live data set size, how big is the heap, etc? I did some cache tests (Oracle coherence) to compare cms vs g1. g1 is better than cms when there are fragmentations. If you tune cms well to have little fragmentation, then g1 is behind cms. But for those cases, they have to tune CMS very well, changing default to g1 won't impact them. >>> >>> For big data kind of workloads (ycsb, spark in memory computing), g1 is much better than cms. >>> >>> Thanks, >>> Jenny >>> >>> On 6/1/2015 10:06 AM, Ben Evans wrote: >>>> Hi Vitaly, >>>> >>>>>> Instead, G1 is now being talked of as a replacement for the default >>>>>> collector. If that's the case, then I think we need to acknowledge it, >>>>>> and have a conversation about where G1 is actually supposed to be >>>>>> used. Are we saying we want a "reasonably high throughput with reduced >>>>>> STW, but not low pause time" collector? If we are, that's fine, but >>>>>> that's not where we started. >>>>> That's a fair point, and one I'd be interesting in hearing an answer to as >>>>> well. FWIW, the only GC I know of that's actually used in low latency >>>>> systems is Azul's C4, so I'm not even sure Oracle is trying to target the >>>>> same use cases. So when we talk about "low latency" GCs, we should probably >>>>> also be clear on what "low" actually means. >>>> Well, when I started playing with them, "low latency" meant a >>>> sub-10-ms transaction time with 100ms STW as acceptable, if not ideal. >>>> >>>> These days, the same sort of system needs a sub 500us transaction >>>> time, and ideally no GC pause at all. But that leads to Zing, or >>>> non-JVM solutions, and I think takes us too far into a specialised use >>>> case. >>>> >>>> Having said that, there is definitely a decent-sized class of systems >>>> (not just in finance) that cannot really tolerate any more than about >>>> 10-15ms of STW. So, what usually happens is that they live with the >>>> young collections, use CMS and tune out the CMFs as best they can (by >>>> clustering, rolling restart, etc, etc). I don't see any possibility of >>>> G1 becoming a viable solution for those systems any time soon. >>>> >>>> Thanks, >>>> >>>> Ben > From erik.osterlund at lnu.se Mon Jun 1 19:53:22 2015 From: erik.osterlund at lnu.se (=?iso-8859-1?Q?Erik_=D6sterlund?=) Date: Mon, 1 Jun 2015 19:53:22 +0000 Subject: JEP 248: Make G1 the Default Garbage Collector In-Reply-To: <7E7759C3-3AF0-4047-9B00-605DBB55DC79@oracle.com> References: <20150428220211.4355960845@eggemoggin.niobe.net> <5C5564BB-23ED-49AB-81C6-CFF85B56ACA4@kodewerk.com> <5540D689.6020407@oracle.com> <73855087-8BB2-4A8C-B9AD-080CD39FAB7A@kodewerk.com> <55423444.7040009@beckwithclan.com> <556CA452.9040405@oracle.com> <7E7759C3-3AF0-4047-9B00-605DBB55DC79@oracle.com> Message-ID: Hi all, Does there have to be a single default one-size-fits-all GC algorithm for users to rely on? Or could we allow multiple algorithms and explicitly document that unless a GC is picked, the runtime is free to pick whatever it believes is better? This could have multiple benefits. 1. This could make such a similar change easier in the future as everyone will already be aware that if they really rely on the properties of a specific GC algorithm, then they should choose that GC explicitly and not rely on defaults not changing; there are no guarantees that defaults will not change. 2. Obviously there has been a long discussion in this thread which GC is better in which context, and it seems like right now one size does not fit all. The user that relied on the defaults might not be so aware of these specifics. Therefore we might do them a big favour of attempting to make a guess for them to work out-of-the-box, which is pretty neat. 3. This approach allows deploying G1 not everywhere, but where we guess it performs pretty well. This means it will run in fewer JVM contexts and hence pose less risk than deploying it to be used for all contexts, making the transition smoother. One idea could be to first determine valid GC variants given the supplied flags (GC-specific flags imply use of that GC), and then among the valid GCs left, ?guess? which algorithm is better based on the other general parameters, such as e.g. heap size (and maybe target latency)? Could for instance pick ParallelGC for small heaps, G1 for larger heaps and CMS for ridiculously large heaps or cases when extremely low latency is wanted? My reasoning is based on two assumptions: 1) changing the defaults would target the users that don?t know what?s best for them, 2) one size does not fit all. If these assumption are wrong, then this is a bad idea. Thanks, /Erik Den 01/06/15 20:53 skrev charlie hunt : >Hi Jenny, > >A couple questions and comments below. > >thanks, > >charlie > >> On Jun 1, 2015, at 1:28 PM, Yu Zhang wrote: >> >> Hi, >> >> I have done some performance comparison g1/cms/parallelgc internally at >>Oracle. I would like to post my observations here to get some feedback, >>as I have limited benchmarks and hardware. These are out of box >>performance. >> >> Memory footprint/startup: >> g1 has bigger memory footprint and longer start up time. The overhead >>comes from more gc threads, and internal data structures to keep track >>of remember set. > >This is the memory footprint of the JVM itself when using the same size >Java heap, right? > >I don?t recall if it has been your observation? One observation I have >had with G1 is that it tends to be able to operate within tolerable >throughput and latency with a smaller Java heap than with Parallel GC. I >have seen cases where G1 may not use the entire Java heap because it was >able to keep enough free regions available yet still meet pause time >goals. But, Parallel GC always use the entire Java heap, and once its >occupancy reach capacity, it would GC. So they are cases where between >the JVM?s footprint overhead, and taking into account the amount of Java >heap required, G1 may actually require less memory. > >> >> g1 vs parallelgc: >> If the workload involves young gc only, g1 could be slightly slower. >>Also g1 can consume more cpu, which might slow down the benchmark if SUT >>is cpu saturated. >> >> If there are promotions from young to old gen and leads to full gc with >>parallelgc, for smaller heap, parallel full gc can finish within some >>range of pause time, still out performs g1. But for bigger heap, g1 >>mixed gc can clean the heap with pause times a fraction of parallel full >>gc time, so improve both throughput and response time. Extreme cases >>are big data workloads(for example ycsb) with 100g heap. > >I think what you are saying here is that it looks like if one can tune >Parallel GC such that you can avoid a lengthy collection of old >generation, or the live occupancy of old gen is small enough that the >time to collect is small enough to be tolerated, then Parallel GC will >offer a better experience. > >However, if the live data in old generation at the time of its collection >is large enough such that the time it takes to collect it exceeds a >tolerable pause time, then G1 will offer a better experience. > >Would also say that G1 offers a better experience in the presences of >(wide) swings in object allocation rates since there would likely be a >larger number of promotions during the allocation spikes? In other >words, G1 may offer more predictable pauses. > >> >> g1 vs cms: >> I will focus on response time type of workloads. >> Ben mentioned >> >> "Having said that, there is definitely a decent-sized class of systems >> (not just in finance) that cannot really tolerate any more than about >> 10-15ms of STW. So, what usually happens is that they live with the >> young collections, use CMS and tune out the CMFs as best they can (by >> clustering, rolling restart, etc, etc). I don't see any possibility of >> G1 becoming a viable solution for those systems any time soon." >> >> Can you give more details, like what is the live data set size, how big >>is the heap, etc? I did some cache tests (Oracle coherence) to compare >>cms vs g1. g1 is better than cms when there are fragmentations. If you >>tune cms well to have little fragmentation, then g1 is behind cms. But >>for those cases, they have to tune CMS very well, changing default to g1 >>won't impact them. >> >> For big data kind of workloads (ycsb, spark in memory computing), g1 is >>much better than cms. >> >> Thanks, >> Jenny >> >> On 6/1/2015 10:06 AM, Ben Evans wrote: >>> Hi Vitaly, >>> >>>>> Instead, G1 is now being talked of as a replacement for the default >>>>> collector. If that's the case, then I think we need to acknowledge >>>>>it, >>>>> and have a conversation about where G1 is actually supposed to be >>>>> used. Are we saying we want a "reasonably high throughput with >>>>>reduced >>>>> STW, but not low pause time" collector? If we are, that's fine, but >>>>> that's not where we started. >>>> That's a fair point, and one I'd be interesting in hearing an answer >>>>to as >>>> well. FWIW, the only GC I know of that's actually used in low latency >>>> systems is Azul's C4, so I'm not even sure Oracle is trying to target >>>>the >>>> same use cases. So when we talk about "low latency" GCs, we should >>>>probably >>>> also be clear on what "low" actually means. >>> Well, when I started playing with them, "low latency" meant a >>> sub-10-ms transaction time with 100ms STW as acceptable, if not ideal. >>> >>> These days, the same sort of system needs a sub 500us transaction >>> time, and ideally no GC pause at all. But that leads to Zing, or >>> non-JVM solutions, and I think takes us too far into a specialised use >>> case. >>> >>> Having said that, there is definitely a decent-sized class of systems >>> (not just in finance) that cannot really tolerate any more than about >>> 10-15ms of STW. So, what usually happens is that they live with the >>> young collections, use CMS and tune out the CMFs as best they can (by >>> clustering, rolling restart, etc, etc). I don't see any possibility of >>> G1 becoming a viable solution for those systems any time soon. >>> >>> Thanks, >>> >>> Ben >> > From charlie.hunt at oracle.com Mon Jun 1 20:51:52 2015 From: charlie.hunt at oracle.com (charlie hunt) Date: Mon, 1 Jun 2015 15:51:52 -0500 Subject: JEP 248: Make G1 the Default Garbage Collector In-Reply-To: References: <20150428220211.4355960845@eggemoggin.niobe.net> <5C5564BB-23ED-49AB-81C6-CFF85B56ACA4@kodewerk.com> <5540D689.6020407@oracle.com> <73855087-8BB2-4A8C-B9AD-080CD39FAB7A@kodewerk.com> <55423444.7040009@beckwithclan.com> <556CA452.9040405@oracle.com> <7E7759C3-3AF0-4047-9B00-605DBB55DC79@oracle.com> Message-ID: Hi Erik, HotSpot does some of this ergonomics today for both GC and JIT compiler in cases where the JVM sees less than 2 GB of RAM and the OS it is running on. These decisions are based on what is called a ?server class machine?. A ?server class machine? as of JDK 6u18 is defined as a system that has 2 GB or more of RAM, two or more hardware threads. There are other cases for a given hardware platform, and if it is a 32-bit JVM, the collector (and JIT compiler) ergonomically selected may also differ from other configurations. AFAIK, the JEP is proposing to change the default GC in configurations where the default GC is Parallel GC to using G1 as the default. The challenge with what you are describing is that the best GC cannot always be ergonomically selected by the JVM without some input from the user, i.e. GC doesn?t know if any GC pauses greater than 200 ms are acceptable regardless of Java heap size, number of hardware threads, etc. thanks, charlie > On Jun 1, 2015, at 2:53 PM, Erik ?sterlund wrote: > > Hi all, > > Does there have to be a single default one-size-fits-all GC algorithm for > users to rely on? Or could we allow multiple algorithms and explicitly > document that unless a GC is picked, the runtime is free to pick whatever > it believes is better? This could have multiple benefits. > > 1. This could make such a similar change easier in the future as everyone > will already be aware that if they really rely on the properties of a > specific GC algorithm, then they should choose that GC explicitly and not > rely on defaults not changing; there are no guarantees that defaults will > not change. > > 2. Obviously there has been a long discussion in this thread which GC is > better in which context, and it seems like right now one size does not fit > all. The user that relied on the defaults might not be so aware of these > specifics. Therefore we might do them a big favour of attempting to make a > guess for them to work out-of-the-box, which is pretty neat. > > 3. This approach allows deploying G1 not everywhere, but where we guess it > performs pretty well. This means it will run in fewer JVM contexts and > hence pose less risk than deploying it to be used for all contexts, making > the transition smoother. > > One idea could be to first determine valid GC variants given the supplied > flags (GC-specific flags imply use of that GC), and then among the valid > GCs left, ?guess? which algorithm is better based on the other general > parameters, such as e.g. heap size (and maybe target latency)? Could for > instance pick ParallelGC for small heaps, G1 for larger heaps and CMS for > ridiculously large heaps or cases when extremely low latency is wanted? > > My reasoning is based on two assumptions: 1) changing the defaults would > target the users that don?t know what?s best for them, 2) one size does > not fit all. If these assumption are wrong, then this is a bad idea. > > Thanks, > /Erik > > > > Den 01/06/15 20:53 skrev charlie hunt : > >> Hi Jenny, >> >> A couple questions and comments below. >> >> thanks, >> >> charlie >> >>> On Jun 1, 2015, at 1:28 PM, Yu Zhang wrote: >>> >>> Hi, >>> >>> I have done some performance comparison g1/cms/parallelgc internally at >>> Oracle. I would like to post my observations here to get some feedback, >>> as I have limited benchmarks and hardware. These are out of box >>> performance. >>> >>> Memory footprint/startup: >>> g1 has bigger memory footprint and longer start up time. The overhead >>> comes from more gc threads, and internal data structures to keep track >>> of remember set. >> >> This is the memory footprint of the JVM itself when using the same size >> Java heap, right? >> >> I don?t recall if it has been your observation? One observation I have >> had with G1 is that it tends to be able to operate within tolerable >> throughput and latency with a smaller Java heap than with Parallel GC. I >> have seen cases where G1 may not use the entire Java heap because it was >> able to keep enough free regions available yet still meet pause time >> goals. But, Parallel GC always use the entire Java heap, and once its >> occupancy reach capacity, it would GC. So they are cases where between >> the JVM?s footprint overhead, and taking into account the amount of Java >> heap required, G1 may actually require less memory. >> >>> >>> g1 vs parallelgc: >>> If the workload involves young gc only, g1 could be slightly slower. >>> Also g1 can consume more cpu, which might slow down the benchmark if SUT >>> is cpu saturated. >>> >>> If there are promotions from young to old gen and leads to full gc with >>> parallelgc, for smaller heap, parallel full gc can finish within some >>> range of pause time, still out performs g1. But for bigger heap, g1 >>> mixed gc can clean the heap with pause times a fraction of parallel full >>> gc time, so improve both throughput and response time. Extreme cases >>> are big data workloads(for example ycsb) with 100g heap. >> >> I think what you are saying here is that it looks like if one can tune >> Parallel GC such that you can avoid a lengthy collection of old >> generation, or the live occupancy of old gen is small enough that the >> time to collect is small enough to be tolerated, then Parallel GC will >> offer a better experience. >> >> However, if the live data in old generation at the time of its collection >> is large enough such that the time it takes to collect it exceeds a >> tolerable pause time, then G1 will offer a better experience. >> >> Would also say that G1 offers a better experience in the presences of >> (wide) swings in object allocation rates since there would likely be a >> larger number of promotions during the allocation spikes? In other >> words, G1 may offer more predictable pauses. >> >>> >>> g1 vs cms: >>> I will focus on response time type of workloads. >>> Ben mentioned >>> >>> "Having said that, there is definitely a decent-sized class of systems >>> (not just in finance) that cannot really tolerate any more than about >>> 10-15ms of STW. So, what usually happens is that they live with the >>> young collections, use CMS and tune out the CMFs as best they can (by >>> clustering, rolling restart, etc, etc). I don't see any possibility of >>> G1 becoming a viable solution for those systems any time soon." >>> >>> Can you give more details, like what is the live data set size, how big >>> is the heap, etc? I did some cache tests (Oracle coherence) to compare >>> cms vs g1. g1 is better than cms when there are fragmentations. If you >>> tune cms well to have little fragmentation, then g1 is behind cms. But >>> for those cases, they have to tune CMS very well, changing default to g1 >>> won't impact them. >>> >>> For big data kind of workloads (ycsb, spark in memory computing), g1 is >>> much better than cms. >>> >>> Thanks, >>> Jenny >>> >>> On 6/1/2015 10:06 AM, Ben Evans wrote: >>>> Hi Vitaly, >>>> >>>>>> Instead, G1 is now being talked of as a replacement for the default >>>>>> collector. If that's the case, then I think we need to acknowledge >>>>>> it, >>>>>> and have a conversation about where G1 is actually supposed to be >>>>>> used. Are we saying we want a "reasonably high throughput with >>>>>> reduced >>>>>> STW, but not low pause time" collector? If we are, that's fine, but >>>>>> that's not where we started. >>>>> That's a fair point, and one I'd be interesting in hearing an answer >>>>> to as >>>>> well. FWIW, the only GC I know of that's actually used in low latency >>>>> systems is Azul's C4, so I'm not even sure Oracle is trying to target >>>>> the >>>>> same use cases. So when we talk about "low latency" GCs, we should >>>>> probably >>>>> also be clear on what "low" actually means. >>>> Well, when I started playing with them, "low latency" meant a >>>> sub-10-ms transaction time with 100ms STW as acceptable, if not ideal. >>>> >>>> These days, the same sort of system needs a sub 500us transaction >>>> time, and ideally no GC pause at all. But that leads to Zing, or >>>> non-JVM solutions, and I think takes us too far into a specialised use >>>> case. >>>> >>>> Having said that, there is definitely a decent-sized class of systems >>>> (not just in finance) that cannot really tolerate any more than about >>>> 10-15ms of STW. So, what usually happens is that they live with the >>>> young collections, use CMS and tune out the CMFs as best they can (by >>>> clustering, rolling restart, etc, etc). I don't see any possibility of >>>> G1 becoming a viable solution for those systems any time soon. >>>> >>>> Thanks, >>>> >>>> Ben >>> >> > From gerard.ziemski at oracle.com Mon Jun 1 21:24:40 2015 From: gerard.ziemski at oracle.com (Gerard Ziemski) Date: Mon, 01 Jun 2015 16:24:40 -0500 Subject: Revision2: Corrected: RFR 8059557 (XL): Validate JVM Command-Line Flag Arguments In-Reply-To: <556808CC.80203@oracle.com> References: <5554FE2D.6020405@oracle.com> <555E0028.8070108@oracle.com> <55663700.5050606@oracle.com> <556808CC.80203@oracle.com> Message-ID: <556CCD98.1000501@oracle.com> hi Bengt, Thank you for taking the time to provide your feedback. My answers are provided in-line: On 5/29/2015 1:35 AM, Bengt Rutisson wrote: > > Hi Gerard, > > Not a full review, but just a couple of questions. > > The new constraint methods added in commandLineFlagConstraintsGC.cpp > are all just implementations of the existing constraints for the GC > flags, right? Basically these checks are just moved from arguments.cpp > to the constraint methods, or have any new ones been added? The constraints were moved, as well as many ranges, though about 60% of ranges are new and were implemented based on comments and/or their names (ie. percentage in name implies 0..100) > > All methods in commandLineFlagConstraintsGC.cpp and > commandLineFlagConstraintsCompiler.cpp start with this check: > > if ((CommandLineFlags::finishedInitializing() == true) > > Only the runtime flags, checked in > commandLineFlagConstraintsRuntime.cpp, are checked even when > initialization has not been completed. Why is it important to be able > to check the constraints even before we have finished initializing? > Wouldn't it be simpler to just call the constraint methods once after > we've reached CommandLineFlags::finishedInitializing()? Then all the > constraint methods wouldn't have to remember to check for that. The ideal flow for the flags is "define --> check --> use", however, that flow does not represent all the flags. There are flags that are set and then used to set other flags and parts of VM before the final check and therefore require validation earlier, hence the need for the "finishedInitiliazing". Personally, I don't like the added complexity myself either, but I think this is the best we can do for now without making lots of other changes to the code. > > (BTW, it is error prone to use == for boolean values. Better to just > use "if (CommandLineFlags::finishedInitializing())" .) > Fixed. I will be posting up a new webrev shortly. cheers From gerard.ziemski at oracle.com Mon Jun 1 21:29:48 2015 From: gerard.ziemski at oracle.com (Gerard Ziemski) Date: Mon, 01 Jun 2015 16:29:48 -0500 Subject: Revision2: Corrected: RFR 8059557 (XL): Validate JVM Command-Line Flag Arguments In-Reply-To: <5567ED6F.7000906@oracle.com> References: <5554FE2D.6020405@oracle.com> <555E0028.8070108@oracle.com> <55663700.5050606@oracle.com> <5567ED6F.7000906@oracle.com> Message-ID: <556CCECC.6090509@oracle.com> Thank you David for more feedback. My answers are provided inline: > Subject: Re: Revision2: Corrected: RFR 8059557 (XL): Validate JVM Command-Line Flag Arguments > Date: Fri, 29 May 2015 14:39:11 +1000 > From: David Holmes > Organization: Oracle Corporation > To: Gerard Ziemski,hotspot-dev at openjdk.java.net Developers > CC: Coleen Phillimore, Dmitry Dmitriev, Kim Barrett, Alexander Harlap > > Hi Gerard, > > Meta-comment: I had expected to see constraint functions subsume range > checks - ie that the range check would be folded into the constraints > function so that all the constraints are clearly seen in one place. Not > sure splitting things across two checks aids in understandability. This > isn't a blocker but I'd be interested to hear other views on this. > Keeping ranges separate from constraints allows us to easily print them out on demand - a requirement from SQA point of view (see PrintFlagsRanges) > A general comment, note that in cases like: > > "intx %s="INTX_FORMAT" is outside the allowed range [ "INTX_FORMAT" > ... "INTX_FORMAT" ]\n", > > we now need to add spaces between the macros like INTX_FRORMAT and the > double-quotes - see 8081202. Not sure who will be pushing first but it's > an easy fix to make. Done. > A few minor specific comments: > > src/share/vm/runtime/commandLineFlagConstraintsCompiler.hpp > > Has the comment: > > 32 * Here we have runtime arguments constraints functions, > > - should say 'compiler' > Done. > --- > > src/share/vm/runtime/commandLineFlagConstraintsCompiler.cpp > > Not obvious all the includes are needed ie java.hpp and os.hpp Done. > > --- > > src/share/vm/runtime/commandLineFlagConstraintsGC.hpp > > Has the comment: > > 32 * Here we have runtime arguments constraints functions, > > - should say 'GC' > > I'm a little surprised the #if INCLUDE_ALL_GCS only covers the G1 > options. I guess we don't as aggressively exclude the code for the other > GC's. Done. > --- > src/share/vm/runtime/commandLineFlagConstraintsGC.cpp > > Not obvious all the includes are needed ie java.hpp and os.hpp, and > c1/c2 globals? Done. > --- > > Nothing else jumped out at me, but I didn't verify the non-runtime > constraints. Thank you - I will be posting up a new webrev soon. cheers From gerard.ziemski at oracle.com Mon Jun 1 21:32:33 2015 From: gerard.ziemski at oracle.com (Gerard Ziemski) Date: Mon, 01 Jun 2015 16:32:33 -0500 Subject: Revision2: Corrected: RFR 8059557 (XL): Validate JVM Command-Line Flag Arguments In-Reply-To: References: <5554FE2D.6020405@oracle.com> <555E0028.8070108@oracle.com> <55663700.5050606@oracle.com> Message-ID: <556CCF71.8030506@oracle.com> Thank you Kim for a review. I provided answers to the raised issues in-line: > Subject: Re: Revision2: Corrected: RFR 8059557 (XL): Validate JVM Command-Line Flag Arguments > Date: Thu, 28 May 2015 18:10:15 -0400 > From: Kim Barrett > To: Gerard Ziemski > CC: hotspot-dev at openjdk.java.net Developers, David Holmes, Coleen Phillimore, Dmitry Dmitriev, Alexander Harlap > > This is only a partial review. I haven't taken a detailed look at > arguments.[ch]pp or globals.cpp, and haven't looked at the new range > and constraint checking or the tests. But I'm running out of steam > for today, and won't be able to get back to this until Monday, so > giving you what I have so far. > > ------------------------------------------------------------------------------ > Many files are being changed to #include globals.hpp just to get > access to Flag values. Perhaps globals.hpp ought to be split up. > This probably ought to be addressed as a separate CR though. Filed ashttps://bugs.openjdk.java.net/browse/JDK-8081519 > ------------------------------------------------------------------------------ > src/share/vm/runtime/globals.hpp > 362 void print_on(outputStream* st, bool printRanges = false, bool withComments = false ); > 458 static void printFlags(outputStream* out, bool withComments, bool printRanges = false); > > Why are the withComments and printRanges arguments in different > orders? > > Just in general, multiple bool arguments tend to be problematic for > understanding the using code. Common alternative is to use enums. > Another common alternative (used often in hotspot) is to use comments > in the calls; that helps the reader, so long as the (not checked by > compiler) order is actually as commented. Calls should at least be > commented, for consistency with other hotspot usage. > I had originally implemented the API with ?printRanges? argument before ?withComments?, however, there are quite few places using this API, so I decided to go with simpler changes, by ordering the arguments the way I did and assigning the default value of false, which allowed me not to touch all the places this API was used. ?print_on? is an SPI and I did not change it to reflect the ?printFlags? order, because that?s how I originally had it in ?printFlags?, and then forgot to keep them in sync. I added comments and changed the order of arguments of ?print_on? to match that of ?printFlags? for consistency. > ------------------------------------------------------------------------------ > src/share/vm/runtime/init.cpp > 145 if (PrintFlagsFinal) { > 146 CommandLineFlags::printFlags(tty, false); > 147 } > 148 if (PrintFlagsRanges) { > 149 CommandLineFlags::printFlags(tty, false, true); > 150 } > [145-147 from original, 148-150 added] > > Really print the flags twice if both options are provided? I was expecting something like: > > if (PrintFlagsFinal || PrintFlagsRanges) { > CommandLineFlags::printFlags(tty, false, PrintFlagsRanges); > } > Done. > ------------------------------------------------------------------------------ > src/share/vm/runtime/os.hpp > 167 // A strlcat like API for safe string concatenation of 2 NULL limited C strings > 168 // strlcat is not guranteed to exist on all platforms, so we implement our own > 169 static void strlcat(char *dst, const char *src, size_t size) { > 170 register char *_dst = dst; > 171 register char *_src = (char *)src; > 172 register int _size = (int)size; > 173 > 174 while ((_size-- != 0) && (*_dst != '\0')) { > 175 _dst++; > 176 } > 177 while ((_size-- != 0) && (*_src != '\0')) { > 178 *_dst = *_src; > 179 _dst++; _src++; > 180 } > 181 *_dst = '\0'; > 182 } > > Several problems here: > > 1. In the description comment: NULL is a pointer. The string > terminator is NUL. > > 2. Use of "register" storage class specifiers: The "register" storage > class is deprecated in C++11 and slated for removal in C++17. > Compilers have for a long time been parsing it but otherwise ascribing > no special meaning beyond specifying automatic storage allocation. > > 3. There's no reason for any of the casts. > > 4. Use of _ prefixed names is generally reserved for member variables > in hotspot. There's no need for these additional variables anyway, > after elimination of the register storage class usage and the > inappropriate casts. > > 5. This will buffer overrun if strlen(dst) >= size. This differs from > BSD strlcat. > Quite frankly I feel pretty embarrassed that there was a bug in the previous implementation. I have taken the various feedback into account and came up with a better one. I have asked for help making sure the new implementation has no bugs. > 6. Unlike BSD strlcat, this doesn't provide a return value that allows > the caller to detect truncation. I would think most real uses aught > to care about that case, though I haven't audited uses in this change > set yet. The new code doesn?t care about the truncation. > ------------------------------------------------------------------------------ > src/share/vm/services/classLoadingService.cpp > 184 bool succeed = (CommandLineFlags::boolAtPut((char*)"TraceClassLoading", &verbose, Flag::MANAGEMENT) == Flag::SUCCESS); > 185 assert(succeed, "Setting TraceClassLoading flag fails"); > > I'm surprised this doesn't produce an unused variable warning in a > product build. > > Rather than converting the boolAtPut result to a bool success and > asserting it to be true, it would be better to capture the resulting > Flag::Error, test for success in the assert, and report the failure > reason in the assert message. > > Pre-existing defect: Unnecessary cast. > > Possible pre-existing defect: I don't understand exactly how these > service functions are used, but I wonder whether an assertion is > really the appropriate method to check for failure to perform the > operation. > > Similarly for line 195. > > Similarly for src/share/vm/services/memoryService.cpp:521 > I fixed those the best I could, but I left the asserts in place to keep the same behavior. > ------------------------------------------------------------------------------ > src/share/vm/services/writeableFlags.cpp > 62 if (error != Flag::SUCCESS) { > ... > 93 } > > Rather than if != success and indenting the whole function, I think it > would be more readable if this were > > if (error == Flag::SUCCESS) { > return; > } > ... > Done. > ------------------------------------------------------------------------------ > src/share/vm/services/writeableFlags.cpp > 88 buffer[79] = '\0'; > > What's this about? Debugging leftover - removed. > ------------------------------------------------------------------------------ > src/share/vm/services/writeableFlags.cpp > 108 Flag::Error err = CommandLineFlags::boolAtPut((char*)name, &value, origin); > 125 Flag::Error err = CommandLineFlags::intxAtPut((char*)name, &value, origin); > 142 Flag::Error err = CommandLineFlags::uintxAtPut((char*)name, &value, origin); > ... and so on ... > > Pre-existing inappropriate casts. > Cleaned. Thank you Kim for the detailed feedback - I will be posting up the new webrev soon, so please take a look. cheers From derek.white at oracle.com Mon Jun 1 22:13:23 2015 From: derek.white at oracle.com (Derek White) Date: Mon, 01 Jun 2015 18:13:23 -0400 Subject: Revision2: Corrected: RFR 8059557 (XL): Validate JVM Command-Line Flag Arguments In-Reply-To: <55663700.5050606@oracle.com> References: <5554FE2D.6020405@oracle.com> <555E0028.8070108@oracle.com> <55663700.5050606@oracle.com> Message-ID: <556CD903.1080004@oracle.com> Hi Gerard, Still going over arguments.cpp and globals.hpp... Here are a few issues found so far: ---------------------------------------- g1_globals.hpp: ---------------------------------------- - G1ConcMarkStepDurationMillis: The range is declared as range(1.0, (double)max_uintx). But max_uintx has nothing to do with max double. It may not even be precisely representable as a double. - G1NewSizePercent: The constraint is checks that that its is <= G1MaxNewSizePercent, but not that it's >= 0. I assume that the uintx type is checking that? ---------------------------------------- arguments.cpp: ---------------------------------------- - Line 1405 - where did this come from? if (SurvivorAlignmentInBytes == 0) { SurvivorAlignmentInBytes = ObjectAlignmentInBytes; } ---------------------------------------- globals.hpp: ---------------------------------------- - The variables StringTableSize and SymbolTableSize used to have ranges - minimumStringTableSize..(max_uintx / StringTable::bucket_size() - minimumSymbolTableSize..(max_uintx / SymbolTable::bucket_size() Now they are: - range(minimumStringTableSize, 111*defaultStringTableSize) - range(minimumSymbolTableSize, 111*defaultSymbolTableSize) This is OK? I didn't have a chance to calculate these myself. - MinMetaspaceFreeRatio: used to have range 0..99, now it has range 0..100 and constraint <= MaxMetaspaceFreeRatio. - Not sure how important. - Actually the GC, runtime, and compiler groups should check all of their "percent" variables to see if having tighter ranges makes sense. Line 2036, 2041: - Set status to false instead of returning directly? Line 2827 (existing); Change "K" -> "1*K" for consistency. ---------------------------------------- commandLineFlagConstraintList.hpp ---------------------------------------- - Initialize CommandLineFlagConstraintList._constraints in constructor to avoid dealing with NULL case? - Shouldn't the default implementations for CommandLineFlagConstraint::apply_XXX() return failure, not success? ---------------------------------------- commandLineFlagConstraintsGC.cpp ---------------------------------------- Is this necessary?: 37 #include "c1/c1_globals.hpp" 40 #include "opto/c2_globals.hpp" BAD TYPO: - CMSOldPLABMaxConstraintFunc() is comparing against itself, not CMSOldPLABMin. The rest of what I've seen looks good. Still looking... - Derek On 5/27/15 5:28 PM, Gerard Ziemski wrote: > hi all, > > Here is a revision 2 of the feature taking into account feedback from > Dmitry, David, Kim and Alexander. > > One significant change in this rev is the addition of > runtime/commandLineFlagConstraintsCompiler.hpp/.cpp with one simple > constraint needed by Dmitry's test framework. > > We introduce a new mechanism that allows specification of a valid > range per flag that is then used to automatically validate given > flag's value every time it changes. Ranges values must be constant and > can not change. Optionally, a constraint can also be specified and > applied every time a flag value changes for those flags whose valid > value can not be trivially checked by a simple min and max (ex. > whether it's power of 2, or bigger or smaller than some other flag > that can also change) > > I have chosen to modify the table macros (ex. RUNTIME_FLAGS in > globals.hpp) instead of using a more sophisticated solution, such as > C++ templates, because even though macros were unfriendly when > initially developing, once a solution was arrived at, subsequent > additions to the tables of new ranges, or constraint are trivial from > developer's point of view. (The intial development unfriendliness of > macros was mitigated by using a pre-processor, which for those using a > modern IDE like Xcode, is easily available from a menu). Using macros > also allowed for more minimal code changes. > > The presented solution is based on expansion of macros using variadic > functions and can be readily seen in > runtime/commandLineFlagConstraintList.cpp and > runtime/commandLineFlagRangeList.cpp > > In commandLineFlagConstraintList.cpp or commandLineFlagRangesList.cpp, > there is bunch of classes and methods that seems to beg for C++ > template to be used. I have tried, but when the compiler tries to > generate code for both uintx and size_t, which happen to have the same > underlying type (on BSD), it fails to compile overridden methods with > same type, but different name. If someone has a way of simplifying the > new code via C++ templates, however, we can file a new enhancement > request to address that. > > This webrev represents only the initial range checking framework and > only 100 or so flags that were ported from an existing ad hoc range > checking code to this new mechanism. There are about 250 remaining > flags that still need their ranges determined and ported over to this > new mechansim and they are tracked by individual subtasks. > > I had to modify several existing tests to change the error message > that they expected when VM refuses to run, which was changed to > provide uniform error messages. > > To help with testing and subtask efforts I have introduced a new > runtime flag: > > PrintFlagsRanges: "Print VM flags and their ranges and exit VM" > > which in addition to the already existing flags: "PrintFlagsInitial" > and "PrintFlagsFinal" allow for thorough examination of the flags > values and their ranges. > > The code change builds and passes JPRT (-testset hotspot) and UTE > (vm.quick.testlist) > > > References: > > Webrev: http://cr.openjdk.java.net/~gziemski/8059557_rev2 > note: due to "awk" limit of 50 pats the Frames diff is not > available for "src/share/vm/runtime/arguments.cpp" > > JEP:https://bugs.openjdk.java.net/browse/JDK-8059557 > Compiler subtask:https://bugs.openjdk.java.net/browse/JDK-8078554 > GC subtask:https://bugs.openjdk.java.net/browse/JDK-8078555 > Runtime subtask:https://bugs.openjdk.java.net/browse/JDK-8078556 > > > hgstat: > > src/cpu/ppc/vm/globals_ppc.hpp | 2 +- > src/cpu/sparc/vm/globals_sparc.hpp | 2 +- > src/cpu/x86/vm/globals_x86.hpp | 2 +- > src/cpu/zero/vm/globals_zero.hpp | 3 +- > src/os/aix/vm/globals_aix.hpp | 2 +- > src/os/bsd/vm/globals_bsd.hpp | 29 +- > src/os/linux/vm/globals_linux.hpp | 9 +- > src/os/solaris/vm/globals_solaris.hpp | 4 +- > src/os/windows/vm/globals_windows.hpp | 5 +- > src/share/vm/c1/c1_globals.cpp | 4 +- > src/share/vm/c1/c1_globals.hpp | 17 +- > src/share/vm/gc_implementation/g1/g1_globals.cpp | 16 +- > src/share/vm/gc_implementation/g1/g1_globals.hpp | 38 +- > src/share/vm/opto/c2_globals.cpp | 12 +- > src/share/vm/opto/c2_globals.hpp | 40 +- > src/share/vm/prims/whitebox.cpp | 12 +- > src/share/vm/runtime/arguments.cpp | 753 > ++++++++++++++---------------------- > src/share/vm/runtime/arguments.hpp | 24 +- > src/share/vm/runtime/commandLineFlagConstraintList.cpp | 243 > +++++++++++ > src/share/vm/runtime/commandLineFlagConstraintList.hpp | 73 +++ > src/share/vm/runtime/commandLineFlagConstraintsCompiler.cpp | 46 ++ > src/share/vm/runtime/commandLineFlagConstraintsCompiler.hpp | 39 + > src/share/vm/runtime/commandLineFlagConstraintsGC.cpp | 251 > ++++++++++++ > src/share/vm/runtime/commandLineFlagConstraintsGC.hpp | 59 ++ > src/share/vm/runtime/commandLineFlagConstraintsRuntime.cpp | 67 +++ > src/share/vm/runtime/commandLineFlagConstraintsRuntime.hpp | 41 ++ > src/share/vm/runtime/commandLineFlagRangeList.cpp | 304 > ++++++++++++++ > src/share/vm/runtime/commandLineFlagRangeList.hpp | 67 +++ > src/share/vm/runtime/globals.cpp | 699 > +++++++++++++++++++++++++++------ > src/share/vm/runtime/globals.hpp | 310 > ++++++++++++-- > src/share/vm/runtime/globals_extension.hpp | 101 +++- > src/share/vm/runtime/init.cpp | 6 +- > src/share/vm/runtime/os.hpp | 17 + > src/share/vm/runtime/os_ext.hpp | 7 +- > src/share/vm/runtime/thread.cpp | 6 + > src/share/vm/services/attachListener.cpp | 4 +- > src/share/vm/services/classLoadingService.cpp | 6 +- > src/share/vm/services/diagnosticCommand.cpp | 3 +- > src/share/vm/services/management.cpp | 6 +- > src/share/vm/services/memoryService.cpp | 2 +- > src/share/vm/services/writeableFlags.cpp | 161 > +++++-- > src/share/vm/services/writeableFlags.hpp | 52 +- > test/compiler/c2/7200264/Test7200264.sh | 5 +- > test/compiler/startup/NumCompilerThreadsCheck.java | 2 +- > test/gc/arguments/TestHeapFreeRatio.java | 23 +- > test/gc/arguments/TestSurvivorAlignmentInBytesOption.java | 6 +- > test/gc/g1/TestStringDeduplicationTools.java | 6 +- > test/runtime/CompressedOops/CompressedClassSpaceSize.java | 4 +- > test/runtime/CompressedOops/ObjectAlignment.java | 9 +- > test/runtime/contended/Options.java | 10 +- > 50 files changed, 2730 insertions(+), 879 deletions(-) > From jeremymanson at google.com Mon Jun 1 23:04:07 2015 From: jeremymanson at google.com (Jeremy Manson) Date: Mon, 1 Jun 2015 16:04:07 -0700 Subject: JEP 248: Make G1 the Default Garbage Collector In-Reply-To: References: <20150428220211.4355960845@eggemoggin.niobe.net> <5C5564BB-23ED-49AB-81C6-CFF85B56ACA4@kodewerk.com> <5540D689.6020407@oracle.com> <73855087-8BB2-4A8C-B9AD-080CD39FAB7A@kodewerk.com> <55423444.7040009@beckwithclan.com> <556CA452.9040405@oracle.com> <7E7759C3-3AF0-4047-9B00-605DBB55DC79@oracle.com> Message-ID: This is a very interesting conversation, and I'd like to throw in Google's not-quite-relevant observations, too. We're not quite relevant because we'll just change the default to whatever we want, and because we ignore the parallel GC, for the most part. Much of it has been said before in this thread, but it's worth reiterating. - As it happens, we're considering changing the default, too - to the CMS collector! - We've been asking people to try G1 approximately annually for the last five or so years. - Although G1 performance has gotten better over time, we still find that the additional CPU costs outweigh any benefits, and that CMS typically ends up ahead. - With most of our more important workloads, our admins tend to tune applications carefully so that the OG doesn't fill up too much, and CMS cycles are not triggered often. This is deeply important in server-style applications - you want anything generated and used by a single request to go away with a YG collection. - Part of the reason our CMS performs better is that we've made changes to CMS to improve its performance. We see roughly half as much CPU utilization, and the long tail pause times have been cut dramatically. It would be nice if we could upstream the changes (especially for us, because they break with every new release, and we have to fix them!), but we've never been able to find anyone at Oracle who has the bandwidth to do the reviews. For example, the response to this: http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2015-May/013426.html was not hugely enthusiastic, and that's not even one of the more complex changes. Jeremy On Mon, Jun 1, 2015 at 1:51 PM, charlie hunt wrote: > Hi Erik, > > HotSpot does some of this ergonomics today for both GC and JIT compiler in > cases where the JVM sees less than 2 GB of RAM and the OS it is running on. > These decisions are based on what is called a ?server class machine?. A > ?server class machine? as of JDK 6u18 is defined as a system that has 2 GB > or more of RAM, two or more hardware threads. There are other cases for a > given hardware platform, and if it is a 32-bit JVM, the collector (and JIT > compiler) ergonomically selected may also differ from other configurations. > > AFAIK, the JEP is proposing to change the default GC in configurations > where the default GC is Parallel GC to using G1 as the default. > > The challenge with what you are describing is that the best GC cannot > always be ergonomically selected by the JVM without some input from the > user, i.e. GC doesn?t know if any GC pauses greater than 200 ms are > acceptable regardless of Java heap size, number of hardware threads, etc. > > thanks, > > charlie > > > On Jun 1, 2015, at 2:53 PM, Erik ?sterlund > wrote: > > > > Hi all, > > > > Does there have to be a single default one-size-fits-all GC algorithm for > > users to rely on? Or could we allow multiple algorithms and explicitly > > document that unless a GC is picked, the runtime is free to pick whatever > > it believes is better? This could have multiple benefits. > > > > 1. This could make such a similar change easier in the future as everyone > > will already be aware that if they really rely on the properties of a > > specific GC algorithm, then they should choose that GC explicitly and not > > rely on defaults not changing; there are no guarantees that defaults will > > not change. > > > > 2. Obviously there has been a long discussion in this thread which GC is > > better in which context, and it seems like right now one size does not > fit > > all. The user that relied on the defaults might not be so aware of these > > specifics. Therefore we might do them a big favour of attempting to make > a > > guess for them to work out-of-the-box, which is pretty neat. > > > > 3. This approach allows deploying G1 not everywhere, but where we guess > it > > performs pretty well. This means it will run in fewer JVM contexts and > > hence pose less risk than deploying it to be used for all contexts, > making > > the transition smoother. > > > > One idea could be to first determine valid GC variants given the supplied > > flags (GC-specific flags imply use of that GC), and then among the valid > > GCs left, ?guess? which algorithm is better based on the other general > > parameters, such as e.g. heap size (and maybe target latency)? Could for > > instance pick ParallelGC for small heaps, G1 for larger heaps and CMS for > > ridiculously large heaps or cases when extremely low latency is wanted? > > > > My reasoning is based on two assumptions: 1) changing the defaults would > > target the users that don?t know what?s best for them, 2) one size does > > not fit all. If these assumption are wrong, then this is a bad idea. > > > > Thanks, > > /Erik > > > > > > > > Den 01/06/15 20:53 skrev charlie hunt : > > > >> Hi Jenny, > >> > >> A couple questions and comments below. > >> > >> thanks, > >> > >> charlie > >> > >>> On Jun 1, 2015, at 1:28 PM, Yu Zhang wrote: > >>> > >>> Hi, > >>> > >>> I have done some performance comparison g1/cms/parallelgc internally at > >>> Oracle. I would like to post my observations here to get some > feedback, > >>> as I have limited benchmarks and hardware. These are out of box > >>> performance. > >>> > >>> Memory footprint/startup: > >>> g1 has bigger memory footprint and longer start up time. The overhead > >>> comes from more gc threads, and internal data structures to keep track > >>> of remember set. > >> > >> This is the memory footprint of the JVM itself when using the same size > >> Java heap, right? > >> > >> I don?t recall if it has been your observation? One observation I have > >> had with G1 is that it tends to be able to operate within tolerable > >> throughput and latency with a smaller Java heap than with Parallel GC. > I > >> have seen cases where G1 may not use the entire Java heap because it was > >> able to keep enough free regions available yet still meet pause time > >> goals. But, Parallel GC always use the entire Java heap, and once its > >> occupancy reach capacity, it would GC. So they are cases where between > >> the JVM?s footprint overhead, and taking into account the amount of Java > >> heap required, G1 may actually require less memory. > >> > >>> > >>> g1 vs parallelgc: > >>> If the workload involves young gc only, g1 could be slightly slower. > >>> Also g1 can consume more cpu, which might slow down the benchmark if > SUT > >>> is cpu saturated. > >>> > >>> If there are promotions from young to old gen and leads to full gc with > >>> parallelgc, for smaller heap, parallel full gc can finish within some > >>> range of pause time, still out performs g1. But for bigger heap, g1 > >>> mixed gc can clean the heap with pause times a fraction of parallel > full > >>> gc time, so improve both throughput and response time. Extreme cases > >>> are big data workloads(for example ycsb) with 100g heap. > >> > >> I think what you are saying here is that it looks like if one can tune > >> Parallel GC such that you can avoid a lengthy collection of old > >> generation, or the live occupancy of old gen is small enough that the > >> time to collect is small enough to be tolerated, then Parallel GC will > >> offer a better experience. > >> > >> However, if the live data in old generation at the time of its > collection > >> is large enough such that the time it takes to collect it exceeds a > >> tolerable pause time, then G1 will offer a better experience. > >> > >> Would also say that G1 offers a better experience in the presences of > >> (wide) swings in object allocation rates since there would likely be a > >> larger number of promotions during the allocation spikes? In other > >> words, G1 may offer more predictable pauses. > >> > >>> > >>> g1 vs cms: > >>> I will focus on response time type of workloads. > >>> Ben mentioned > >>> > >>> "Having said that, there is definitely a decent-sized class of systems > >>> (not just in finance) that cannot really tolerate any more than about > >>> 10-15ms of STW. So, what usually happens is that they live with the > >>> young collections, use CMS and tune out the CMFs as best they can (by > >>> clustering, rolling restart, etc, etc). I don't see any possibility of > >>> G1 becoming a viable solution for those systems any time soon." > >>> > >>> Can you give more details, like what is the live data set size, how big > >>> is the heap, etc? I did some cache tests (Oracle coherence) to compare > >>> cms vs g1. g1 is better than cms when there are fragmentations. If you > >>> tune cms well to have little fragmentation, then g1 is behind cms. But > >>> for those cases, they have to tune CMS very well, changing default to > g1 > >>> won't impact them. > >>> > >>> For big data kind of workloads (ycsb, spark in memory computing), g1 is > >>> much better than cms. > >>> > >>> Thanks, > >>> Jenny > >>> > >>> On 6/1/2015 10:06 AM, Ben Evans wrote: > >>>> Hi Vitaly, > >>>> > >>>>>> Instead, G1 is now being talked of as a replacement for the default > >>>>>> collector. If that's the case, then I think we need to acknowledge > >>>>>> it, > >>>>>> and have a conversation about where G1 is actually supposed to be > >>>>>> used. Are we saying we want a "reasonably high throughput with > >>>>>> reduced > >>>>>> STW, but not low pause time" collector? If we are, that's fine, but > >>>>>> that's not where we started. > >>>>> That's a fair point, and one I'd be interesting in hearing an answer > >>>>> to as > >>>>> well. FWIW, the only GC I know of that's actually used in low > latency > >>>>> systems is Azul's C4, so I'm not even sure Oracle is trying to target > >>>>> the > >>>>> same use cases. So when we talk about "low latency" GCs, we should > >>>>> probably > >>>>> also be clear on what "low" actually means. > >>>> Well, when I started playing with them, "low latency" meant a > >>>> sub-10-ms transaction time with 100ms STW as acceptable, if not ideal. > >>>> > >>>> These days, the same sort of system needs a sub 500us transaction > >>>> time, and ideally no GC pause at all. But that leads to Zing, or > >>>> non-JVM solutions, and I think takes us too far into a specialised use > >>>> case. > >>>> > >>>> Having said that, there is definitely a decent-sized class of systems > >>>> (not just in finance) that cannot really tolerate any more than about > >>>> 10-15ms of STW. So, what usually happens is that they live with the > >>>> young collections, use CMS and tune out the CMFs as best they can (by > >>>> clustering, rolling restart, etc, etc). I don't see any possibility of > >>>> G1 becoming a viable solution for those systems any time soon. > >>>> > >>>> Thanks, > >>>> > >>>> Ben > >>> > >> > > > > From erik.osterlund at lnu.se Mon Jun 1 23:16:26 2015 From: erik.osterlund at lnu.se (=?windows-1254?Q?Erik_=D6sterlund?=) Date: Mon, 1 Jun 2015 23:16:26 +0000 Subject: JEP 248: Make G1 the Default Garbage Collector In-Reply-To: References: <20150428220211.4355960845@eggemoggin.niobe.net> <5C5564BB-23ED-49AB-81C6-CFF85B56ACA4@kodewerk.com> <5540D689.6020407@oracle.com> <73855087-8BB2-4A8C-B9AD-080CD39FAB7A@kodewerk.com> <55423444.7040009@beckwithclan.com> <556CA452.9040405@oracle.com> <7E7759C3-3AF0-4047-9B00-605DBB55DC79@oracle.com> Message-ID: Hi Charlie, Den 01/06/15 22:51 skrev charlie hunt : >Hi Erik, > >HotSpot does some of this ergonomics today for both GC and JIT compiler >in cases where the JVM sees less than 2 GB of RAM and the OS it is >running on. These decisions are based on what is called a ?server class >machine?. A ?server class machine? as of JDK 6u18 is defined as a system >that has 2 GB or more of RAM, two or more hardware threads. There are >other cases for a given hardware platform, and if it is a 32-bit JVM, the >collector (and JIT compiler) ergonomically selected may also differ from >other configurations. > >AFAIK, the JEP is proposing to change the default GC in configurations >where the default GC is Parallel GC to using G1 as the default. I think the fact that these ergonomics tricks are already around only motivates the approach further as it is in line with the current philosophy that if the user is not explicit about things, then the runtime can and will guess a bit and try to aim for some kind of middle ground solutions that are pretty good but not necessarily the best at everything (like G1 was designed to be). If the guess doesn?t cut it because it turns out that only a single QoS was important, like for instance performance over everything else, then maybe the user should have said so. ;) >The challenge with what you are describing is that the best GC cannot >always be ergonomically selected by the JVM without some input from the >user, i.e. GC doesn?t know if any GC pauses greater than 200 ms are >acceptable regardless of Java heap size, number of hardware threads, etc. I do not see why this (latency requirement uncertainty) specifically would be a problem for this particular transition into using G1 more instead of ParallelGC. Let?s focus only on the narrow scope of transitioning application contexts from ParallelGC to G1 only for ?larger" heaps. Is there any application context then where G1 has worse latency than ParallelGC? I assume not. So the only visible effect such a change would bring is improved latencies if anything. And the whole mega-low-latency discussion where G1 doesn?t cut it is quite irrelevant for this change as well as those people affected are already not satisfied with ParallelGC that wouldn?t cut it either, and hence specify something explicitly. Another concern Jenny mentioned where G1 could perform worse was JVM start up time. Again, I have a hard time imagining a /server application/ with an explicitly specified ?large" heap where anyone would care too much about this. Am I wrong? What is left to annoy people with such a change then (apart from bugs) with latency not being one of them, is resource trade offs in terms of memory footprints and performance. And here G1 was designed, correct me if I?m wrong, to be not necessarily the best at anything, but pretty good at everything (latencies, performance and memory footprints). This sounds to me like a reasonable choice for default application contexts where it?s not known if the user cares about this or that QoS. And with the observation from Jenny that even performance seems to actually be better than ParallelGC for application contexts with large heaps, and the knowledge that latency is in general more important then, does it not make sense to choose G1 at least for those application contexts? Of course this is just a suggestion based on generalizations. Just thought it?s an interesting middle ground worth considering to instead of only considering either changing all or none of the default server application contexts, to only change the subset where we think it is least likely to annoy people, and then as G1 continues to improve and one size starts fitting all, expand that subset in a smoother transition. Thanks, /Erik > >thanks, > >charlie > >> On Jun 1, 2015, at 2:53 PM, Erik ?sterlund >>wrote: >> >> Hi all, >> >> Does there have to be a single default one-size-fits-all GC algorithm >>for >> users to rely on? Or could we allow multiple algorithms and explicitly >> document that unless a GC is picked, the runtime is free to pick >>whatever >> it believes is better? This could have multiple benefits. >> >> 1. This could make such a similar change easier in the future as >>everyone >> will already be aware that if they really rely on the properties of a >> specific GC algorithm, then they should choose that GC explicitly and >>not >> rely on defaults not changing; there are no guarantees that defaults >>will >> not change. >> >> 2. Obviously there has been a long discussion in this thread which GC is >> better in which context, and it seems like right now one size does not >>fit >> all. The user that relied on the defaults might not be so aware of these >> specifics. Therefore we might do them a big favour of attempting to >>make a >> guess for them to work out-of-the-box, which is pretty neat. >> >> 3. This approach allows deploying G1 not everywhere, but where we guess >>it >> performs pretty well. This means it will run in fewer JVM contexts and >> hence pose less risk than deploying it to be used for all contexts, >>making >> the transition smoother. >> >> One idea could be to first determine valid GC variants given the >>supplied >> flags (GC-specific flags imply use of that GC), and then among the valid >> GCs left, ?guess? which algorithm is better based on the other general >> parameters, such as e.g. heap size (and maybe target latency)? Could for >> instance pick ParallelGC for small heaps, G1 for larger heaps and CMS >>for >> ridiculously large heaps or cases when extremely low latency is wanted? >> >> My reasoning is based on two assumptions: 1) changing the defaults would >> target the users that don?t know what?s best for them, 2) one size does >> not fit all. If these assumption are wrong, then this is a bad idea. >> >> Thanks, >> /Erik >> >> >> >> Den 01/06/15 20:53 skrev charlie hunt : >> >>> Hi Jenny, >>> >>> A couple questions and comments below. >>> >>> thanks, >>> >>> charlie >>> >>>> On Jun 1, 2015, at 1:28 PM, Yu Zhang wrote: >>>> >>>> Hi, >>>> >>>> I have done some performance comparison g1/cms/parallelgc internally >>>>at >>>> Oracle. I would like to post my observations here to get some >>>>feedback, >>>> as I have limited benchmarks and hardware. These are out of box >>>> performance. >>>> >>>> Memory footprint/startup: >>>> g1 has bigger memory footprint and longer start up time. The overhead >>>> comes from more gc threads, and internal data structures to keep track >>>> of remember set. >>> >>> This is the memory footprint of the JVM itself when using the same size >>> Java heap, right? >>> >>> I don?t recall if it has been your observation? One observation I have >>> had with G1 is that it tends to be able to operate within tolerable >>> throughput and latency with a smaller Java heap than with Parallel GC. >>> I >>> have seen cases where G1 may not use the entire Java heap because it >>>was >>> able to keep enough free regions available yet still meet pause time >>> goals. But, Parallel GC always use the entire Java heap, and once its >>> occupancy reach capacity, it would GC. So they are cases where between >>> the JVM?s footprint overhead, and taking into account the amount of >>>Java >>> heap required, G1 may actually require less memory. >>> >>>> >>>> g1 vs parallelgc: >>>> If the workload involves young gc only, g1 could be slightly slower. >>>> Also g1 can consume more cpu, which might slow down the benchmark if >>>>SUT >>>> is cpu saturated. >>>> >>>> If there are promotions from young to old gen and leads to full gc >>>>with >>>> parallelgc, for smaller heap, parallel full gc can finish within some >>>> range of pause time, still out performs g1. But for bigger heap, g1 >>>> mixed gc can clean the heap with pause times a fraction of parallel >>>>full >>>> gc time, so improve both throughput and response time. Extreme cases >>>> are big data workloads(for example ycsb) with 100g heap. >>> >>> I think what you are saying here is that it looks like if one can tune >>> Parallel GC such that you can avoid a lengthy collection of old >>> generation, or the live occupancy of old gen is small enough that the >>> time to collect is small enough to be tolerated, then Parallel GC will >>> offer a better experience. >>> >>> However, if the live data in old generation at the time of its >>>collection >>> is large enough such that the time it takes to collect it exceeds a >>> tolerable pause time, then G1 will offer a better experience. >>> >>> Would also say that G1 offers a better experience in the presences of >>> (wide) swings in object allocation rates since there would likely be a >>> larger number of promotions during the allocation spikes? In other >>> words, G1 may offer more predictable pauses. >>> >>>> >>>> g1 vs cms: >>>> I will focus on response time type of workloads. >>>> Ben mentioned >>>> >>>> "Having said that, there is definitely a decent-sized class of systems >>>> (not just in finance) that cannot really tolerate any more than about >>>> 10-15ms of STW. So, what usually happens is that they live with the >>>> young collections, use CMS and tune out the CMFs as best they can (by >>>> clustering, rolling restart, etc, etc). I don't see any possibility of >>>> G1 becoming a viable solution for those systems any time soon." >>>> >>>> Can you give more details, like what is the live data set size, how >>>>big >>>> is the heap, etc? I did some cache tests (Oracle coherence) to >>>>compare >>>> cms vs g1. g1 is better than cms when there are fragmentations. If you >>>> tune cms well to have little fragmentation, then g1 is behind cms. >>>>But >>>> for those cases, they have to tune CMS very well, changing default to >>>>g1 >>>> won't impact them. >>>> >>>> For big data kind of workloads (ycsb, spark in memory computing), g1 >>>>is >>>> much better than cms. >>>> >>>> Thanks, >>>> Jenny >>>> >>>> On 6/1/2015 10:06 AM, Ben Evans wrote: >>>>> Hi Vitaly, >>>>> >>>>>>> Instead, G1 is now being talked of as a replacement for the default >>>>>>> collector. If that's the case, then I think we need to acknowledge >>>>>>> it, >>>>>>> and have a conversation about where G1 is actually supposed to be >>>>>>> used. Are we saying we want a "reasonably high throughput with >>>>>>> reduced >>>>>>> STW, but not low pause time" collector? If we are, that's fine, but >>>>>>> that's not where we started. >>>>>> That's a fair point, and one I'd be interesting in hearing an answer >>>>>> to as >>>>>> well. FWIW, the only GC I know of that's actually used in low >>>>>>latency >>>>>> systems is Azul's C4, so I'm not even sure Oracle is trying to >>>>>>target >>>>>> the >>>>>> same use cases. So when we talk about "low latency" GCs, we should >>>>>> probably >>>>>> also be clear on what "low" actually means. >>>>> Well, when I started playing with them, "low latency" meant a >>>>> sub-10-ms transaction time with 100ms STW as acceptable, if not >>>>>ideal. >>>>> >>>>> These days, the same sort of system needs a sub 500us transaction >>>>> time, and ideally no GC pause at all. But that leads to Zing, or >>>>> non-JVM solutions, and I think takes us too far into a specialised >>>>>use >>>>> case. >>>>> >>>>> Having said that, there is definitely a decent-sized class of systems >>>>> (not just in finance) that cannot really tolerate any more than about >>>>> 10-15ms of STW. So, what usually happens is that they live with the >>>>> young collections, use CMS and tune out the CMFs as best they can (by >>>>> clustering, rolling restart, etc, etc). I don't see any possibility >>>>>of >>>>> G1 becoming a viable solution for those systems any time soon. >>>>> >>>>> Thanks, >>>>> >>>>> Ben >>>> >>> >> > From erik.osterlund at lnu.se Tue Jun 2 01:00:38 2015 From: erik.osterlund at lnu.se (=?utf-8?B?RXJpayDDlnN0ZXJsdW5k?=) Date: Tue, 2 Jun 2015 01:00:38 +0000 Subject: JEP 248: Make G1 the Default Garbage Collector In-Reply-To: References: <20150428220211.4355960845@eggemoggin.niobe.net> <5C5564BB-23ED-49AB-81C6-CFF85B56ACA4@kodewerk.com> <5540D689.6020407@oracle.com> <73855087-8BB2-4A8C-B9AD-080CD39FAB7A@kodewerk.com> <55423444.7040009@beckwithclan.com> <556CA452.9040405@oracle.com> <7E7759C3-3AF0-4047-9B00-605DBB55DC79@oracle.com> Message-ID: Hi Jeremy, Are you suggesting making Google?s CMS the new default instead? The target for this is long running server applications where fragmentation issues become increasingly awkward over time. Literature suggests fragmentation overheads can be as bad as allocations costing 1/2 log(n) as much memory due to fragmentation, where n is the ratio of the smallest and largest allocatable objects. In short? ouch! This can make the JVM run out of memory and crash, which is suboptimal. So I?m curious - what?s the Google solution to fragmentation using CMS? Let me guess? buy more memory? :p Cheers, /Erik Fr?n: Jeremy Manson > Datum: Tuesday 2 June 2015 01:04 Till: charlie hunt > Kopia: Erik ?sterlund >, "hotspot-dev at openjdk.java.net Source Developers" > ?mne: Re: JEP 248: Make G1 the Default Garbage Collector This is a very interesting conversation, and I'd like to throw in Google's not-quite-relevant observations, too. We're not quite relevant because we'll just change the default to whatever we want, and because we ignore the parallel GC, for the most part. Much of it has been said before in this thread, but it's worth reiterating. - As it happens, we're considering changing the default, too - to the CMS collector! - We've been asking people to try G1 approximately annually for the last five or so years. - Although G1 performance has gotten better over time, we still find that the additional CPU costs outweigh any benefits, and that CMS typically ends up ahead. - With most of our more important workloads, our admins tend to tune applications carefully so that the OG doesn't fill up too much, and CMS cycles are not triggered often. This is deeply important in server-style applications - you want anything generated and used by a single request to go away with a YG collection. - Part of the reason our CMS performs better is that we've made changes to CMS to improve its performance. We see roughly half as much CPU utilization, and the long tail pause times have been cut dramatically. It would be nice if we could upstream the changes (especially for us, because they break with every new release, and we have to fix them!), but we've never been able to find anyone at Oracle who has the bandwidth to do the reviews. For example, the response to this: http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2015-May/013426.html was not hugely enthusiastic, and that's not even one of the more complex changes. Jeremy On Mon, Jun 1, 2015 at 1:51 PM, charlie hunt > wrote: Hi Erik, HotSpot does some of this ergonomics today for both GC and JIT compiler in cases where the JVM sees less than 2 GB of RAM and the OS it is running on. These decisions are based on what is called a ?server class machine?. A ?server class machine? as of JDK 6u18 is defined as a system that has 2 GB or more of RAM, two or more hardware threads. There are other cases for a given hardware platform, and if it is a 32-bit JVM, the collector (and JIT compiler) ergonomically selected may also differ from other configurations. AFAIK, the JEP is proposing to change the default GC in configurations where the default GC is Parallel GC to using G1 as the default. The challenge with what you are describing is that the best GC cannot always be ergonomically selected by the JVM without some input from the user, i.e. GC doesn?t know if any GC pauses greater than 200 ms are acceptable regardless of Java heap size, number of hardware threads, etc. thanks, charlie > On Jun 1, 2015, at 2:53 PM, Erik ?sterlund > wrote: > > Hi all, > > Does there have to be a single default one-size-fits-all GC algorithm for > users to rely on? Or could we allow multiple algorithms and explicitly > document that unless a GC is picked, the runtime is free to pick whatever > it believes is better? This could have multiple benefits. > > 1. This could make such a similar change easier in the future as everyone > will already be aware that if they really rely on the properties of a > specific GC algorithm, then they should choose that GC explicitly and not > rely on defaults not changing; there are no guarantees that defaults will > not change. > > 2. Obviously there has been a long discussion in this thread which GC is > better in which context, and it seems like right now one size does not fit > all. The user that relied on the defaults might not be so aware of these > specifics. Therefore we might do them a big favour of attempting to make a > guess for them to work out-of-the-box, which is pretty neat. > > 3. This approach allows deploying G1 not everywhere, but where we guess it > performs pretty well. This means it will run in fewer JVM contexts and > hence pose less risk than deploying it to be used for all contexts, making > the transition smoother. > > One idea could be to first determine valid GC variants given the supplied > flags (GC-specific flags imply use of that GC), and then among the valid > GCs left, ?guess? which algorithm is better based on the other general > parameters, such as e.g. heap size (and maybe target latency)? Could for > instance pick ParallelGC for small heaps, G1 for larger heaps and CMS for > ridiculously large heaps or cases when extremely low latency is wanted? > > My reasoning is based on two assumptions: 1) changing the defaults would > target the users that don?t know what?s best for them, 2) one size does > not fit all. If these assumption are wrong, then this is a bad idea. > > Thanks, > /Erik > > > > Den 01/06/15 20:53 skrev charlie hunt >: > >> Hi Jenny, >> >> A couple questions and comments below. >> >> thanks, >> >> charlie >> >>> On Jun 1, 2015, at 1:28 PM, Yu Zhang > wrote: >>> >>> Hi, >>> >>> I have done some performance comparison g1/cms/parallelgc internally at >>> Oracle. I would like to post my observations here to get some feedback, >>> as I have limited benchmarks and hardware. These are out of box >>> performance. >>> >>> Memory footprint/startup: >>> g1 has bigger memory footprint and longer start up time. The overhead >>> comes from more gc threads, and internal data structures to keep track >>> of remember set. >> >> This is the memory footprint of the JVM itself when using the same size >> Java heap, right? >> >> I don?t recall if it has been your observation? One observation I have >> had with G1 is that it tends to be able to operate within tolerable >> throughput and latency with a smaller Java heap than with Parallel GC. I >> have seen cases where G1 may not use the entire Java heap because it was >> able to keep enough free regions available yet still meet pause time >> goals. But, Parallel GC always use the entire Java heap, and once its >> occupancy reach capacity, it would GC. So they are cases where between >> the JVM?s footprint overhead, and taking into account the amount of Java >> heap required, G1 may actually require less memory. >> >>> >>> g1 vs parallelgc: >>> If the workload involves young gc only, g1 could be slightly slower. >>> Also g1 can consume more cpu, which might slow down the benchmark if SUT >>> is cpu saturated. >>> >>> If there are promotions from young to old gen and leads to full gc with >>> parallelgc, for smaller heap, parallel full gc can finish within some >>> range of pause time, still out performs g1. But for bigger heap, g1 >>> mixed gc can clean the heap with pause times a fraction of parallel full >>> gc time, so improve both throughput and response time. Extreme cases >>> are big data workloads(for example ycsb) with 100g heap. >> >> I think what you are saying here is that it looks like if one can tune >> Parallel GC such that you can avoid a lengthy collection of old >> generation, or the live occupancy of old gen is small enough that the >> time to collect is small enough to be tolerated, then Parallel GC will >> offer a better experience. >> >> However, if the live data in old generation at the time of its collection >> is large enough such that the time it takes to collect it exceeds a >> tolerable pause time, then G1 will offer a better experience. >> >> Would also say that G1 offers a better experience in the presences of >> (wide) swings in object allocation rates since there would likely be a >> larger number of promotions during the allocation spikes? In other >> words, G1 may offer more predictable pauses. >> >>> >>> g1 vs cms: >>> I will focus on response time type of workloads. >>> Ben mentioned >>> >>> "Having said that, there is definitely a decent-sized class of systems >>> (not just in finance) that cannot really tolerate any more than about >>> 10-15ms of STW. So, what usually happens is that they live with the >>> young collections, use CMS and tune out the CMFs as best they can (by >>> clustering, rolling restart, etc, etc). I don't see any possibility of >>> G1 becoming a viable solution for those systems any time soon." >>> >>> Can you give more details, like what is the live data set size, how big >>> is the heap, etc? I did some cache tests (Oracle coherence) to compare >>> cms vs g1. g1 is better than cms when there are fragmentations. If you >>> tune cms well to have little fragmentation, then g1 is behind cms. But >>> for those cases, they have to tune CMS very well, changing default to g1 >>> won't impact them. >>> >>> For big data kind of workloads (ycsb, spark in memory computing), g1 is >>> much better than cms. >>> >>> Thanks, >>> Jenny >>> >>> On 6/1/2015 10:06 AM, Ben Evans wrote: >>>> Hi Vitaly, >>>> >>>>>> Instead, G1 is now being talked of as a replacement for the default >>>>>> collector. If that's the case, then I think we need to acknowledge >>>>>> it, >>>>>> and have a conversation about where G1 is actually supposed to be >>>>>> used. Are we saying we want a "reasonably high throughput with >>>>>> reduced >>>>>> STW, but not low pause time" collector? If we are, that's fine, but >>>>>> that's not where we started. >>>>> That's a fair point, and one I'd be interesting in hearing an answer >>>>> to as >>>>> well. FWIW, the only GC I know of that's actually used in low latency >>>>> systems is Azul's C4, so I'm not even sure Oracle is trying to target >>>>> the >>>>> same use cases. So when we talk about "low latency" GCs, we should >>>>> probably >>>>> also be clear on what "low" actually means. >>>> Well, when I started playing with them, "low latency" meant a >>>> sub-10-ms transaction time with 100ms STW as acceptable, if not ideal. >>>> >>>> These days, the same sort of system needs a sub 500us transaction >>>> time, and ideally no GC pause at all. But that leads to Zing, or >>>> non-JVM solutions, and I think takes us too far into a specialised use >>>> case. >>>> >>>> Having said that, there is definitely a decent-sized class of systems >>>> (not just in finance) that cannot really tolerate any more than about >>>> 10-15ms of STW. So, what usually happens is that they live with the >>>> young collections, use CMS and tune out the CMFs as best they can (by >>>> clustering, rolling restart, etc, etc). I don't see any possibility of >>>> G1 becoming a viable solution for those systems any time soon. >>>> >>>> Thanks, >>>> >>>> Ben >>> >> > From kim.barrett at oracle.com Tue Jun 2 01:04:36 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 1 Jun 2015 21:04:36 -0400 Subject: JEP 248: Make G1 the Default Garbage Collector In-Reply-To: References: <20150428220211.4355960845@eggemoggin.niobe.net> <5C5564BB-23ED-49AB-81C6-CFF85B56ACA4@kodewerk.com> <5540D689.6020407@oracle.com> <73855087-8BB2-4A8C-B9AD-080CD39FAB7A@kodewerk.com> <55423444.7040009@beckwithclan.com> <556CA452.9040405@oracle.com> <7E7759C3-3AF0-4047-9B00-605DBB55DC79@oracle.com> Message-ID: <7AAB831F-127D-4508-BA79-E89783F352C2@oracle.com> On Jun 1, 2015, at 7:04 PM, Jeremy Manson wrote: > > - Part of the reason our CMS performs better is that we've made changes to > CMS to improve its performance. We see roughly half as much CPU > utilization, and the long tail pause times have been cut dramatically. It > would be nice if we could upstream the changes (especially for us, because > they break with every new release, and we have to fix them!), but we've > never been able to find anyone at Oracle who has the bandwidth to do the > reviews. For example, the response to this: > > http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2015-May/013426.html > > was not hugely enthusiastic, and that's not even one of the more complex > changes. I?d be interested in looking at the mentioned card table scanning speedup. But I completely missed that comment, buried as it is in the middle of a more or less unrelated discussion. I?m going to go reply over there, since that technical problem doesn?t have anything to do with what?s being discussed here. From vitalyd at gmail.com Tue Jun 2 01:09:30 2015 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Mon, 1 Jun 2015 21:09:30 -0400 Subject: JEP 248: Make G1 the Default Garbage Collector In-Reply-To: References: <20150428220211.4355960845@eggemoggin.niobe.net> <5C5564BB-23ED-49AB-81C6-CFF85B56ACA4@kodewerk.com> <5540D689.6020407@oracle.com> <73855087-8BB2-4A8C-B9AD-080CD39FAB7A@kodewerk.com> <55423444.7040009@beckwithclan.com> <556CA452.9040405@oracle.com> <7E7759C3-3AF0-4047-9B00-605DBB55DC79@oracle.com> Message-ID: I think Jeremy alluded to it: make sure there's very little promotion by tuning CMS such that things don't get aged into promotion. I'm assuming the unspoken aspect is also: don't allocate like a maniac, which is good for other reasons as well of course. sent from my phone On Jun 1, 2015 9:01 PM, "Erik ?sterlund" wrote: > Hi Jeremy, > > Are you suggesting making Google?s CMS the new default instead? > The target for this is long running server applications where > fragmentation issues become increasingly awkward over time. Literature > suggests fragmentation overheads can be as bad as allocations costing 1/2 > log(n) as much memory due to fragmentation, where n is the ratio of the > smallest and largest allocatable objects. In short? ouch! This can make the > JVM run out of memory and crash, which is suboptimal. > So I?m curious - what?s the Google solution to fragmentation using CMS? > Let me guess? buy more memory? :p > > Cheers, > /Erik > > Fr?n: Jeremy Manson jeremymanson at google.com>> > Datum: Tuesday 2 June 2015 01:04 > Till: charlie hunt >> > Kopia: Erik ?sterlund >, > "hotspot-dev at openjdk.java.net Source > Developers" hotspot-dev at openjdk.java.net>> > ?mne: Re: JEP 248: Make G1 the Default Garbage Collector > > This is a very interesting conversation, and I'd like to throw in Google's > not-quite-relevant observations, too. We're not quite relevant because > we'll just change the default to whatever we want, and because we ignore > the parallel GC, for the most part. Much of it has been said before in > this thread, but it's worth reiterating. > > - As it happens, we're considering changing the default, too - to the CMS > collector! > > - We've been asking people to try G1 approximately annually for the last > five or so years. > > - Although G1 performance has gotten better over time, we still find that > the additional CPU costs outweigh any benefits, and that CMS typically ends > up ahead. > > - With most of our more important workloads, our admins tend to tune > applications carefully so that the OG doesn't fill up too much, and CMS > cycles are not triggered often. This is deeply important in server-style > applications - you want anything generated and used by a single request to > go away with a YG collection. > > - Part of the reason our CMS performs better is that we've made changes to > CMS to improve its performance. We see roughly half as much CPU > utilization, and the long tail pause times have been cut dramatically. It > would be nice if we could upstream the changes (especially for us, because > they break with every new release, and we have to fix them!), but we've > never been able to find anyone at Oracle who has the bandwidth to do the > reviews. For example, the response to this: > > http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2015-May/013426.html > > was not hugely enthusiastic, and that's not even one of the more complex > changes. > > Jeremy > > On Mon, Jun 1, 2015 at 1:51 PM, charlie hunt > wrote: > Hi Erik, > > HotSpot does some of this ergonomics today for both GC and JIT compiler in > cases where the JVM sees less than 2 GB of RAM and the OS it is running on. > These decisions are based on what is called a ?server class machine?. A > ?server class machine? as of JDK 6u18 is defined as a system that has 2 GB > or more of RAM, two or more hardware threads. There are other cases for a > given hardware platform, and if it is a 32-bit JVM, the collector (and JIT > compiler) ergonomically selected may also differ from other configurations. > > AFAIK, the JEP is proposing to change the default GC in configurations > where the default GC is Parallel GC to using G1 as the default. > > The challenge with what you are describing is that the best GC cannot > always be ergonomically selected by the JVM without some input from the > user, i.e. GC doesn?t know if any GC pauses greater than 200 ms are > acceptable regardless of Java heap size, number of hardware threads, etc. > > thanks, > > charlie > > > On Jun 1, 2015, at 2:53 PM, Erik ?sterlund > wrote: > > > > Hi all, > > > > Does there have to be a single default one-size-fits-all GC algorithm for > > users to rely on? Or could we allow multiple algorithms and explicitly > > document that unless a GC is picked, the runtime is free to pick whatever > > it believes is better? This could have multiple benefits. > > > > 1. This could make such a similar change easier in the future as everyone > > will already be aware that if they really rely on the properties of a > > specific GC algorithm, then they should choose that GC explicitly and not > > rely on defaults not changing; there are no guarantees that defaults will > > not change. > > > > 2. Obviously there has been a long discussion in this thread which GC is > > better in which context, and it seems like right now one size does not > fit > > all. The user that relied on the defaults might not be so aware of these > > specifics. Therefore we might do them a big favour of attempting to make > a > > guess for them to work out-of-the-box, which is pretty neat. > > > > 3. This approach allows deploying G1 not everywhere, but where we guess > it > > performs pretty well. This means it will run in fewer JVM contexts and > > hence pose less risk than deploying it to be used for all contexts, > making > > the transition smoother. > > > > One idea could be to first determine valid GC variants given the supplied > > flags (GC-specific flags imply use of that GC), and then among the valid > > GCs left, ?guess? which algorithm is better based on the other general > > parameters, such as e.g. heap size (and maybe target latency)? Could for > > instance pick ParallelGC for small heaps, G1 for larger heaps and CMS for > > ridiculously large heaps or cases when extremely low latency is wanted? > > > > My reasoning is based on two assumptions: 1) changing the defaults would > > target the users that don?t know what?s best for them, 2) one size does > > not fit all. If these assumption are wrong, then this is a bad idea. > > > > Thanks, > > /Erik > > > > > > > > Den 01/06/15 20:53 skrev charlie hunt charlie.hunt at oracle.com>>: > > > >> Hi Jenny, > >> > >> A couple questions and comments below. > >> > >> thanks, > >> > >> charlie > >> > >>> On Jun 1, 2015, at 1:28 PM, Yu Zhang yu.zhang at oracle.com>> wrote: > >>> > >>> Hi, > >>> > >>> I have done some performance comparison g1/cms/parallelgc internally at > >>> Oracle. I would like to post my observations here to get some > feedback, > >>> as I have limited benchmarks and hardware. These are out of box > >>> performance. > >>> > >>> Memory footprint/startup: > >>> g1 has bigger memory footprint and longer start up time. The overhead > >>> comes from more gc threads, and internal data structures to keep track > >>> of remember set. > >> > >> This is the memory footprint of the JVM itself when using the same size > >> Java heap, right? > >> > >> I don?t recall if it has been your observation? One observation I have > >> had with G1 is that it tends to be able to operate within tolerable > >> throughput and latency with a smaller Java heap than with Parallel GC. > I > >> have seen cases where G1 may not use the entire Java heap because it was > >> able to keep enough free regions available yet still meet pause time > >> goals. But, Parallel GC always use the entire Java heap, and once its > >> occupancy reach capacity, it would GC. So they are cases where between > >> the JVM?s footprint overhead, and taking into account the amount of Java > >> heap required, G1 may actually require less memory. > >> > >>> > >>> g1 vs parallelgc: > >>> If the workload involves young gc only, g1 could be slightly slower. > >>> Also g1 can consume more cpu, which might slow down the benchmark if > SUT > >>> is cpu saturated. > >>> > >>> If there are promotions from young to old gen and leads to full gc with > >>> parallelgc, for smaller heap, parallel full gc can finish within some > >>> range of pause time, still out performs g1. But for bigger heap, g1 > >>> mixed gc can clean the heap with pause times a fraction of parallel > full > >>> gc time, so improve both throughput and response time. Extreme cases > >>> are big data workloads(for example ycsb) with 100g heap. > >> > >> I think what you are saying here is that it looks like if one can tune > >> Parallel GC such that you can avoid a lengthy collection of old > >> generation, or the live occupancy of old gen is small enough that the > >> time to collect is small enough to be tolerated, then Parallel GC will > >> offer a better experience. > >> > >> However, if the live data in old generation at the time of its > collection > >> is large enough such that the time it takes to collect it exceeds a > >> tolerable pause time, then G1 will offer a better experience. > >> > >> Would also say that G1 offers a better experience in the presences of > >> (wide) swings in object allocation rates since there would likely be a > >> larger number of promotions during the allocation spikes? In other > >> words, G1 may offer more predictable pauses. > >> > >>> > >>> g1 vs cms: > >>> I will focus on response time type of workloads. > >>> Ben mentioned > >>> > >>> "Having said that, there is definitely a decent-sized class of systems > >>> (not just in finance) that cannot really tolerate any more than about > >>> 10-15ms of STW. So, what usually happens is that they live with the > >>> young collections, use CMS and tune out the CMFs as best they can (by > >>> clustering, rolling restart, etc, etc). I don't see any possibility of > >>> G1 becoming a viable solution for those systems any time soon." > >>> > >>> Can you give more details, like what is the live data set size, how big > >>> is the heap, etc? I did some cache tests (Oracle coherence) to compare > >>> cms vs g1. g1 is better than cms when there are fragmentations. If you > >>> tune cms well to have little fragmentation, then g1 is behind cms. But > >>> for those cases, they have to tune CMS very well, changing default to > g1 > >>> won't impact them. > >>> > >>> For big data kind of workloads (ycsb, spark in memory computing), g1 is > >>> much better than cms. > >>> > >>> Thanks, > >>> Jenny > >>> > >>> On 6/1/2015 10:06 AM, Ben Evans wrote: > >>>> Hi Vitaly, > >>>> > >>>>>> Instead, G1 is now being talked of as a replacement for the default > >>>>>> collector. If that's the case, then I think we need to acknowledge > >>>>>> it, > >>>>>> and have a conversation about where G1 is actually supposed to be > >>>>>> used. Are we saying we want a "reasonably high throughput with > >>>>>> reduced > >>>>>> STW, but not low pause time" collector? If we are, that's fine, but > >>>>>> that's not where we started. > >>>>> That's a fair point, and one I'd be interesting in hearing an answer > >>>>> to as > >>>>> well. FWIW, the only GC I know of that's actually used in low > latency > >>>>> systems is Azul's C4, so I'm not even sure Oracle is trying to target > >>>>> the > >>>>> same use cases. So when we talk about "low latency" GCs, we should > >>>>> probably > >>>>> also be clear on what "low" actually means. > >>>> Well, when I started playing with them, "low latency" meant a > >>>> sub-10-ms transaction time with 100ms STW as acceptable, if not ideal. > >>>> > >>>> These days, the same sort of system needs a sub 500us transaction > >>>> time, and ideally no GC pause at all. But that leads to Zing, or > >>>> non-JVM solutions, and I think takes us too far into a specialised use > >>>> case. > >>>> > >>>> Having said that, there is definitely a decent-sized class of systems > >>>> (not just in finance) that cannot really tolerate any more than about > >>>> 10-15ms of STW. So, what usually happens is that they live with the > >>>> young collections, use CMS and tune out the CMFs as best they can (by > >>>> clustering, rolling restart, etc, etc). I don't see any possibility of > >>>> G1 becoming a viable solution for those systems any time soon. > >>>> > >>>> Thanks, > >>>> > >>>> Ben > >>> > >> > > > > > From david.holmes at oracle.com Tue Jun 2 04:48:23 2015 From: david.holmes at oracle.com (David Holmes) Date: Tue, 02 Jun 2015 14:48:23 +1000 Subject: RFR 8059557: Test set for "Validate JVM Command-Line Flag Arguments" In-Reply-To: <55671906.10000@oracle.com> References: <555A09B8.7010402@oracle.com> <555E46A7.4020402@oracle.com> <55671906.10000@oracle.com> Message-ID: <556D3597.8090508@oracle.com> Hi Dmitry, On 28/05/2015 11:32 PM, Dmitry Dmitriev wrote: > Hello all, > > Here is a 3 version of the tests taking into account feedback from > Christian, David and Gerard. > > I limit number of options in TestOptionsWithRanges.java to 15. This > include options of different types(intx, uintx etc.) and with different > combination of min/max range. TestOptionsWithRangesDynamic.java leaved > as is, because amount of manageable numeric options is very small and > currently only 3 of them have range. Also, I improve code for double > option. > > Webrev: http://cr.openjdk.java.net/~ddmitriev/8059557/webrev.03/ > Only a few style/grammar nits (the downside of writing so many doc comments :) ). Meta-question: is there a specific reason to use the package "options validation"? It looks odd to me to have OptionsValidation/common/optionsvalidation/ in the paths. General doc-comment comments: - @param/@return descriptions should start with lower-case (you currently mix-n-match) - @throws description should start with "if", so: @throws IOException if an error occurred reading the data General Java-style comments: - access modifiers (public, private, protected) always come first --- test/runtime/CommandLine/OptionsValidation/common/optionsvalidation/IntJVMOption.java 265 * passed value is negative then error will be catched earlier for catched -> caught --- test/runtime/CommandLine/OptionsValidation/common/optionsvalidation/JVMOption.java 327 * @param param Tested parameter passed to the java "the java" is not a noun - suggest "the JVM" ? Maybe change Java to JVM to avoid use of "java" as a noun everywhere. 350 failedMessage(name, fullOptionString, valid, "JVM output reports about fatal error. JVM exit with code " + returnCode + "!"); The message isn't grammatically correct: about -> a; exit -> exited Similarly "JVM exit" -> "JVM exited" 377 failedMessage(name, fullOptionString, valid, "JVM output not contains " not contains -> does not contain 400 * Return list of strings which contain options with valid values which used which used -> which can be used 416 * Return list of strings which contain options with invalid values which 417 * used for testing on command line Ditto --- test/runtime/CommandLine/OptionsValidation/common/optionsvalidation/JVMOptionsUtils.java 101 * Add dependency for option depending on it's type. E.g. ran java in ran java -> run the JVM 119 * @param withRanges true if needed options with defined ranges I'm not sure what this means. Occurs elswhere too. 121 * "product", "diagnostic" etc. Accept option only if acceptOrigin return return -> returns (or even return -> evaluates). Occurs elsewhere too. 260 * methods. Tested only writeable options. Suggestion: Only tests writeable options. Occurs elsewhere too. 264 * @throws Exception When? Why? Occurs elsewhere too. Thanks, David ----- > Thanks, > Dmitry > > > On 21.05.2015 23:57, Dmitry Dmitriev wrote: >> Hello all, >> >> Recently I correct several typos, so here a new webrev for tests: >> http://cr.openjdk.java.net/~ddmitriev/8059557/webrev.02/ >> >> >> Thanks, >> Dmitry >> >> On 18.05.2015 18:48, Dmitry Dmitriev wrote: >>> Hello all, >>> >>> Please review test set for verifying functionality implemented by JEP >>> 245 "Validate JVM Command-Line Flag Arguments"(JDK-8059557). Review >>> request for this JEP can be found there: >>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-May/018539.html >>> >>> I create 3 tests for verifying options with ranges. The tests mostly >>> rely on common/optionsvalidation/JVMOptionsUtils.java. Class in this >>> file contains functions to get options with ranges as list(by parsing >>> new option "-XX:+PrintFlagsRanges" output), run command line test for >>> list of options and other. The actual test code contained in >>> common/optionsvalidation/JVMOption.java file - testCommandLine(), >>> testDynamic(), testJcmd() and testAttach() methods. >>> common/optionsvalidation/IntJVMOption.java and >>> common/optionsvalidation/DoubleJVMOption.java source files contain >>> classes derived from JVMOption class for integer and double JVM >>> options correspondingly. >>> >>> Here are description of the tests: >>> 1) >>> hotspot/test/runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java >>> >>> >>> This test get all options with ranges by parsing output of new option >>> "-XX:+PrintFlagsRanges" and verify these options by starting Java and >>> passing options in command line with valid and invalid values. >>> Currently it verifies about 106 options which have ranges. >>> Invalid values are values which out-of-range. In test used values >>> "min-1" and "max+1".In this case Java should always exit with code 1 >>> and print error message about out-of-range value(with one exception, >>> if option is unsigned and passing negative value, then out-of-range >>> error message is not printed because error occurred earlier). >>> Valid values are values in range, e.g. min&max and also several >>> additional values. In this case Java should successfully exit(exit >>> code 0) or exit with error code 1 for other reasons(low memory with >>> certain option value etc.). In any case for values in range Java >>> should not print messages about out of range value. >>> In any case Java should not crash. >>> This test excluded from JPRT because it takes long time to execute >>> and also fails - some options with value in valid range cause Java to >>> crash(bugs are submitted). >>> >>> 2) >>> hotspot/test/runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java >>> >>> >>> This test get all writeable options with ranges by parsing output of >>> new option "-XX:+PrintFlagsRanges" and verify these options by >>> dynamically changing it's values to the valid and invalid values. >>> Used 3 methods for that: DynamicVMOption isValidValue and >>> isInvalidValue methods, Jcmd and by attach method. Currently 3 >>> writeable options with ranges are verified by this test. >>> This test pass in JPRT. >>> >>> 3) >>> hotspot/test/runtime/CommandLine/OptionsValidation/TestJcmdOutput.java >>> >>> This test verified output of Jcmd when out-of-range value is set to >>> the writeable option or value violates option constraint. Also this >>> test verify that jcmd not write error message to the target process. >>> This test pass in JPRT. >>> >>> >>> I am not write special tests for constraints for this JEP because >>> there are exist test for that(e.g. >>> test/runtime/CompressedOops/ObjectAlignment.java for >>> ObjectAlignmentInBytes or >>> hotspot/test/gc/arguments/TestHeapFreeRatio.java for >>> MinHeapFreeRatio/MaxHeapFreeRatio). >>> >>> Webrev: http://cr.openjdk.java.net/~ddmitriev/8059557/webrev.00/ >>> >>> >>> JEP: https://bugs.openjdk.java.net/browse/JDK-8059557 >>> >>> Thanks, >>> Dmitry >>> >> > From jeremymanson at google.com Tue Jun 2 05:21:29 2015 From: jeremymanson at google.com (Jeremy Manson) Date: Mon, 1 Jun 2015 22:21:29 -0700 Subject: JEP 248: Make G1 the Default Garbage Collector In-Reply-To: References: <20150428220211.4355960845@eggemoggin.niobe.net> <5C5564BB-23ED-49AB-81C6-CFF85B56ACA4@kodewerk.com> <5540D689.6020407@oracle.com> <73855087-8BB2-4A8C-B9AD-080CD39FAB7A@kodewerk.com> <55423444.7040009@beckwithclan.com> <556CA452.9040405@oracle.com> <7E7759C3-3AF0-4047-9B00-605DBB55DC79@oracle.com> Message-ID: On Mon, Jun 1, 2015 at 6:00 PM, Erik ?sterlund wrote: > Hi Jeremy, > > Are you suggesting making Google?s CMS the new default instead? > Not even a little bit. As I said, our experiences are just that - ours. I'm more or less just saying that we have had much more luck improving CMS than we have trying G1. Once every year or two, we ask ourselves the question of whether we should focus our attention on G1, and the answer has perennially been no. > The target for this is long running server applications where > fragmentation issues become increasingly awkward over time. Literature > suggests fragmentation overheads can be as bad as allocations costing 1/2 > log(n) as much memory due to fragmentation, where n is the ratio of the > smallest and largest allocatable objects. In short? ouch! This can make the > JVM run out of memory and crash, which is suboptimal. > So I?m curious - what?s the Google solution to fragmentation using CMS? > Let me guess? buy more memory? :p > Google scale is such that *any* increased use of memory on a per-server basis costs an enormous amount, when multiplied by the number of servers we're running. We very aggressively keep heap footprints as small as possible. We even give unused space in the heap back to the OS, which saves us huge amounts of RAM across Google's servers, but is another patch that Oracle doesn't want. For all of this talk of larger heaps - anything larger than single digit GB are outliers for our Java jobs, and we would never consider switching the default to make those kinds of jobs better. For users who really care about GC behavior, they design their system so that they either don't see fragmentation issues, or so that periods of unavailability are acceptable. Some tune it so that the CMS generation basically only contains objects that live forever, so CMS cycles (and resulting fragmentation) are rare. Aggressive users even have their admins get paged when their services do a full compacting collection in the CMS, and consider it a major regression. Fragmentation *can* be a problem, of course. We've responded to it by doing / attempting a few things: Simply optimizing the existing code can help a great deal. For example, for users who don't want to have their pager go off when they do a full compaction, we've parallelized full compacting collection of the CMS generation, so that it is much closer to the speed of the parallel old GC. Hotspot currently falls back to an insanely slow serial collection in this case, which was unacceptable for us. This (in concert with other optimizations) has significantly improved long-tail latencies. We have some users who don't mind OOMEs because of thrashing as much, as long as they happen in a timely fashion. The current metrics don't really allow OOME to happen because of GC thrashing in a timely way, so we've tweaked that. We also export fragmentation metrics from Hotspot, so that our users can identify problematic behaviors. We have a ton of other metrics we export about what's in the heap and what garbage collection statistics there are, allowing people to keep a pretty close eye on these issues. At one point, we tried to do partial compaction during the mark phase, but it was so expensive that we didn't feel comfortable inflicting it on our users - it would have helped worst case behavior, and pretty much got rid of full compacting collections, but would have made latencies for well tuned services significantly worse. We thought about having it be opt-in, and then we realized that anyone who cared enough about their systems to opt into something like that probably cared enough to fix it so that fragmentation wouldn't be a problem. I'm probably forgetting some other things. :) Jeremy From jeremymanson at google.com Tue Jun 2 05:22:18 2015 From: jeremymanson at google.com (Jeremy Manson) Date: Mon, 1 Jun 2015 22:22:18 -0700 Subject: JEP 248: Make G1 the Default Garbage Collector In-Reply-To: <7AAB831F-127D-4508-BA79-E89783F352C2@oracle.com> References: <20150428220211.4355960845@eggemoggin.niobe.net> <5C5564BB-23ED-49AB-81C6-CFF85B56ACA4@kodewerk.com> <5540D689.6020407@oracle.com> <73855087-8BB2-4A8C-B9AD-080CD39FAB7A@kodewerk.com> <55423444.7040009@beckwithclan.com> <556CA452.9040405@oracle.com> <7E7759C3-3AF0-4047-9B00-605DBB55DC79@oracle.com> <7AAB831F-127D-4508-BA79-E89783F352C2@oracle.com> Message-ID: On Mon, Jun 1, 2015 at 6:04 PM, Kim Barrett wrote: > On Jun 1, 2015, at 7:04 PM, Jeremy Manson wrote: > > > > - Part of the reason our CMS performs better is that we've made changes > to > > CMS to improve its performance. We see roughly half as much CPU > > utilization, and the long tail pause times have been cut dramatically. > It > > would be nice if we could upstream the changes (especially for us, > because > > they break with every new release, and we have to fix them!), but we've > > never been able to find anyone at Oracle who has the bandwidth to do the > > reviews. For example, the response to this: > > > > > http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2015-May/013426.html > > > > was not hugely enthusiastic, and that's not even one of the more complex > > changes. > > I?d be interested in looking at the mentioned card table scanning > speedup. But I completely > missed that comment, buried as it is in the middle of a more or less > unrelated discussion. I?m > going to go reply over there, since that technical problem doesn?t have > anything to do with > what?s being discussed here. > Excellent! In that case, my interjection here was completely worth my time. Jungwoo is out until Wednesday, but I'll make sure he sees it. Jeremy From yu.zhang at oracle.com Tue Jun 2 05:38:46 2015 From: yu.zhang at oracle.com (Yu Zhang) Date: Mon, 01 Jun 2015 22:38:46 -0700 Subject: JEP 248: Make G1 the Default Garbage Collector In-Reply-To: References: <20150428220211.4355960845@eggemoggin.niobe.net> <55423444.7040009@beckwithclan.com> <556CA452.9040405@oracle.com> <7E7759C3-3AF0-4047-9B00-605DBB55DC79@oracle.com> Message-ID: <556D4166.4060806@oracle.com> Jeremy, Thanks for the information on your case. Very interesting, and might be typical how users are using CMS. If we keep fragmentation out of the picture, it boils down to comparing g1 and cms young gc. From your experience, what is the dominant cost for g1 young gc? Thanks, Jenny On 6/1/2015 10:21 PM, Jeremy Manson wrote: > On Mon, Jun 1, 2015 at 6:00 PM, Erik ?sterlund > wrote: > >> Hi Jeremy, >> >> Are you suggesting making Google?s CMS the new default instead? >> > Not even a little bit. As I said, our experiences are just that - ours. > I'm more or less just saying that we have had much more luck improving CMS > than we have trying G1. Once every year or two, we ask ourselves the > question of whether we should focus our attention on G1, and the answer has > perennially been no. > > >> The target for this is long running server applications where >> fragmentation issues become increasingly awkward over time. Literature >> suggests fragmentation overheads can be as bad as allocations costing 1/2 >> log(n) as much memory due to fragmentation, where n is the ratio of the >> smallest and largest allocatable objects. In short? ouch! This can make the >> JVM run out of memory and crash, which is suboptimal. >> So I?m curious - what?s the Google solution to fragmentation using CMS? >> Let me guess? buy more memory? :p >> > Google scale is such that *any* increased use of memory on a per-server > basis costs an enormous amount, when multiplied by the number of servers > we're running. We very aggressively keep heap footprints as small as > possible. We even give unused space in the heap back to the OS, which > saves us huge amounts of RAM across Google's servers, but is another patch > that Oracle doesn't want. > > For all of this talk of larger heaps - anything larger than single digit GB > are outliers for our Java jobs, and we would never consider switching the > default to make those kinds of jobs better. > > For users who really care about GC behavior, they design their system so > that they either don't see fragmentation issues, or so that periods of > unavailability are acceptable. Some tune it so that the CMS generation > basically only contains objects that live forever, so CMS cycles (and > resulting fragmentation) are rare. Aggressive users even have their admins > get paged when their services do a full compacting collection in the CMS, > and consider it a major regression. > > Fragmentation *can* be a problem, of course. We've responded to it by > doing / attempting a few things: > > Simply optimizing the existing code can help a great deal. For example, > for users who don't want to have their pager go off when they do a full > compaction, we've parallelized full compacting collection of the CMS > generation, so that it is much closer to the speed of the parallel old GC. > Hotspot currently falls back to an insanely slow serial collection in this > case, which was unacceptable for us. This (in concert with other > optimizations) has significantly improved long-tail latencies. > > We have some users who don't mind OOMEs because of thrashing as much, as > long as they happen in a timely fashion. The current metrics don't really > allow OOME to happen because of GC thrashing in a timely way, so we've > tweaked that. > > We also export fragmentation metrics from Hotspot, so that our users can > identify problematic behaviors. We have a ton of other metrics we export > about what's in the heap and what garbage collection statistics there are, > allowing people to keep a pretty close eye on these issues. > > At one point, we tried to do partial compaction during the mark phase, but > it was so expensive that we didn't feel comfortable inflicting it on our > users - it would have helped worst case behavior, and pretty much got rid > of full compacting collections, but would have made latencies for well > tuned services significantly worse. We thought about having it be opt-in, > and then we realized that anyone who cared enough about their systems to > opt into something like that probably cared enough to fix it so that > fragmentation wouldn't be a problem. > > I'm probably forgetting some other things. :) > > Jeremy From aph at redhat.com Tue Jun 2 07:44:57 2015 From: aph at redhat.com (Andrew Haley) Date: Tue, 02 Jun 2015 08:44:57 +0100 Subject: RFR: 8079315: UseCondCardMark broken in conjunction with CMS precleaning In-Reply-To: References: <5548D913.1030507@redhat.com> <5548EDE9.8090803@redhat.com> <5548F59D.6090008@oracle.com> <5549D681.3000806@redhat.com> <554A1CA0.6070801@oracle.com> <473C887F-8CC5-4E67-BD9A-1882660CFD3C@lnu.se> <554B3B5E.8000705@oracle.com> <8EE73C49-83CD-4162-A3EF-19DDA2C2CDFA@lnu.se> <554FC66F.20307@oracle.com> <55507BE4.3050605@redhat.com> <03C141D8-952E-4E7A-BDAD-024CE2239010@lnu.se> <55508B60.1000200@redhat.com> <8868A273-7C97-45F0-BF10-85DDE5859E85@lnu.se> <5550B182.7090009@redhat.com> <5551FA97.9090502@oracle.com> <5551FD72.1020504@oracle.com> <38CAAA0B-6F32-4508-818F-AD9D248E8B35@lnu.se> <55524C58.4030904@oracle.com> <55524E8C.6080709@redhat.com> <55526041.1030709@redhat.com> <7C4CBC57-D7B2-4779-9353-DEACCB626370@lnu.se> <5552838B.3020305@oracle.com> Message-ID: <556D5EF9.6030702@redhat.com> Have we come to a complete standstill? We have a number of AArch64 patches, needed for correctness, which are blocked on this. But part of the simple AArch64 fix, which would be a StoreLoad barrier, requires a change to shared code. I could submit something #ifdef AARCH64, which probably wouldn't be popular. Andrew. From aph at redhat.com Tue Jun 2 07:57:14 2015 From: aph at redhat.com (Andrew Haley) Date: Tue, 02 Jun 2015 08:57:14 +0100 Subject: JEP 248: Make G1 the Default Garbage Collector In-Reply-To: References: <20150428220211.4355960845@eggemoggin.niobe.net> <5540D689.6020407@oracle.com> <73855087-8BB2-4A8C-B9AD-080CD39FAB7A@kodewerk.com> <55423444.7040009@beckwithclan.com> <8DFF9BB7-3E76-4545-B5D9-07BE0D4693CB@oracle.com> <94973BE6-4FA4-45D9-A2F5-AF2B81226B4D@oracle.com> Message-ID: <556D61DA.9020906@redhat.com> On 01/06/15 18:54, Ben Evans wrote: > I would not want to see a change made to the default behaviour that > could potentially negatively affect a large number of apps and in > doing so harm the long-term perception of the platform as a "safe pair > of hands". But that would mean that we could never change the default behaviour of anything important. Andrew. From erik.osterlund at lnu.se Tue Jun 2 08:17:47 2015 From: erik.osterlund at lnu.se (=?iso-8859-1?Q?Erik_=D6sterlund?=) Date: Tue, 2 Jun 2015 08:17:47 +0000 Subject: RFR: 8079315: UseCondCardMark broken in conjunction with CMS precleaning In-Reply-To: <556D5EF9.6030702@redhat.com> References: <5548D913.1030507@redhat.com> <5548EDE9.8090803@redhat.com> <5548F59D.6090008@oracle.com> <5549D681.3000806@redhat.com> <554A1CA0.6070801@oracle.com> <473C887F-8CC5-4E67-BD9A-1882660CFD3C@lnu.se> <554B3B5E.8000705@oracle.com> <8EE73C49-83CD-4162-A3EF-19DDA2C2CDFA@lnu.se> <554FC66F.20307@oracle.com> <55507BE4.3050605@redhat.com> <03C141D8-952E-4E7A-BDAD-024CE2239010@lnu.se> <55508B60.1000200@redhat.com> <8868A273-7C97-45F0-BF10-85DDE5859E85@lnu.se> <5550B182.7090009@redhat.com> <5551FA97.9090502@oracle.com> <5551FD72.1020504@oracle.com> <38CAAA0B-6F32-4508-818F-AD9D248E8B35@lnu.se> <55524C58.4030904@oracle.com> <55524E8C.6080709@redhat.com> <55526041.1030709@redhat.com> <7C4CBC57-D7B2-4779-9353-DEACCB626370@lnu.se> <5552838B.3020305@oracle.com> <556D5EF9.6030702@redhat.com> Message-ID: Hi Andrew, Unfortunately it looks like the global_fence performance and portability discussion led the thread to a halt. I don?t think a correctness patch should be held back by a discussion about which platforms can elide the correctness fix and potentially experience better performance. So I think we should just go for the fencing solution for now, and discuss global_fence later if anyone is interested and think it?s worth doing and on which platforms it makes sense for etc. The suggestion with fences look good from my point of view. But I?m only an author. Cheers, /Erik Den 02/06/15 09:44 skrev Andrew Haley : >Have we come to a complete standstill? > >We have a number of AArch64 patches, needed for correctness, which are >blocked on this. But part of the simple AArch64 fix, which would be a >StoreLoad barrier, requires a change to shared code. I could submit >something #ifdef AARCH64, which probably wouldn't be popular. > >Andrew. > > From aleksey.shipilev at oracle.com Tue Jun 2 09:25:32 2015 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Tue, 02 Jun 2015 12:25:32 +0300 Subject: RFR: 8079315: UseCondCardMark broken in conjunction with CMS precleaning In-Reply-To: References: <5548D913.1030507@redhat.com> <5548EDE9.8090803@redhat.com> <5548F59D.6090008@oracle.com> <5549D681.3000806@redhat.com> <554A1CA0.6070801@oracle.com> <473C887F-8CC5-4E67-BD9A-1882660CFD3C@lnu.se> <554B3B5E.8000705@oracle.com> <8EE73C49-83CD-4162-A3EF-19DDA2C2CDFA@lnu.se> <554FC66F.20307@oracle.com> <55507BE4.3050605@redhat.com> <03C141D8-952E-4E7A-BDAD-024CE2239010@lnu.se> <55508B60.1000200@redhat.com> <8868A273-7C97-45F0-BF10-85DDE5859E85@lnu.se> <5550B182.7090009@redhat.com> <5551FA97.9090502@oracle.com> <5551FD72.1020504@oracle.com> <38CAAA0B-6F32-4508-818F-AD9D248E8B35@lnu.se> <55524C58.4030904@oracle.com> <55524E8C.6080709@redhat.com> <55526041.1030709@redhat.com> <7C4CBC57-D7B2-4779-9353-DEACCB626370@lnu.se> <5552838B.3020305@oracle.com> Message-ID: <556D768C.6070603@oracle.com> On 05/21/2015 03:54 PM, Erik ?sterlund wrote: > Den 12/05/15 23:49 skrev Aleksey Shipilev : > >> On 12.05.2015 23:44, Erik ?sterlund wrote: >>> I don?t know what windows does because it?s open source but we only have >>> x86 there and its hardware has no support for doing it any other way >>> than with IPI messages which is all we need. And if we feel that scared, >>> windows has a system call that does exactly what we want and with the >>> architecture I propose it?s trivial to specialize the barrier for >>> windows do use this instead. >> >> I think I get what you tell, but I am not convinced. The thing about >> reading stuff in the mutator is to align the actions in collector with >> the actions in mutator. So what if you push the IPI to all processors. >> Some lucky processor will get that interrupt *after* (e.g. too late!) >> both the reference store and (reordered/stale) card mark read => same >> problem, right? In other words, asking a mutator to do a fence-like op >> after an already missed card mark update solves what? > > The IPI will be received for sure on all processors after mprotect begins > and before it ends. Otherwise they wouldn't serve any purpose. The purpose > of the cross call is to shoot down TLBs and make the new permissions > visible. If IPIs were to be delayed until after mprotect returns, it > simply would not work. And this is all we need. I still don't get it. AFAIU, it is not enough to delay precleaning until every mutator flushes their stores. My point is that we need to coordinate with mutator to at least make the reads and writes in the proper order? Or we are hoping that whatever mechanics global_store_fence is using restores the program order? And how that helps against the compiler reorderings? Suppose x.a = prev and card[@x.a] = dirty. Mutator is about to write x.a = cur. preclean: if (card[@x.a] == dirty) preclean: card[@x.a] = precleaned mutator: card_state = card[@x.a]; // reads "dirty" preclean: global_store_fence(); mutator: preclean: read x.a preclean: mutator: x.a = cur; mutator: StoreStore mutator: if (card_state != dirty) mutator: card[@x.a] = dirty; // does not happen! (...later...) preclean: End result: the card mark update for "x.a = cur" is lost. -Aleksey From aleksey.shipilev at oracle.com Tue Jun 2 09:25:38 2015 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Tue, 02 Jun 2015 12:25:38 +0300 Subject: RFR: 8079315: UseCondCardMark broken in conjunction with CMS precleaning In-Reply-To: <556D5EF9.6030702@redhat.com> References: <5548D913.1030507@redhat.com> <5548F59D.6090008@oracle.com> <5549D681.3000806@redhat.com> <554A1CA0.6070801@oracle.com> <473C887F-8CC5-4E67-BD9A-1882660CFD3C@lnu.se> <554B3B5E.8000705@oracle.com> <8EE73C49-83CD-4162-A3EF-19DDA2C2CDFA@lnu.se> <554FC66F.20307@oracle.com> <55507BE4.3050605@redhat.com> <03C141D8-952E-4E7A-BDAD-024CE2239010@lnu.se> <55508B60.1000200@redhat.com> <8868A273-7C97-45F0-BF10-85DDE5859E85@lnu.se> <5550B182.7090009@redhat.com> <5551FA97.9090502@oracle.com> <5551FD72.1020504@oracle.com> <38CAAA0B-6F32-4508-818F-AD9D248E8B35@lnu.se> <55524C58.4030904@oracle.com> <55524E8C.6080709@redhat.com> <55526041.1030709@redhat.com> <7C4CBC57-D7B2-4779-9353-DEACCB626370@lnu.se> <5552838B.3020305@oracle.com> <556D5EF9.6030702@redhat.com> Message-ID: <556D7692.3070707@oracle.com> On 06/02/2015 10:44 AM, Andrew Haley wrote: > Have we come to a complete standstill? Appears to be so. I am still uneasy about global_store_fence/mprotect trick, since I don't quite believe it works without a hitch everywhere, even given Erik's extensive explanation it "appears" to work fine. Erik, can you follow up with Dave Dice on whether that is actually safe? The original StoreLoad patch by Andrew looks moderately okay to me, given it is conditionalized for CMS (I wonder if it should be conditionalized on CMSPrecleaningEnabled?). Google folks may chime in saying it breaks the performance for them... Actually, GC guys should make this call. Thanks, -Aleksey From edward.nevill at linaro.org Tue Jun 2 09:26:35 2015 From: edward.nevill at linaro.org (Edward Nevill) Date: Tue, 02 Jun 2015 10:26:35 +0100 Subject: RFR: 8081669: aarch64: JTreg TestStable tests failing Message-ID: <1433237195.16770.13.camel@mylittlepony.linaroharston> Hi, The following webrev http://cr.openjdk.java.net/~enevill/8081669/webrev.00/ fixes a number of TestStable tests. This patch was contributed by alexander.alexeev at caviumnetworks.com The following are the test failures that are fixed by this patch compiler/stable/TestStableByte.java compiler/stable/TestStableBoolean.java compiler/stable/TestStableChar.java compiler/stable/TestStableFloat.java compiler/stable/TestStableObject.java compiler/stable/TestStableDouble.java compiler/stable/TestStableInt.java compiler/stable/TestStableLong.java compiler/stable/TestStableShort.java The problem is that the method 'get' in StableConfiguration is supposed to return true if the method is server compiled, false otherwise. On aarch64 it is always returning true, even when the method is client compiled. The reason for this is that aarch64 differs from other ports in that it always deopts on patching. This means that the method 'get' deopts immediately when compiled with -Xcomp because it hits an unresolved method call. This means that the method is now executing in the interpreter. When the method 'get' is executing in the interpreter, it uses the value of java.vm.name to determine whether the method would be server compiled if it were to be compiled. This ends up returning true on aarch64, because it is a server compiler. However in the case where we force it not to server compile by using -XX:+TieredCompilation and -XX:TieredStopAtLevel=1 (as in the TestStable tests) this will be incorrect. The solution is to introduce a simple (null) method 'get1' which will never be deopted (because there is never anything to patch) and uses this as the basis for deciding whether we are server compiling or not. This is more fully explained in the inline comment in the patch. Please review and if appropriate I will push. All the best, Ed. From erik.osterlund at lnu.se Tue Jun 2 10:22:52 2015 From: erik.osterlund at lnu.se (=?iso-8859-1?Q?Erik_=D6sterlund?=) Date: Tue, 2 Jun 2015 10:22:52 +0000 Subject: RFR: 8079315: UseCondCardMark broken in conjunction with CMS precleaning In-Reply-To: <556D7692.3070707@oracle.com> References: <5548D913.1030507@redhat.com> <5548F59D.6090008@oracle.com> <5549D681.3000806@redhat.com> <554A1CA0.6070801@oracle.com> <473C887F-8CC5-4E67-BD9A-1882660CFD3C@lnu.se> <554B3B5E.8000705@oracle.com> <8EE73C49-83CD-4162-A3EF-19DDA2C2CDFA@lnu.se> <554FC66F.20307@oracle.com> <55507BE4.3050605@redhat.com> <03C141D8-952E-4E7A-BDAD-024CE2239010@lnu.se> <55508B60.1000200@redhat.com> <8868A273-7C97-45F0-BF10-85DDE5859E85@lnu.se> <5550B182.7090009@redhat.com> <5551FA97.9090502@oracle.com> <5551FD72.1020504@oracle.com> <38CAAA0B-6F32-4508-818F-AD9D248E8B35@lnu.se> <55524C58.4030904@oracle.com> <55524E8C.6080709@redhat.com> <55526041.1030709@redhat.com> <7C4CBC57-D7B2-4779-9353-DEACCB626370@lnu.se> <5552838B.3020305@oracle.com> <556D5EF9.6030702@redhat.com> <556D7692.3070707@oracle.com> Message-ID: Hi Aleksey, Den 02/06/15 11:25 skrev Aleksey Shipilev : >On 06/02/2015 10:44 AM, Andrew Haley wrote: >> Have we come to a complete standstill? > >Appears to be so. > >I am still uneasy about global_store_fence/mprotect trick, since I don't >quite believe it works without a hitch everywhere, even given Erik's >extensive explanation it "appears" to work fine. Erik, can you follow up >with Dave Dice on whether that is actually safe? Sure, will do. >The original StoreLoad patch by Andrew looks moderately okay to me, >given it is conditionalized for CMS (I wonder if it should be >conditionalized on CMSPrecleaningEnabled?). Google folks may chime in >saying it breaks the performance for them... I think the patch looks okay for now, and it?s important to get a correctness fix although potentially suboptimal in terms of performance ASAP. I have a feeling the global_fence discussion could take a while before reaching a conclusion, don?t know how long. It would be good to have the correctness fix while exploring better performant synchronization solutions to elide the fences. Yes, Google folks might say there are performance regressions then, but others might complain the JVM unexpectedly crashes now as it is now. I think this is worse. Thanks, /Erik >Actually, GC guys should make this call. > >Thanks, >-Aleksey > > From aph at redhat.com Tue Jun 2 10:45:02 2015 From: aph at redhat.com (Andrew Haley) Date: Tue, 02 Jun 2015 11:45:02 +0100 Subject: [aarch64-port-dev ] RFR: 8081669: aarch64: JTreg TestStable tests failing In-Reply-To: <1433237195.16770.13.camel@mylittlepony.linaroharston> References: <1433237195.16770.13.camel@mylittlepony.linaroharston> Message-ID: <556D892E.50805@redhat.com> On 06/02/2015 10:26 AM, Edward Nevill wrote: > Please review and if appropriate I will push. That sounds correct to me, but I need a JDK9 reviewer. Andrew. From alexander.kulyakhtin at oracle.com Tue Jun 2 11:18:42 2015 From: alexander.kulyakhtin at oracle.com (Alexander Kulyakhtin) Date: Tue, 2 Jun 2015 04:18:42 -0700 (PDT) Subject: RFR: JDK-8075327: Merge jdk and hotspot test libraries Message-ID: <1a17632e-265f-4adb-864f-79cb9a1587ec@default> Hi, Could you, please, review the following test-only changes to the 'jdk', 'hotspot' and the common 'test' repository http://cr.openjdk.java.net/~akulyakh/8075327/wr_hs/webrev.01/index.html http://cr.openjdk.java.net/~akulyakh/8075327/wr_jdk/webrev.01/index.html http://cr.openjdk.java.net/~akulyakh/8075327/wr_test/webrev.01/ The changes are to move test library files common to both jdk and hotspot to the upper-level test repository. The following has been done: 1) Common files (Asserts.java, OutputAnalyzer.java etc) from the jdk and hotspot repositories, have been merged and moved to the upper-level common test repository, to test/lib/share/classes. 2) Package jdk.testlibrary in the jdk repository have been renamed to jdk.test.lib to have the same name as in the hotspot repository 2) Upper level test/lib/share/classes library references have been added to the @library statements 3) Some packages previously located at upper level test repo at /test/lib have been moved to /test/lib/share/classes for consistency Best regards, Alexander From bengt.rutisson at oracle.com Tue Jun 2 12:14:42 2015 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Tue, 02 Jun 2015 14:14:42 +0200 Subject: RFR: 8080947: Add uint as a valid VM flag type In-Reply-To: <5566FBF4.1060401@oracle.com> References: <5566FBF4.1060401@oracle.com> Message-ID: <556D9E32.2020400@oracle.com> Hi David, On 2015-05-28 13:28, David Lindholm wrote: > Hi, > > Please review this patch that adds uint and int as valid VM flag > types. This patch adds the possibility to specify VM flags with types > int and uint, it does not change the type of any flags. > > > Webrev: http://cr.openjdk.java.net/~david/JDK-8080947/webrev.hotspot.00/ > Webrev: http://cr.openjdk.java.net/~david/JDK-8080947/webrev.jdk.00/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8080947 Overall this looks good to me, but shouldn't Flag::get_uint() in globals.cpp/hpp return an uint rather than an int? 113 int Flag::get_uint() const { 287 int get_uint() const; Thanks, Bengt > > > Testing: Passed JPRT > > > Thanks, > David From kirk at kodewerk.com Tue Jun 2 12:21:25 2015 From: kirk at kodewerk.com (Kirk Pepperdine) Date: Tue, 2 Jun 2015 14:21:25 +0200 Subject: JEP 248: Make G1 the Default Garbage Collector In-Reply-To: References: <20150428220211.4355960845@eggemoggin.niobe.net> <5C5564BB-23ED-49AB-81C6-CFF85B56ACA4@kodewerk.com> <5540D689.6020407@oracle.com> <73855087-8BB2-4A8C-B9AD-080CD39FAB7A@kodewerk.com> <55423444.7040009@beckwithclan.com> <556CA452.9040405@oracle.com> <7E7759C3-3AF0-4047-9B00-605DBB55DC79@oracle.com> <8815A8AF-0C3A-44DD-86BD-18E373ED2C60@oracle.com> Message-ID: <9EAEE9D5-4AD9-4786-B78C-0454067D53AE@kodewerk.com> On Jun 1, 2015, at 9:16 PM, Vitaly Davidovich wrote: >> >> I suppose it is worth mentioning that the population of apps that don?t >> stress GC is pretty small compared to those that do. ;-) > > > Sadly, that's true :). I?m not sure I agree with this. Unfortunately the negative effects of GC isn?t well recognized and therefor not reported. I rarely see an app where GC isn?t stressed to some degree. Regards, Kirk > > On Mon, Jun 1, 2015 at 3:12 PM, charlie hunt > wrote: > >> Yep, that?s right. >> >> I suppose it is worth mentioning that the population of apps that don?t >> stress GC is pretty small compared to those that do. ;-) >> >> On Jun 1, 2015, at 2:01 PM, Vitaly Davidovich wrote: >> >> Also, G1 also has heavier write barriers than parallel gc, so some >> existing workloads that don't stress the GC (e.g. code written purposely to >> avoid GC during uptime by, say, object pooling) and wouldn't have tweaked >> the default may experience some degradation. >> >> On Mon, Jun 1, 2015 at 2:53 PM, charlie hunt >> wrote: >> >>> Hi Jenny, >>> >>> A couple questions and comments below. >>> >>> thanks, >>> >>> charlie >>> >>>> On Jun 1, 2015, at 1:28 PM, Yu Zhang wrote: >>>> >>>> Hi, >>>> >>>> I have done some performance comparison g1/cms/parallelgc internally at >>> Oracle. I would like to post my observations here to get some feedback, as >>> I have limited benchmarks and hardware. These are out of box performance. >>>> >>>> Memory footprint/startup: >>>> g1 has bigger memory footprint and longer start up time. The overhead >>> comes from more gc threads, and internal data structures to keep track of >>> remember set. >>> >>> This is the memory footprint of the JVM itself when using the same size >>> Java heap, right? >>> >>> I don?t recall if it has been your observation? One observation I have >>> had with G1 is that it tends to be able to operate within tolerable >>> throughput and latency with a smaller Java heap than with Parallel GC. I >>> have seen cases where G1 may not use the entire Java heap because it was >>> able to keep enough free regions available yet still meet pause time goals. >>> But, Parallel GC always use the entire Java heap, and once its occupancy >>> reach capacity, it would GC. So they are cases where between the JVM?s >>> footprint overhead, and taking into account the amount of Java heap >>> required, G1 may actually require less memory. >>> >>>> >>>> g1 vs parallelgc: >>>> If the workload involves young gc only, g1 could be slightly slower. >>> Also g1 can consume more cpu, which might slow down the benchmark if SUT is >>> cpu saturated. >>>> >>>> If there are promotions from young to old gen and leads to full gc with >>> parallelgc, for smaller heap, parallel full gc can finish within some range >>> of pause time, still out performs g1. But for bigger heap, g1 mixed gc can >>> clean the heap with pause times a fraction of parallel full gc time, so >>> improve both throughput and response time. Extreme cases are big data >>> workloads(for example ycsb) with 100g heap. >>> >>> I think what you are saying here is that it looks like if one can tune >>> Parallel GC such that you can avoid a lengthy collection of old generation, >>> or the live occupancy of old gen is small enough that the time to collect >>> is small enough to be tolerated, then Parallel GC will offer a better >>> experience. >>> >>> However, if the live data in old generation at the time of its collection >>> is large enough such that the time it takes to collect it exceeds a >>> tolerable pause time, then G1 will offer a better experience. >>> >>> Would also say that G1 offers a better experience in the presences of >>> (wide) swings in object allocation rates since there would likely be a >>> larger number of promotions during the allocation spikes? In other words, >>> G1 may offer more predictable pauses. >>> >>>> >>>> g1 vs cms: >>>> I will focus on response time type of workloads. >>>> Ben mentioned >>>> >>>> "Having said that, there is definitely a decent-sized class of systems >>>> (not just in finance) that cannot really tolerate any more than about >>>> 10-15ms of STW. So, what usually happens is that they live with the >>>> young collections, use CMS and tune out the CMFs as best they can (by >>>> clustering, rolling restart, etc, etc). I don't see any possibility of >>>> G1 becoming a viable solution for those systems any time soon." >>>> >>>> Can you give more details, like what is the live data set size, how big >>> is the heap, etc? I did some cache tests (Oracle coherence) to compare cms >>> vs g1. g1 is better than cms when there are fragmentations. If you tune cms >>> well to have little fragmentation, then g1 is behind cms. But for those >>> cases, they have to tune CMS very well, changing default to g1 won't impact >>> them. >>>> >>>> For big data kind of workloads (ycsb, spark in memory computing), g1 is >>> much better than cms. >>>> >>>> Thanks, >>>> Jenny >>>> >>>> On 6/1/2015 10:06 AM, Ben Evans wrote: >>>>> Hi Vitaly, >>>>> >>>>>>> Instead, G1 is now being talked of as a replacement for the default >>>>>>> collector. If that's the case, then I think we need to acknowledge >>> it, >>>>>>> and have a conversation about where G1 is actually supposed to be >>>>>>> used. Are we saying we want a "reasonably high throughput with >>> reduced >>>>>>> STW, but not low pause time" collector? If we are, that's fine, but >>>>>>> that's not where we started. >>>>>> That's a fair point, and one I'd be interesting in hearing an answer >>> to as >>>>>> well. FWIW, the only GC I know of that's actually used in low latency >>>>>> systems is Azul's C4, so I'm not even sure Oracle is trying to target >>> the >>>>>> same use cases. So when we talk about "low latency" GCs, we should >>> probably >>>>>> also be clear on what "low" actually means. >>>>> Well, when I started playing with them, "low latency" meant a >>>>> sub-10-ms transaction time with 100ms STW as acceptable, if not ideal. >>>>> >>>>> These days, the same sort of system needs a sub 500us transaction >>>>> time, and ideally no GC pause at all. But that leads to Zing, or >>>>> non-JVM solutions, and I think takes us too far into a specialised use >>>>> case. >>>>> >>>>> Having said that, there is definitely a decent-sized class of systems >>>>> (not just in finance) that cannot really tolerate any more than about >>>>> 10-15ms of STW. So, what usually happens is that they live with the >>>>> young collections, use CMS and tune out the CMFs as best they can (by >>>>> clustering, rolling restart, etc, etc). I don't see any possibility of >>>>> G1 becoming a viable solution for those systems any time soon. >>>>> >>>>> Thanks, >>>>> >>>>> Ben >>>> >>> >>> >> >> From ben at jclarity.com Tue Jun 2 12:22:15 2015 From: ben at jclarity.com (Ben Evans) Date: Tue, 2 Jun 2015 13:22:15 +0100 Subject: JEP 248: Make G1 the Default Garbage Collector In-Reply-To: <7109616A-5C6C-47AA-9EA7-1E026C37D333@oracle.com> References: <20150428220211.4355960845@eggemoggin.niobe.net> <5C5564BB-23ED-49AB-81C6-CFF85B56ACA4@kodewerk.com> <5540D689.6020407@oracle.com> <73855087-8BB2-4A8C-B9AD-080CD39FAB7A@kodewerk.com> <55423444.7040009@beckwithclan.com> <8DFF9BB7-3E76-4545-B5D9-07BE0D4693CB@oracle.com> <94973BE6-4FA4-45D9-A2F5-AF2B81226B4D@oracle.com> <7109616A-5C6C-47AA-9EA7-1E026C37D333@oracle.com> Message-ID: Of, course, but the point of the debate is that hasn't been proved yet. By the way, I've kicked off a survey, initially to the LJC (but opening it out now) about which GC people use. With ~70 responses in, ~40% of people are using the default collector, and ~10% don't know. Of those who do know & explicitly set, CMS is the winner, with ~25% I'll report back when we have more data. Thanks, Ben On Mon, Jun 1, 2015 at 7:25 PM, charlie hunt wrote: > >> On Jun 1, 2015, at 12:54 PM, Ben Evans wrote: >> >>>>> One question that may be worth pondering ? suppose G1 happened to be the default GC today, and there was a JEP to make Parallel GC the default GC. What would your reaction to that JEP be? I?m asking that question since I?d like to get a sense if your concerns are more about conservatism (not wanting to change behavior), stability of G1 or otherwise. >>>> >>>> Primarily conservatism. Of course, if G1 had been default, the >>>> "unknown unknowns" would have been resolved by now, so there would be >>>> no need to worry. >>>> >>>> I think that if G1 was default, and the platform was as successful >>>> across the same range of workloads as it is today, I'd be advocating >>>> for no change. >>> >>> Is that because you think G1 would offer a better out of the box experience than Parallel GC, or because you would not want to see a change made to the JVM?s default GC? >> >> I would not want to see a change made to the default behaviour that >> could potentially negatively affect a large number of apps and in >> doing so harm the long-term perception of the platform as a "safe pair >> of hands?. > > And you also realize there could be a certain number (maybe as many as, or more) applications that could realize a better out of the box experience with G1 as the default versus Parallel GC being the default? Implying of course that the ?safe pair of hands? would have a better experience. > > thanks, > > charlie > >> >> Thanks, >> >> Ben >> -- >> Ben Evans, Co-founder jClarity @jclarity > -- Ben Evans, Co-founder jClarity @jclarity From charlie.hunt at oracle.com Tue Jun 2 12:29:32 2015 From: charlie.hunt at oracle.com (charlie hunt) Date: Tue, 2 Jun 2015 07:29:32 -0500 Subject: JEP 248: Make G1 the Default Garbage Collector In-Reply-To: References: <20150428220211.4355960845@eggemoggin.niobe.net> <5C5564BB-23ED-49AB-81C6-CFF85B56ACA4@kodewerk.com> <5540D689.6020407@oracle.com> <73855087-8BB2-4A8C-B9AD-080CD39FAB7A@kodewerk.com> <55423444.7040009@beckwithclan.com> <556CA452.9040405@oracle.com> <7E7759C3-3AF0-4047-9B00-605DBB55DC79@oracle.com> Message-ID: Hi Erik, Let?s pull out a couple of your questions here and see I can offer some answers. > I do not see why this (latency requirement uncertainty) specifically > would be a problem for this particular transition into using G1 more instead of > ParallelGC. Let?s focus only on the narrow scope of transitioning > application contexts from ParallelGC to G1 only for ?larger? heaps. Is > there any application context then where G1 has worse latency than > ParallelGC? My observations have been that it is not a question of the size of the Java heap, although folks often refer to it in this way. It is more about the combination of the amount of live data, the amount of available space between the live data and the Java heap and the object lifetimes. There are Java apps out there where if Parallel GC is configured in a way (either by mere accident the defaults hit this situation, which would be unusual, or by manually tuning GC), Parallel GC?s young generation is configured in a way that old generation collection can be avoided, many of objects allocated die young, (i.e. there is not a humongous amount of objects sloshing around between survivor spaces, and few, if any are promoted to old gen), Parallel GC will likely offer lower latency than G1. Again, to reiterate, to do this with Parallel GC will likely require a GC tuning effort. Yet there may be an app, or some small number of apps that Parallel GC with its JVM defaults could fit what I just described. But, then again, the context of this JEP is before GC tuning. To up level this a bit, with a given GC, it is generally accepted that as one performance attribute is emphasized, (throughput, latency and memory footprint), there is a sacrifice in one or two of the others. I think you are kind of saying this here too. But, I thought it was worth mentioning specifically. I?ll come back to this a bit later. > Another concern Jenny mentioned where G1 could perform worse was JVM start > up time. Again, I have a hard time imagining a /server application/ with > an explicitly specified ?large? heap where anyone would care too much > about this. Am I wrong? If we are talking about the difference in time to start the JVM relative to the time it takes to generally initiate a Java app with a large Java heap, then yes, I don?t think it would be much of a concern. This is not to be confused with whether someone is not concerned with the time it takes to initiate an application with a large Java heap taking a long time. That is a different story. ;-) > And here G1 was designed, correct me if > I?m wrong, to be not necessarily the best at anything, but pretty good at > everything (latencies, performance and memory footprints). This sounds to > me like a reasonable choice for default application contexts where it?s > not known if the user cares about this or that QoS. This is pretty much the conclusion that I have arrived at. IMO, G1 due to its ergonomics offers a larger population of applications a ?happy medium? of tradeoffs between the three performance attributes than Parallel GC in the absence of further tuning. thanks, charlie > On Jun 1, 2015, at 6:16 PM, Erik ?sterlund wrote: > > Hi Charlie, > > Den 01/06/15 22:51 skrev charlie hunt : > >> Hi Erik, >> >> HotSpot does some of this ergonomics today for both GC and JIT compiler >> in cases where the JVM sees less than 2 GB of RAM and the OS it is >> running on. These decisions are based on what is called a ?server class >> machine?. A ?server class machine? as of JDK 6u18 is defined as a system >> that has 2 GB or more of RAM, two or more hardware threads. There are >> other cases for a given hardware platform, and if it is a 32-bit JVM, the >> collector (and JIT compiler) ergonomically selected may also differ from >> other configurations. >> >> AFAIK, the JEP is proposing to change the default GC in configurations >> where the default GC is Parallel GC to using G1 as the default. > > I think the fact that these ergonomics tricks are already around only > motivates the approach further as it is in line with the current > philosophy that if the user is not explicit about things, then the runtime > can and will guess a bit and try to aim for some kind of middle ground > solutions that are pretty good but not necessarily the best at everything > (like G1 was designed to be). If the guess doesn?t cut it because it turns > out that only a single QoS was important, like for instance performance > over everything else, then maybe the user should have said so. ;) > >> The challenge with what you are describing is that the best GC cannot >> always be ergonomically selected by the JVM without some input from the >> user, i.e. GC doesn?t know if any GC pauses greater than 200 ms are >> acceptable regardless of Java heap size, number of hardware threads, etc. > > I do not see why this (latency requirement uncertainty) specifically would > be a problem for this particular transition into using G1 more instead of > ParallelGC. Let?s focus only on the narrow scope of transitioning > application contexts from ParallelGC to G1 only for ?larger" heaps. Is > there any application context then where G1 has worse latency than > ParallelGC? I assume not. So the only visible effect such a change would > bring is improved latencies if anything. And the whole mega-low-latency > discussion where G1 doesn?t cut it is quite irrelevant for this change as > well as those people affected are already not satisfied with ParallelGC > that wouldn?t cut it either, and hence specify something explicitly. > > Another concern Jenny mentioned where G1 could perform worse was JVM start > up time. Again, I have a hard time imagining a /server application/ with > an explicitly specified ?large" heap where anyone would care too much > about this. Am I wrong? > > What is left to annoy people with such a change then (apart from bugs) > with latency not being one of them, is resource trade offs in terms of > memory footprints and performance. And here G1 was designed, correct me if > I?m wrong, to be not necessarily the best at anything, but pretty good at > everything (latencies, performance and memory footprints). This sounds to > me like a reasonable choice for default application contexts where it?s > not known if the user cares about this or that QoS. And with the > observation from Jenny that even performance seems to actually be better > than ParallelGC for application contexts with large heaps, and the > knowledge that latency is in general more important then, does it not make > sense to choose G1 at least for those application contexts? > > Of course this is just a suggestion based on generalizations. Just thought > it?s an interesting middle ground worth considering to instead of only > considering either changing all or none of the default server application > contexts, to only change the subset where we think it is least likely to > annoy people, and then as G1 continues to improve and one size starts > fitting all, expand that subset in a smoother transition. > > Thanks, > /Erik > >> >> thanks, >> >> charlie >> >>> On Jun 1, 2015, at 2:53 PM, Erik ?sterlund >>> wrote: >>> >>> Hi all, >>> >>> Does there have to be a single default one-size-fits-all GC algorithm >>> for >>> users to rely on? Or could we allow multiple algorithms and explicitly >>> document that unless a GC is picked, the runtime is free to pick >>> whatever >>> it believes is better? This could have multiple benefits. >>> >>> 1. This could make such a similar change easier in the future as >>> everyone >>> will already be aware that if they really rely on the properties of a >>> specific GC algorithm, then they should choose that GC explicitly and >>> not >>> rely on defaults not changing; there are no guarantees that defaults >>> will >>> not change. >>> >>> 2. Obviously there has been a long discussion in this thread which GC is >>> better in which context, and it seems like right now one size does not >>> fit >>> all. The user that relied on the defaults might not be so aware of these >>> specifics. Therefore we might do them a big favour of attempting to >>> make a >>> guess for them to work out-of-the-box, which is pretty neat. >>> >>> 3. This approach allows deploying G1 not everywhere, but where we guess >>> it >>> performs pretty well. This means it will run in fewer JVM contexts and >>> hence pose less risk than deploying it to be used for all contexts, >>> making >>> the transition smoother. >>> >>> One idea could be to first determine valid GC variants given the >>> supplied >>> flags (GC-specific flags imply use of that GC), and then among the valid >>> GCs left, ?guess? which algorithm is better based on the other general >>> parameters, such as e.g. heap size (and maybe target latency)? Could for >>> instance pick ParallelGC for small heaps, G1 for larger heaps and CMS >>> for >>> ridiculously large heaps or cases when extremely low latency is wanted? >>> >>> My reasoning is based on two assumptions: 1) changing the defaults would >>> target the users that don?t know what?s best for them, 2) one size does >>> not fit all. If these assumption are wrong, then this is a bad idea. >>> >>> Thanks, >>> /Erik >>> >>> >>> >>> Den 01/06/15 20:53 skrev charlie hunt : >>> >>>> Hi Jenny, >>>> >>>> A couple questions and comments below. >>>> >>>> thanks, >>>> >>>> charlie >>>> >>>>> On Jun 1, 2015, at 1:28 PM, Yu Zhang wrote: >>>>> >>>>> Hi, >>>>> >>>>> I have done some performance comparison g1/cms/parallelgc internally >>>>> at >>>>> Oracle. I would like to post my observations here to get some >>>>> feedback, >>>>> as I have limited benchmarks and hardware. These are out of box >>>>> performance. >>>>> >>>>> Memory footprint/startup: >>>>> g1 has bigger memory footprint and longer start up time. The overhead >>>>> comes from more gc threads, and internal data structures to keep track >>>>> of remember set. >>>> >>>> This is the memory footprint of the JVM itself when using the same size >>>> Java heap, right? >>>> >>>> I don?t recall if it has been your observation? One observation I have >>>> had with G1 is that it tends to be able to operate within tolerable >>>> throughput and latency with a smaller Java heap than with Parallel GC. >>>> I >>>> have seen cases where G1 may not use the entire Java heap because it >>>> was >>>> able to keep enough free regions available yet still meet pause time >>>> goals. But, Parallel GC always use the entire Java heap, and once its >>>> occupancy reach capacity, it would GC. So they are cases where between >>>> the JVM?s footprint overhead, and taking into account the amount of >>>> Java >>>> heap required, G1 may actually require less memory. >>>> >>>>> >>>>> g1 vs parallelgc: >>>>> If the workload involves young gc only, g1 could be slightly slower. >>>>> Also g1 can consume more cpu, which might slow down the benchmark if >>>>> SUT >>>>> is cpu saturated. >>>>> >>>>> If there are promotions from young to old gen and leads to full gc >>>>> with >>>>> parallelgc, for smaller heap, parallel full gc can finish within some >>>>> range of pause time, still out performs g1. But for bigger heap, g1 >>>>> mixed gc can clean the heap with pause times a fraction of parallel >>>>> full >>>>> gc time, so improve both throughput and response time. Extreme cases >>>>> are big data workloads(for example ycsb) with 100g heap. >>>> >>>> I think what you are saying here is that it looks like if one can tune >>>> Parallel GC such that you can avoid a lengthy collection of old >>>> generation, or the live occupancy of old gen is small enough that the >>>> time to collect is small enough to be tolerated, then Parallel GC will >>>> offer a better experience. >>>> >>>> However, if the live data in old generation at the time of its >>>> collection >>>> is large enough such that the time it takes to collect it exceeds a >>>> tolerable pause time, then G1 will offer a better experience. >>>> >>>> Would also say that G1 offers a better experience in the presences of >>>> (wide) swings in object allocation rates since there would likely be a >>>> larger number of promotions during the allocation spikes? In other >>>> words, G1 may offer more predictable pauses. >>>> >>>>> >>>>> g1 vs cms: >>>>> I will focus on response time type of workloads. >>>>> Ben mentioned >>>>> >>>>> "Having said that, there is definitely a decent-sized class of systems >>>>> (not just in finance) that cannot really tolerate any more than about >>>>> 10-15ms of STW. So, what usually happens is that they live with the >>>>> young collections, use CMS and tune out the CMFs as best they can (by >>>>> clustering, rolling restart, etc, etc). I don't see any possibility of >>>>> G1 becoming a viable solution for those systems any time soon." >>>>> >>>>> Can you give more details, like what is the live data set size, how >>>>> big >>>>> is the heap, etc? I did some cache tests (Oracle coherence) to >>>>> compare >>>>> cms vs g1. g1 is better than cms when there are fragmentations. If you >>>>> tune cms well to have little fragmentation, then g1 is behind cms. >>>>> But >>>>> for those cases, they have to tune CMS very well, changing default to >>>>> g1 >>>>> won't impact them. >>>>> >>>>> For big data kind of workloads (ycsb, spark in memory computing), g1 >>>>> is >>>>> much better than cms. >>>>> >>>>> Thanks, >>>>> Jenny >>>>> >>>>> On 6/1/2015 10:06 AM, Ben Evans wrote: >>>>>> Hi Vitaly, >>>>>> >>>>>>>> Instead, G1 is now being talked of as a replacement for the default >>>>>>>> collector. If that's the case, then I think we need to acknowledge >>>>>>>> it, >>>>>>>> and have a conversation about where G1 is actually supposed to be >>>>>>>> used. Are we saying we want a "reasonably high throughput with >>>>>>>> reduced >>>>>>>> STW, but not low pause time" collector? If we are, that's fine, but >>>>>>>> that's not where we started. >>>>>>> That's a fair point, and one I'd be interesting in hearing an answer >>>>>>> to as >>>>>>> well. FWIW, the only GC I know of that's actually used in low >>>>>>> latency >>>>>>> systems is Azul's C4, so I'm not even sure Oracle is trying to >>>>>>> target >>>>>>> the >>>>>>> same use cases. So when we talk about "low latency" GCs, we should >>>>>>> probably >>>>>>> also be clear on what "low" actually means. >>>>>> Well, when I started playing with them, "low latency" meant a >>>>>> sub-10-ms transaction time with 100ms STW as acceptable, if not >>>>>> ideal. >>>>>> >>>>>> These days, the same sort of system needs a sub 500us transaction >>>>>> time, and ideally no GC pause at all. But that leads to Zing, or >>>>>> non-JVM solutions, and I think takes us too far into a specialised >>>>>> use >>>>>> case. >>>>>> >>>>>> Having said that, there is definitely a decent-sized class of systems >>>>>> (not just in finance) that cannot really tolerate any more than about >>>>>> 10-15ms of STW. So, what usually happens is that they live with the >>>>>> young collections, use CMS and tune out the CMFs as best they can (by >>>>>> clustering, rolling restart, etc, etc). I don't see any possibility >>>>>> of >>>>>> G1 becoming a viable solution for those systems any time soon. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Ben >>>>> >>>> >>> >> > From vitalyd at gmail.com Tue Jun 2 12:30:46 2015 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Tue, 2 Jun 2015 08:30:46 -0400 Subject: JEP 248: Make G1 the Default Garbage Collector In-Reply-To: <9EAEE9D5-4AD9-4786-B78C-0454067D53AE@kodewerk.com> References: <20150428220211.4355960845@eggemoggin.niobe.net> <5C5564BB-23ED-49AB-81C6-CFF85B56ACA4@kodewerk.com> <5540D689.6020407@oracle.com> <73855087-8BB2-4A8C-B9AD-080CD39FAB7A@kodewerk.com> <55423444.7040009@beckwithclan.com> <556CA452.9040405@oracle.com> <7E7759C3-3AF0-4047-9B00-605DBB55DC79@oracle.com> <8815A8AF-0C3A-44DD-86BD-18E373ED2C60@oracle.com> <9EAEE9D5-4AD9-4786-B78C-0454067D53AE@kodewerk.com> Message-ID: Perhaps you misunderstood - I'm saying it's sadly true that most apps stress the GC. As for awareness of GC impact on performance, it's well understood in certain circles, but perhaps not as widely as it should be. Part of that is due to java not having any options other than heap allocation and the other is the GC marketing of "allocations are cheap". sent from my phone On Jun 2, 2015 8:21 AM, "Kirk Pepperdine" wrote: > > On Jun 1, 2015, at 9:16 PM, Vitaly Davidovich wrote: > > >> > >> I suppose it is worth mentioning that the population of apps that don?t > >> stress GC is pretty small compared to those that do. ;-) > > > > > > Sadly, that's true :). > > I?m not sure I agree with this. Unfortunately the negative effects of GC > isn?t well recognized and therefor not reported. I rarely see an app where > GC isn?t stressed to some degree. > > Regards, > Kirk > > > > > > On Mon, Jun 1, 2015 at 3:12 PM, charlie hunt > > wrote: > > > >> Yep, that?s right. > >> > >> I suppose it is worth mentioning that the population of apps that don?t > >> stress GC is pretty small compared to those that do. ;-) > >> > >> On Jun 1, 2015, at 2:01 PM, Vitaly Davidovich > wrote: > >> > >> Also, G1 also has heavier write barriers than parallel gc, so some > >> existing workloads that don't stress the GC (e.g. code written > purposely to > >> avoid GC during uptime by, say, object pooling) and wouldn't have > tweaked > >> the default may experience some degradation. > >> > >> On Mon, Jun 1, 2015 at 2:53 PM, charlie hunt > >> wrote: > >> > >>> Hi Jenny, > >>> > >>> A couple questions and comments below. > >>> > >>> thanks, > >>> > >>> charlie > >>> > >>>> On Jun 1, 2015, at 1:28 PM, Yu Zhang wrote: > >>>> > >>>> Hi, > >>>> > >>>> I have done some performance comparison g1/cms/parallelgc internally > at > >>> Oracle. I would like to post my observations here to get some > feedback, as > >>> I have limited benchmarks and hardware. These are out of box > performance. > >>>> > >>>> Memory footprint/startup: > >>>> g1 has bigger memory footprint and longer start up time. The overhead > >>> comes from more gc threads, and internal data structures to keep track > of > >>> remember set. > >>> > >>> This is the memory footprint of the JVM itself when using the same size > >>> Java heap, right? > >>> > >>> I don?t recall if it has been your observation? One observation I have > >>> had with G1 is that it tends to be able to operate within tolerable > >>> throughput and latency with a smaller Java heap than with Parallel > GC. I > >>> have seen cases where G1 may not use the entire Java heap because it > was > >>> able to keep enough free regions available yet still meet pause time > goals. > >>> But, Parallel GC always use the entire Java heap, and once its > occupancy > >>> reach capacity, it would GC. So they are cases where between the JVM?s > >>> footprint overhead, and taking into account the amount of Java heap > >>> required, G1 may actually require less memory. > >>> > >>>> > >>>> g1 vs parallelgc: > >>>> If the workload involves young gc only, g1 could be slightly slower. > >>> Also g1 can consume more cpu, which might slow down the benchmark if > SUT is > >>> cpu saturated. > >>>> > >>>> If there are promotions from young to old gen and leads to full gc > with > >>> parallelgc, for smaller heap, parallel full gc can finish within some > range > >>> of pause time, still out performs g1. But for bigger heap, g1 mixed > gc can > >>> clean the heap with pause times a fraction of parallel full gc time, so > >>> improve both throughput and response time. Extreme cases are big data > >>> workloads(for example ycsb) with 100g heap. > >>> > >>> I think what you are saying here is that it looks like if one can tune > >>> Parallel GC such that you can avoid a lengthy collection of old > generation, > >>> or the live occupancy of old gen is small enough that the time to > collect > >>> is small enough to be tolerated, then Parallel GC will offer a better > >>> experience. > >>> > >>> However, if the live data in old generation at the time of its > collection > >>> is large enough such that the time it takes to collect it exceeds a > >>> tolerable pause time, then G1 will offer a better experience. > >>> > >>> Would also say that G1 offers a better experience in the presences of > >>> (wide) swings in object allocation rates since there would likely be a > >>> larger number of promotions during the allocation spikes? In other > words, > >>> G1 may offer more predictable pauses. > >>> > >>>> > >>>> g1 vs cms: > >>>> I will focus on response time type of workloads. > >>>> Ben mentioned > >>>> > >>>> "Having said that, there is definitely a decent-sized class of systems > >>>> (not just in finance) that cannot really tolerate any more than about > >>>> 10-15ms of STW. So, what usually happens is that they live with the > >>>> young collections, use CMS and tune out the CMFs as best they can (by > >>>> clustering, rolling restart, etc, etc). I don't see any possibility of > >>>> G1 becoming a viable solution for those systems any time soon." > >>>> > >>>> Can you give more details, like what is the live data set size, how > big > >>> is the heap, etc? I did some cache tests (Oracle coherence) to > compare cms > >>> vs g1. g1 is better than cms when there are fragmentations. If you > tune cms > >>> well to have little fragmentation, then g1 is behind cms. But for > those > >>> cases, they have to tune CMS very well, changing default to g1 won't > impact > >>> them. > >>>> > >>>> For big data kind of workloads (ycsb, spark in memory computing), g1 > is > >>> much better than cms. > >>>> > >>>> Thanks, > >>>> Jenny > >>>> > >>>> On 6/1/2015 10:06 AM, Ben Evans wrote: > >>>>> Hi Vitaly, > >>>>> > >>>>>>> Instead, G1 is now being talked of as a replacement for the default > >>>>>>> collector. If that's the case, then I think we need to acknowledge > >>> it, > >>>>>>> and have a conversation about where G1 is actually supposed to be > >>>>>>> used. Are we saying we want a "reasonably high throughput with > >>> reduced > >>>>>>> STW, but not low pause time" collector? If we are, that's fine, but > >>>>>>> that's not where we started. > >>>>>> That's a fair point, and one I'd be interesting in hearing an answer > >>> to as > >>>>>> well. FWIW, the only GC I know of that's actually used in low > latency > >>>>>> systems is Azul's C4, so I'm not even sure Oracle is trying to > target > >>> the > >>>>>> same use cases. So when we talk about "low latency" GCs, we should > >>> probably > >>>>>> also be clear on what "low" actually means. > >>>>> Well, when I started playing with them, "low latency" meant a > >>>>> sub-10-ms transaction time with 100ms STW as acceptable, if not > ideal. > >>>>> > >>>>> These days, the same sort of system needs a sub 500us transaction > >>>>> time, and ideally no GC pause at all. But that leads to Zing, or > >>>>> non-JVM solutions, and I think takes us too far into a specialised > use > >>>>> case. > >>>>> > >>>>> Having said that, there is definitely a decent-sized class of systems > >>>>> (not just in finance) that cannot really tolerate any more than about > >>>>> 10-15ms of STW. So, what usually happens is that they live with the > >>>>> young collections, use CMS and tune out the CMFs as best they can (by > >>>>> clustering, rolling restart, etc, etc). I don't see any possibility > of > >>>>> G1 becoming a viable solution for those systems any time soon. > >>>>> > >>>>> Thanks, > >>>>> > >>>>> Ben > >>>> > >>> > >>> > >> > >> > > From david.lindholm at oracle.com Tue Jun 2 12:34:55 2015 From: david.lindholm at oracle.com (David Lindholm) Date: Tue, 02 Jun 2015 14:34:55 +0200 Subject: RFR: 8080947: Add uint as a valid VM flag type In-Reply-To: <556D9E32.2020400@oracle.com> References: <5566FBF4.1060401@oracle.com> <556D9E32.2020400@oracle.com> Message-ID: <556DA2EF.4040302@oracle.com> On 2015-06-02 14:14, Bengt Rutisson wrote: > > Hi David, > > On 2015-05-28 13:28, David Lindholm wrote: >> Hi, >> >> Please review this patch that adds uint and int as valid VM flag >> types. This patch adds the possibility to specify VM flags with types >> int and uint, it does not change the type of any flags. >> >> >> Webrev: http://cr.openjdk.java.net/~david/JDK-8080947/webrev.hotspot.00/ >> Webrev: http://cr.openjdk.java.net/~david/JDK-8080947/webrev.jdk.00/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8080947 > > Overall this looks good to me, but shouldn't Flag::get_uint() in > globals.cpp/hpp return an uint rather than an int? > > 113 int Flag::get_uint() const { > > 287 int get_uint() const; Good catch! I'll fix that. Do you need a new webrev? Thanks, David > Thanks, > Bengt > > > >> >> >> Testing: Passed JPRT >> >> >> Thanks, >> David > From bengt.rutisson at oracle.com Tue Jun 2 12:56:02 2015 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Tue, 02 Jun 2015 14:56:02 +0200 Subject: RFR: 8080947: Add uint as a valid VM flag type In-Reply-To: <556DA2EF.4040302@oracle.com> References: <5566FBF4.1060401@oracle.com> <556D9E32.2020400@oracle.com> <556DA2EF.4040302@oracle.com> Message-ID: <556DA7E2.7050805@oracle.com> On 02/06/15 14:34, David Lindholm wrote: > On 2015-06-02 14:14, Bengt Rutisson wrote: >> >> Hi David, >> >> On 2015-05-28 13:28, David Lindholm wrote: >>> Hi, >>> >>> Please review this patch that adds uint and int as valid VM flag >>> types. This patch adds the possibility to specify VM flags with >>> types int and uint, it does not change the type of any flags. >>> >>> >>> Webrev: >>> http://cr.openjdk.java.net/~david/JDK-8080947/webrev.hotspot.00/ >>> Webrev: http://cr.openjdk.java.net/~david/JDK-8080947/webrev.jdk.00/ >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8080947 >> >> Overall this looks good to me, but shouldn't Flag::get_uint() in >> globals.cpp/hpp return an uint rather than an int? >> >> 113 int Flag::get_uint() const { >> >> 287 int get_uint() const; > > Good catch! I'll fix that. Do you need a new webrev? No need for a new webrev for that. Bengt > > > Thanks, > David > >> Thanks, >> Bengt >> >> >> >>> >>> >>> Testing: Passed JPRT >>> >>> >>> Thanks, >>> David >> > From aph at redhat.com Tue Jun 2 12:56:41 2015 From: aph at redhat.com (Andrew Haley) Date: Tue, 02 Jun 2015 13:56:41 +0100 Subject: [aarch64-port-dev ] RFR: 8079565: aarch64: Add vectorization support for aarch64 In-Reply-To: <1432658017.17486.32.camel@mylittlepony.linaroharston> References: <1432658017.17486.32.camel@mylittlepony.linaroharston> Message-ID: <556DA809.9080305@redhat.com> On 05/26/2015 05:33 PM, Edward Nevill wrote: > The following webrev > > http://cr.openjdk.java.net/~enevill/8079565/webrev.00/ Looks like a great start, thanks. Can we have a JDK9 reviewer, please? Thanks, Andrew. From david.lindholm at oracle.com Tue Jun 2 13:02:35 2015 From: david.lindholm at oracle.com (David Lindholm) Date: Tue, 02 Jun 2015 15:02:35 +0200 Subject: RFR: 8080947: Add uint as a valid VM flag type In-Reply-To: <556DA7E2.7050805@oracle.com> References: <5566FBF4.1060401@oracle.com> <556D9E32.2020400@oracle.com> <556DA2EF.4040302@oracle.com> <556DA7E2.7050805@oracle.com> Message-ID: <556DA96B.1080308@oracle.com> On 2015-06-02 14:56, Bengt Rutisson wrote: > On 02/06/15 14:34, David Lindholm wrote: >> On 2015-06-02 14:14, Bengt Rutisson wrote: >>> >>> Hi David, >>> >>> On 2015-05-28 13:28, David Lindholm wrote: >>>> Hi, >>>> >>>> Please review this patch that adds uint and int as valid VM flag >>>> types. This patch adds the possibility to specify VM flags with >>>> types int and uint, it does not change the type of any flags. >>>> >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~david/JDK-8080947/webrev.hotspot.00/ >>>> Webrev: http://cr.openjdk.java.net/~david/JDK-8080947/webrev.jdk.00/ >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8080947 >>> >>> Overall this looks good to me, but shouldn't Flag::get_uint() in >>> globals.cpp/hpp return an uint rather than an int? >>> >>> 113 int Flag::get_uint() const { >>> >>> 287 int get_uint() const; >> >> Good catch! I'll fix that. Do you need a new webrev? > > No need for a new webrev for that. Thanks for the review Bengt. /David > Bengt > >> >> >> Thanks, >> David >> >>> Thanks, >>> Bengt >>> >>> >>> >>>> >>>> >>>> Testing: Passed JPRT >>>> >>>> >>>> Thanks, >>>> David >>> >> > From erik.osterlund at lnu.se Tue Jun 2 13:39:25 2015 From: erik.osterlund at lnu.se (=?windows-1254?Q?Erik_=D6sterlund?=) Date: Tue, 2 Jun 2015 13:39:25 +0000 Subject: JEP 248: Make G1 the Default Garbage Collector In-Reply-To: References: <20150428220211.4355960845@eggemoggin.niobe.net> <5C5564BB-23ED-49AB-81C6-CFF85B56ACA4@kodewerk.com> <5540D689.6020407@oracle.com> <73855087-8BB2-4A8C-B9AD-080CD39FAB7A@kodewerk.com> <55423444.7040009@beckwithclan.com> <556CA452.9040405@oracle.com> <7E7759C3-3AF0-4047-9B00-605DBB55DC79@oracle.com> Message-ID: Hi Charlie, So in summary what you are said is that G1 is in general, without GC fine tuning, a better default GC than ParallelGC for larger heaps because it by design considers more QoS aspects than ParallelGC does and has lots of ergonomics stuff, which is attractive for a default choice of GC when it?s unknown which specific QoS is a concern to the user and how to best tune it. Except hypothetically in the unlikely event that ParallelGC by mere accident happens to behave like a finely GC-tuned application with additional application-specific properties that ultimately results in better latencies for ParallelGC. I can see where this is going? ;) Thanks, /Erik Den 02/06/15 14:29 skrev charlie hunt : >Hi Erik, > >Let?s pull out a couple of your questions here and see I can offer some >answers. > >> I do not see why this (latency requirement uncertainty) specifically >> would be a problem for this particular transition into using G1 more >>instead of >> ParallelGC. Let?s focus only on the narrow scope of transitioning >> application contexts from ParallelGC to G1 only for ?larger? heaps. Is >> there any application context then where G1 has worse latency than >> ParallelGC? > >My observations have been that it is not a question of the size of the >Java heap, although folks often refer to it in this way. It is more about >the combination of the amount of live data, the amount of available space >between the live data and the Java heap and the object lifetimes. There >are Java apps out there where if Parallel GC is configured in a way >(either by mere accident the defaults hit this situation, which would be >unusual, or by manually tuning GC), Parallel GC?s young generation is >configured in a way that old generation collection can be avoided, many >of objects allocated die young, (i.e. there is not a humongous amount of >objects sloshing around between survivor spaces, and few, if any are >promoted to old gen), Parallel GC will likely offer lower latency than >G1. Again, to reiterate, to do this with Parallel GC will likely require >a GC tuning effort. Yet there may be an app, or some small number of apps >that Parallel GC with its JVM defaults could fit what I just described. >But, then again, the context of this JEP is before GC tuning. > >To up level this a bit, with a given GC, it is generally accepted that as >one performance attribute is emphasized, (throughput, latency and memory >footprint), there is a sacrifice in one or two of the others. I think you >are kind of saying this here too. But, I thought it was worth mentioning >specifically. I?ll come back to this a bit later. > >> Another concern Jenny mentioned where G1 could perform worse was JVM >>start >> up time. Again, I have a hard time imagining a /server application/ with >> an explicitly specified ?large? heap where anyone would care too much >> about this. Am I wrong? > >If we are talking about the difference in time to start the JVM relative >to the time it takes to generally initiate a Java app with a large Java >heap, then yes, I don?t think it would be much of a concern. This is not >to be confused with whether someone is not concerned with the time it >takes to initiate an application with a large Java heap taking a long >time. That is a different story. ;-) > >> And here G1 was designed, correct me if >> I?m wrong, to be not necessarily the best at anything, but pretty good >>at >> everything (latencies, performance and memory footprints). This sounds >>to >> me like a reasonable choice for default application contexts where it?s >> not known if the user cares about this or that QoS. > >This is pretty much the conclusion that I have arrived at. IMO, G1 due to >its ergonomics offers a larger population of applications a ?happy >medium? of tradeoffs between the three performance attributes than >Parallel GC in the absence of further tuning. > >thanks, > >charlie > >> On Jun 1, 2015, at 6:16 PM, Erik ?sterlund >>wrote: >> >> Hi Charlie, >> >> Den 01/06/15 22:51 skrev charlie hunt : >> >>> Hi Erik, >>> >>> HotSpot does some of this ergonomics today for both GC and JIT compiler >>> in cases where the JVM sees less than 2 GB of RAM and the OS it is >>> running on. These decisions are based on what is called a ?server class >>> machine?. A ?server class machine? as of JDK 6u18 is defined as a >>>system >>> that has 2 GB or more of RAM, two or more hardware threads. There are >>> other cases for a given hardware platform, and if it is a 32-bit JVM, >>>the >>> collector (and JIT compiler) ergonomically selected may also differ >>>from >>> other configurations. >>> >>> AFAIK, the JEP is proposing to change the default GC in configurations >>> where the default GC is Parallel GC to using G1 as the default. >> >> I think the fact that these ergonomics tricks are already around only >> motivates the approach further as it is in line with the current >> philosophy that if the user is not explicit about things, then the >>runtime >> can and will guess a bit and try to aim for some kind of middle ground >> solutions that are pretty good but not necessarily the best at >>everything >> (like G1 was designed to be). If the guess doesn?t cut it because it >>turns >> out that only a single QoS was important, like for instance performance >> over everything else, then maybe the user should have said so. ;) >> >>> The challenge with what you are describing is that the best GC cannot >>> always be ergonomically selected by the JVM without some input from the >>> user, i.e. GC doesn?t know if any GC pauses greater than 200 ms are >>> acceptable regardless of Java heap size, number of hardware threads, >>>etc. >> >> I do not see why this (latency requirement uncertainty) specifically >>would >> be a problem for this particular transition into using G1 more instead >>of >> ParallelGC. Let?s focus only on the narrow scope of transitioning >> application contexts from ParallelGC to G1 only for ?larger" heaps. Is >> there any application context then where G1 has worse latency than >> ParallelGC? I assume not. So the only visible effect such a change would >> bring is improved latencies if anything. And the whole mega-low-latency >> discussion where G1 doesn?t cut it is quite irrelevant for this change >>as >> well as those people affected are already not satisfied with ParallelGC >> that wouldn?t cut it either, and hence specify something explicitly. >> >> Another concern Jenny mentioned where G1 could perform worse was JVM >>start >> up time. Again, I have a hard time imagining a /server application/ with >> an explicitly specified ?large" heap where anyone would care too much >> about this. Am I wrong? >> >> What is left to annoy people with such a change then (apart from bugs) >> with latency not being one of them, is resource trade offs in terms of >> memory footprints and performance. And here G1 was designed, correct me >>if >> I?m wrong, to be not necessarily the best at anything, but pretty good >>at >> everything (latencies, performance and memory footprints). This sounds >>to >> me like a reasonable choice for default application contexts where it?s >> not known if the user cares about this or that QoS. And with the >> observation from Jenny that even performance seems to actually be better >> than ParallelGC for application contexts with large heaps, and the >> knowledge that latency is in general more important then, does it not >>make >> sense to choose G1 at least for those application contexts? >> >> Of course this is just a suggestion based on generalizations. Just >>thought >> it?s an interesting middle ground worth considering to instead of only >> considering either changing all or none of the default server >>application >> contexts, to only change the subset where we think it is least likely to >> annoy people, and then as G1 continues to improve and one size starts >> fitting all, expand that subset in a smoother transition. >> >> Thanks, >> /Erik >> >>> >>> thanks, >>> >>> charlie >>> >>>> On Jun 1, 2015, at 2:53 PM, Erik ?sterlund >>>> wrote: >>>> >>>> Hi all, >>>> >>>> Does there have to be a single default one-size-fits-all GC algorithm >>>> for >>>> users to rely on? Or could we allow multiple algorithms and explicitly >>>> document that unless a GC is picked, the runtime is free to pick >>>> whatever >>>> it believes is better? This could have multiple benefits. >>>> >>>> 1. This could make such a similar change easier in the future as >>>> everyone >>>> will already be aware that if they really rely on the properties of a >>>> specific GC algorithm, then they should choose that GC explicitly and >>>> not >>>> rely on defaults not changing; there are no guarantees that defaults >>>> will >>>> not change. >>>> >>>> 2. Obviously there has been a long discussion in this thread which GC >>>>is >>>> better in which context, and it seems like right now one size does not >>>> fit >>>> all. The user that relied on the defaults might not be so aware of >>>>these >>>> specifics. Therefore we might do them a big favour of attempting to >>>> make a >>>> guess for them to work out-of-the-box, which is pretty neat. >>>> >>>> 3. This approach allows deploying G1 not everywhere, but where we >>>>guess >>>> it >>>> performs pretty well. This means it will run in fewer JVM contexts and >>>> hence pose less risk than deploying it to be used for all contexts, >>>> making >>>> the transition smoother. >>>> >>>> One idea could be to first determine valid GC variants given the >>>> supplied >>>> flags (GC-specific flags imply use of that GC), and then among the >>>>valid >>>> GCs left, ?guess? which algorithm is better based on the other general >>>> parameters, such as e.g. heap size (and maybe target latency)? Could >>>>for >>>> instance pick ParallelGC for small heaps, G1 for larger heaps and CMS >>>> for >>>> ridiculously large heaps or cases when extremely low latency is >>>>wanted? >>>> >>>> My reasoning is based on two assumptions: 1) changing the defaults >>>>would >>>> target the users that don?t know what?s best for them, 2) one size >>>>does >>>> not fit all. If these assumption are wrong, then this is a bad idea. >>>> >>>> Thanks, >>>> /Erik >>>> >>>> >>>> >>>> Den 01/06/15 20:53 skrev charlie hunt : >>>> >>>>> Hi Jenny, >>>>> >>>>> A couple questions and comments below. >>>>> >>>>> thanks, >>>>> >>>>> charlie >>>>> >>>>>> On Jun 1, 2015, at 1:28 PM, Yu Zhang wrote: >>>>>> >>>>>> Hi, >>>>>> >>>>>> I have done some performance comparison g1/cms/parallelgc internally >>>>>> at >>>>>> Oracle. I would like to post my observations here to get some >>>>>> feedback, >>>>>> as I have limited benchmarks and hardware. These are out of box >>>>>> performance. >>>>>> >>>>>> Memory footprint/startup: >>>>>> g1 has bigger memory footprint and longer start up time. The >>>>>>overhead >>>>>> comes from more gc threads, and internal data structures to keep >>>>>>track >>>>>> of remember set. >>>>> >>>>> This is the memory footprint of the JVM itself when using the same >>>>>size >>>>> Java heap, right? >>>>> >>>>> I don?t recall if it has been your observation? One observation I >>>>>have >>>>> had with G1 is that it tends to be able to operate within tolerable >>>>> throughput and latency with a smaller Java heap than with Parallel >>>>>GC. >>>>> I >>>>> have seen cases where G1 may not use the entire Java heap because it >>>>> was >>>>> able to keep enough free regions available yet still meet pause time >>>>> goals. But, Parallel GC always use the entire Java heap, and once its >>>>> occupancy reach capacity, it would GC. So they are cases where >>>>>between >>>>> the JVM?s footprint overhead, and taking into account the amount of >>>>> Java >>>>> heap required, G1 may actually require less memory. >>>>> >>>>>> >>>>>> g1 vs parallelgc: >>>>>> If the workload involves young gc only, g1 could be slightly slower. >>>>>> Also g1 can consume more cpu, which might slow down the benchmark if >>>>>> SUT >>>>>> is cpu saturated. >>>>>> >>>>>> If there are promotions from young to old gen and leads to full gc >>>>>> with >>>>>> parallelgc, for smaller heap, parallel full gc can finish within >>>>>>some >>>>>> range of pause time, still out performs g1. But for bigger heap, g1 >>>>>> mixed gc can clean the heap with pause times a fraction of parallel >>>>>> full >>>>>> gc time, so improve both throughput and response time. Extreme >>>>>>cases >>>>>> are big data workloads(for example ycsb) with 100g heap. >>>>> >>>>> I think what you are saying here is that it looks like if one can >>>>>tune >>>>> Parallel GC such that you can avoid a lengthy collection of old >>>>> generation, or the live occupancy of old gen is small enough that the >>>>> time to collect is small enough to be tolerated, then Parallel GC >>>>>will >>>>> offer a better experience. >>>>> >>>>> However, if the live data in old generation at the time of its >>>>> collection >>>>> is large enough such that the time it takes to collect it exceeds a >>>>> tolerable pause time, then G1 will offer a better experience. >>>>> >>>>> Would also say that G1 offers a better experience in the presences of >>>>> (wide) swings in object allocation rates since there would likely be >>>>>a >>>>> larger number of promotions during the allocation spikes? In other >>>>> words, G1 may offer more predictable pauses. >>>>> >>>>>> >>>>>> g1 vs cms: >>>>>> I will focus on response time type of workloads. >>>>>> Ben mentioned >>>>>> >>>>>> "Having said that, there is definitely a decent-sized class of >>>>>>systems >>>>>> (not just in finance) that cannot really tolerate any more than >>>>>>about >>>>>> 10-15ms of STW. So, what usually happens is that they live with the >>>>>> young collections, use CMS and tune out the CMFs as best they can >>>>>>(by >>>>>> clustering, rolling restart, etc, etc). I don't see any possibility >>>>>>of >>>>>> G1 becoming a viable solution for those systems any time soon." >>>>>> >>>>>> Can you give more details, like what is the live data set size, how >>>>>> big >>>>>> is the heap, etc? I did some cache tests (Oracle coherence) to >>>>>> compare >>>>>> cms vs g1. g1 is better than cms when there are fragmentations. If >>>>>>you >>>>>> tune cms well to have little fragmentation, then g1 is behind cms. >>>>>> But >>>>>> for those cases, they have to tune CMS very well, changing default >>>>>>to >>>>>> g1 >>>>>> won't impact them. >>>>>> >>>>>> For big data kind of workloads (ycsb, spark in memory computing), g1 >>>>>> is >>>>>> much better than cms. >>>>>> >>>>>> Thanks, >>>>>> Jenny >>>>>> >>>>>> On 6/1/2015 10:06 AM, Ben Evans wrote: >>>>>>> Hi Vitaly, >>>>>>> >>>>>>>>> Instead, G1 is now being talked of as a replacement for the >>>>>>>>>default >>>>>>>>> collector. If that's the case, then I think we need to >>>>>>>>>acknowledge >>>>>>>>> it, >>>>>>>>> and have a conversation about where G1 is actually supposed to be >>>>>>>>> used. Are we saying we want a "reasonably high throughput with >>>>>>>>> reduced >>>>>>>>> STW, but not low pause time" collector? If we are, that's fine, >>>>>>>>>but >>>>>>>>> that's not where we started. >>>>>>>> That's a fair point, and one I'd be interesting in hearing an >>>>>>>>answer >>>>>>>> to as >>>>>>>> well. FWIW, the only GC I know of that's actually used in low >>>>>>>> latency >>>>>>>> systems is Azul's C4, so I'm not even sure Oracle is trying to >>>>>>>> target >>>>>>>> the >>>>>>>> same use cases. So when we talk about "low latency" GCs, we >>>>>>>>should >>>>>>>> probably >>>>>>>> also be clear on what "low" actually means. >>>>>>> Well, when I started playing with them, "low latency" meant a >>>>>>> sub-10-ms transaction time with 100ms STW as acceptable, if not >>>>>>> ideal. >>>>>>> >>>>>>> These days, the same sort of system needs a sub 500us transaction >>>>>>> time, and ideally no GC pause at all. But that leads to Zing, or >>>>>>> non-JVM solutions, and I think takes us too far into a specialised >>>>>>> use >>>>>>> case. >>>>>>> >>>>>>> Having said that, there is definitely a decent-sized class of >>>>>>>systems >>>>>>> (not just in finance) that cannot really tolerate any more than >>>>>>>about >>>>>>> 10-15ms of STW. So, what usually happens is that they live with the >>>>>>> young collections, use CMS and tune out the CMFs as best they can >>>>>>>(by >>>>>>> clustering, rolling restart, etc, etc). I don't see any possibility >>>>>>> of >>>>>>> G1 becoming a viable solution for those systems any time soon. >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Ben >>>>>> >>>>> >>>> >>> >> > From kirk at kodewerk.com Tue Jun 2 13:47:45 2015 From: kirk at kodewerk.com (Kirk Pepperdine) Date: Tue, 2 Jun 2015 15:47:45 +0200 Subject: JEP 248: Make G1 the Default Garbage Collector In-Reply-To: References: <20150428220211.4355960845@eggemoggin.niobe.net> <5C5564BB-23ED-49AB-81C6-CFF85B56ACA4@kodewerk.com> <5540D689.6020407@oracle.com> <73855087-8BB2-4A8C-B9AD-080CD39FAB7A@kodewerk.com> <55423444.7040009@beckwithclan.com> <556CA452.9040405@oracle.com> <7E7759C3-3AF0-4047-9B00-605DBB55DC79@oracle.com> <8815A8AF-0C3A-44DD-86BD-18E373ED2C60@oracle.com> <9EAEE9D5-4AD9-4786-B78C-0454067D53AE@kodewerk.com> Message-ID: <7DF4FB20-9E29-4D18-9C1B-8EA63B0A5669@kodewerk.com> On Jun 2, 2015, at 2:30 PM, Vitaly Davidovich wrote: > Perhaps you misunderstood - I'm saying it's sadly true that most apps > stress the GC. Ahh, my bad, I did read that backwards.. my apologies! > > As for awareness of GC impact on performance, it's well understood in > certain circles, but perhaps not as widely as it should be. Part of that > is due to java not having any options other than heap allocation and the > other is the GC marketing of "allocations are cheap?. that marketing is cr at p and I educate against it at every opportunity *with real world examples*. Collection of recently dead is cheap (something else that I also demo), allocating still comes at cost from a number of directions.. but I digress.. ? Kirk From vladimir.x.ivanov at oracle.com Tue Jun 2 14:17:17 2015 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Tue, 02 Jun 2015 17:17:17 +0300 Subject: RFR: 8081669: aarch64: JTreg TestStable tests failing In-Reply-To: <1433237195.16770.13.camel@mylittlepony.linaroharston> References: <1433237195.16770.13.camel@mylittlepony.linaroharston> Message-ID: <556DBAED.5030701@oracle.com> Looks good. Best regards, Vladimir Ivanov On 6/2/15 12:26 PM, Edward Nevill wrote: > Hi, > > The following webrev > > http://cr.openjdk.java.net/~enevill/8081669/webrev.00/ > > fixes a number of TestStable tests. > > This patch was contributed by alexander.alexeev at caviumnetworks.com > > The following are the test failures that are fixed by this patch > > compiler/stable/TestStableByte.java > compiler/stable/TestStableBoolean.java > compiler/stable/TestStableChar.java > compiler/stable/TestStableFloat.java > compiler/stable/TestStableObject.java > compiler/stable/TestStableDouble.java > compiler/stable/TestStableInt.java > compiler/stable/TestStableLong.java > compiler/stable/TestStableShort.java > > The problem is that the method 'get' in StableConfiguration is supposed to return true if the method is server compiled, false otherwise. > > On aarch64 it is always returning true, even when the method is client compiled. The reason for this is that aarch64 differs from other ports in that it always deopts on patching. > > This means that the method 'get' deopts immediately when compiled with -Xcomp because it hits an unresolved method call. This means that the method is now executing in the interpreter. > > When the method 'get' is executing in the interpreter, it uses the value of java.vm.name to determine whether the method would be server compiled if it were to be compiled. This ends up returning true on aarch64, because it is a server compiler. > > However in the case where we force it not to server compile by using -XX:+TieredCompilation and -XX:TieredStopAtLevel=1 (as in the TestStable tests) this will be incorrect. > > The solution is to introduce a simple (null) method 'get1' which will never be deopted (because there is never anything to patch) and uses this as the basis for deciding whether we are server compiling or not. > > This is more fully explained in the inline comment in the patch. > > Please review and if appropriate I will push. > > All the best, > Ed. > > From charlie.hunt at oracle.com Tue Jun 2 14:31:07 2015 From: charlie.hunt at oracle.com (charlie hunt) Date: Tue, 2 Jun 2015 09:31:07 -0500 Subject: JEP 248: Make G1 the Default Garbage Collector In-Reply-To: References: <20150428220211.4355960845@eggemoggin.niobe.net> <5C5564BB-23ED-49AB-81C6-CFF85B56ACA4@kodewerk.com> <5540D689.6020407@oracle.com> <73855087-8BB2-4A8C-B9AD-080CD39FAB7A@kodewerk.com> <55423444.7040009@beckwithclan.com> <556CA452.9040405@oracle.com> <7E7759C3-3AF0-4047-9B00-605DBB55DC79@oracle.com> Message-ID: Hi Erik, Yes, very good summary, (including the ?I can see where this is going. ;)? ) comment. :) thanks, charlie > On Jun 2, 2015, at 8:39 AM, Erik ?sterlund wrote: > > Hi Charlie, > > So in summary what you are said is that G1 is in general, without GC fine > tuning, a better default GC than ParallelGC for larger heaps because it by > design considers more QoS aspects than ParallelGC does and has lots of > ergonomics stuff, which is attractive for a default choice of GC when it?s > unknown which specific QoS is a concern to the user and how to best tune > it. Except hypothetically in the unlikely event that ParallelGC by mere > accident happens to behave like a finely GC-tuned application with > additional application-specific properties that ultimately results in > better latencies for ParallelGC. > > I can see where this is going? ;) > > Thanks, > /Erik > > Den 02/06/15 14:29 skrev charlie hunt : > >> Hi Erik, >> >> Let?s pull out a couple of your questions here and see I can offer some >> answers. >> >>> I do not see why this (latency requirement uncertainty) specifically >>> would be a problem for this particular transition into using G1 more >>> instead of >>> ParallelGC. Let?s focus only on the narrow scope of transitioning >>> application contexts from ParallelGC to G1 only for ?larger? heaps. Is >>> there any application context then where G1 has worse latency than >>> ParallelGC? >> >> My observations have been that it is not a question of the size of the >> Java heap, although folks often refer to it in this way. It is more about >> the combination of the amount of live data, the amount of available space >> between the live data and the Java heap and the object lifetimes. There >> are Java apps out there where if Parallel GC is configured in a way >> (either by mere accident the defaults hit this situation, which would be >> unusual, or by manually tuning GC), Parallel GC?s young generation is >> configured in a way that old generation collection can be avoided, many >> of objects allocated die young, (i.e. there is not a humongous amount of >> objects sloshing around between survivor spaces, and few, if any are >> promoted to old gen), Parallel GC will likely offer lower latency than >> G1. Again, to reiterate, to do this with Parallel GC will likely require >> a GC tuning effort. Yet there may be an app, or some small number of apps >> that Parallel GC with its JVM defaults could fit what I just described. >> But, then again, the context of this JEP is before GC tuning. >> >> To up level this a bit, with a given GC, it is generally accepted that as >> one performance attribute is emphasized, (throughput, latency and memory >> footprint), there is a sacrifice in one or two of the others. I think you >> are kind of saying this here too. But, I thought it was worth mentioning >> specifically. I?ll come back to this a bit later. >> >>> Another concern Jenny mentioned where G1 could perform worse was JVM >>> start >>> up time. Again, I have a hard time imagining a /server application/ with >>> an explicitly specified ?large? heap where anyone would care too much >>> about this. Am I wrong? >> >> If we are talking about the difference in time to start the JVM relative >> to the time it takes to generally initiate a Java app with a large Java >> heap, then yes, I don?t think it would be much of a concern. This is not >> to be confused with whether someone is not concerned with the time it >> takes to initiate an application with a large Java heap taking a long >> time. That is a different story. ;-) >> >>> And here G1 was designed, correct me if >>> I?m wrong, to be not necessarily the best at anything, but pretty good >>> at >>> everything (latencies, performance and memory footprints). This sounds >>> to >>> me like a reasonable choice for default application contexts where it?s >>> not known if the user cares about this or that QoS. >> >> This is pretty much the conclusion that I have arrived at. IMO, G1 due to >> its ergonomics offers a larger population of applications a ?happy >> medium? of tradeoffs between the three performance attributes than >> Parallel GC in the absence of further tuning. >> >> thanks, >> >> charlie >> >>> On Jun 1, 2015, at 6:16 PM, Erik ?sterlund >>> wrote: >>> >>> Hi Charlie, >>> >>> Den 01/06/15 22:51 skrev charlie hunt : >>> >>>> Hi Erik, >>>> >>>> HotSpot does some of this ergonomics today for both GC and JIT compiler >>>> in cases where the JVM sees less than 2 GB of RAM and the OS it is >>>> running on. These decisions are based on what is called a ?server class >>>> machine?. A ?server class machine? as of JDK 6u18 is defined as a >>>> system >>>> that has 2 GB or more of RAM, two or more hardware threads. There are >>>> other cases for a given hardware platform, and if it is a 32-bit JVM, >>>> the >>>> collector (and JIT compiler) ergonomically selected may also differ >>>> from >>>> other configurations. >>>> >>>> AFAIK, the JEP is proposing to change the default GC in configurations >>>> where the default GC is Parallel GC to using G1 as the default. >>> >>> I think the fact that these ergonomics tricks are already around only >>> motivates the approach further as it is in line with the current >>> philosophy that if the user is not explicit about things, then the >>> runtime >>> can and will guess a bit and try to aim for some kind of middle ground >>> solutions that are pretty good but not necessarily the best at >>> everything >>> (like G1 was designed to be). If the guess doesn?t cut it because it >>> turns >>> out that only a single QoS was important, like for instance performance >>> over everything else, then maybe the user should have said so. ;) >>> >>>> The challenge with what you are describing is that the best GC cannot >>>> always be ergonomically selected by the JVM without some input from the >>>> user, i.e. GC doesn?t know if any GC pauses greater than 200 ms are >>>> acceptable regardless of Java heap size, number of hardware threads, >>>> etc. >>> >>> I do not see why this (latency requirement uncertainty) specifically >>> would >>> be a problem for this particular transition into using G1 more instead >>> of >>> ParallelGC. Let?s focus only on the narrow scope of transitioning >>> application contexts from ParallelGC to G1 only for ?larger" heaps. Is >>> there any application context then where G1 has worse latency than >>> ParallelGC? I assume not. So the only visible effect such a change would >>> bring is improved latencies if anything. And the whole mega-low-latency >>> discussion where G1 doesn?t cut it is quite irrelevant for this change >>> as >>> well as those people affected are already not satisfied with ParallelGC >>> that wouldn?t cut it either, and hence specify something explicitly. >>> >>> Another concern Jenny mentioned where G1 could perform worse was JVM >>> start >>> up time. Again, I have a hard time imagining a /server application/ with >>> an explicitly specified ?large" heap where anyone would care too much >>> about this. Am I wrong? >>> >>> What is left to annoy people with such a change then (apart from bugs) >>> with latency not being one of them, is resource trade offs in terms of >>> memory footprints and performance. And here G1 was designed, correct me >>> if >>> I?m wrong, to be not necessarily the best at anything, but pretty good >>> at >>> everything (latencies, performance and memory footprints). This sounds >>> to >>> me like a reasonable choice for default application contexts where it?s >>> not known if the user cares about this or that QoS. And with the >>> observation from Jenny that even performance seems to actually be better >>> than ParallelGC for application contexts with large heaps, and the >>> knowledge that latency is in general more important then, does it not >>> make >>> sense to choose G1 at least for those application contexts? >>> >>> Of course this is just a suggestion based on generalizations. Just >>> thought >>> it?s an interesting middle ground worth considering to instead of only >>> considering either changing all or none of the default server >>> application >>> contexts, to only change the subset where we think it is least likely to >>> annoy people, and then as G1 continues to improve and one size starts >>> fitting all, expand that subset in a smoother transition. >>> >>> Thanks, >>> /Erik >>> >>>> >>>> thanks, >>>> >>>> charlie >>>> >>>>> On Jun 1, 2015, at 2:53 PM, Erik ?sterlund >>>>> wrote: >>>>> >>>>> Hi all, >>>>> >>>>> Does there have to be a single default one-size-fits-all GC algorithm >>>>> for >>>>> users to rely on? Or could we allow multiple algorithms and explicitly >>>>> document that unless a GC is picked, the runtime is free to pick >>>>> whatever >>>>> it believes is better? This could have multiple benefits. >>>>> >>>>> 1. This could make such a similar change easier in the future as >>>>> everyone >>>>> will already be aware that if they really rely on the properties of a >>>>> specific GC algorithm, then they should choose that GC explicitly and >>>>> not >>>>> rely on defaults not changing; there are no guarantees that defaults >>>>> will >>>>> not change. >>>>> >>>>> 2. Obviously there has been a long discussion in this thread which GC >>>>> is >>>>> better in which context, and it seems like right now one size does not >>>>> fit >>>>> all. The user that relied on the defaults might not be so aware of >>>>> these >>>>> specifics. Therefore we might do them a big favour of attempting to >>>>> make a >>>>> guess for them to work out-of-the-box, which is pretty neat. >>>>> >>>>> 3. This approach allows deploying G1 not everywhere, but where we >>>>> guess >>>>> it >>>>> performs pretty well. This means it will run in fewer JVM contexts and >>>>> hence pose less risk than deploying it to be used for all contexts, >>>>> making >>>>> the transition smoother. >>>>> >>>>> One idea could be to first determine valid GC variants given the >>>>> supplied >>>>> flags (GC-specific flags imply use of that GC), and then among the >>>>> valid >>>>> GCs left, ?guess? which algorithm is better based on the other general >>>>> parameters, such as e.g. heap size (and maybe target latency)? Could >>>>> for >>>>> instance pick ParallelGC for small heaps, G1 for larger heaps and CMS >>>>> for >>>>> ridiculously large heaps or cases when extremely low latency is >>>>> wanted? >>>>> >>>>> My reasoning is based on two assumptions: 1) changing the defaults >>>>> would >>>>> target the users that don?t know what?s best for them, 2) one size >>>>> does >>>>> not fit all. If these assumption are wrong, then this is a bad idea. >>>>> >>>>> Thanks, >>>>> /Erik >>>>> >>>>> >>>>> >>>>> Den 01/06/15 20:53 skrev charlie hunt : >>>>> >>>>>> Hi Jenny, >>>>>> >>>>>> A couple questions and comments below. >>>>>> >>>>>> thanks, >>>>>> >>>>>> charlie >>>>>> >>>>>>> On Jun 1, 2015, at 1:28 PM, Yu Zhang wrote: >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> I have done some performance comparison g1/cms/parallelgc internally >>>>>>> at >>>>>>> Oracle. I would like to post my observations here to get some >>>>>>> feedback, >>>>>>> as I have limited benchmarks and hardware. These are out of box >>>>>>> performance. >>>>>>> >>>>>>> Memory footprint/startup: >>>>>>> g1 has bigger memory footprint and longer start up time. The >>>>>>> overhead >>>>>>> comes from more gc threads, and internal data structures to keep >>>>>>> track >>>>>>> of remember set. >>>>>> >>>>>> This is the memory footprint of the JVM itself when using the same >>>>>> size >>>>>> Java heap, right? >>>>>> >>>>>> I don?t recall if it has been your observation? One observation I >>>>>> have >>>>>> had with G1 is that it tends to be able to operate within tolerable >>>>>> throughput and latency with a smaller Java heap than with Parallel >>>>>> GC. >>>>>> I >>>>>> have seen cases where G1 may not use the entire Java heap because it >>>>>> was >>>>>> able to keep enough free regions available yet still meet pause time >>>>>> goals. But, Parallel GC always use the entire Java heap, and once its >>>>>> occupancy reach capacity, it would GC. So they are cases where >>>>>> between >>>>>> the JVM?s footprint overhead, and taking into account the amount of >>>>>> Java >>>>>> heap required, G1 may actually require less memory. >>>>>> >>>>>>> >>>>>>> g1 vs parallelgc: >>>>>>> If the workload involves young gc only, g1 could be slightly slower. >>>>>>> Also g1 can consume more cpu, which might slow down the benchmark if >>>>>>> SUT >>>>>>> is cpu saturated. >>>>>>> >>>>>>> If there are promotions from young to old gen and leads to full gc >>>>>>> with >>>>>>> parallelgc, for smaller heap, parallel full gc can finish within >>>>>>> some >>>>>>> range of pause time, still out performs g1. But for bigger heap, g1 >>>>>>> mixed gc can clean the heap with pause times a fraction of parallel >>>>>>> full >>>>>>> gc time, so improve both throughput and response time. Extreme >>>>>>> cases >>>>>>> are big data workloads(for example ycsb) with 100g heap. >>>>>> >>>>>> I think what you are saying here is that it looks like if one can >>>>>> tune >>>>>> Parallel GC such that you can avoid a lengthy collection of old >>>>>> generation, or the live occupancy of old gen is small enough that the >>>>>> time to collect is small enough to be tolerated, then Parallel GC >>>>>> will >>>>>> offer a better experience. >>>>>> >>>>>> However, if the live data in old generation at the time of its >>>>>> collection >>>>>> is large enough such that the time it takes to collect it exceeds a >>>>>> tolerable pause time, then G1 will offer a better experience. >>>>>> >>>>>> Would also say that G1 offers a better experience in the presences of >>>>>> (wide) swings in object allocation rates since there would likely be >>>>>> a >>>>>> larger number of promotions during the allocation spikes? In other >>>>>> words, G1 may offer more predictable pauses. >>>>>> >>>>>>> >>>>>>> g1 vs cms: >>>>>>> I will focus on response time type of workloads. >>>>>>> Ben mentioned >>>>>>> >>>>>>> "Having said that, there is definitely a decent-sized class of >>>>>>> systems >>>>>>> (not just in finance) that cannot really tolerate any more than >>>>>>> about >>>>>>> 10-15ms of STW. So, what usually happens is that they live with the >>>>>>> young collections, use CMS and tune out the CMFs as best they can >>>>>>> (by >>>>>>> clustering, rolling restart, etc, etc). I don't see any possibility >>>>>>> of >>>>>>> G1 becoming a viable solution for those systems any time soon." >>>>>>> >>>>>>> Can you give more details, like what is the live data set size, how >>>>>>> big >>>>>>> is the heap, etc? I did some cache tests (Oracle coherence) to >>>>>>> compare >>>>>>> cms vs g1. g1 is better than cms when there are fragmentations. If >>>>>>> you >>>>>>> tune cms well to have little fragmentation, then g1 is behind cms. >>>>>>> But >>>>>>> for those cases, they have to tune CMS very well, changing default >>>>>>> to >>>>>>> g1 >>>>>>> won't impact them. >>>>>>> >>>>>>> For big data kind of workloads (ycsb, spark in memory computing), g1 >>>>>>> is >>>>>>> much better than cms. >>>>>>> >>>>>>> Thanks, >>>>>>> Jenny >>>>>>> >>>>>>> On 6/1/2015 10:06 AM, Ben Evans wrote: >>>>>>>> Hi Vitaly, >>>>>>>> >>>>>>>>>> Instead, G1 is now being talked of as a replacement for the >>>>>>>>>> default >>>>>>>>>> collector. If that's the case, then I think we need to >>>>>>>>>> acknowledge >>>>>>>>>> it, >>>>>>>>>> and have a conversation about where G1 is actually supposed to be >>>>>>>>>> used. Are we saying we want a "reasonably high throughput with >>>>>>>>>> reduced >>>>>>>>>> STW, but not low pause time" collector? If we are, that's fine, >>>>>>>>>> but >>>>>>>>>> that's not where we started. >>>>>>>>> That's a fair point, and one I'd be interesting in hearing an >>>>>>>>> answer >>>>>>>>> to as >>>>>>>>> well. FWIW, the only GC I know of that's actually used in low >>>>>>>>> latency >>>>>>>>> systems is Azul's C4, so I'm not even sure Oracle is trying to >>>>>>>>> target >>>>>>>>> the >>>>>>>>> same use cases. So when we talk about "low latency" GCs, we >>>>>>>>> should >>>>>>>>> probably >>>>>>>>> also be clear on what "low" actually means. >>>>>>>> Well, when I started playing with them, "low latency" meant a >>>>>>>> sub-10-ms transaction time with 100ms STW as acceptable, if not >>>>>>>> ideal. >>>>>>>> >>>>>>>> These days, the same sort of system needs a sub 500us transaction >>>>>>>> time, and ideally no GC pause at all. But that leads to Zing, or >>>>>>>> non-JVM solutions, and I think takes us too far into a specialised >>>>>>>> use >>>>>>>> case. >>>>>>>> >>>>>>>> Having said that, there is definitely a decent-sized class of >>>>>>>> systems >>>>>>>> (not just in finance) that cannot really tolerate any more than >>>>>>>> about >>>>>>>> 10-15ms of STW. So, what usually happens is that they live with the >>>>>>>> young collections, use CMS and tune out the CMFs as best they can >>>>>>>> (by >>>>>>>> clustering, rolling restart, etc, etc). I don't see any possibility >>>>>>>> of >>>>>>>> G1 becoming a viable solution for those systems any time soon. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Ben >>>>>>> >>>>>> >>>>> >>>> >>> >> > From volker.simonis at gmail.com Tue Jun 2 16:12:02 2015 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 2 Jun 2015 18:12:02 +0200 Subject: RFR(M): 8081674: EmptyStackException at startup if running with extended or unsupported charset Message-ID: Hi, can I please have review (and a sponsor) for these changes: https://bugs.openjdk.java.net/browse/JDK-8081674 http://cr.openjdk.java.net/~simonis/webrevs/2015/8081674.jdk http://cr.openjdk.java.net/~simonis/webrevs/2015/8081674.hs Please notice that the fix requires synchronous changes in the jdk and the hotspot forest. The changes themselves are by far not that big as this explanation but I found the problem to be quite intricate so I tried to explain it as good as I could. I'd suggest to read the HTML-formatted explanation in the webrev although the content is equal to the one in this mail: Using an unsupported character encoding (e.g. vi_VN.TCVN on Linux) results in an immediate VM failure with jdk 8 and 9: export LANG=vi_VN.TCVN java -version Error occurred during initialization of VM java.util.EmptyStackException at java.util.Stack.peek(Stack.java:102) at java.lang.ClassLoader$NativeLibrary.getFromClass(ClassLoader.java:1751) at java.lang.ClassLoader$NativeLibrary.findBuiltinLib(Native Method) at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1862) at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1835) at java.lang.Runtime.loadLibrary0(Runtime.java:870) at java.lang.System.loadLibrary(System.java:1119) at java.lang.System.initializeSystemClass(System.java:1194) This is a consequence of "8005716: Enhance JNI specification to allow support of static JNI libraries in Embedded JREs". With jdk 9 we get this error even if we're running with a supported charset which is in the ExtendedCharsets (as opposed to being in the StandardCharsets) class which is a consequence of delegating the loading of the ExtendedCharsets class to the ServiceLoader in jdk 9. export LANG=eo.iso-8859-3 output-jdk9/images/jdk/bin/java -version Error occurred during initialization of VM java.util.EmptyStackException at java.util.Stack.peek(Stack.java:102) at java.lang.ClassLoader$NativeLibrary.getFromClass(ClassLoader.java:1737) at java.lang.ClassLoader$NativeLibrary.findBuiltinLib(Native Method) at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1866) at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1840) at java.lang.Runtime.loadLibrary0(Runtime.java:874) at java.lang.System.loadLibrary(System.java:1111) at java.lang.System.initializeSystemClass(System.java:1186) Here's why the exception happens for an unsupported charset (see the mixed stack trace below for the full details): java.lang.System.loadLibrary() wants to load libzip.so. It calls java.lang.Runtime.loadLibrary0() which at the very beginning calls the native method ClassLoader$NativeLibrary.findBuiltinLib() which checks if the corresponding library is already statically linked into the VM (introduced by 8005716). Java_java_lang_ClassLoader_00024NativeLibrary_findBuiltinLib(), the native implementation of findBuiltinLib() in Classloader.c calls GetStringPlatformChars() to convert the library name into the native platform encoding. GetStringPlatformChars() calls the helper function jnuEncodingSupported() to check if the platform encoding which is stored in the property "sun.jnu.encoding" is supported by Java. jnuEncodingSupported() is implemented as follows: static jboolean isJNUEncodingSupported = JNI_FALSE; static jboolean jnuEncodingSupported(JNIEnv *env) { jboolean exe; if (isJNUEncodingSupported == JNI_TRUE) { return JNI_TRUE; } isJNUEncodingSupported = (jboolean) JNU_CallStaticMethodByName ( env, &exe, "java/nio/charset/Charset", "isSupported", "(Ljava/lang/String;)Z", jnuEncoding).z; return isJNUEncodingSupported; } Once the function finds that the platform encoding is supported (by calling java.nio.charset.Charset.isSupported()) it caches this value and always returns it on following calls. However if the platform encoding is not supported, it ALWAYS calls java.nio.charset.Charset.isSupported() an every subsequent invocation. In order to call the Java method Charset.isSupported() (in JNU_CallStaticMethodByName() in file jni_util.c), we have to call jni_FindClass() to convert the symbolic class name "java.nio.charset.Charset" into a class reference. But unfortunately, jni_FindClass() (from jni.cpp in libjvm.so) has a special handling if called from java.lang.ClassLoader$NativeLibrary to ensure that JNI_OnLoad/JNI_OnUnload are executed in the correct class context: instanceKlassHandle k (THREAD, thread->security_get_caller_class(0)); if (k.not_null()) { loader = Handle(THREAD, k->class_loader()); // Special handling to make sure JNI_OnLoad and JNI_OnUnload are executed // in the correct class context. if (loader.is_null() && k->name() == vmSymbols::java_lang_ClassLoader_NativeLibrary()) { JavaValue result(T_OBJECT); JavaCalls::call_static(&result, k, vmSymbols::getFromClass_name(), vmSymbols::void_class_signature(), thread); if (HAS_PENDING_EXCEPTION) { Handle ex(thread, thread->pending_exception()); CLEAR_PENDING_EXCEPTION; THROW_HANDLE_0(ex); } So if that's the case and jni_FindClass() was reallycalled from ClassLoader$NativeLibrary, then jni_FindClass() calles ClassLoader$NativeLibrary().getFromClass() to find out the corresponding context class which is supposed to be saved there in a field of type java.util.Stack named "nativeLibraryContext": // Invoked in the VM to determine the context class in // JNI_Load/JNI_Unload static Class getFromClass() { return ClassLoader.nativeLibraryContext.peek().fromClass; } Unfortunately, "nativeLibraryContext" doesn't contain any entry at this point and the invocation of Stack.peek() will throw the exception shown before. In general, the "nativeLibraryContext" stack will be filled later on in Runtime.loadLibrary0() like this: NativeLibrary lib = new NativeLibrary(fromClass, name, isBuiltin); nativeLibraryContext.push(lib); try { lib.load(name, isBuiltin); } finally { nativeLibraryContext.pop(); } such that it always contains at least one element later when jni_FindClass() will be invoked. So in summary, the problem is that the implementors of 8005716 didn't took into account that calling ClassLoader$NativeLibrary.findBuiltinLib() may trigger a call to jni_FindClass() if we are running on a system with an unsupported character encoding. I'd suggest the following fix for this problem: Change ClassLoader$NativeLibrary().getFromClass() to return null if the stack is empty instead of throwing an exception: static Class getFromClass() { return ClassLoader.nativeLibraryContext.empty() ? null : ClassLoader.nativeLibraryContext.peek().fromClass; } Unfortunately this also requires a HotSpot change in jni_FindClass() in order to properly handle the new 'null' return value: if (k.not_null()) { loader = Handle(THREAD, k->class_loader()); // Special handling to make sure JNI_OnLoad and JNI_OnUnload are executed // in the correct class context. if (loader.is_null() && k->name() == vmSymbols::java_lang_ClassLoader_NativeLibrary()) { JavaValue result(T_OBJECT); JavaCalls::call_static(&result, k, vmSymbols::getFromClass_name(), vmSymbols::void_class_signature(), thread); if (HAS_PENDING_EXCEPTION) { Handle ex(thread, thread->pending_exception()); CLEAR_PENDING_EXCEPTION; THROW_HANDLE_0(ex); } oop mirror = (oop) result.get_jobject(); if (oopDesc::is_null(mirror)) { loader = Handle(THREAD, SystemDictionary::java_system_loader()); } else { loader = Handle(THREAD, InstanceKlass::cast(java_lang_Class::as_Klass(mirror))->class_loader()); protection_domain = Handle(THREAD, InstanceKlass::cast(java_lang_Class::as_Klass(mirror))->protection_domain()); } } } else { // We call ClassLoader.getSystemClassLoader to obtain the system class loader. loader = Handle(THREAD, SystemDictionary::java_system_loader()); } These changes are sufficient to solve the problem in Java 8. Unfortunately, that's still not enough in Java 9 because there the loading of the extended charsets has been delegated to ServiceLoader. But ServiceLoader calls ClassLoader.getBootstrapResources() which calls sun.misc.Launcher.getBootstrapClassPath(). This leads to another problem during class initialization of sun.misc.Launcher if running on an unsupported locale. The first thing done in sun.misc.Launcher. is the initialisation of the bootstrap URLClassPath in the Launcher. However this initialisation will eventually call Charset.isSupported() and if we are running on an unsupported locale this will inevitably end in another recursive call to ServiceLoader. But as explained below, ServiceLoader will query the Launcher's bootstrap URLClassPath which will be still uninitialized at that point. So we'll have to additionally guard guard against this situation on JDK 9 like this: private static Charset lookupExtendedCharset(String charsetName) { if (!sun.misc.VM.isBooted() || // see lookupViaProviders() sun.misc.Launcher.getBootstrapClassPath() == null) return null; This fixes the crashes, but still at the price of not having the extended charsets available during initialization until Launcher.getBootstrapClassPath is set up properly. This may be still a problem if the jdk is installed in a directory which contains characters specific to an extended encoding or if we have such characters in the command line arguments. Thank you and best regards, Volker *Mixed stack trace of the initial EmptyStackException for unsupported charsets described before:* Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) j java.util.Stack.peek()Ljava/lang/Object;+1 j java.lang.ClassLoader$NativeLibrary.getFromClass()Ljava/lang/Class;+3 v ~StubRoutines::call_stub V [libjvm.so+0x9d279a] JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, Thread*)+0x6b4 V [libjvm.so+0xcad591] os::os_exception_wrapper(void (*)(JavaValue*, methodHandle*, JavaCallArguments*, Thread*), JavaValue*, methodHandle*, JavaCallArguments*, Thread*)+0x45 V [libjvm.so+0x9d20cf] JavaCalls::call(JavaValue*, methodHandle, JavaCallArguments*, Thread*)+0x8b V [libjvm.so+0x9d1d3b] JavaCalls::call_static(JavaValue*, KlassHandle, Symbol*, Symbol*, JavaCallArguments*, Thread*)+0x139 V [libjvm.so+0x9d1e3f] JavaCalls::call_static(JavaValue*, KlassHandle, Symbol*, Symbol*, Thread*)+0x9d V [libjvm.so+0x9e6588] jni_FindClass+0x428 C [libjava.so+0x20208] JNU_CallStaticMethodByName+0xff C [libjava.so+0x21cae] jnuEncodingSupported+0x61 C [libjava.so+0x22125] JNU_GetStringPlatformChars+0x125 C [libjava.so+0xedcd] Java_java_lang_ClassLoader_00024NativeLibrary_findBuiltinLib+0x8b j java.lang.ClassLoader$NativeLibrary.findBuiltinLib(Ljava/lang/String;)Ljava/lang/String;+0 j java.lang.ClassLoader.loadLibrary0(Ljava/lang/Class;Ljava/io/File;)Z+4 j java.lang.ClassLoader.loadLibrary(Ljava/lang/Class;Ljava/lang/String;Z)V+228 j java.lang.Runtime.loadLibrary0(Ljava/lang/Class;Ljava/lang/String;)V+54 j java.lang.System.loadLibrary(Ljava/lang/String;)V+7 j java.lang.System.initializeSystemClass()V+113 v ~StubRoutines::call_stub V [libjvm.so+0x9d279a] JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, Thread*)+0x6b4 V [libjvm.so+0xcad591] os::os_exception_wrapper(void (*)(JavaValue*, methodHandle*, JavaCallArguments*, Thread*), JavaValue*, methodHandle*, JavaCallArguments*, Thread*)+0x45 V [libjvm.so+0x9d20cf] JavaCalls::call(JavaValue*, methodHandle, JavaCallArguments*, Thread*)+0x8b V [libjvm.so+0x9d1d3b] JavaCalls::call_static(JavaValue*, KlassHandle, Symbol*, Symbol*, JavaCallArguments*, Thread*)+0x139 V [libjvm.so+0x9d1e3f] JavaCalls::call_static(JavaValue*, KlassHandle, Symbol*, Symbol*, Thread*)+0x9d V [libjvm.so+0xe3cceb] call_initializeSystemClass(Thread*)+0xb0 V [libjvm.so+0xe44444] Threads::initialize_java_lang_classes(JavaThread*, Thread*)+0x21a V [libjvm.so+0xe44b12] Threads::create_vm(JavaVMInitArgs*, bool*)+0x4a6 V [libjvm.so+0xa19bd7] JNI_CreateJavaVM+0xc7 C [libjli.so+0xa520] InitializeJVM+0x154 C [libjli.so+0x8024] JavaMain+0xcc From alexander.kulyakhtin at oracle.com Tue Jun 2 16:26:29 2015 From: alexander.kulyakhtin at oracle.com (Alexander Kulyakhtin) Date: Tue, 2 Jun 2015 09:26:29 -0700 (PDT) Subject: RFR: JDK-8075327: Merge jdk and hotspot test libraries Message-ID: Hi Ivan, I did my changes using hs-rt repository. The file you mention is not there yet. I'm going to do the changes to this and any other possible new jdk files as a follow up to this bulk change. The goal of the webrev is to receive approval of the way the test libraries are going to be merged. Best regards, Alexander ----- Original Message ----- From: ivan.gerasimov at oracle.com To: alexander.kulyakhtin at oracle.com, jdk9-dev at openjdk.java.net, hotspot-dev at openjdk.java.net Sent: Tuesday, June 2, 2015 6:44:33 PM GMT +03:00 Iraq Subject: Re: RFR: JDK-8075327: Merge jdk and hotspot test libraries Hi Alexander! Would you please include jdk/test/lib/testlibrary/jdk/testlibrary/OptimalCapacity.java in the webrev? This file was added recently with the fix for JDK-8081027 It's currently used from the following three tests, which will need to be updated too: jdk/test/java/lang/Character/UnicodeBlock/OptimalMapSize.java jdk/test/sun/invoke/anon/ConstantPoolPatch/OptimalMapSize.java jdk/test/sun/security/ssl/ExtensionType/OptimalListSize.java Sincerely yours, Ivan On 02.06.2015 14:18, Alexander Kulyakhtin wrote: > Hi, > > Could you, please, review the following test-only changes to the 'jdk', 'hotspot' and the common 'test' repository > > http://cr.openjdk.java.net/~akulyakh/8075327/wr_hs/webrev.01/index.html > http://cr.openjdk.java.net/~akulyakh/8075327/wr_jdk/webrev.01/index.html > http://cr.openjdk.java.net/~akulyakh/8075327/wr_test/webrev.01/ > > The changes are to move test library files common to both jdk and hotspot to the upper-level test repository. > > The following has been done: > 1) Common files (Asserts.java, OutputAnalyzer.java etc) from the jdk and hotspot repositories, have been merged and moved to the upper-level common test repository, to test/lib/share/classes. > 2) Package jdk.testlibrary in the jdk repository have been renamed to jdk.test.lib to have the same name as in the hotspot repository > 2) Upper level test/lib/share/classes library references have been added to the @library statements > 3) Some packages previously located at upper level test repo at /test/lib have been moved to /test/lib/share/classes for consistency > > Best regards, > Alexander > > From vladimir.x.ivanov at oracle.com Tue Jun 2 16:50:55 2015 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Tue, 02 Jun 2015 19:50:55 +0300 Subject: RFR: 8081669: aarch64: JTreg TestStable tests failing In-Reply-To: <556DBAED.5030701@oracle.com> References: <1433237195.16770.13.camel@mylittlepony.linaroharston> <556DBAED.5030701@oracle.com> Message-ID: <556DDEEF.4060703@oracle.com> The only concern I have is that I don't see Alexander on OCA list [1]. In order to proceed with the fix, he should sign OCA first. Best regards, Vladimir Ivanov [1] http://www.oracle.com/technetwork/community/oca-486395.html On 6/2/15 5:17 PM, Vladimir Ivanov wrote: > Looks good. > > Best regards, > Vladimir Ivanov > > On 6/2/15 12:26 PM, Edward Nevill wrote: >> Hi, >> >> The following webrev >> >> http://cr.openjdk.java.net/~enevill/8081669/webrev.00/ >> >> fixes a number of TestStable tests. >> >> This patch was contributed by alexander.alexeev at caviumnetworks.com >> >> The following are the test failures that are fixed by this patch >> >> compiler/stable/TestStableByte.java >> compiler/stable/TestStableBoolean.java >> compiler/stable/TestStableChar.java >> compiler/stable/TestStableFloat.java >> compiler/stable/TestStableObject.java >> compiler/stable/TestStableDouble.java >> compiler/stable/TestStableInt.java >> compiler/stable/TestStableLong.java >> compiler/stable/TestStableShort.java >> >> The problem is that the method 'get' in StableConfiguration is >> supposed to return true if the method is server compiled, false >> otherwise. >> >> On aarch64 it is always returning true, even when the method is client >> compiled. The reason for this is that aarch64 differs from other ports >> in that it always deopts on patching. >> >> This means that the method 'get' deopts immediately when compiled with >> -Xcomp because it hits an unresolved method call. This means that the >> method is now executing in the interpreter. >> >> When the method 'get' is executing in the interpreter, it uses the >> value of java.vm.name to determine whether the method would be server >> compiled if it were to be compiled. This ends up returning true on >> aarch64, because it is a server compiler. >> >> However in the case where we force it not to server compile by using >> -XX:+TieredCompilation and -XX:TieredStopAtLevel=1 (as in the >> TestStable tests) this will be incorrect. >> >> The solution is to introduce a simple (null) method 'get1' which will >> never be deopted (because there is never anything to patch) and uses >> this as the basis for deciding whether we are server compiling or not. >> >> This is more fully explained in the inline comment in the patch. >> >> Please review and if appropriate I will push. >> >> All the best, >> Ed. >> >> From vladimir.x.ivanov at oracle.com Tue Jun 2 17:16:55 2015 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Tue, 02 Jun 2015 20:16:55 +0300 Subject: [aarch64-port-dev ] RFR: 8081669: aarch64: JTreg TestStable tests failing In-Reply-To: <1433265102.1852.5.camel@mint> References: <1433237195.16770.13.camel@mylittlepony.linaroharston> <556DBAED.5030701@oracle.com> <556DDEEF.4060703@oracle.com> <1433265102.1852.5.camel@mint> Message-ID: <556DE507.2060403@oracle.com> Edward, Alexander, thanks for the clarifications! My bad, missed Cavium in the OCA list. Best regards, Vladimir Ivanov On 6/2/15 8:11 PM, Edward Nevill wrote: > Hi Vladimir, > > - Alexander is employed as a contractor by Cavium > - Cavium have signed the OCA > - Alexander is using his Cavium email address > > I have checked this with Dalibor Topic (on cc) and my understanding was > that this was sufficient to allow Alexander to contribute. > > All the best, > Ed. > > On Tue, 2015-06-02 at 19:50 +0300, Vladimir Ivanov wrote: >> The only concern I have is that I don't see Alexander on OCA list [1]. >> In order to proceed with the fix, he should sign OCA first. >> >> Best regards, >> Vladimir Ivanov >> >> [1] http://www.oracle.com/technetwork/community/oca-486395.html >> >> On 6/2/15 5:17 PM, Vladimir Ivanov wrote: >>> Looks good. >>> >>> Best regards, >>> Vladimir Ivanov >>> >>> On 6/2/15 12:26 PM, Edward Nevill wrote: >>>> Hi, >>>> >>>> The following webrev >>>> >>>> http://cr.openjdk.java.net/~enevill/8081669/webrev.00/ >>>> >>>> fixes a number of TestStable tests. >>>> >>>> This patch was contributed by alexander.alexeev at caviumnetworks.com >>>> >>>> The following are the test failures that are fixed by this patch >>>> >>>> compiler/stable/TestStableByte.java >>>> compiler/stable/TestStableBoolean.java >>>> compiler/stable/TestStableChar.java >>>> compiler/stable/TestStableFloat.java >>>> compiler/stable/TestStableObject.java >>>> compiler/stable/TestStableDouble.java >>>> compiler/stable/TestStableInt.java >>>> compiler/stable/TestStableLong.java >>>> compiler/stable/TestStableShort.java >>>> >>>> The problem is that the method 'get' in StableConfiguration is >>>> supposed to return true if the method is server compiled, false >>>> otherwise. >>>> >>>> On aarch64 it is always returning true, even when the method is client >>>> compiled. The reason for this is that aarch64 differs from other ports >>>> in that it always deopts on patching. >>>> >>>> This means that the method 'get' deopts immediately when compiled with >>>> -Xcomp because it hits an unresolved method call. This means that the >>>> method is now executing in the interpreter. >>>> >>>> When the method 'get' is executing in the interpreter, it uses the >>>> value of java.vm.name to determine whether the method would be server >>>> compiled if it were to be compiled. This ends up returning true on >>>> aarch64, because it is a server compiler. >>>> >>>> However in the case where we force it not to server compile by using >>>> -XX:+TieredCompilation and -XX:TieredStopAtLevel=1 (as in the >>>> TestStable tests) this will be incorrect. >>>> >>>> The solution is to introduce a simple (null) method 'get1' which will >>>> never be deopted (because there is never anything to patch) and uses >>>> this as the basis for deciding whether we are server compiling or not. >>>> >>>> This is more fully explained in the inline comment in the patch. >>>> >>>> Please review and if appropriate I will push. >>>> >>>> All the best, >>>> Ed. >>>> >>>> > > From Alexander.Alexeev at caviumnetworks.com Tue Jun 2 16:55:29 2015 From: Alexander.Alexeev at caviumnetworks.com (Alexeev, Alexander) Date: Tue, 2 Jun 2015 16:55:29 +0000 Subject: [aarch64-port-dev ] RFR: 8081669: aarch64: JTreg TestStable tests failing In-Reply-To: <556DDEEF.4060703@oracle.com> References: <1433237195.16770.13.camel@mylittlepony.linaroharston> <556DBAED.5030701@oracle.com> <556DDEEF.4060703@oracle.com> Message-ID: Vladimir, I am contributing on behalf of Cavium Inc. It actually exists in the list. Is it enough? Regards, Alexander -----Original Message----- From: aarch64-port-dev [mailto:aarch64-port-dev-bounces at openjdk.java.net] On Behalf Of Vladimir Ivanov Sent: Tuesday, June 2, 2015 7:51 PM To: edward.nevill at linaro.org; aarch64-port-dev at openjdk.java.net; hotspot-dev Source Developers Subject: Re: [aarch64-port-dev ] RFR: 8081669: aarch64: JTreg TestStable tests failing The only concern I have is that I don't see Alexander on OCA list [1]. In order to proceed with the fix, he should sign OCA first. Best regards, Vladimir Ivanov [1] http://www.oracle.com/technetwork/community/oca-486395.html On 6/2/15 5:17 PM, Vladimir Ivanov wrote: > Looks good. > > Best regards, > Vladimir Ivanov > > On 6/2/15 12:26 PM, Edward Nevill wrote: >> Hi, >> >> The following webrev >> >> http://cr.openjdk.java.net/~enevill/8081669/webrev.00/ >> >> fixes a number of TestStable tests. >> >> This patch was contributed by alexander.alexeev at caviumnetworks.com >> >> The following are the test failures that are fixed by this patch >> >> compiler/stable/TestStableByte.java >> compiler/stable/TestStableBoolean.java >> compiler/stable/TestStableChar.java >> compiler/stable/TestStableFloat.java >> compiler/stable/TestStableObject.java >> compiler/stable/TestStableDouble.java >> compiler/stable/TestStableInt.java >> compiler/stable/TestStableLong.java >> compiler/stable/TestStableShort.java >> >> The problem is that the method 'get' in StableConfiguration is >> supposed to return true if the method is server compiled, false >> otherwise. >> >> On aarch64 it is always returning true, even when the method is >> client compiled. The reason for this is that aarch64 differs from >> other ports in that it always deopts on patching. >> >> This means that the method 'get' deopts immediately when compiled >> with -Xcomp because it hits an unresolved method call. This means >> that the method is now executing in the interpreter. >> >> When the method 'get' is executing in the interpreter, it uses the >> value of java.vm.name to determine whether the method would be server >> compiled if it were to be compiled. This ends up returning true on >> aarch64, because it is a server compiler. >> >> However in the case where we force it not to server compile by using >> -XX:+TieredCompilation and -XX:TieredStopAtLevel=1 (as in the >> TestStable tests) this will be incorrect. >> >> The solution is to introduce a simple (null) method 'get1' which will >> never be deopted (because there is never anything to patch) and uses >> this as the basis for deciding whether we are server compiling or not. >> >> This is more fully explained in the inline comment in the patch. >> >> Please review and if appropriate I will push. >> >> All the best, >> Ed. >> >> From ivan.gerasimov at oracle.com Tue Jun 2 15:44:31 2015 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Tue, 02 Jun 2015 18:44:31 +0300 Subject: RFR: JDK-8075327: Merge jdk and hotspot test libraries In-Reply-To: <1a17632e-265f-4adb-864f-79cb9a1587ec@default> References: <1a17632e-265f-4adb-864f-79cb9a1587ec@default> Message-ID: <556DCF5F.7050601@oracle.com> Hi Alexander! Would you please include jdk/test/lib/testlibrary/jdk/testlibrary/OptimalCapacity.java in the webrev? This file was added recently with the fix for JDK-8081027 It's currently used from the following three tests, which will need to be updated too: jdk/test/java/lang/Character/UnicodeBlock/OptimalMapSize.java jdk/test/sun/invoke/anon/ConstantPoolPatch/OptimalMapSize.java jdk/test/sun/security/ssl/ExtensionType/OptimalListSize.java Sincerely yours, Ivan On 02.06.2015 14:18, Alexander Kulyakhtin wrote: > Hi, > > Could you, please, review the following test-only changes to the 'jdk', 'hotspot' and the common 'test' repository > > http://cr.openjdk.java.net/~akulyakh/8075327/wr_hs/webrev.01/index.html > http://cr.openjdk.java.net/~akulyakh/8075327/wr_jdk/webrev.01/index.html > http://cr.openjdk.java.net/~akulyakh/8075327/wr_test/webrev.01/ > > The changes are to move test library files common to both jdk and hotspot to the upper-level test repository. > > The following has been done: > 1) Common files (Asserts.java, OutputAnalyzer.java etc) from the jdk and hotspot repositories, have been merged and moved to the upper-level common test repository, to test/lib/share/classes. > 2) Package jdk.testlibrary in the jdk repository have been renamed to jdk.test.lib to have the same name as in the hotspot repository > 2) Upper level test/lib/share/classes library references have been added to the @library statements > 3) Some packages previously located at upper level test repo at /test/lib have been moved to /test/lib/share/classes for consistency > > Best regards, > Alexander > > From gerard.ziemski at oracle.com Tue Jun 2 20:09:15 2015 From: gerard.ziemski at oracle.com (Gerard Ziemski) Date: Tue, 02 Jun 2015 15:09:15 -0500 Subject: Revision2: Corrected: RFR 8059557 (XL): Validate JVM Command-Line Flag Arguments In-Reply-To: <556CD903.1080004@oracle.com> References: <5554FE2D.6020405@oracle.com> <555E0028.8070108@oracle.com> <55663700.5050606@oracle.com> <556CD903.1080004@oracle.com> Message-ID: <556E0D6B.7030909@oracle.com> Thank you Derek very much for your feedback. Please see my answers inline: > Subject: Re: Revision2: Corrected: RFR 8059557 (XL): Validate JVM Command-Line Flag Arguments > Date: Mon, 01 Jun 2015 18:13:23 -0400 > From: Derek White > Organization: Oracle > To: hotspot-dev at openjdk.java.net > > Hi Gerard, > > Still going over arguments.cpp and globals.hpp... > > Here are a few issues found so far: > > ---------------------------------------- > g1_globals.hpp: > ---------------------------------------- > - G1ConcMarkStepDurationMillis: The range is declared as range(1.0, > (double)max_uintx). But max_uintx has nothing to do with max double. It > may not even be precisely representable as a double. > The original code just specified min=1.0 and did not cap it, so I had to provide some valid value. I decided against using FLT_MAX, because I would need ?#include ? just for that instance (also I am not 100% sure it?s available on all platforms). The max does not need to be mathematically ideal value, so long as it makes sense and "(double)max_uintx? is a good value, even if it might not be represented exactly. > - G1NewSizePercent: The constraint is checks that that its is <= > G1MaxNewSizePercent, but not that it's >= 0. I assume that the uintx > type is checking that? That is correct. > ---------------------------------------- > arguments.cpp: > ---------------------------------------- > - Line 1405 - where did this come from? > if (SurvivorAlignmentInBytes == 0) { > SurvivorAlignmentInBytes = ObjectAlignmentInBytes; > } It came from the old "verify_object_alignment()? which I re-implemented as constraints and moved the setter code in question to ?set_object_alignment()?, which seems a much more ideal solution. > ---------------------------------------- > globals.hpp: > ---------------------------------------- > - The variables StringTableSize and SymbolTableSize used to have ranges > - minimumStringTableSize..(max_uintx / StringTable::bucket_size() > - minimumSymbolTableSize..(max_uintx / SymbolTable::bucket_size() > Now they are: > - range(minimumStringTableSize, 111*defaultStringTableSize) > - range(minimumSymbolTableSize, 111*defaultSymbolTableSize) > This is OK? I didn't have a chance to calculate these myself. The max value must be some ?sane? value that actually works - the main point of this exercise is to only allow values that are guaranteed not to crash the VM. The previous max values might be mathematically correct, but they will crash the VM, so we need smaller values. Based on my previous experience with table sizes (ie. dynamically resizing the system hashtables) where I was privileged to be able to run several different performance benchmarks (with the help from the performance team) with different table sizes, I can say with confidence that size even an order of magnitude larger than the default is really big. I have allowed for 2 order?s of magnitude (ie. 111), which should be more than satisfactory and works. > - MinMetaspaceFreeRatio: used to have range 0..99, now it has range > 0..100 and constraint <= MaxMetaspaceFreeRatio. > - Not sure how important. > - Actually the GC, runtime, and compiler groups should check all of > their "percent" variables to see if having tighter ranges makes sense. Oh yes, it should be 0..99 Fixed. > Line 2036, 2041: > - Set status to false instead of returning directly? I?m sorry, which file do those lines refer to? > Line 2827 (existing); Change "K" -> "1*K" for consistency. Line 2827 in gobals.hpp or is it a different file? > ---------------------------------------- > commandLineFlagConstraintList.hpp > ---------------------------------------- > - Initialize CommandLineFlagConstraintList._constraints in constructor > to avoid dealing with NULL case? Currently all the APIs are static. If I wanted to use the constructor, then I would need to create an instance of the object to use the APIs and some singleton API to retrieve the instance, which I am not sure that it would be worth it. The current NULL checks are pretty simple as is the class itself. > - Shouldn't the default implementations for > CommandLineFlagConstraint::apply_XXX() return failure, not success? I looked at it from the point of view of the more likely scenario, which is assume success, unless a fault detected. If we did do this, though, then instead of: Flag::Error MinHeapFreeRatioConstraintFunc(bool verbose, uintx* value) { if ((CommandLineFlags::finishedInitializing()) && (*value > MaxHeapFreeRatio)) { if (verbose == true) { jio_fprintf(defaultStream::error_stream(), "MinHeapFreeRatio (" UINTX_FORMAT ") must be less than or " "equal to MaxHeapFreeRatio (" UINTX_FORMAT ")\n", *value, MaxHeapFreeRatio); } return Flag::VIOLATES_CONSTRAINT; } else { return Flag::SUCCESS; } } we?d have: Flag::Error MinHeapFreeRatioConstraintFunc(bool verbose, uintx* value) { Flag::Error error = Flag::VIOLATES_CONSTRAINT; if ((CommandLineFlags::finishedInitializing()) && (*value > MaxHeapFreeRatio)) { if (verbose == true) { jio_fprintf(defaultStream::error_stream(), "MinHeapFreeRatio (" UINTX_FORMAT ") must be less than or " "equal to MaxHeapFreeRatio (" UINTX_FORMAT ")\n", *value, MaxHeapFreeRatio); } } else { error = Flag::SUCCESS; } return error; } which is not as nice, in my opinion. > ---------------------------------------- > commandLineFlagConstraintsGC.cpp > ---------------------------------------- > Is this necessary?: > 37 #include "c1/c1_globals.hpp" > 40 #include "opto/c2_globals.hpp? Fixed. > BAD TYPO: > - CMSOldPLABMaxConstraintFunc() is comparing against itself, not > CMSOldPLABMin. > Fixed. Thank you and I will be posting a new webrev shortly. cheers From kim.barrett at oracle.com Tue Jun 2 22:52:40 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 2 Jun 2015 18:52:40 -0400 Subject: Revision2: Corrected: RFR 8059557 (XL): Validate JVM Command-Line Flag Arguments In-Reply-To: <55663700.5050606@oracle.com> References: <5554FE2D.6020405@oracle.com> <555E0028.8070108@oracle.com> <55663700.5050606@oracle.com> Message-ID: <7A921A5A-AB1A-4462-8C15-7F4010B5590C@oracle.com> On May 27, 2015, at 5:28 PM, Gerard Ziemski wrote: > > hi all, > > Here is a revision 2 of the feature taking into account feedback from Dmitry, David, Kim and Alexander. > ... > > References: > > Webrev: http://cr.openjdk.java.net/~gziemski/8059557_rev2 > note: due to "awk" limit of 50 pats the Frames diff is not available for "src/share/vm/runtime/arguments.cpp? Here's another collection of comments. I haven't looked at the actual ranges and constraints yet. I might leave off that, since others seem to be looking there. Let me know if you think another set of eyes is needed there. ------------------------------------------------------------------------------ src/share/vm/runtime/globals.cpp 1067 //#define PRINT_FLAGS_SORTED_BY_TYPE_THEN_NAMES and following The PRINT_FLAGS_SORTED_BYTE_TYPE_THEN_NAMES is never defined, so the associated #else clause is (presently) dead code. If it were live code then I'd have several complaints about it. But since it appears to be dead, I'll limit my complaint to it existing at all. ------------------------------------------------------------------------------ src/share/vm/runtime/commandLineFlagRangeList.cpp There is a large amount of code near-duplication among the various CommandLineFlagRange_ classes. I think this could be substantially reduced via some fairly straightforward usage of macros and templates. This can be dealt with in a follow-on cleanup - please file a CR. Probably similarly for the constraint classes. ------------------------------------------------------------------------------ src/share/vm/runtime/commandLineFlagConstraintList.cpp src/share/vm/runtime/commandLineFlagRangeList.cpp The macros EMIT_CONSTRAINT_COMMERCIAL_FLAG and EMIT_RANGE_COMMERCIAL_FLAG are defined in these files. This is parhaps the wrong place for them, since they are unused in open code. If moving the commercial flag handlers, it might be desirable to define a helper macro for use by all the EMIT_RANGE_xxx_FLAG (and similarly for EMIT_COMMERCIAL_xxx_FLAG). ------------------------------------------------------------------------------ src/share/vm/runtime/commandLineFlagConstraintList.cpp src/share/vm/runtime/commandLineFlagRangeList.cpp The classes CommandLineFlag{Constraint,Range}List are derived from CHeapObj, but appear to never be allocated, and only have static members. I think they should instead be derived from AllStatic. ------------------------------------------------------------------------------ src/share/vm/runtime/commandLineFlagRangeList.cpp The various emit_range_xxx functions are defined with global scope. I *think* they should be defined at file scope. Similarly for the constraint list functions. ------------------------------------------------------------------------------ src/share/vm/runtime/commandLineFlagRangeList.cpp src/share/vm/runtime/commandLineFlagRangeList.cpp These files directly include runtime/os_ext.hpp, but that file is not intended to be directly included, but must be included from the *middle* of runtime/os.hpp. I think the only reason this include isn't blowing up is that there is some earlier include of runtime/os.hpp, so that the direct include of os_ext.hpp is suppressed by its include guard. It's not obvious what earlier file might be providing that include of os.hpp, and I wonder if perhaps it's coming from the precompiled headers. Which reminds me, has this changeset been tested without precompiled headers? That include of os_ext.hpp is to obtain the definitions of the macros EMIT_{CONSTRAINTS,RANGES}_FOR_GLOBALS_EXT. I think those macro definitions probably ought to be moved to a different place, though I don't have a suggested landing place. ------------------------------------------------------------------------------ src/share/vm/services/writeableFlags.cpp 34 #define TEMP_BUF_SIZE 256 ... 61 static void print_flag_error_message_if_needed(Flag::Error error, const char* name, FormatBuffer<80>& err_msg) { The ultimate destination of the error message is err_msg, which is explicitly limited to 80 characters. It seems kind of pointless to make TEMP_BUF_SIZE larger than the err_msg size. ------------------------------------------------------------------------------ src/share/vm/runtime/globals.cpp In the various CommandLineFlags::AtPut(const char* name, ...) functions, the call to the associated apply_constraint_and_check_range_ helper function uses (CommandLineFlags::finishedInitializing() == false) to compute the verbose argument in that helper function call. Better would be simply !CommandLineFlags::finishedInitializing() ------------------------------------------------------------------------------ src/share/vm/runtime/commandLineFlagRangeList.hpp 42 public: 43 const char* _name; _name should be private. Any external accesses should be via the existing public name() member function. Similarly for CommandLineFlagConstraint. ------------------------------------------------------------------------------ src/share/vm/runtime/commandLineFlagRangeList.hpp 44 CommandLineFlagRange(const char* name) { _name=name; } This will result in a dangling pointer if the name argument can be deallocated. I suspect the intent is that this is only called with a string literal, and that all callers do so, but that's hard to ensure. Similarly for CommandLineFlagConstraint. I'm not sure there's anything to do here, other than audit and add comments. ------------------------------------------------------------------------------ src/share/vm/runtime/commandLineFlagRangeList.hpp 47 virtual Flag::Error check_intx(intx value, bool verbose = true) { return Flag::SUCCESS; } ... and other similar functions ... ... and similar functions in CommandLineFlagConstraint ... I'm dubious about default implementations returning success. I think the default should be a failure indication, possibly even with ShouldNotReachHere(), since it indicates an attempt to apply a constraint for the wrong type of value. If the constraint were being applied to the correct type of value, the default implementation would be overridden by the derived class of the constraint object. Similarly for CommandLineFlagConstraint. ------------------------------------------------------------------------------ If I'm understanding correctly, there should now never be a call to FLAG_SET_{CMDLINE,DEFAULT,ERGO,other?} that doesn't have its result checked. But most (by a substantial majority) appear to be unchecked. I'm guessing that's a followup task? I don't see any mention of FLAG_SET_xxx checking in the review summary; it's a different task from determining appropriate ranges for flags that haven't had that done yet. ------------------------------------------------------------------------------ src/share/vm/runtime/globals.cpp 331 if (printRanges == false) { I'd prefer "if (!printRanges) {". Similarly for 380 } else if ((is_bool() == false) && (is_ccstr() == false)) { 381 381 if (printRanges == true) { Searching for " == true" and " == false" will probably find more. ------------------------------------------------------------------------------ From david.holmes at oracle.com Wed Jun 3 08:01:46 2015 From: david.holmes at oracle.com (David Holmes) Date: Wed, 03 Jun 2015 18:01:46 +1000 Subject: RFR: 8080947: Add uint as a valid VM flag type In-Reply-To: <5566FBF4.1060401@oracle.com> References: <5566FBF4.1060401@oracle.com> Message-ID: <556EB46A.1030408@oracle.com> Hi David, On 28/05/2015 9:28 PM, David Lindholm wrote: > Hi, > > Please review this patch that adds uint and int as valid VM flag types. > This patch adds the possibility to specify VM flags with types int and > uint, it does not change the type of any flags. > > > Webrev: http://cr.openjdk.java.net/~david/JDK-8080947/webrev.hotspot.00/ > Webrev: http://cr.openjdk.java.net/~david/JDK-8080947/webrev.jdk.00/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8080947 src/share/vm/services/management.cpp + } else if (flag->is_int()) { + global->value.j = (jlong)flag->get_int(); + global->type = JMM_VMGLOBAL_TYPE_JLONG; + } else if (flag->is_uint()) { + global->value.j = (jlong)flag->get_uint(); + global->type = JMM_VMGLOBAL_TYPE_JLONG; These should be JINT types not JLONG. Cheers, David H. ------- > > Testing: Passed JPRT > > > Thanks, > David From edward.nevill at linaro.org Wed Jun 3 08:51:47 2015 From: edward.nevill at linaro.org (Edward Nevill) Date: Wed, 03 Jun 2015 09:51:47 +0100 Subject: RFR: 8081790: SHA tests fail Message-ID: <1433321507.32688.13.camel@mylittlepony.linaroharston> Hi, The following webrev http://cr.openjdk.java.net/~enevill/8081790/webrev.00/ fixes a number of SHA test failures on aarch64. This patch was contributed by alexander.alexeev at caviumnetworks.com Currently the following JTReg/hotspot SHA tests fail on aarch64 FAILED: compiler/intrinsics/sha/cli/TestUseSHA1IntrinsicsOptionOnUnsupportedCPU.java FAILED: compiler/intrinsics/sha/cli/TestUseSHA256IntrinsicsOptionOnUnsupportedCPU.java FAILED: compiler/intrinsics/sha/cli/TestUseSHAOptionOnUnsupportedCPU.java (ie FAILED: compiler/intrinsics/sha/sanity/TestSHA1Intrinsics.java FAILED: compiler/intrinsics/sha/sanity/TestSHA1MultiBlockIntrinsics.java FAILED: compiler/intrinsics/sha/sanity/TestSHA256MultiBlockIntrinsics.java FAILED: compiler/intrinsics/sha/sanity/TestSHA256Intrinsics.java The reason for the test failures is that the test suite is configured on the assumption that Sparc is the only arch which support SHA in hw (and therefore supports the -XX:+UseSHA options). The webrev adds tests for aarch64. The following files have also been renamed as they were inappropriately named. R test/compiler/intrinsics/sha/cli/testcases/GenericTestCaseForSupportedSparcCPU.java R test/compiler/intrinsics/sha/cli/testcases/UseSHAIntrinsicsSpecificTestCaseForUnsupportedSparcCPU.java R test/compiler/intrinsics/sha/cli/testcases/UseSHASpecificTestCaseForSupportedSparcCPU.java R test/compiler/intrinsics/sha/cli/testcases/UseSHASpecificTestCaseForUnsupportedSparcCPU.java These now become A test/compiler/intrinsics/sha/cli/testcases/GenericTestCaseForSupportedCPU.java A test/compiler/intrinsics/sha/cli/testcases/UseSHAIntrinsicsSpecificTestCaseForUnsupportedCPU.java A test/compiler/intrinsics/sha/cli/testcases/UseSHASpecificTestCaseForSupportedCPU.java A test/compiler/intrinsics/sha/cli/testcases/UseSHASpecificTestCaseForUnsupportedCPU.java (ie. the 'Sparc' has been dropped from the filename as Sparc is no longer the only arch which supports SHA). Tested with JTReg/hotspot Before: Test results: passed: 840; failed: 10; error: 5 After: Test results: passed: 847; failed: 3; error: 5 Please review, Thanks, Ed. From david.lindholm at oracle.com Wed Jun 3 08:51:01 2015 From: david.lindholm at oracle.com (David Lindholm) Date: Wed, 03 Jun 2015 10:51:01 +0200 Subject: RFR: 8080947: Add uint as a valid VM flag type In-Reply-To: <556EB46A.1030408@oracle.com> References: <5566FBF4.1060401@oracle.com> <556EB46A.1030408@oracle.com> Message-ID: <556EBFF5.8070205@oracle.com> Hi David, Thanks for looking at this. I have a few places where I convert uint and int to Java types, besides management.cpp also whitebox.cpp/java and VM.java . After discussing with several people we though it was most correct to go with JLONG as java type for both int and uint, since it is not certain that an uint will fit in a JINT and I wanted the same java type for both int and uint. I don't think the C spec specifies the size of int (please correct me if I'm wrong), so having JLONG as type for int and uint is safer than JINT. But I can change to JINT if you think that is better. Thanks, David On 2015-06-03 10:01, David Holmes wrote: > Hi David, > > On 28/05/2015 9:28 PM, David Lindholm wrote: >> Hi, >> >> Please review this patch that adds uint and int as valid VM flag types. >> This patch adds the possibility to specify VM flags with types int and >> uint, it does not change the type of any flags. >> >> >> Webrev: http://cr.openjdk.java.net/~david/JDK-8080947/webrev.hotspot.00/ >> Webrev: http://cr.openjdk.java.net/~david/JDK-8080947/webrev.jdk.00/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8080947 > > src/share/vm/services/management.cpp > > + } else if (flag->is_int()) { > + global->value.j = (jlong)flag->get_int(); > + global->type = JMM_VMGLOBAL_TYPE_JLONG; > + } else if (flag->is_uint()) { > + global->value.j = (jlong)flag->get_uint(); > + global->type = JMM_VMGLOBAL_TYPE_JLONG; > > These should be JINT types not JLONG. > > Cheers, > David H. > ------- > >> >> Testing: Passed JPRT >> >> >> Thanks, >> David From stefan.sarne at oracle.com Wed Jun 3 09:04:25 2015 From: stefan.sarne at oracle.com (=?UTF-8?B?U3RlZmFuIFPDpHJuZQ==?=) Date: Wed, 03 Jun 2015 11:04:25 +0200 Subject: RFR: JDK-8075327: Merge jdk and hotspot test libraries In-Reply-To: <1a17632e-265f-4adb-864f-79cb9a1587ec@default> References: <1a17632e-265f-4adb-864f-79cb9a1587ec@default> Message-ID: <556EC319.3020300@oracle.com> Hi Alexander, I think we want to group the utilities into packages directly. One reason for grouping is to support discovery, to clarify what belongs together. For example both the OutputAnalyzer and the StreamPumper belong together in a processtools package, while Asserts doesn't. Another reason is to simplify imports and reduce the impact of wild card includes, since for example an import of process tools should not have to bother with declaring usage of sun.misc.Unsafe in the modules world, just because Utils happen to be in the same package. Here are some examples - also available in the jira case: Package jdk.test.lib.processtools is the package for utilities for launching processes and analyzing the output. /test/lib/share/classes/jdk/test/lib/processtools/OutputAnalyzer.java /test/lib/share/classes/jdk/test/lib/processtools/OutputBuffer.java /test/lib/share/classes/jdk/test/lib/processtools/ProcessTools.java /test/lib/share/classes/jdk/test/lib/processtools/StreamPumper.java /test/lib/share/classes/jdk/test/lib/processtools/JDKToolFinder.java /test/lib/share/classes/jdk/test/lib/processtools/JDKToolLauncher.java /test/lib-test/jdk/test/lib/processtools/OutputAnalyzerTest.java Asserts can stay at top level. /test/lib/share/classes/jdk/test/lib/Asserts.java /test/lib-test/jdk/test/lib/AssertsTest.java For VM specific info, it would have vm package. Note that the whitebox API moves here. /test/lib/share/classes/jdk/test/lib/vm/InputArguments.java /test/lib/share/classes/jdk/test/lib/vm/Platform.java Ok, so then there are the stuff which just is a bucket of stuff and fluff. A later exercise could be to break this class into better named and placed classes, but this is a start: /test/lib/share/classes/jdk/test/lib/misc/Utils.java Thanks, Stefan Alexander Kulyakhtin skrev den 2015-06-02 13:18: > Hi, > > Could you, please, review the following test-only changes to the 'jdk', 'hotspot' and the common 'test' repository > > http://cr.openjdk.java.net/~akulyakh/8075327/wr_hs/webrev.01/index.html > http://cr.openjdk.java.net/~akulyakh/8075327/wr_jdk/webrev.01/index.html > http://cr.openjdk.java.net/~akulyakh/8075327/wr_test/webrev.01/ > > The changes are to move test library files common to both jdk and hotspot to the upper-level test repository. > > The following has been done: > 1) Common files (Asserts.java, OutputAnalyzer.java etc) from the jdk and hotspot repositories, have been merged and moved to the upper-level common test repository, to test/lib/share/classes. > 2) Package jdk.testlibrary in the jdk repository have been renamed to jdk.test.lib to have the same name as in the hotspot repository > 2) Upper level test/lib/share/classes library references have been added to the @library statements > 3) Some packages previously located at upper level test repo at /test/lib have been moved to /test/lib/share/classes for consistency > > Best regards, > Alexander From david.holmes at oracle.com Wed Jun 3 09:43:36 2015 From: david.holmes at oracle.com (David Holmes) Date: Wed, 03 Jun 2015 19:43:36 +1000 Subject: RFR: 8080947: Add uint as a valid VM flag type In-Reply-To: <556EBFF5.8070205@oracle.com> References: <5566FBF4.1060401@oracle.com> <556EB46A.1030408@oracle.com> <556EBFF5.8070205@oracle.com> Message-ID: <556ECC48.7080400@oracle.com> Hi David, On 3/06/2015 6:51 PM, David Lindholm wrote: > Hi David, > > Thanks for looking at this. I have a few places where I convert uint and > int to Java types, besides management.cpp also whitebox.cpp/java and > VM.java . After discussing with several people we though it was most > correct to go with JLONG as java type for both int and uint, since it is > not certain that an uint will fit in a JINT and I wanted the same java > type for both int and uint. > > I don't think the C spec specifies the size of int (please correct me if > I'm wrong), so having JLONG as type for int and uint is safer than JINT. ILP32 programming model defines 32-bit int, long and pointer. LP64 programming model defines 64-bit long and 64-bit pointer, and so 32-bit int. We already assume/require that an int is equivalent of a jint ./cpu/x86/vm/jni_x86.h: typedef int jint; and the same for the other platforms. So int, uint, jint are all 32-bit. However if you set a uint into a Java int you won't be able to read positive values >= 0x80000000, so using a jlong is necessary for that reason. Sorry for the noise. Cheers, David H. > But I can change to JINT if you think that is better. > > > Thanks, > David > > On 2015-06-03 10:01, David Holmes wrote: >> Hi David, >> >> On 28/05/2015 9:28 PM, David Lindholm wrote: >>> Hi, >>> >>> Please review this patch that adds uint and int as valid VM flag types. >>> This patch adds the possibility to specify VM flags with types int and >>> uint, it does not change the type of any flags. >>> >>> >>> Webrev: http://cr.openjdk.java.net/~david/JDK-8080947/webrev.hotspot.00/ >>> Webrev: http://cr.openjdk.java.net/~david/JDK-8080947/webrev.jdk.00/ >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8080947 >> >> src/share/vm/services/management.cpp >> >> + } else if (flag->is_int()) { >> + global->value.j = (jlong)flag->get_int(); >> + global->type = JMM_VMGLOBAL_TYPE_JLONG; >> + } else if (flag->is_uint()) { >> + global->value.j = (jlong)flag->get_uint(); >> + global->type = JMM_VMGLOBAL_TYPE_JLONG; >> >> These should be JINT types not JLONG. >> >> Cheers, >> David H. >> ------- >> >>> >>> Testing: Passed JPRT >>> >>> >>> Thanks, >>> David > From aph at redhat.com Wed Jun 3 09:53:09 2015 From: aph at redhat.com (Andrew Haley) Date: Wed, 03 Jun 2015 10:53:09 +0100 Subject: Defensive programming / intrinsics Message-ID: <556ECE85.1070702@redhat.com> Does a HotSpot intrinsic need to check the validity of all its args, particularly array lengths? I'm thinking of an intrinsic only called by trusted code. It is important because this is the inner loop of a crypto operation, and is highly speed-critical. Thanks, Andrew. From alexander.kulyakhtin at oracle.com Wed Jun 3 12:33:22 2015 From: alexander.kulyakhtin at oracle.com (Alexander Kulyakhtin) Date: Wed, 3 Jun 2015 05:33:22 -0700 (PDT) Subject: RFR: JDK-8075327: Merge jdk and hotspot test libraries Message-ID: Hi Stefan, Thank you very much for the review. I'll update the patch accordingly, shortly. Best regards, Alexander ----- Original Message ----- From: stefan.sarne at oracle.com To: alexander.kulyakhtin at oracle.com, jdk9-dev at openjdk.java.net, hotspot-dev at openjdk.java.net Cc: yekaterina.kantserova at oracle.com Sent: Wednesday, June 3, 2015 12:08:33 PM GMT +03:00 Iraq Subject: Re: RFR: JDK-8075327: Merge jdk and hotspot test libraries Hi Alexander, I think we want to group the utilities into packages directly. One reason for grouping is to support discovery, to clarify what belongs together. For example both the OutputAnalyzer and the StreamPumper belong together in a processtools package, while Asserts doesn't. Another reason is to simplify imports and reduce the impact of wild card includes, since for example an import of process tools should not have to bother with declaring usage of sun.misc.Unsafe in the modules world, just because Utils happen to be in the same package. Here are some examples - also available in the jira case: Package jdk.test.lib.processtools is the package for utilities for launching processes and analyzing the output. /test/lib/share/classes/jdk/test/lib/processtools/OutputAnalyzer.java /test/lib/share/classes/jdk/test/lib/processtools/OutputBuffer.java /test/lib/share/classes/jdk/test/lib/processtools/ProcessTools.java /test/lib/share/classes/jdk/test/lib/processtools/StreamPumper.java /test/lib/share/classes/jdk/test/lib/processtools/JDKToolFinder.java /test/lib/share/classes/jdk/test/lib/processtools/JDKToolLauncher.java /test/lib-test/jdk/test/lib/processtools/OutputAnalyzerTest.java Asserts can stay at top level. /test/lib/share/classes/jdk/test/lib/Asserts.java /test/lib-test/jdk/test/lib/AssertsTest.java For VM specific info, it would have vm package. Note that the whitebox API moves here. /test/lib/share/classes/jdk/test/lib/vm/InputArguments.java /test/lib/share/classes/jdk/test/lib/vm/Platform.java Ok, so then there are the stuff which just is a bucket of stuff and fluff. A later exercise could be to break this class into better named and placed classes, but this is a start: /test/lib/share/classes/jdk/test/lib/misc/Utils.java Thanks, Stefan Alexander Kulyakhtin skrev den 2015-06-02 13:18: Hi, Could you, please, review the following test-only changes to the 'jdk', 'hotspot' and the common 'test' repository http://cr.openjdk.java.net/~akulyakh/8075327/wr_hs/webrev.01/index.html http://cr.openjdk.java.net/~akulyakh/8075327/wr_jdk/webrev.01/index.html http://cr.openjdk.java.net/~akulyakh/8075327/wr_test/webrev.01/ The changes are to move test library files common to both jdk and hotspot to the upper-level test repository. The following has been done: 1) Common files (Asserts.java, OutputAnalyzer.java etc) from the jdk and hotspot repositories, have been merged and moved to the upper-level common test repository, to test/lib/share/classes. 2) Package jdk.testlibrary in the jdk repository have been renamed to jdk.test.lib to have the same name as in the hotspot repository 2) Upper level test/lib/share/classes library references have been added to the @library statements 3) Some packages previously located at upper level test repo at /test/lib have been moved to /test/lib/share/classes for consistency Best regards, Alexander From dmitry.dmitriev at oracle.com Wed Jun 3 13:47:05 2015 From: dmitry.dmitriev at oracle.com (Dmitry Dmitriev) Date: Wed, 03 Jun 2015 16:47:05 +0300 Subject: RFR 8059557: Test set for "Validate JVM Command-Line Flag Arguments" In-Reply-To: <556D3597.8090508@oracle.com> References: <555A09B8.7010402@oracle.com> <555E46A7.4020402@oracle.com> <55671906.10000@oracle.com> <556D3597.8090508@oracle.com> Message-ID: <556F0559.3080601@oracle.com> Hello David, Thank you for pointing on style/grammar mistakes! I corrected all of them. Here a link to the updated webrev:http://cr.openjdk.java.net/~ddmitriev/8059557/webrev.04/ About "options validation" package - I agree that this looks odd, but if you don't mind I prefer to leave it. It slightly simplify calling static methods by using static import and also I use package-private access level. Regards, Dmitry On 02.06.2015 7:48, David Holmes wrote: > Hi Dmitry, > > On 28/05/2015 11:32 PM, Dmitry Dmitriev wrote: >> Hello all, >> >> Here is a 3 version of the tests taking into account feedback from >> Christian, David and Gerard. >> >> I limit number of options in TestOptionsWithRanges.java to 15. This >> include options of different types(intx, uintx etc.) and with different >> combination of min/max range. TestOptionsWithRangesDynamic.java leaved >> as is, because amount of manageable numeric options is very small and >> currently only 3 of them have range. Also, I improve code for double >> option. >> >> Webrev: http://cr.openjdk.java.net/~ddmitriev/8059557/webrev.03/ >> > > Only a few style/grammar nits (the downside of writing so many doc > comments :) ). > > Meta-question: is there a specific reason to use the package "options > validation"? It looks odd to me to have > OptionsValidation/common/optionsvalidation/ in the paths. > > General doc-comment comments: > - @param/@return descriptions should start with lower-case (you > currently mix-n-match) > - @throws description should start with "if", so: > @throws IOException if an error occurred reading the data > > > General Java-style comments: > - access modifiers (public, private, protected) always come first > > --- > > test/runtime/CommandLine/OptionsValidation/common/optionsvalidation/IntJVMOption.java > > > 265 * passed value is negative then error will be > catched earlier for > > catched -> caught > > --- > > test/runtime/CommandLine/OptionsValidation/common/optionsvalidation/JVMOption.java > > > 327 * @param param Tested parameter passed to the java > > "the java" is not a noun - suggest "the JVM" ? > > Maybe change Java to JVM to avoid use of "java" as a noun everywhere. > > 350 failedMessage(name, fullOptionString, valid, "JVM > output reports about fatal error. JVM exit with code " + returnCode + > "!"); > > The message isn't grammatically correct: about -> a; exit -> exited > > Similarly "JVM exit" -> "JVM exited" > > 377 failedMessage(name, fullOptionString, valid, "JVM > output not contains " > > not contains -> does not contain > > 400 * Return list of strings which contain options with valid > values which used > > which used -> which can be used > > 416 * Return list of strings which contain options with invalid > values which > 417 * used for testing on command line > > Ditto > > --- > > test/runtime/CommandLine/OptionsValidation/common/optionsvalidation/JVMOptionsUtils.java > > > 101 * Add dependency for option depending on it's type. E.g. ran > java in > > ran java -> run the JVM > > 119 * @param withRanges true if needed options with defined ranges > > I'm not sure what this means. Occurs elswhere too. > > 121 * "product", "diagnostic" etc. Accept option only if > acceptOrigin return > > return -> returns (or even return -> evaluates). Occurs elsewhere too. > > 260 * methods. Tested only writeable options. > > Suggestion: Only tests writeable options. Occurs elsewhere too. > > 264 * @throws Exception > > When? Why? Occurs elsewhere too. > > Thanks, > David > ----- > >> Thanks, >> Dmitry >> >> >> On 21.05.2015 23:57, Dmitry Dmitriev wrote: >>> Hello all, >>> >>> Recently I correct several typos, so here a new webrev for tests: >>> http://cr.openjdk.java.net/~ddmitriev/8059557/webrev.02/ >>> >>> >>> Thanks, >>> Dmitry >>> >>> On 18.05.2015 18:48, Dmitry Dmitriev wrote: >>>> Hello all, >>>> >>>> Please review test set for verifying functionality implemented by JEP >>>> 245 "Validate JVM Command-Line Flag Arguments"(JDK-8059557). Review >>>> request for this JEP can be found there: >>>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-May/018539.html >>>> >>>> >>>> I create 3 tests for verifying options with ranges. The tests mostly >>>> rely on common/optionsvalidation/JVMOptionsUtils.java. Class in this >>>> file contains functions to get options with ranges as list(by parsing >>>> new option "-XX:+PrintFlagsRanges" output), run command line test for >>>> list of options and other. The actual test code contained in >>>> common/optionsvalidation/JVMOption.java file - testCommandLine(), >>>> testDynamic(), testJcmd() and testAttach() methods. >>>> common/optionsvalidation/IntJVMOption.java and >>>> common/optionsvalidation/DoubleJVMOption.java source files contain >>>> classes derived from JVMOption class for integer and double JVM >>>> options correspondingly. >>>> >>>> Here are description of the tests: >>>> 1) >>>> hotspot/test/runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java >>>> >>>> >>>> >>>> This test get all options with ranges by parsing output of new option >>>> "-XX:+PrintFlagsRanges" and verify these options by starting Java and >>>> passing options in command line with valid and invalid values. >>>> Currently it verifies about 106 options which have ranges. >>>> Invalid values are values which out-of-range. In test used values >>>> "min-1" and "max+1".In this case Java should always exit with code 1 >>>> and print error message about out-of-range value(with one exception, >>>> if option is unsigned and passing negative value, then out-of-range >>>> error message is not printed because error occurred earlier). >>>> Valid values are values in range, e.g. min&max and also several >>>> additional values. In this case Java should successfully exit(exit >>>> code 0) or exit with error code 1 for other reasons(low memory with >>>> certain option value etc.). In any case for values in range Java >>>> should not print messages about out of range value. >>>> In any case Java should not crash. >>>> This test excluded from JPRT because it takes long time to execute >>>> and also fails - some options with value in valid range cause Java to >>>> crash(bugs are submitted). >>>> >>>> 2) >>>> hotspot/test/runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java >>>> >>>> >>>> >>>> This test get all writeable options with ranges by parsing output of >>>> new option "-XX:+PrintFlagsRanges" and verify these options by >>>> dynamically changing it's values to the valid and invalid values. >>>> Used 3 methods for that: DynamicVMOption isValidValue and >>>> isInvalidValue methods, Jcmd and by attach method. Currently 3 >>>> writeable options with ranges are verified by this test. >>>> This test pass in JPRT. >>>> >>>> 3) >>>> hotspot/test/runtime/CommandLine/OptionsValidation/TestJcmdOutput.java >>>> >>>> This test verified output of Jcmd when out-of-range value is set to >>>> the writeable option or value violates option constraint. Also this >>>> test verify that jcmd not write error message to the target process. >>>> This test pass in JPRT. >>>> >>>> >>>> I am not write special tests for constraints for this JEP because >>>> there are exist test for that(e.g. >>>> test/runtime/CompressedOops/ObjectAlignment.java for >>>> ObjectAlignmentInBytes or >>>> hotspot/test/gc/arguments/TestHeapFreeRatio.java for >>>> MinHeapFreeRatio/MaxHeapFreeRatio). >>>> >>>> Webrev: http://cr.openjdk.java.net/~ddmitriev/8059557/webrev.00/ >>>> >>>> >>>> JEP: https://bugs.openjdk.java.net/browse/JDK-8059557 >>>> >>>> Thanks, >>>> Dmitry >>>> >>> >> From mikael.vidstedt at oracle.com Wed Jun 3 14:28:08 2015 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Wed, 03 Jun 2015 07:28:08 -0700 Subject: Experiment: Merging hs-rt and hs-gc In-Reply-To: <5568A27C.9020205@oracle.com> References: <5568A27C.9020205@oracle.com> Message-ID: <556F0EF8.8020608@oracle.com> Given that the feedback on this has been positive we're going to move ahead with this experiment. The plan is to do a final integration from jdk9/hs-gc up to jdk9/hs *tomorrow* and then lock down hs-gc. More detailed information will be sent out in separate emails. If you have feedback on how the experiment is working out please let us know! Cheers, Mikael On 2015-05-29 10:31, Mikael Vidstedt wrote: > > All, > > As you all know the JDK 9 development of Hotspot is done in three > different mercurial forests: hs-rt[1], hs-gc[2] and hs-comp[3]. This > division has served as a way of isolating changes from each other in > order to get more testing done on them before they are shared to other > forests. However, as a side effect of this the propagation time of > fixes is also impacted, and in some cases we have seen fixes stuck for > several weeks waiting for the respective forests to stabilize. > > We would like to propose an experiment, which will merge the hs-rt and > hs-gc forests, having hs-rt be the forest through which all the hs-rt > and hs-gc changes are integrated. For the duration of the experiment > the hs-gc forest will be locked down so that no accidental > integrations are made to it. This change would mean that the combined > hs-rt gets more testing faster, and that the fix propagation time goes > to zero for changes between hs-rt and hs-gc. The hs-comp forest will > not be affected. > > We suggest that the experiment starts June 4th and goes on for at > least two weeks (giving us some time to adapt in case of issues). > Monitoring and evaluation of the new structure will take place > continuously, with an option to revert back if things do not work out. > This will remain an experiment for at least a few months, after which > we will evaluate it and depending on the results consider making it > the new standard. If so, the hs-gc forest will eventually be retired, > with an option of looking at further reduction of forests going forward. > > It's worth pointing out explicitly that if you have any changes based > on the hs-gc forest those changes would have to be rebased on top of > hs-rt instead once the hs-gc forest has been locked down. > > Please let us know if you have any feedback or questions! > > Cheers, > Mikael > > [1] http://hg.openjdk.java.net/jdk9/hs-rt > [2] http://hg.openjdk.java.net/jdk9/hs-gc > [3] http://hg.openjdk.java.net/jdk9/hs-comp > From roland.westrelin at oracle.com Wed Jun 3 16:29:58 2015 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Wed, 3 Jun 2015 18:29:58 +0200 Subject: [8u] backport of 8077504: Unsafe load can loose control dependency and cause crash Message-ID: <85C560E0-AC0D-426B-8335-E3E3E98E4FE4@oracle.com> 8u backport request. 8077504 was pushed to jdk9 2 weeks ago and it hasn?t caused any new failures during nightly testing. The change doesn?t apply cleanly to 8u. One reason is that we haven?t backported: 8036851: volatile double accesses are not explicitly atomic in C2 which applies cleanly to 8u so I?d like to backport it as well. There are other changes that were not backported and are causing the change to not apply cleanly (https://bugs.openjdk.java.net/browse/JDK-8054033 is one) but it?s probably too late for a backport of those. https://bugs.openjdk.java.net/browse/JDK-8036851 http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/446bb44e5367 https://bugs.openjdk.java.net/browse/JDK-8077504 http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/ed9cc6871da2 webrev against 8u (only 8077504 contrary to the webrev comment): http://cr.openjdk.java.net/~roland/8077504/webrev.03/ The 8u change went through jprt. Roland. From vladimir.kozlov at oracle.com Wed Jun 3 16:38:15 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 03 Jun 2015 09:38:15 -0700 Subject: [8u] backport of 8077504: Unsafe load can loose control dependency and cause crash In-Reply-To: <85C560E0-AC0D-426B-8335-E3E3E98E4FE4@oracle.com> References: <85C560E0-AC0D-426B-8335-E3E3E98E4FE4@oracle.com> Message-ID: <556F2D77.8010908@oracle.com> Good. I agree with backporting 8036851 fix. Thanks, Vladimir On 6/3/15 9:29 AM, Roland Westrelin wrote: > 8u backport request. 8077504 was pushed to jdk9 2 weeks ago and it hasn?t caused any new failures during nightly testing. The change doesn?t apply cleanly to 8u. One reason is that we haven?t backported: > > 8036851: volatile double accesses are not explicitly atomic in C2 > > which applies cleanly to 8u so I?d like to backport it as well. There are other changes that were not backported and are causing the change to not apply cleanly (https://bugs.openjdk.java.net/browse/JDK-8054033 is one) but it?s probably too late for a backport of those. > > https://bugs.openjdk.java.net/browse/JDK-8036851 > http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/446bb44e5367 > > https://bugs.openjdk.java.net/browse/JDK-8077504 > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/ed9cc6871da2 > webrev against 8u (only 8077504 contrary to the webrev comment): > http://cr.openjdk.java.net/~roland/8077504/webrev.03/ > > The 8u change went through jprt. > > Roland. > From gerard.ziemski at oracle.com Wed Jun 3 19:26:14 2015 From: gerard.ziemski at oracle.com (Gerard Ziemski) Date: Wed, 03 Jun 2015 14:26:14 -0500 Subject: Revision2: Corrected: RFR 8059557 (XL): Validate JVM Command-Line Flag Arguments In-Reply-To: <7A921A5A-AB1A-4462-8C15-7F4010B5590C@oracle.com> References: <5554FE2D.6020405@oracle.com> <555E0028.8070108@oracle.com> <55663700.5050606@oracle.com> <7A921A5A-AB1A-4462-8C15-7F4010B5590C@oracle.com> Message-ID: <556F54D6.6000909@oracle.com> Thank you Kim, for more feedback. Please my comments in-line: > Subject: Re: Revision2: Corrected: RFR 8059557 (XL): Validate JVM Command-Line Flag Arguments > Date: Tue, 2 Jun 2015 18:52:40 -0400 > From: Kim Barrett > To: Gerard Ziemski > CC: hotspot-dev at openjdk.java.net Developers, David Holmes, Coleen Phillimore, Dmitry Dmitriev, Alexander Harlap > > On May 27, 2015, at 5:28 PM, Gerard Ziemski > wrote: >> hi all, >> >> Here is a revision 2 of the feature taking into account feedback from Dmitry, David, Kim and Alexander. >> ... > Here's another collection of comments. I haven't looked at the actual > ranges and constraints yet. I might leave off that, since others seem > to be looking there. Let me know if you think another set of eyes is > needed there. > Given the breath of issues your review brings up, having you go over those would be very helpful - just please wait until rev 3. > ------------------------------------------------------------------------------ > src/share/vm/runtime/globals.cpp > 1067 //#define PRINT_FLAGS_SORTED_BY_TYPE_THEN_NAMES > and following > > The PRINT_FLAGS_SORTED_BYTE_TYPE_THEN_NAMES is never defined, so the > associated #else clause is (presently) dead code. If it were live > code then I'd have several complaints about it. But since it appears > to be dead, I'll limit my complaint to it existing at all. I will keep it simple and just remove it. > ------------------------------------------------------------------------------ > src/share/vm/runtime/commandLineFlagRangeList.cpp > > There is a large amount of code near-duplication among the various > CommandLineFlagRange_ classes. I think this could be > substantially reduced via some fairly straightforward usage of macros > and templates. This can be dealt with in a follow-on cleanup - please > file a CR. > > Probably similarly for the constraint classes. Filed as JDK-8081833. Could you please add detail there? > ------------------------------------------------------------------------------ > src/share/vm/runtime/commandLineFlagConstraintList.cpp > src/share/vm/runtime/commandLineFlagRangeList.cpp > > The macros EMIT_CONSTRAINT_COMMERCIAL_FLAG and > EMIT_RANGE_COMMERCIAL_FLAG are defined in these files. This is > parhaps the wrong place for them, since they are unused in open code. > > If moving the commercial flag handlers, it might be desirable to > define a helper macro for use by all the EMIT_RANGE_xxx_FLAG (and > similarly for EMIT_COMMERCIAL_xxx_FLAG). Those macros are not revealing anything - do we really need to move them? If we decide we absolutely must move them and hide behind a level of extra macros, would you kindly elaborate (in private if it needs to be) how to do so? > ------------------------------------------------------------------------------ > src/share/vm/runtime/commandLineFlagConstraintList.cpp > src/share/vm/runtime/commandLineFlagRangeList.cpp > > The classes CommandLineFlag{Constraint,Range}List are derived from > CHeapObj, but appear to never be allocated, and only have > static members. I think they should instead be derived from > AllStatic. Fixed. > ------------------------------------------------------------------------------ > src/share/vm/runtime/commandLineFlagRangeList.cpp > > The various emit_range_xxx functions are defined with global scope. > I*think* they should be defined at file scope. > > Similarly for the constraint list functions. If I make them at file scope then the compiler complains that some methods are not used, so I would have to remove those corresponding methods whose flag type is not currently used yet in our macro tables. But then in a future, when we add constraint or a range to a flag, whose type has not been used yet, we will have to implement those methods, which might be confusing to whoever it is that happens to be doing that. I think we would be better off by leaving things here implemented as is and prepared for any new ranges/constraints flags. > ------------------------------------------------------------------------------ > src/share/vm/runtime/commandLineFlagRangeList.cpp > src/share/vm/runtime/commandLineFlagRangeList.cpp > > These files directly include runtime/os_ext.hpp, but that file is not > intended to be directly included, but must be included from the > *middle* of runtime/os.hpp. I think the only reason this include > isn't blowing up is that there is some earlier include of > runtime/os.hpp, so that the direct include of os_ext.hpp is suppressed > by its include guard. It's not obvious what earlier file might be > providing that include of os.hpp, and I wonder if perhaps it's coming > from the precompiled headers. Changed it to ?runtime/os.hpp? and all seems well. > Which reminds me, has this changeset > been tested without precompiled headers? > Yes, I have explicitly tested it out by building without precompiled headers (on Mac OS X) > That include of os_ext.hpp is to obtain the definitions of the macros > EMIT_{CONSTRAINTS,RANGES}_FOR_GLOBALS_EXT. I think those macro > definitions probably ought to be moved to a different place, though I > don't have a suggested landing place. Filed JDK-8081842 to follow up on this. > ------------------------------------------------------------------------------ > src/share/vm/services/writeableFlags.cpp > > 34 #define TEMP_BUF_SIZE 256 > ... > 61 static void print_flag_error_message_if_needed(Flag::Error error, const char* name, FormatBuffer<80>& err_msg) { > > The ultimate destination of the error message is err_msg, which is > explicitly limited to 80 characters. It seems kind of pointless to > make TEMP_BUF_SIZE larger than the err_msg size. I need large enough buffer to hold the raw range string, which I then ?compress? by removing white spaces, so that it fits into the 80 character error buffer. > ------------------------------------------------------------------------------ > src/share/vm/runtime/globals.cpp > > In the various CommandLineFlags::AtPut(const char* name, ...) > functions, the call to the associated > apply_constraint_and_check_range_ helper function uses > (CommandLineFlags::finishedInitializing() == false) > to compute the verbose argument in that helper function call. Better > would be simply > !CommandLineFlags::finishedInitializing() > Done. > ------------------------------------------------------------------------------ > src/share/vm/runtime/commandLineFlagRangeList.hpp > 42 public: > 43 const char* _name; > > _name should be private. Any external accesses should be via the > existing public name() member function. > > Similarly for CommandLineFlagConstraint. Fixed. > ------------------------------------------------------------------------------ > src/share/vm/runtime/commandLineFlagRangeList.hpp > 44 CommandLineFlagRange(const char* name) { _name=name; } > > This will result in a dangling pointer if the name argument can be > deallocated. I suspect the intent is that this is only called with a > string literal, and that all callers do so, but that's hard to ensure. > > Similarly for CommandLineFlagConstraint. > > I'm not sure there's anything to do here, other than audit and add > comments. The name arguments for the constructors come from macro tables and are string literals. > ------------------------------------------------------------------------------ > src/share/vm/runtime/commandLineFlagRangeList.hpp > 47 virtual Flag::Error check_intx(intx value, bool verbose = true) { return Flag::SUCCESS; } > ... and other similar functions ... > ... and similar functions in CommandLineFlagConstraint ... > > I'm dubious about default implementations returning success. I think > the default should be a failure indication, possibly even with > ShouldNotReachHere(), since it indicates an attempt to apply a > constraint for the wrong type of value. If the constraint were being > applied to the correct type of value, the default implementation would > be overridden by the derived class of the constraint object. > > Similarly for CommandLineFlagConstraint. I?m just mimicking the pre-existing behavior, which was with no checking everything was passing. The way I see it, we pass unless we prove we violate constraint or range. > ------------------------------------------------------------------------------ > > If I'm understanding correctly, there should now never be a call to > FLAG_SET_{CMDLINE,DEFAULT,ERGO,other?} that doesn't have its result > checked. But most (by a substantial majority) appear to be unchecked. > I'm guessing that's a followup task? I don't see any mention of > FLAG_SET_xxx checking in the review summary; it's a different task > from determining appropriate ranges for flags that haven't had that > done yet. Actually, most FLAG_SET_CMDLINE uses check the return values, except for a few cases where a flag is deprecated, or some used in some unit tests, that I left up to the team responsible. I assumed that the uses of FLAG_SET_DEFAULT and FLAG_SET_ERGO know what that are doing, but if it?s a wrong assumption, then we can add error check there too later. This is an initial effort of introducing the new mechanism in. There are already subtasks covering pending tasks such as implementing those flags that don?t have ranges yet, so this checkin doesn?t represent the final effort. > ------------------------------------------------------------------------------ > src/share/vm/runtime/globals.cpp > 331 if (printRanges == false) { > > I'd prefer "if (!printRanges) {". > > Similarly for > > 380 } else if ((is_bool() == false) && (is_ccstr() == false)) { > 381 > 381 if (printRanges == true) { > > Searching for " == true" and " == false" will probably find more. > I must say that personally I prefer to see the value of the comparison shown explicitly, but I understand that in cases of ?true? and ?false?, it may lead to bugs. Fixed. Thank you Kim for excellent feedback and I will be posting Revision 3 soon. cheers From kim.barrett at oracle.com Wed Jun 3 19:37:02 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 3 Jun 2015 15:37:02 -0400 Subject: Revision2: Corrected: RFR 8059557 (XL): Validate JVM Command-Line Flag Arguments In-Reply-To: <7A921A5A-AB1A-4462-8C15-7F4010B5590C@oracle.com> References: <5554FE2D.6020405@oracle.com> <555E0028.8070108@oracle.com> <55663700.5050606@oracle.com> <7A921A5A-AB1A-4462-8C15-7F4010B5590C@oracle.com> Message-ID: On Jun 2, 2015, at 6:52 PM, Kim Barrett wrote: > > On May 27, 2015, at 5:28 PM, Gerard Ziemski wrote: >> >> hi all, >> >> Here is a revision 2 of the feature taking into account feedback from Dmitry, David, Kim and Alexander. >> ... >> >> References: >> >> Webrev: http://cr.openjdk.java.net/~gziemski/8059557_rev2 >> note: due to "awk" limit of 50 pats the Frames diff is not available for "src/share/vm/runtime/arguments.cpp? > One more: ------------------------------------------------------------------------------ src/share/vm/services/writeableFlags.cpp 46 for (int i=0; i References: <5554FE2D.6020405@oracle.com> <555E0028.8070108@oracle.com> <55663700.5050606@oracle.com> <7A921A5A-AB1A-4462-8C15-7F4010B5590C@oracle.com> Message-ID: <556F5C00.4030403@oracle.com> On 6/3/2015 2:37 PM, Kim Barrett wrote: > On Jun 2, 2015, at 6:52 PM, Kim Barrett wrote: >> On May 27, 2015, at 5:28 PM, Gerard Ziemski wrote: >>> hi all, >>> >>> Here is a revision 2 of the feature taking into account feedback from Dmitry, David, Kim and Alexander. >>> ... >>> >>> References: >>> >>> Webrev: http://cr.openjdk.java.net/~gziemski/8059557_rev2 >>> note: due to "awk" limit of 50 pats the Frames diff is not available for "src/share/vm/runtime/arguments.cpp? > One more: > > ------------------------------------------------------------------------------ > src/share/vm/services/writeableFlags.cpp > 46 for (int i=0; i > That should be "j < TEMP_BUF_SIZE-1". j is the index into the > range_string_no_whitespaces buffer that needs to be limited. Yes, thank you. cheers From kim.barrett at oracle.com Wed Jun 3 20:09:38 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 3 Jun 2015 16:09:38 -0400 Subject: Revision2: Corrected: RFR 8059557 (XL): Validate JVM Command-Line Flag Arguments In-Reply-To: <556F5C00.4030403@oracle.com> References: <5554FE2D.6020405@oracle.com> <555E0028.8070108@oracle.com> <55663700.5050606@oracle.com> <7A921A5A-AB1A-4462-8C15-7F4010B5590C@oracle.com> <556F5C00.4030403@oracle.com> Message-ID: On Jun 3, 2015, at 3:56 PM, Gerard Ziemski wrote: > > > > On 6/3/2015 2:37 PM, Kim Barrett wrote: >> On Jun 2, 2015, at 6:52 PM, Kim Barrett wrote: >>> On May 27, 2015, at 5:28 PM, Gerard Ziemski wrote: >>>> hi all, >>>> >>>> Here is a revision 2 of the feature taking into account feedback from Dmitry, David, Kim and Alexander. >>>> ... >>>> >>>> References: >>>> >>>> Webrev: http://cr.openjdk.java.net/~gziemski/8059557_rev2 >>>> note: due to "awk" limit of 50 pats the Frames diff is not available for "src/share/vm/runtime/arguments.cpp? >> One more: >> >> ------------------------------------------------------------------------------ >> src/share/vm/services/writeableFlags.cpp >> 46 for (int i=0; i> >> That should be "j < TEMP_BUF_SIZE-1". j is the index into the >> range_string_no_whitespaces buffer that needs to be limited. > And another: ------------------------------------------------------------------------------ src/share/vm/services/writeableFlags.cpp 43 char* range_string = stream.as_string(); 44 char range_string_no_whitespaces[TEMP_BUF_SIZE]; 45 int j = 0; 46 for (int i=0; i References: <5554FE2D.6020405@oracle.com> <555E0028.8070108@oracle.com> <55663700.5050606@oracle.com> <556CD903.1080004@oracle.com> <556E0D6B.7030909@oracle.com> Message-ID: <556F71D2.4020604@oracle.com> Hi Gerard, Thanks for the explanations. Just quoting still-open issues below: On 6/2/15 4:09 PM, Gerard Ziemski wrote: > Thank you Derek very much for your feedback. Please see my answers inline: > >> Line 2036, 2041: >> - Set status to false instead of returning directly? > I?m sorry, which file do those lines refer to? In arguments.cpp, in bool Arguments::check_vm_args_consistency(). My point is that the pre-existing control flow was to set "status = false" and continue checking flags, not to bail out when the first failure occurred. >> Line 2827 (existing); Change "K" -> "1*K" for consistency. > Line 2827 in gobals.hpp or is it a different file? Never mind. I should have been talking about arguments.cpp, but I must have miss-typed the line #, and now I can't find it. There are actually lots of naked "K"s around, so even though I'm not a fan, I can't complain about consistency. > - Shouldn't the default implementations for > CommandLineFlagConstraint::apply_XXX() return failure, not success? > I looked at it from the point of view of the more likely scenario, which is assume success, unless a fault detected. > > If we did do this, though, then instead of: > > Flag::Error MinHeapFreeRatioConstraintFunc(bool verbose, uintx* value) { > if ((CommandLineFlags::finishedInitializing()) && (*value > MaxHeapFreeRatio)) { > if (verbose == true) { > jio_fprintf(defaultStream::error_stream(), > "MinHeapFreeRatio (" UINTX_FORMAT ") must be less than or " > "equal to MaxHeapFreeRatio (" UINTX_FORMAT ")\n", > *value, MaxHeapFreeRatio); > } > return Flag::VIOLATES_CONSTRAINT; > } else { > return Flag::SUCCESS; > } > } > > we?d have: > > Flag::Error MinHeapFreeRatioConstraintFunc(bool verbose, uintx* value) { > Flag::Error error = Flag::VIOLATES_CONSTRAINT; > if ((CommandLineFlags::finishedInitializing()) && (*value > MaxHeapFreeRatio)) { > if (verbose == true) { > jio_fprintf(defaultStream::error_stream(), > "MinHeapFreeRatio (" UINTX_FORMAT ") must be less than or " > "equal to MaxHeapFreeRatio (" UINTX_FORMAT ")\n", > *value, MaxHeapFreeRatio); > } > } else { > error = Flag::SUCCESS; > } > return error; > } > > which is not as nice, in my opinion. I'm not sure we're talking about the same thing. Looking at commandLineFlagConstraintList.hpp: 55 virtual Flag::Error apply_bool(bool* value, bool verbose = true) { return Flag::SUCCESS; }; I had the question "What happens if someone calls a version of the apply function (apply_FOO) that doesn't match the type of the constraint?" For example, look at CommandLineFlagConstraint::apply_bool(). What if the flag is really an "int", and it has a constraint? So the constraint is of type CommandLineFlagConstraint_intx. If apply_bool() is ever called on a CommandLineFlagConstraint_intx it will return Flag::SUCCESS. This is wrong - it violates the implicit constraint that the type of the value matches the type of the flag. It looks like the callers ensure that constraint's type matches the value's type, so the default apply_bool() is never called. I'm not sure why you'd have to re-write MinHeapFreeRatioConstraint() (as describe above) no matter what the default value of apply_bool() is. But if some later code forgets to match the types correctly, I think we're better off calling shouldNotReachHere() in the default methods. I think Kim had a similar question about default check_FOO() methods in commandLineFlagRangeList.hpp. 47 virtual Flag::Error check_intx(intx value, bool verbose = true) { return Flag::SUCCESS; } 48 virtual Flag::Error check_uintx(uintx value, bool verbose = true) { return Flag::SUCCESS; } 49 virtual Flag::Error check_uint64_t(uint64_t value, bool verbose = true) { return Flag::SUCCESS; } 50 virtual Flag::Error check_size_t(size_t value, bool verbose = true) { return Flag::SUCCESS; } 51 virtual Flag::Error check_double(double value, bool verbose = true) { return Flag::SUCCESS; } Thanks for reading this far! - Derek Notes: apply_bool() is called in two places. 1) apply_constraint_and_check_range_bool() - Do the callers do a type check? - Yes. On type mismatch: - CommandLineFlags::boolAtPut(const char* name, size_t len, bool* value, Flag::Flags origin) returns Flag::WRONG_FORMAT. - CommandLineFlagsEx::boolAtPut(CommandLineFlagWithType flag, bool value, Flag::Flags origin) will fail a "guarantee". Not sure if that's best idea. 2) CommandLineFlags::check_all_ranges_and_constraints() - Caller basically does a type case, so apply_bool() is never called with wrong type flag. 55 virtual Flag::Error apply_bool(bool* value, bool verbose = true) { return Flag::SUCCESS; }; 56 virtual Flag::Error apply_intx(intx* value, bool verbose = true) { return Flag::SUCCESS; }; 57 virtual Flag::Error apply_uintx(uintx* value, bool verbose = true) { return Flag::SUCCESS; }; 58 virtual Flag::Error apply_uint64_t(uint64_t* value, bool verbose = true) { return Flag::SUCCESS; }; 59 virtual Flag::Error apply_size_t(size_t* value, bool verbose = true) { return Flag::SUCCESS; }; 60 virtual Flag::Error apply_double(double* value, bool verbose = true) { return Flag::SUCCESS; These are never called (because the callers ensure that constraint's type matches the "value" type), so it shouldn't matter if they return Flag::SUCCESS or Flag::INVALID_FLAG. From kim.barrett at oracle.com Wed Jun 3 21:50:39 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 3 Jun 2015 17:50:39 -0400 Subject: Revision2: Corrected: RFR 8059557 (XL): Validate JVM Command-Line Flag Arguments In-Reply-To: <556F71D2.4020604@oracle.com> References: <5554FE2D.6020405@oracle.com> <555E0028.8070108@oracle.com> <55663700.5050606@oracle.com> <556CD903.1080004@oracle.com> <556E0D6B.7030909@oracle.com> <556F71D2.4020604@oracle.com> Message-ID: On Jun 3, 2015, at 5:29 PM, Derek White wrote: > >> - Shouldn't the default implementations for CommandLineFlagConstraint::apply_XXX() return failure, not success? >> I looked at it from the point of view of the more likely scenario, which is assume success, unless a fault detected. >> >> If we did do this, though, then instead of: >> >> Flag::Error MinHeapFreeRatioConstraintFunc(bool verbose, uintx* value) { >> if ((CommandLineFlags::finishedInitializing()) && (*value > MaxHeapFreeRatio)) { >> if (verbose == true) { >> jio_fprintf(defaultStream::error_stream(), >> "MinHeapFreeRatio (" UINTX_FORMAT ") must be less than or " >> "equal to MaxHeapFreeRatio (" UINTX_FORMAT ")\n", >> *value, MaxHeapFreeRatio); >> } >> return Flag::VIOLATES_CONSTRAINT; >> } else { >> return Flag::SUCCESS; >> } >> } >> >> we?d have: >> >> Flag::Error MinHeapFreeRatioConstraintFunc(bool verbose, uintx* value) { >> Flag::Error error = Flag::VIOLATES_CONSTRAINT; >> if ((CommandLineFlags::finishedInitializing()) && (*value > MaxHeapFreeRatio)) { >> if (verbose == true) { >> jio_fprintf(defaultStream::error_stream(), >> "MinHeapFreeRatio (" UINTX_FORMAT ") must be less than or " >> "equal to MaxHeapFreeRatio (" UINTX_FORMAT ")\n", >> *value, MaxHeapFreeRatio); >> } >> } else { >> error = Flag::SUCCESS; >> } >> return error; >> } >> >> which is not as nice, in my opinion. > I'm not sure we're talking about the same thing. > > Looking at commandLineFlagConstraintList.hpp: > > 55 virtual Flag::Error apply_bool(bool* value, bool verbose = true) { return Flag::SUCCESS; }; > > I had the question "What happens if someone calls a version of the apply function (apply_FOO) that doesn't match the type of the constraint?" > > For example, look at CommandLineFlagConstraint::apply_bool(). What if the flag is really an "int", and it has a constraint? So the constraint is of type CommandLineFlagConstraint_intx. If apply_bool() is ever called on a CommandLineFlagConstraint_intx it will return Flag::SUCCESS. This is wrong - it violates the implicit constraint that the type of the value matches the type of the flag. > > It looks like the callers ensure that constraint's type matches the value's type, so the default apply_bool() is never called. I'm not sure why you'd have to re-write MinHeapFreeRatioConstraint() (as describe above) no matter what the default value of apply_bool() is. > > But if some later code forgets to match the types correctly, I think we're better off calling shouldNotReachHere() in the default methods. > > I think Kim had a similar question about default check_FOO() methods in commandLineFlagRangeList.hpp. > > 47 virtual Flag::Error check_intx(intx value, bool verbose = true) { return Flag::SUCCESS; } > 48 virtual Flag::Error check_uintx(uintx value, bool verbose = true) { return Flag::SUCCESS; } > 49 virtual Flag::Error check_uint64_t(uint64_t value, bool verbose = true) { return Flag::SUCCESS; } > 50 virtual Flag::Error check_size_t(size_t value, bool verbose = true) { return Flag::SUCCESS; } > 51 virtual Flag::Error check_double(double value, bool verbose = true) { return Flag::SUCCESS; } > > Thanks for reading this far! > > - Derek > > Notes: > > apply_bool() is called in two places. > > 1) apply_constraint_and_check_range_bool() > - Do the callers do a type check? > - Yes. On type mismatch: > - CommandLineFlags::boolAtPut(const char* name, size_t > len, bool* value, Flag::Flags origin) returns Flag::WRONG_FORMAT. > - CommandLineFlagsEx::boolAtPut(CommandLineFlagWithType > flag, bool value, Flag::Flags origin) will fail a "guarantee". Not > sure if that's best idea. > > 2) CommandLineFlags::check_all_ranges_and_constraints() > - Caller basically does a type case, so apply_bool() is > never called with wrong type flag. > > 55 virtual Flag::Error apply_bool(bool* value, bool verbose = true) { return Flag::SUCCESS; }; > 56 virtual Flag::Error apply_intx(intx* value, bool verbose = true) { return Flag::SUCCESS; }; > 57 virtual Flag::Error apply_uintx(uintx* value, bool verbose = true) { return Flag::SUCCESS; }; > 58 virtual Flag::Error apply_uint64_t(uint64_t* value, bool verbose = true) { return Flag::SUCCESS; }; > 59 virtual Flag::Error apply_size_t(size_t* value, bool verbose = true) { return Flag::SUCCESS; }; > 60 virtual Flag::Error apply_double(double* value, bool verbose = true) { return Flag::SUCCESS; > > These are never called (because the callers ensure that constraint's type matches the "value" type), so it shouldn't matter if they return Flag::SUCCESS or Flag::INVALID_FLAG. Yes, this is what I was talking about, and I agree with Derek, except I would go further an make these default implementations be ShouldNotReachHere(), because we shouldn?t be reaching there... From kim.barrett at oracle.com Wed Jun 3 22:08:14 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 3 Jun 2015 18:08:14 -0400 Subject: Revision2: Corrected: RFR 8059557 (XL): Validate JVM Command-Line Flag Arguments In-Reply-To: <556F54D6.6000909@oracle.com> References: <5554FE2D.6020405@oracle.com> <555E0028.8070108@oracle.com> <55663700.5050606@oracle.com> <7A921A5A-AB1A-4462-8C15-7F4010B5590C@oracle.com> <556F54D6.6000909@oracle.com> Message-ID: On Jun 3, 2015, at 3:26 PM, Gerard Ziemski wrote: > >> ------------------------------------------------------------------------------ >> src/share/vm/services/writeableFlags.cpp >> >> 34 #define TEMP_BUF_SIZE 256 >> ... >> 61 static void print_flag_error_message_if_needed(Flag::Error error, const char* name, FormatBuffer<80>& err_msg) { >> >> The ultimate destination of the error message is err_msg, which is >> explicitly limited to 80 characters. It seems kind of pointless to >> make TEMP_BUF_SIZE larger than the err_msg size. >> > I need large enough buffer to hold the raw range string, which I then ?compress? by removing white spaces, so that it fits into the 80 character error buffer. I don't see that. What I see is output of the range into a local stringStream, with whitespace elimination occurring in the transfer of data from that stringStream to the buffer. The undesired whitespace never makes it into the buffer. >> ------------------------------------------------------------------------------ >> src/share/vm/runtime/commandLineFlagRangeList.hpp >> 44 CommandLineFlagRange(const char* name) { _name=name; } >> >> This will result in a dangling pointer if the name argument can be >> deallocated. I suspect the intent is that this is only called with a >> string literal, and that all callers do so, but that's hard to ensure. >> >> Similarly for CommandLineFlagConstraint. >> >> I'm not sure there's anything to do here, other than audit and add >> comments. >> > The name arguments for the constructors come from macro tables and are string literals. Yes, but there's no assurance of that, or even any indication that it must be so. At least some comments would make me feel a little better. >> ------------------------------------------------------------------------------ >> src/share/vm/runtime/commandLineFlagRangeList.hpp >> 47 virtual Flag::Error check_intx(intx value, bool verbose = true) { return Flag::SUCCESS; } >> ... and other similar functions ... >> ... and similar functions in CommandLineFlagConstraint ... >> >> I'm dubious about default implementations returning success. I think >> the default should be a failure indication, possibly even with >> ShouldNotReachHere(), since it indicates an attempt to apply a >> constraint for the wrong type of value. If the constraint were being >> applied to the correct type of value, the default implementation would >> be overridden by the derived class of the constraint object. >> >> Similarly for CommandLineFlagConstraint. >> > I?m just mimicking the pre-existing behavior, which was with no checking everything was passing. The way I see it, we pass unless we prove we violate constraint or range. See Derek?s followup and my reply to that. >> If I'm understanding correctly, there should now never be a call to >> FLAG_SET_{CMDLINE,DEFAULT,ERGO,other?} that doesn't have its result >> checked. But most (by a substantial majority) appear to be unchecked. >> I'm guessing that's a followup task? I don't see any mention of >> FLAG_SET_xxx checking in the review summary; it's a different task >> from determining appropriate ranges for flags that haven't had that >> done yet. >> > Actually, most FLAG_SET_CMDLINE uses check the return values, except for a few cases where a flag is deprecated, or some used in some unit tests, that I left up to the team responsible. I think there are 10 of these. I haven?t audited them any further than discovery. cd hotspot/src egrep -R " FLAG_SET_CMDLINE\(" * | grep -v "#define FLAG_SET_CMDLINE? flags are: MaxRAMFraction, CreateCoredumpOnCrash, NewSize, OldSize, MaxNewSize > I assumed that the uses of FLAG_SET_DEFAULT and FLAG_SET_ERGO know what that are doing, but if it?s a wrong assumption, then we can add error check there too later. > > This is an initial effort of introducing the new mechanism in. There are already subtasks covering pending tasks such as implementing those flags that don?t have ranges yet, so this checkin doesn?t represent the final effort. I don't think that's a safe assumption; bugs happen. But I'm fine with addressing that being a followup task. Just make sure that task exists... From kim.barrett at oracle.com Wed Jun 3 22:26:21 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 3 Jun 2015 18:26:21 -0400 Subject: Revision2: Corrected: RFR 8059557 (XL): Validate JVM Command-Line Flag Arguments In-Reply-To: <556F54D6.6000909@oracle.com> References: <5554FE2D.6020405@oracle.com> <555E0028.8070108@oracle.com> <55663700.5050606@oracle.com> <7A921A5A-AB1A-4462-8C15-7F4010B5590C@oracle.com> <556F54D6.6000909@oracle.com> Message-ID: On Jun 3, 2015, at 3:26 PM, Gerard Ziemski wrote: > >> ------------------------------------------------------------------------------ >> src/share/vm/runtime/commandLineFlagRangeList.cpp >> >> The various emit_range_xxx functions are defined with global scope. >> I >> *think* >> they should be defined at file scope. >> >> Similarly for the constraint list functions. >> > If I make them at file scope then the compiler complains that some methods are not used, so I would have to remove those corresponding methods whose flag type is not currently used yet in our macro tables. But then in a future, when we add constraint or a range to a flag, whose type has not been used yet, we will have to implement those methods, which might be confusing to whoever it is that happens to be doing that. > > I think we would be better off by leaving things here implemented as is and prepared for any new ranges/constraints flags. Ick. So the problem is we have not yet defined constraints that use some of these functions (though we expect we eventually will) and the compiler is being a whiny pain about the presently unused functions. For gcc this is easy to fix: __attribute__((__unused__)) I don't know about other compilers. And if we went down that path, we'd want to macroize it, the same way ATTRIBUTE_PRINTF and ATTRIBUTE_SCANF have been macroized. OK, I think this doesn't need to be addressed in this change set, but can be dealt with as a follow-on task. From coleen.phillimore at oracle.com Thu Jun 4 01:09:03 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 03 Jun 2015 21:09:03 -0400 Subject: RFR: 8080947: Add uint as a valid VM flag type In-Reply-To: <556EBFF5.8070205@oracle.com> References: <5566FBF4.1060401@oracle.com> <556EB46A.1030408@oracle.com> <556EBFF5.8070205@oracle.com> Message-ID: <556FA52F.3030802@oracle.com> David, If you have all the reviews you need, you can integrate. Gerard is working through review comments and has to retest, and is fine with merging with your change. Thanks everyone for all the thorough reviews of the command line validation change. Coleen On 6/3/15 4:51 AM, David Lindholm wrote: > Hi David, > > Thanks for looking at this. I have a few places where I convert uint > and int to Java types, besides management.cpp also whitebox.cpp/java > and VM.java . After discussing with several people we though it was > most correct to go with JLONG as java type for both int and uint, > since it is not certain that an uint will fit in a JINT and I wanted > the same java type for both int and uint. > > I don't think the C spec specifies the size of int (please correct me > if I'm wrong), so having JLONG as type for int and uint is safer than > JINT. > > But I can change to JINT if you think that is better. > > > Thanks, > David > > On 2015-06-03 10:01, David Holmes wrote: >> Hi David, >> >> On 28/05/2015 9:28 PM, David Lindholm wrote: >>> Hi, >>> >>> Please review this patch that adds uint and int as valid VM flag types. >>> This patch adds the possibility to specify VM flags with types int and >>> uint, it does not change the type of any flags. >>> >>> >>> Webrev: >>> http://cr.openjdk.java.net/~david/JDK-8080947/webrev.hotspot.00/ >>> Webrev: http://cr.openjdk.java.net/~david/JDK-8080947/webrev.jdk.00/ >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8080947 >> >> src/share/vm/services/management.cpp >> >> + } else if (flag->is_int()) { >> + global->value.j = (jlong)flag->get_int(); >> + global->type = JMM_VMGLOBAL_TYPE_JLONG; >> + } else if (flag->is_uint()) { >> + global->value.j = (jlong)flag->get_uint(); >> + global->type = JMM_VMGLOBAL_TYPE_JLONG; >> >> These should be JINT types not JLONG. >> >> Cheers, >> David H. >> ------- >> >>> >>> Testing: Passed JPRT >>> >>> >>> Thanks, >>> David > From david.holmes at oracle.com Thu Jun 4 05:55:31 2015 From: david.holmes at oracle.com (David Holmes) Date: Thu, 04 Jun 2015 15:55:31 +1000 Subject: RFR 8059557: Test set for "Validate JVM Command-Line Flag Arguments" In-Reply-To: <556F0559.3080601@oracle.com> References: <555A09B8.7010402@oracle.com> <555E46A7.4020402@oracle.com> <55671906.10000@oracle.com> <556D3597.8090508@oracle.com> <556F0559.3080601@oracle.com> Message-ID: <556FE853.6040703@oracle.com> On 3/06/2015 11:47 PM, Dmitry Dmitriev wrote: > Hello David, > > Thank you for pointing on style/grammar mistakes! I corrected all of them. > Here a link to the updated > webrev:http://cr.openjdk.java.net/~ddmitriev/8059557/webrev.04/ > I'll take your word for it - I really can't re-read all the code and do a check :) > About "options validation" package - I agree that this looks odd, but if > you don't mind I prefer to leave it. It slightly simplify calling static > methods by using static import and also I use package-private access level. Ok. Thanks, David > Regards, > Dmitry > > On 02.06.2015 7:48, David Holmes wrote: >> Hi Dmitry, >> >> On 28/05/2015 11:32 PM, Dmitry Dmitriev wrote: >>> Hello all, >>> >>> Here is a 3 version of the tests taking into account feedback from >>> Christian, David and Gerard. >>> >>> I limit number of options in TestOptionsWithRanges.java to 15. This >>> include options of different types(intx, uintx etc.) and with different >>> combination of min/max range. TestOptionsWithRangesDynamic.java leaved >>> as is, because amount of manageable numeric options is very small and >>> currently only 3 of them have range. Also, I improve code for double >>> option. >>> >>> Webrev: http://cr.openjdk.java.net/~ddmitriev/8059557/webrev.03/ >>> >> >> Only a few style/grammar nits (the downside of writing so many doc >> comments :) ). >> >> Meta-question: is there a specific reason to use the package "options >> validation"? It looks odd to me to have >> OptionsValidation/common/optionsvalidation/ in the paths. >> >> General doc-comment comments: >> - @param/@return descriptions should start with lower-case (you >> currently mix-n-match) >> - @throws description should start with "if", so: >> @throws IOException if an error occurred reading the data >> >> >> General Java-style comments: >> - access modifiers (public, private, protected) always come first >> >> --- >> >> test/runtime/CommandLine/OptionsValidation/common/optionsvalidation/IntJVMOption.java >> >> >> 265 * passed value is negative then error will be >> catched earlier for >> >> catched -> caught >> >> --- >> >> test/runtime/CommandLine/OptionsValidation/common/optionsvalidation/JVMOption.java >> >> >> 327 * @param param Tested parameter passed to the java >> >> "the java" is not a noun - suggest "the JVM" ? >> >> Maybe change Java to JVM to avoid use of "java" as a noun everywhere. >> >> 350 failedMessage(name, fullOptionString, valid, "JVM >> output reports about fatal error. JVM exit with code " + returnCode + >> "!"); >> >> The message isn't grammatically correct: about -> a; exit -> exited >> >> Similarly "JVM exit" -> "JVM exited" >> >> 377 failedMessage(name, fullOptionString, valid, "JVM >> output not contains " >> >> not contains -> does not contain >> >> 400 * Return list of strings which contain options with valid >> values which used >> >> which used -> which can be used >> >> 416 * Return list of strings which contain options with invalid >> values which >> 417 * used for testing on command line >> >> Ditto >> >> --- >> >> test/runtime/CommandLine/OptionsValidation/common/optionsvalidation/JVMOptionsUtils.java >> >> >> 101 * Add dependency for option depending on it's type. E.g. ran >> java in >> >> ran java -> run the JVM >> >> 119 * @param withRanges true if needed options with defined ranges >> >> I'm not sure what this means. Occurs elswhere too. >> >> 121 * "product", "diagnostic" etc. Accept option only if >> acceptOrigin return >> >> return -> returns (or even return -> evaluates). Occurs elsewhere too. >> >> 260 * methods. Tested only writeable options. >> >> Suggestion: Only tests writeable options. Occurs elsewhere too. >> >> 264 * @throws Exception >> >> When? Why? Occurs elsewhere too. >> >> Thanks, >> David >> ----- >> >>> Thanks, >>> Dmitry >>> >>> >>> On 21.05.2015 23:57, Dmitry Dmitriev wrote: >>>> Hello all, >>>> >>>> Recently I correct several typos, so here a new webrev for tests: >>>> http://cr.openjdk.java.net/~ddmitriev/8059557/webrev.02/ >>>> >>>> >>>> Thanks, >>>> Dmitry >>>> >>>> On 18.05.2015 18:48, Dmitry Dmitriev wrote: >>>>> Hello all, >>>>> >>>>> Please review test set for verifying functionality implemented by JEP >>>>> 245 "Validate JVM Command-Line Flag Arguments"(JDK-8059557). Review >>>>> request for this JEP can be found there: >>>>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-May/018539.html >>>>> >>>>> >>>>> I create 3 tests for verifying options with ranges. The tests mostly >>>>> rely on common/optionsvalidation/JVMOptionsUtils.java. Class in this >>>>> file contains functions to get options with ranges as list(by parsing >>>>> new option "-XX:+PrintFlagsRanges" output), run command line test for >>>>> list of options and other. The actual test code contained in >>>>> common/optionsvalidation/JVMOption.java file - testCommandLine(), >>>>> testDynamic(), testJcmd() and testAttach() methods. >>>>> common/optionsvalidation/IntJVMOption.java and >>>>> common/optionsvalidation/DoubleJVMOption.java source files contain >>>>> classes derived from JVMOption class for integer and double JVM >>>>> options correspondingly. >>>>> >>>>> Here are description of the tests: >>>>> 1) >>>>> hotspot/test/runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java >>>>> >>>>> >>>>> >>>>> This test get all options with ranges by parsing output of new option >>>>> "-XX:+PrintFlagsRanges" and verify these options by starting Java and >>>>> passing options in command line with valid and invalid values. >>>>> Currently it verifies about 106 options which have ranges. >>>>> Invalid values are values which out-of-range. In test used values >>>>> "min-1" and "max+1".In this case Java should always exit with code 1 >>>>> and print error message about out-of-range value(with one exception, >>>>> if option is unsigned and passing negative value, then out-of-range >>>>> error message is not printed because error occurred earlier). >>>>> Valid values are values in range, e.g. min&max and also several >>>>> additional values. In this case Java should successfully exit(exit >>>>> code 0) or exit with error code 1 for other reasons(low memory with >>>>> certain option value etc.). In any case for values in range Java >>>>> should not print messages about out of range value. >>>>> In any case Java should not crash. >>>>> This test excluded from JPRT because it takes long time to execute >>>>> and also fails - some options with value in valid range cause Java to >>>>> crash(bugs are submitted). >>>>> >>>>> 2) >>>>> hotspot/test/runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java >>>>> >>>>> >>>>> >>>>> This test get all writeable options with ranges by parsing output of >>>>> new option "-XX:+PrintFlagsRanges" and verify these options by >>>>> dynamically changing it's values to the valid and invalid values. >>>>> Used 3 methods for that: DynamicVMOption isValidValue and >>>>> isInvalidValue methods, Jcmd and by attach method. Currently 3 >>>>> writeable options with ranges are verified by this test. >>>>> This test pass in JPRT. >>>>> >>>>> 3) >>>>> hotspot/test/runtime/CommandLine/OptionsValidation/TestJcmdOutput.java >>>>> >>>>> This test verified output of Jcmd when out-of-range value is set to >>>>> the writeable option or value violates option constraint. Also this >>>>> test verify that jcmd not write error message to the target process. >>>>> This test pass in JPRT. >>>>> >>>>> >>>>> I am not write special tests for constraints for this JEP because >>>>> there are exist test for that(e.g. >>>>> test/runtime/CompressedOops/ObjectAlignment.java for >>>>> ObjectAlignmentInBytes or >>>>> hotspot/test/gc/arguments/TestHeapFreeRatio.java for >>>>> MinHeapFreeRatio/MaxHeapFreeRatio). >>>>> >>>>> Webrev: http://cr.openjdk.java.net/~ddmitriev/8059557/webrev.00/ >>>>> >>>>> >>>>> JEP: https://bugs.openjdk.java.net/browse/JDK-8059557 >>>>> >>>>> Thanks, >>>>> Dmitry >>>>> >>>> >>> > From roland.westrelin at oracle.com Thu Jun 4 10:07:05 2015 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Thu, 4 Jun 2015 12:07:05 +0200 Subject: [8u] backport of 8077504: Unsafe load can loose control dependency and cause crash In-Reply-To: <556F2D77.8010908@oracle.com> References: <85C560E0-AC0D-426B-8335-E3E3E98E4FE4@oracle.com> <556F2D77.8010908@oracle.com> Message-ID: <7354F587-A955-46ED-898B-82E4F4FEB0C8@oracle.com> Thanks, Vladimir. Roland. > On Jun 3, 2015, at 6:38 PM, Vladimir Kozlov wrote: > > Good. > I agree with backporting 8036851 fix. > > Thanks, > Vladimir > > On 6/3/15 9:29 AM, Roland Westrelin wrote: >> 8u backport request. 8077504 was pushed to jdk9 2 weeks ago and it hasn?t caused any new failures during nightly testing. The change doesn?t apply cleanly to 8u. One reason is that we haven?t backported: >> >> 8036851: volatile double accesses are not explicitly atomic in C2 >> >> which applies cleanly to 8u so I?d like to backport it as well. There are other changes that were not backported and are causing the change to not apply cleanly (https://bugs.openjdk.java.net/browse/JDK-8054033 is one) but it?s probably too late for a backport of those. >> >> https://bugs.openjdk.java.net/browse/JDK-8036851 >> http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/446bb44e5367 >> >> https://bugs.openjdk.java.net/browse/JDK-8077504 >> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/ed9cc6871da2 >> webrev against 8u (only 8077504 contrary to the webrev comment): >> http://cr.openjdk.java.net/~roland/8077504/webrev.03/ >> >> The 8u change went through jprt. >> >> Roland. >> From edward.nevill at linaro.org Thu Jun 4 10:37:55 2015 From: edward.nevill at linaro.org (Edward Nevill) Date: Thu, 4 Jun 2015 11:37:55 +0100 Subject: RFR: 8081289: aarch64: add support for RewriteFrequentPairs in interpreter In-Reply-To: <1432732880.11287.10.camel@mylittlepony.linaroharston> References: <1432732880.11287.10.camel@mylittlepony.linaroharston> Message-ID: Hi, Just a polite ping. I submitted this patch for review by a JDK9 reviewer over a week ago and there has been no response. This patch was contributed by Alexander Alexeev who is a new contributer to OpenJDK. The patch affects only _arch64 files and both Alexander and I have verified it by running JTreg hotspot with -Xint. Thanks for your help, Ed, On 27 May 2015 at 14:21, Edward Nevill wrote: > Hi, > > The following webrev adds support for RewriteFrequentPairs to the template > interpreter for aarch64. > > http://cr.openjdk.java.net/~enevill/8081289/webrev.00 > > This was contributed by Alexander Alexeev ( > alexander.alexeev at caviumnetworks.com) > > This gives a small improvement to the interpreter on aarch64, and brings > it in line with all the other ports (x86, sparc, ppc, zero) which all > support RewriteFrequentPairs. > > I have done some performance measurement using -Xint with some micro > benchmarks and I see a small improvement on each. > > java dhrystone: +9% > embedded caffeinemark: +4% > grinderbench: +1% > dacapo (avrora): +1% > > Tested with hotspot jtreg:- > > Original: Test results: passed: 787; failed: 24; error: 44 > With patch: Test results: passed: 785; failed: 24; error: 46 > > The difference in the # of errors is due to timeouts because we are > running -Xint. > > Please review and if OK I will push. > > All the best, > Ed. > > > From roland.westrelin at oracle.com Thu Jun 4 10:41:12 2015 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Thu, 4 Jun 2015 12:41:12 +0200 Subject: RFR: 8081289: aarch64: add support for RewriteFrequentPairs in interpreter In-Reply-To: <1432732880.11287.10.camel@mylittlepony.linaroharston> References: <1432732880.11287.10.camel@mylittlepony.linaroharston> Message-ID: <73430178-4F90-4AC4-B2A9-7591909750ED@oracle.com> > http://cr.openjdk.java.net/~enevill/8081289/webrev.00 That looks good to me. Roland. From roland.westrelin at oracle.com Thu Jun 4 11:29:27 2015 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Thu, 4 Jun 2015 13:29:27 +0200 Subject: RFR: 8079565: aarch64: Add vectorization support for aarch64 In-Reply-To: <1432658017.17486.32.camel@mylittlepony.linaroharston> References: <1432658017.17486.32.camel@mylittlepony.linaroharston> Message-ID: <1EE4C04D-7286-4ABF-B3FA-3343DC006BEF@oracle.com> > http://cr.openjdk.java.net/~enevill/8079565/webrev.00/ The platform specific changes look good. I don?t have an opinion on these: - if (TraceSuperWord && Verbose) { + if (TraceSuperWord) { I never used TraceSuperWord. If someone has opinion, it?s time to speak up I guess. Roland. From david.lindholm at oracle.com Thu Jun 4 11:40:39 2015 From: david.lindholm at oracle.com (David Lindholm) Date: Thu, 04 Jun 2015 13:40:39 +0200 Subject: RFR: 8080947: Add uint as a valid VM flag type In-Reply-To: <556FA52F.3030802@oracle.com> References: <5566FBF4.1060401@oracle.com> <556EB46A.1030408@oracle.com> <556EBFF5.8070205@oracle.com> <556FA52F.3030802@oracle.com> Message-ID: <55703937.1080709@oracle.com> Hi, Thanks. I have put up a new webrev with a few small changes: http://cr.openjdk.java.net/~david/JDK-8080947/webrev.hotspot.01/ Thanks, David On 2015-06-04 03:09, Coleen Phillimore wrote: > > David, If you have all the reviews you need, you can integrate. > Gerard is working through review comments and has to retest, and is > fine with merging with your change. > > Thanks everyone for all the thorough reviews of the command line > validation change. > > Coleen > > On 6/3/15 4:51 AM, David Lindholm wrote: >> Hi David, >> >> Thanks for looking at this. I have a few places where I convert uint >> and int to Java types, besides management.cpp also whitebox.cpp/java >> and VM.java . After discussing with several people we though it was >> most correct to go with JLONG as java type for both int and uint, >> since it is not certain that an uint will fit in a JINT and I wanted >> the same java type for both int and uint. >> >> I don't think the C spec specifies the size of int (please correct me >> if I'm wrong), so having JLONG as type for int and uint is safer than >> JINT. >> >> But I can change to JINT if you think that is better. >> >> >> Thanks, >> David >> >> On 2015-06-03 10:01, David Holmes wrote: >>> Hi David, >>> >>> On 28/05/2015 9:28 PM, David Lindholm wrote: >>>> Hi, >>>> >>>> Please review this patch that adds uint and int as valid VM flag >>>> types. >>>> This patch adds the possibility to specify VM flags with types int and >>>> uint, it does not change the type of any flags. >>>> >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~david/JDK-8080947/webrev.hotspot.00/ >>>> Webrev: http://cr.openjdk.java.net/~david/JDK-8080947/webrev.jdk.00/ >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8080947 >>> >>> src/share/vm/services/management.cpp >>> >>> + } else if (flag->is_int()) { >>> + global->value.j = (jlong)flag->get_int(); >>> + global->type = JMM_VMGLOBAL_TYPE_JLONG; >>> + } else if (flag->is_uint()) { >>> + global->value.j = (jlong)flag->get_uint(); >>> + global->type = JMM_VMGLOBAL_TYPE_JLONG; >>> >>> These should be JINT types not JLONG. >>> >>> Cheers, >>> David H. >>> ------- >>> >>>> >>>> Testing: Passed JPRT >>>> >>>> >>>> Thanks, >>>> David >> > From dmitry.dmitriev at oracle.com Thu Jun 4 12:00:45 2015 From: dmitry.dmitriev at oracle.com (Dmitry Dmitriev) Date: Thu, 04 Jun 2015 15:00:45 +0300 Subject: RFR: 8080947: Add uint as a valid VM flag type In-Reply-To: <55703937.1080709@oracle.com> References: <5566FBF4.1060401@oracle.com> <556EB46A.1030408@oracle.com> <556EBFF5.8070205@oracle.com> <556FA52F.3030802@oracle.com> <55703937.1080709@oracle.com> Message-ID: <55703DED.2020107@oracle.com> Hello David, In src/share/vm/runtime/globals.cpp module: 738 bool CommandLineFlags::uintAtPut(const char* name, size_t len, uint* value, Flag::Flags origin) { 739 Flag* result = Flag::find_flag(name, len); 740 if (result == NULL) return false; 741 if (!result->is_uint()) return false; 742 uint old_value = result->get_uint(); 743 trace_flag_changed(name, old_value, *value, origin); 744 result->set_int(*value); 745 *value = old_value; 746 result->set_origin(origin); 747 return true; 748 } 749 750 void CommandLineFlagsEx::uintAtPut(CommandLineFlagWithType flag, uint value, Flag::Flags origin) { 751 Flag* faddr = address_of_flag(flag); 752 guarantee(faddr != NULL && faddr->is_uint(), "wrong flag type"); 753 trace_flag_changed(faddr->_name, faddr->get_uint(), value, origin); 754 faddr->set_int(value); 755 faddr->set_origin(origin); 756 } On lines 744 and 754 "set_int" method is called for unsigned flags. Probably "set_uint" method should be called? Regards, Dmitry On 04.06.2015 14:40, David Lindholm wrote: > Hi, > > Thanks. I have put up a new webrev with a few small changes: > > http://cr.openjdk.java.net/~david/JDK-8080947/webrev.hotspot.01/ > > > Thanks, > David > > On 2015-06-04 03:09, Coleen Phillimore wrote: >> >> David, If you have all the reviews you need, you can integrate. >> Gerard is working through review comments and has to retest, and is >> fine with merging with your change. >> >> Thanks everyone for all the thorough reviews of the command line >> validation change. >> >> Coleen >> >> On 6/3/15 4:51 AM, David Lindholm wrote: >>> Hi David, >>> >>> Thanks for looking at this. I have a few places where I convert uint >>> and int to Java types, besides management.cpp also whitebox.cpp/java >>> and VM.java . After discussing with several people we though it was >>> most correct to go with JLONG as java type for both int and uint, >>> since it is not certain that an uint will fit in a JINT and I wanted >>> the same java type for both int and uint. >>> >>> I don't think the C spec specifies the size of int (please correct >>> me if I'm wrong), so having JLONG as type for int and uint is safer >>> than JINT. >>> >>> But I can change to JINT if you think that is better. >>> >>> >>> Thanks, >>> David >>> >>> On 2015-06-03 10:01, David Holmes wrote: >>>> Hi David, >>>> >>>> On 28/05/2015 9:28 PM, David Lindholm wrote: >>>>> Hi, >>>>> >>>>> Please review this patch that adds uint and int as valid VM flag >>>>> types. >>>>> This patch adds the possibility to specify VM flags with types int >>>>> and >>>>> uint, it does not change the type of any flags. >>>>> >>>>> >>>>> Webrev: >>>>> http://cr.openjdk.java.net/~david/JDK-8080947/webrev.hotspot.00/ >>>>> Webrev: http://cr.openjdk.java.net/~david/JDK-8080947/webrev.jdk.00/ >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8080947 >>>> >>>> src/share/vm/services/management.cpp >>>> >>>> + } else if (flag->is_int()) { >>>> + global->value.j = (jlong)flag->get_int(); >>>> + global->type = JMM_VMGLOBAL_TYPE_JLONG; >>>> + } else if (flag->is_uint()) { >>>> + global->value.j = (jlong)flag->get_uint(); >>>> + global->type = JMM_VMGLOBAL_TYPE_JLONG; >>>> >>>> These should be JINT types not JLONG. >>>> >>>> Cheers, >>>> David H. >>>> ------- >>>> >>>>> >>>>> Testing: Passed JPRT >>>>> >>>>> >>>>> Thanks, >>>>> David >>> >> > From david.lindholm at oracle.com Thu Jun 4 12:09:28 2015 From: david.lindholm at oracle.com (David Lindholm) Date: Thu, 04 Jun 2015 14:09:28 +0200 Subject: RFR: 8080947: Add uint as a valid VM flag type In-Reply-To: <55703DED.2020107@oracle.com> References: <5566FBF4.1060401@oracle.com> <556EB46A.1030408@oracle.com> <556EBFF5.8070205@oracle.com> <556FA52F.3030802@oracle.com> <55703937.1080709@oracle.com> <55703DED.2020107@oracle.com> Message-ID: <55703FF8.1030505@oracle.com> Dmitry, Thanks, you are correct. Fixed now. Do you need another webrev? Thanks, David On 2015-06-04 14:00, Dmitry Dmitriev wrote: > Hello David, > > In src/share/vm/runtime/globals.cpp module: > > 738 bool CommandLineFlags::uintAtPut(const char* name, size_t len, > uint* value, Flag::Flags origin) { > 739 Flag* result = Flag::find_flag(name, len); > 740 if (result == NULL) return false; > 741 if (!result->is_uint()) return false; > 742 uint old_value = result->get_uint(); > 743 trace_flag_changed(name, > old_value, *value, origin); > 744 result->set_int(*value); > 745 *value = old_value; > 746 result->set_origin(origin); > 747 return true; > 748 } > 749 > 750 void CommandLineFlagsEx::uintAtPut(CommandLineFlagWithType flag, > uint value, Flag::Flags origin) { > 751 Flag* faddr = address_of_flag(flag); > 752 guarantee(faddr != NULL && faddr->is_uint(), "wrong flag type"); > 753 trace_flag_changed u4>(faddr->_name, faddr->get_uint(), value, origin); > 754 faddr->set_int(value); > 755 faddr->set_origin(origin); > 756 } > > On lines 744 and 754 "set_int" method is called for unsigned flags. > Probably "set_uint" method should be called? > > Regards, > Dmitry > > On 04.06.2015 14:40, David Lindholm wrote: >> Hi, >> >> Thanks. I have put up a new webrev with a few small changes: >> >> http://cr.openjdk.java.net/~david/JDK-8080947/webrev.hotspot.01/ >> >> >> Thanks, >> David >> >> On 2015-06-04 03:09, Coleen Phillimore wrote: >>> >>> David, If you have all the reviews you need, you can integrate. >>> Gerard is working through review comments and has to retest, and is >>> fine with merging with your change. >>> >>> Thanks everyone for all the thorough reviews of the command line >>> validation change. >>> >>> Coleen >>> >>> On 6/3/15 4:51 AM, David Lindholm wrote: >>>> Hi David, >>>> >>>> Thanks for looking at this. I have a few places where I convert >>>> uint and int to Java types, besides management.cpp also >>>> whitebox.cpp/java and VM.java . After discussing with several >>>> people we though it was most correct to go with JLONG as java type >>>> for both int and uint, since it is not certain that an uint will >>>> fit in a JINT and I wanted the same java type for both int and uint. >>>> >>>> I don't think the C spec specifies the size of int (please correct >>>> me if I'm wrong), so having JLONG as type for int and uint is safer >>>> than JINT. >>>> >>>> But I can change to JINT if you think that is better. >>>> >>>> >>>> Thanks, >>>> David >>>> >>>> On 2015-06-03 10:01, David Holmes wrote: >>>>> Hi David, >>>>> >>>>> On 28/05/2015 9:28 PM, David Lindholm wrote: >>>>>> Hi, >>>>>> >>>>>> Please review this patch that adds uint and int as valid VM flag >>>>>> types. >>>>>> This patch adds the possibility to specify VM flags with types >>>>>> int and >>>>>> uint, it does not change the type of any flags. >>>>>> >>>>>> >>>>>> Webrev: >>>>>> http://cr.openjdk.java.net/~david/JDK-8080947/webrev.hotspot.00/ >>>>>> Webrev: http://cr.openjdk.java.net/~david/JDK-8080947/webrev.jdk.00/ >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8080947 >>>>> >>>>> src/share/vm/services/management.cpp >>>>> >>>>> + } else if (flag->is_int()) { >>>>> + global->value.j = (jlong)flag->get_int(); >>>>> + global->type = JMM_VMGLOBAL_TYPE_JLONG; >>>>> + } else if (flag->is_uint()) { >>>>> + global->value.j = (jlong)flag->get_uint(); >>>>> + global->type = JMM_VMGLOBAL_TYPE_JLONG; >>>>> >>>>> These should be JINT types not JLONG. >>>>> >>>>> Cheers, >>>>> David H. >>>>> ------- >>>>> >>>>>> >>>>>> Testing: Passed JPRT >>>>>> >>>>>> >>>>>> Thanks, >>>>>> David >>>> >>> >> > From dmitry.dmitriev at oracle.com Thu Jun 4 12:12:54 2015 From: dmitry.dmitriev at oracle.com (Dmitry Dmitriev) Date: Thu, 04 Jun 2015 15:12:54 +0300 Subject: RFR: 8080947: Add uint as a valid VM flag type In-Reply-To: <55703FF8.1030505@oracle.com> References: <5566FBF4.1060401@oracle.com> <556EB46A.1030408@oracle.com> <556EBFF5.8070205@oracle.com> <556FA52F.3030802@oracle.com> <55703937.1080709@oracle.com> <55703DED.2020107@oracle.com> <55703FF8.1030505@oracle.com> Message-ID: <557040C6.90702@oracle.com> Thanks! No, not need another webrev. Also, I am not a reviewer. Regards, Dmitry On 04.06.2015 15:09, David Lindholm wrote: > Dmitry, > > Thanks, you are correct. Fixed now. Do you need another webrev? > > > Thanks, > David > > On 2015-06-04 14:00, Dmitry Dmitriev wrote: >> Hello David, >> >> In src/share/vm/runtime/globals.cpp module: >> >> 738 bool CommandLineFlags::uintAtPut(const char* name, size_t len, >> uint* value, Flag::Flags origin) { >> 739 Flag* result = Flag::find_flag(name, len); >> 740 if (result == NULL) return false; >> 741 if (!result->is_uint()) return false; >> 742 uint old_value = result->get_uint(); >> 743 trace_flag_changed(name, >> old_value, *value, origin); >> 744 result->set_int(*value); >> 745 *value = old_value; >> 746 result->set_origin(origin); >> 747 return true; >> 748 } >> 749 >> 750 void CommandLineFlagsEx::uintAtPut(CommandLineFlagWithType flag, >> uint value, Flag::Flags origin) { >> 751 Flag* faddr = address_of_flag(flag); >> 752 guarantee(faddr != NULL && faddr->is_uint(), "wrong flag type"); >> 753 trace_flag_changed> u4>(faddr->_name, faddr->get_uint(), value, origin); >> 754 faddr->set_int(value); >> 755 faddr->set_origin(origin); >> 756 } >> >> On lines 744 and 754 "set_int" method is called for unsigned flags. >> Probably "set_uint" method should be called? >> >> Regards, >> Dmitry >> >> On 04.06.2015 14:40, David Lindholm wrote: >>> Hi, >>> >>> Thanks. I have put up a new webrev with a few small changes: >>> >>> http://cr.openjdk.java.net/~david/JDK-8080947/webrev.hotspot.01/ >>> >>> >>> Thanks, >>> David >>> >>> On 2015-06-04 03:09, Coleen Phillimore wrote: >>>> >>>> David, If you have all the reviews you need, you can integrate. >>>> Gerard is working through review comments and has to retest, and is >>>> fine with merging with your change. >>>> >>>> Thanks everyone for all the thorough reviews of the command line >>>> validation change. >>>> >>>> Coleen >>>> >>>> On 6/3/15 4:51 AM, David Lindholm wrote: >>>>> Hi David, >>>>> >>>>> Thanks for looking at this. I have a few places where I convert >>>>> uint and int to Java types, besides management.cpp also >>>>> whitebox.cpp/java and VM.java . After discussing with several >>>>> people we though it was most correct to go with JLONG as java type >>>>> for both int and uint, since it is not certain that an uint will >>>>> fit in a JINT and I wanted the same java type for both int and uint. >>>>> >>>>> I don't think the C spec specifies the size of int (please correct >>>>> me if I'm wrong), so having JLONG as type for int and uint is >>>>> safer than JINT. >>>>> >>>>> But I can change to JINT if you think that is better. >>>>> >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>> On 2015-06-03 10:01, David Holmes wrote: >>>>>> Hi David, >>>>>> >>>>>> On 28/05/2015 9:28 PM, David Lindholm wrote: >>>>>>> Hi, >>>>>>> >>>>>>> Please review this patch that adds uint and int as valid VM flag >>>>>>> types. >>>>>>> This patch adds the possibility to specify VM flags with types >>>>>>> int and >>>>>>> uint, it does not change the type of any flags. >>>>>>> >>>>>>> >>>>>>> Webrev: >>>>>>> http://cr.openjdk.java.net/~david/JDK-8080947/webrev.hotspot.00/ >>>>>>> Webrev: >>>>>>> http://cr.openjdk.java.net/~david/JDK-8080947/webrev.jdk.00/ >>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8080947 >>>>>> >>>>>> src/share/vm/services/management.cpp >>>>>> >>>>>> + } else if (flag->is_int()) { >>>>>> + global->value.j = (jlong)flag->get_int(); >>>>>> + global->type = JMM_VMGLOBAL_TYPE_JLONG; >>>>>> + } else if (flag->is_uint()) { >>>>>> + global->value.j = (jlong)flag->get_uint(); >>>>>> + global->type = JMM_VMGLOBAL_TYPE_JLONG; >>>>>> >>>>>> These should be JINT types not JLONG. >>>>>> >>>>>> Cheers, >>>>>> David H. >>>>>> ------- >>>>>> >>>>>>> >>>>>>> Testing: Passed JPRT >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> David >>>>> >>>> >>> >> > From edward.nevill at linaro.org Thu Jun 4 12:28:51 2015 From: edward.nevill at linaro.org (Edward Nevill) Date: Thu, 4 Jun 2015 13:28:51 +0100 Subject: RFR: 8079565: aarch64: Add vectorization support for aarch64 In-Reply-To: <1EE4C04D-7286-4ABF-B3FA-3343DC006BEF@oracle.com> References: <1432658017.17486.32.camel@mylittlepony.linaroharston> <1EE4C04D-7286-4ABF-B3FA-3343DC006BEF@oracle.com> Message-ID: On 4 June 2015 at 12:29, Roland Westrelin wrote: > > http://cr.openjdk.java.net/~enevill/8079565/webrev.00/ > > The platform specific changes look good. > I don?t have an opinion on these: > > - if (TraceSuperWord && Verbose) { > + if (TraceSuperWord) { > > I never used TraceSuperWord. If someone has opinion, it?s time to speak up > I guess. Hi Roland, Thanks for spotting this. This was an accidental change. I made it non verbose for my own debugging purposes but forgot to revert it. New webrev http://cr.openjdk.java.net/~enevill/8079565/webrev.01 Only difference is reverting the changes to src/share/vm/opto/superword.cpp There are now no changes to shared code, only _aarch64 files. OK to push? Ed. From roland.westrelin at oracle.com Thu Jun 4 13:43:54 2015 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Thu, 4 Jun 2015 15:43:54 +0200 Subject: RFR: 8079565: aarch64: Add vectorization support for aarch64 In-Reply-To: References: <1432658017.17486.32.camel@mylittlepony.linaroharston> <1EE4C04D-7286-4ABF-B3FA-3343DC006BEF@oracle.com> Message-ID: <0D7936CD-B5BD-4C8C-92BF-0108D3BD7CF0@oracle.com> > OK to push? Yes. Roland. From charlie.hunt at oracle.com Thu Jun 4 13:44:30 2015 From: charlie.hunt at oracle.com (charlie hunt) Date: Thu, 4 Jun 2015 08:44:30 -0500 Subject: JEP 248: Make G1 the Default Garbage Collector In-Reply-To: References: <20150428220211.4355960845@eggemoggin.niobe.net> <5C5564BB-23ED-49AB-81C6-CFF85B56ACA4@kodewerk.com> <5540D689.6020407@oracle.com> <73855087-8BB2-4A8C-B9AD-080CD39FAB7A@kodewerk.com> <55423444.7040009@beckwithclan.com> <4391D841-07CD-4A37-8092-DABBA3C3A627@gmail.com> Message-ID: Wanted to come back to this thread, continue the dialog, reiterate the objective, (try to) summarize the concerns and put forth a potential plan for this JEP going forward. Intent: Use G1 GC as the default collector chosen by the JVM when no GC is explicitly set at the JVM command line. Points to consider: - No new feature capabilities are being added or removed. Anyone who wants to use a particular GC can use his or her favorite GC. - Potential impact, (positive or negative), is limited to those Java apps that do not specify a GC at the JVM command line. . No impact to any app using CMS GC . No impact to any app explicitly specifying Parallel GC . No impact to any app using Serial GC . No impact to any app using G1 GC - G1 by design offers an improved mix, or balance of GC performance (throughput, latency and footprint) over Parallel GC which was designed to be a throughput collector. - G1 ongoing enhancements will continue in JDK 9 through Dec 10, 2015, with bug fixes through April 21, 2016 [1]. - There are, and will be G1 enhancements in JDK 9, that are not, and may not be back ported to a JDK 8 update release. . It is possible should a G1 issue surface in JDK 8, it may be addressed via an enhancement in JDK 9. Concerns mentioned: - Is G1 mature enough to make the default collector? * Observations and experiences, (both positive and negative) ranging from pre-production support of G1 (pre JDK 7u4) through JDK 8u45. ** Mention of potential G1 corrupting indexes in Lucene, bug report [2]. Dawid Weiss, a committer to Lucene, mentioned the issue is very hard to reproduce and pinpoint. More info on this below. [2] - Should ergonomics be enhanced to better support the selection of a default GC? Suggested plan for moving forward: - Make G1 the default collector in JDK 9, continue to evaluate G1 and enhance G1 in JDK 9 - Mitigate risk by reverting back to Parallel GC before JDK 9 goes ?Generally Available? (Sept 22, 2016 [1]) if warranted by continuing to monitor observations and experiences with G1 in both JDK 9 pre-releases and latest JDK 8 update releases - Address enhancing ergonomics for selecting a default GC as a separate JEP if future observations suggests its needed Comments? thanks, charlie [1]: http://openjdk.java.net/projects/jdk9/ [2]: https://bugs.openjdk.java.net/browse/JDK-8038348 Dawid Weiss and Vladimir Kozlov (HotSpot JIT compiler committer) have tried multiple times to reproduce to capture additional information without success. Based on the bug report, the issue was found in a 32-bit Windows JDK 7u25, seems to be limited to 32-bit platforms, perhaps only Windows? Current reaction from Dawid and Vladimir it is a heisenbug, (http://en.wikipedia.org/wiki/Heisenbug ). Both Dawid and Vladimir will continue to monitor the situation. From alexander.kulyakhtin at oracle.com Thu Jun 4 14:23:21 2015 From: alexander.kulyakhtin at oracle.com (Alexander Kulyakhtin) Date: Thu, 4 Jun 2015 07:23:21 -0700 (PDT) Subject: RFR: JDK-8075327: Merge jdk and hotspot test libraries Message-ID: <1365a232-5a2d-4365-ad99-3638fdfac841@default> Stefan, There are some issues which may make it difficult to implement the grouping of the common test library files into the new packages as JDK-8075327 proposes. The changes in the current patch are trivial and made by a script (although they spread over many files). They are trivial because the names of the packages are left intact (except fo renaming of jdk.testlibrary to jdk.test.lib in the jdk repo). However, if we introduce the new packages per the CR description we will end up with import jdk.test.lib.*; import jdk.test.lib.vm.*; import jdk.test.lib.processtools.*; import jdk.test.lib.misc.*; where previously was just a single line import jdk.test.lib.*; The same goes for @build and @run directives where we end up with @build jdk.test.lib.* jdk.test.lib.vm.* jdk.test.lib.processtools.* jdk.test.lib.misc.* instead of @build jdk.test.lib.* There are many tests having import jdk.test.lib.* and @build jdk.test.lib.* and similar constructions. If we then want to deduce the minimal required dependencies for each and every jdk and hotspot test, then it will not be as trivial task as what we have currently done. It will, probably, require a significant review effort from both jdk and hotspot teams. The benefits of that effort are not quite evident for me though I, probably, might be missing something here. The current patch does already provide for the merge of the common part of the jdk and hotspot libraries and do eliminate the duplicated files. Therefore, I would suggest reviewing the current patch as it is , since the changes are trivial and postpone refactoring to the new packages until some time later, since such refactoring is not trivial and the current patch does provide for the merge. Best regards, Alexander ----- Original Message ----- From: alexander.kulyakhtin at oracle.com To: stefan.sarne at oracle.com Cc: jdk9-dev at openjdk.java.net, yekaterina.kantserova at oracle.com, hotspot-dev at openjdk.java.net Sent: Wednesday, June 3, 2015 3:33:22 PM GMT +03:00 Iraq Subject: Re: RFR: JDK-8075327: Merge jdk and hotspot test libraries Hi Stefan, Thank you very much for the review. I'll update the patch accordingly, shortly. Best regards, Alexander ----- Original Message ----- From: stefan.sarne at oracle.com To: alexander.kulyakhtin at oracle.com, jdk9-dev at openjdk.java.net, hotspot-dev at openjdk.java.net Cc: yekaterina.kantserova at oracle.com Sent: Wednesday, June 3, 2015 12:08:33 PM GMT +03:00 Iraq Subject: Re: RFR: JDK-8075327: Merge jdk and hotspot test libraries Hi Alexander, I think we want to group the utilities into packages directly. One reason for grouping is to support discovery, to clarify what belongs together. For example both the OutputAnalyzer and the StreamPumper belong together in a processtools package, while Asserts doesn't. Another reason is to simplify imports and reduce the impact of wild card includes, since for example an import of process tools should not have to bother with declaring usage of sun.misc.Unsafe in the modules world, just because Utils happen to be in the same package. Here are some examples - also available in the jira case: Package jdk.test.lib.processtools is the package for utilities for launching processes and analyzing the output. /test/lib/share/classes/jdk/test/lib/processtools/OutputAnalyzer.java /test/lib/share/classes/jdk/test/lib/processtools/OutputBuffer.java /test/lib/share/classes/jdk/test/lib/processtools/ProcessTools.java /test/lib/share/classes/jdk/test/lib/processtools/StreamPumper.java /test/lib/share/classes/jdk/test/lib/processtools/JDKToolFinder.java /test/lib/share/classes/jdk/test/lib/processtools/JDKToolLauncher.java /test/lib-test/jdk/test/lib/processtools/OutputAnalyzerTest.java Asserts can stay at top level. /test/lib/share/classes/jdk/test/lib/Asserts.java /test/lib-test/jdk/test/lib/AssertsTest.java For VM specific info, it would have vm package. Note that the whitebox API moves here. /test/lib/share/classes/jdk/test/lib/vm/InputArguments.java /test/lib/share/classes/jdk/test/lib/vm/Platform.java Ok, so then there are the stuff which just is a bucket of stuff and fluff. A later exercise could be to break this class into better named and placed classes, but this is a start: /test/lib/share/classes/jdk/test/lib/misc/Utils.java Thanks, Stefan Alexander Kulyakhtin skrev den 2015-06-02 13:18: Hi, Could you, please, review the following test-only changes to the 'jdk', 'hotspot' and the common 'test' repository http://cr.openjdk.java.net/~akulyakh/8075327/wr_hs/webrev.01/index.html http://cr.openjdk.java.net/~akulyakh/8075327/wr_jdk/webrev.01/index.html http://cr.openjdk.java.net/~akulyakh/8075327/wr_test/webrev.01/ The changes are to move test library files common to both jdk and hotspot to the upper-level test repository. The following has been done: 1) Common files (Asserts.java, OutputAnalyzer.java etc) from the jdk and hotspot repositories, have been merged and moved to the upper-level common test repository, to test/lib/share/classes. 2) Package jdk.testlibrary in the jdk repository have been renamed to jdk.test.lib to have the same name as in the hotspot repository 2) Upper level test/lib/share/classes library references have been added to the @library statements 3) Some packages previously located at upper level test repo at /test/lib have been moved to /test/lib/share/classes for consistency Best regards, Alexander From jesper.wilhelmsson at oracle.com Thu Jun 4 14:41:00 2015 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Thu, 04 Jun 2015 16:41:00 +0200 Subject: jdk9/hs-gc is now closed! Message-ID: <5570637C.60709@oracle.com> Hi, The last changes from jdk9/hs-gc has now been pushed to jdk9/hs. This means that jdk9/hs-gc is now officially closed for all changes. A proper lock will be in place eventually. The push job to bring jdk9/hs into jdk9/hs-rt is running now. Any GC related changes should go into jdk9/hs-rt from now on. Thanks, /Jesper From gerard.ziemski at oracle.com Thu Jun 4 15:20:57 2015 From: gerard.ziemski at oracle.com (Gerard Ziemski) Date: Thu, 04 Jun 2015 10:20:57 -0500 Subject: Revision2: Corrected: RFR 8059557 (XL): Validate JVM Command-Line Flag Arguments In-Reply-To: <556F71D2.4020604@oracle.com> References: <5554FE2D.6020405@oracle.com> <555E0028.8070108@oracle.com> <55663700.5050606@oracle.com> <556CD903.1080004@oracle.com> <556E0D6B.7030909@oracle.com> <556F71D2.4020604@oracle.com> Message-ID: <55706CD9.5080502@oracle.com> hi Derek, I answered your questions below: On 6/3/2015 4:29 PM, Derek White wrote: > Hi Gerard, > > Thanks for the explanations. Just quoting still-open issues below: > > On 6/2/15 4:09 PM, Gerard Ziemski wrote: >> Thank you Derek very much for your feedback. Please see my answers >> inline: >> >>> Line 2036, 2041: >>> - Set status to false instead of returning directly? >> I?m sorry, which file do those lines refer to? > In arguments.cpp, in bool Arguments::check_vm_args_consistency(). My > point is that the pre-existing control flow was to set "status = > false" and continue checking flags, not to bail out when the first > failure occurred. Excellent catch, fixed. >>> Line 2827 (existing); Change "K" -> "1*K" for consistency. >> Line 2827 in gobals.hpp or is it a different file? > > Never mind. I should have been talking about arguments.cpp, but I must > have miss-typed the line #, and now I can't find it. There are > actually lots of naked "K"s around, so even though I'm not a fan, I > can't complain about consistency. > >> - Shouldn't the default implementations for >> CommandLineFlagConstraint::apply_XXX() return failure, not success? >> I looked at it from the point of view of the more likely scenario, which is assume success, unless a fault detected. >> >> If we did do this, though, then instead of: >> >> Flag::Error MinHeapFreeRatioConstraintFunc(bool verbose, uintx* value) { >> if ((CommandLineFlags::finishedInitializing()) && (*value > MaxHeapFreeRatio)) { >> if (verbose == true) { >> jio_fprintf(defaultStream::error_stream(), >> "MinHeapFreeRatio (" UINTX_FORMAT ") must be less than or " >> "equal to MaxHeapFreeRatio (" UINTX_FORMAT ")\n", >> *value, MaxHeapFreeRatio); >> } >> return Flag::VIOLATES_CONSTRAINT; >> } else { >> return Flag::SUCCESS; >> } >> } >> >> we?d have: >> >> Flag::Error MinHeapFreeRatioConstraintFunc(bool verbose, uintx* value) { >> Flag::Error error = Flag::VIOLATES_CONSTRAINT; >> if ((CommandLineFlags::finishedInitializing()) && (*value > MaxHeapFreeRatio)) { >> if (verbose == true) { >> jio_fprintf(defaultStream::error_stream(), >> "MinHeapFreeRatio (" UINTX_FORMAT ") must be less than or " >> "equal to MaxHeapFreeRatio (" UINTX_FORMAT ")\n", >> *value, MaxHeapFreeRatio); >> } >> } else { >> error = Flag::SUCCESS; >> } >> return error; >> } >> >> which is not as nice, in my opinion. > I'm not sure we're talking about the same thing. > > Looking at commandLineFlagConstraintList.hpp: > 55 virtual Flag::Error apply_bool(bool* value, bool verbose = true) { return Flag::SUCCESS; }; > I had the question "What happens if someone calls a version of the > apply function (apply_FOO) that doesn't match the type of the constraint?" > > For example, look at CommandLineFlagConstraint::apply_bool(). What if > the flag is really an "int", and it has a constraint? So the > constraint is of type CommandLineFlagConstraint_intx. If apply_bool() > is ever called on a CommandLineFlagConstraint_intx it will return > Flag::SUCCESS. This is wrong - it violates the implicit constraint > that the type of the value matches the type of the flag. > > It looks like the callers ensure that constraint's type matches the > value's type, so the default apply_bool() is never called. I'm not > sure why you'd have to re-write MinHeapFreeRatioConstraint() (as > describe above) no matter what the default value of apply_bool() is. > > But if some later code forgets to match the types correctly, I think > we're better off calling shouldNotReachHere() in the default methods. > > I think Kim had a similar question about default check_FOO() methods > in commandLineFlagRangeList.hpp. > 47 virtual Flag::Error check_intx(intx value, bool verbose = true) { return Flag::SUCCESS; } > 48 virtual Flag::Error check_uintx(uintx value, bool verbose = true) { return Flag::SUCCESS; } > 49 virtual Flag::Error check_uint64_t(uint64_t value, bool verbose = true) { return Flag::SUCCESS; } > 50 virtual Flag::Error check_size_t(size_t value, bool verbose = true) { return Flag::SUCCESS; } > 51 virtual Flag::Error check_double(double value, bool verbose = true) { return Flag::SUCCESS; } > Thanks for reading this far! > > - Derek > > Notes: > > apply_bool() is called in two places. > > 1) apply_constraint_and_check_range_bool() > - Do the callers do a type check? > - Yes. On type mismatch: > - CommandLineFlags::boolAtPut(const char* name, size_t > len, bool* value, Flag::Flags origin) returns Flag::WRONG_FORMAT. > - CommandLineFlagsEx::boolAtPut(CommandLineFlagWithType > flag, bool value, Flag::Flags origin) will fail a "guarantee". > Not sure if that's best idea. > > 2) CommandLineFlags::check_all_ranges_and_constraints() > - Caller basically does a type case, so apply_bool() is > never called with wrong type flag. > > 55 virtual Flag::Error apply_bool(bool* value, bool verbose = true) { return Flag::SUCCESS; }; > 56 virtual Flag::Error apply_intx(intx* value, bool verbose = true) { return Flag::SUCCESS; }; > 57 virtual Flag::Error apply_uintx(uintx* value, bool verbose = true) { return Flag::SUCCESS; }; > 58 virtual Flag::Error apply_uint64_t(uint64_t* value, bool verbose = true) { return Flag::SUCCESS; }; > 59 virtual Flag::Error apply_size_t(size_t* value, bool verbose = true) { return Flag::SUCCESS; }; > 60 virtual Flag::Error apply_double(double* value, bool verbose = true) { return Flag::SUCCESS; > These are never called (because the callers ensure that constraint's > type matches the "value" type), so it shouldn't matter if they return > Flag::SUCCESS or Flag::INVALID_FLAG. Ah, now I see what we're talking about - thank you for clarifying. Fixed with ShouldNotReachHere() I will be posting a new webrev shortly, after I do testing. cheers From gerard.ziemski at oracle.com Thu Jun 4 19:43:31 2015 From: gerard.ziemski at oracle.com (Gerard Ziemski) Date: Thu, 04 Jun 2015 14:43:31 -0500 Subject: Revision2: Corrected: RFR 8059557 (XL): Validate JVM Command-Line Flag Arguments In-Reply-To: References: <5554FE2D.6020405@oracle.com> <555E0028.8070108@oracle.com> <55663700.5050606@oracle.com> <7A921A5A-AB1A-4462-8C15-7F4010B5590C@oracle.com> <556F54D6.6000909@oracle.com> Message-ID: <5570AA63.2040107@oracle.com> Thanks Kim!, Another set of issues handled: On 6/3/2015 5:08 PM, Kim Barrett wrote: > On Jun 3, 2015, at 3:26 PM, Gerard Ziemski wrote: >>> ------------------------------------------------------------------------------ >>> src/share/vm/services/writeableFlags.cpp >>> >>> 34 #define TEMP_BUF_SIZE 256 >>> ... >>> 61 static void print_flag_error_message_if_needed(Flag::Error error, const char* name, FormatBuffer<80>& err_msg) { >>> >>> The ultimate destination of the error message is err_msg, which is >>> explicitly limited to 80 characters. It seems kind of pointless to >>> make TEMP_BUF_SIZE larger than the err_msg size. >>> >> I need large enough buffer to hold the raw range string, which I then ?compress? by removing white spaces, so that it fits into the 80 character error buffer. > I don't see that. What I see is output of the range into a local > stringStream, with whitespace elimination occurring in the transfer of > data from that stringStream to the buffer. The undesired whitespace > never makes it into the buffer. Done. >>> ------------------------------------------------------------------------------ >>> src/share/vm/runtime/commandLineFlagRangeList.hpp >>> 44 CommandLineFlagRange(const char* name) { _name=name; } >>> >>> This will result in a dangling pointer if the name argument can be >>> deallocated. I suspect the intent is that this is only called with a >>> string literal, and that all callers do so, but that's hard to ensure. >>> >>> Similarly for CommandLineFlagConstraint. >>> >>> I'm not sure there's anything to do here, other than audit and add >>> comments. >>> >> The name arguments for the constructors come from macro tables and are string literals. > Yes, but there's no assurance of that, or even any indication that it > must be so. At least some comments would make me feel a little > better. Added comments. >>> ------------------------------------------------------------------------------ >>> src/share/vm/runtime/commandLineFlagRangeList.hpp >>> 47 virtual Flag::Error check_intx(intx value, bool verbose = true) { return Flag::SUCCESS; } >>> ... and other similar functions ... >>> ... and similar functions in CommandLineFlagConstraint ... >>> >>> I'm dubious about default implementations returning success. I think >>> the default should be a failure indication, possibly even with >>> ShouldNotReachHere(), since it indicates an attempt to apply a >>> constraint for the wrong type of value. If the constraint were being >>> applied to the correct type of value, the default implementation would >>> be overridden by the derived class of the constraint object. >>> >>> Similarly for CommandLineFlagConstraint. >>> >> I?m just mimicking the pre-existing behavior, which was with no checking everything was passing. The way I see it, we pass unless we prove we violate constraint or range. > See Derek?s followup and my reply to that. Yep, now I understand - fixed. >>> If I'm understanding correctly, there should now never be a call to >>> FLAG_SET_{CMDLINE,DEFAULT,ERGO,other?} that doesn't have its result >>> checked. But most (by a substantial majority) appear to be unchecked. >>> I'm guessing that's a followup task? I don't see any mention of >>> FLAG_SET_xxx checking in the review summary; it's a different task >>> from determining appropriate ranges for flags that haven't had that >>> done yet. >>> >> Actually, most FLAG_SET_CMDLINE uses check the return values, except for a few cases where a flag is deprecated, or some used in some unit tests, that I left up to the team responsible. > I think there are 10 of these. I haven?t audited them any further than discovery. > > cd hotspot/src > egrep -R " FLAG_SET_CMDLINE\(" * | grep -v "#define FLAG_SET_CMDLINE? > flags are: MaxRAMFraction, CreateCoredumpOnCrash, NewSize, OldSize, MaxNewSize There are 97 of the calls: 1 is a deprecated, 7 are in unit test code in 'collectorPolicy' and are tracked by JDK-8085864, the rest are checked for the return value. >> I assumed that the uses of FLAG_SET_DEFAULT and FLAG_SET_ERGO know what that are doing, but if it?s a wrong assumption, then we can add error check there too later. >> >> This is an initial effort of introducing the new mechanism in. There are already subtasks covering pending tasks such as implementing those flags that don?t have ranges yet, so this checkin doesn?t represent the final effort. > I don't think that's a safe assumption; bugs happen. But I'm fine > with addressing that being a followup task. Just make sure that task > exists... There are 99 uses of FLAG_SET_ERGO, filed JDK-8085866 to track this issue. Thank you Kim again, and I will prepare the next webrev shortly, after I do some testing. cheers From mark.reinhold at oracle.com Thu Jun 4 22:08:35 2015 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 04 Jun 2015 15:08:35 -0700 Subject: JEP 248: Make G1 the Default Garbage Collector In-Reply-To: References: <20150428220211.4355960845@eggemoggin.niobe.net>, <5C5564BB-23ED-49AB-81C6-CFF85B56ACA4@kodewerk.com>, <5540D689.6020407@oracle.com>, <73855087-8BB2-4A8C-B9AD-080CD39FAB7A@kodewerk.com>, , , <55423444.7040009@beckwithclan.com>, , , , , , , <4391D841-07CD-4A37-8092-DABBA3C3A627@gmail.com>, , , , , ,, Message-ID: <20150604150835.278728@eggemoggin.niobe.net> 2015/6/4 6:44 -0700, charlie.hunt at oracle.com: > Wanted to come back to this thread, continue the dialog, reiterate the > objective, (try to) summarize the concerns and put forth a potential > plan for this JEP going forward. > > Intent: Use G1 GC as the default collector chosen by the JVM when no > GC is explicitly set at the JVM command line. > > ... Charlie -- thanks for the excellent summary of this wide-ranging discussion! > ... > > Suggested plan for moving forward: > - Make G1 the default collector in JDK 9, continue to evaluate G1 and > enhance G1 in JDK 9 > - Mitigate risk by reverting back to Parallel GC before JDK 9 goes > ?Generally Available? (Sept 22, 2016 [1]) if warranted by continuing > to monitor observations and experiences with G1 in both JDK 9 > pre-releases and latest JDK 8 update releases > - Address enhancing ergonomics for selecting a default GC as a > separate JEP if future observations suggests its needed I think this is a fine plan. Stefan -- To move forward with JEP 248, could you please revise the second item in the "Risks and Assumptions" section to note that there is some concern that G1 might not be ready to become the default, that making it the default now will allow us to get more feedback on it, and that if it proves to be not ready then we'll revert the default to the Parallel GC in time for JDK 9 GA? Ben -- Can you live with this plan? - Mark From john.r.rose at oracle.com Thu Jun 4 22:16:26 2015 From: john.r.rose at oracle.com (John Rose) Date: Thu, 4 Jun 2015 15:16:26 -0700 Subject: JEP 248: Make G1 the Default Garbage Collector In-Reply-To: References: <20150428220211.4355960845@eggemoggin.niobe.net> <5C5564BB-23ED-49AB-81C6-CFF85B56ACA4@kodewerk.com> <5540D689.6020407@oracle.com> <73855087-8BB2-4A8C-B9AD-080CD39FAB7A@kodewerk.com> <55423444.7040009@beckwithclan.com> <4391D841-07CD-4A37-8092-DABBA3C3A627@gmail.com> Message-ID: <94CB8623-4F84-4112-8003-C41E43CE5512@oracle.com> Thanks Charlie; this is a good summary of the change of (the default setting of) the GC and the effect on JDK 9 users. If you know you are sensitive to GC performance, and you explicitly select a GC algorithm on the command line, this default change won't affect you. If you don't worry about GC performance, we don't expect that this default change will affect you noticeably, but if it does we want to know about it. Also, at the risk of stating the obvious: This change is to the bleeding edge of Java's next release, not the current release (JDK 8). The change will affect people who have chosen to work with early, pre-release versions of JDK 9. And those are exactly the people we need to help us with this next step. ? John P.S. More background, from my POV: G1 is both a set of newer GC algorithms and a framework for regionalized management of the heap. We have invested heavily (>10y) in this framework because we believe it will give us the means to scale best to current and future memory systems, while flexibly balancing pause time and throughput. The point of regionalization is that the GC can divide and conquer its reference tracing work by summarizing "remembered sets" for each region, and can then concentrate memory reclamation work in regions in which the most garbage is being created, treating "quiet" regions with little effort. There is no single "old generation" to accumulate fragmentation or scaling problems. Regionalization should also help us, in the future, with more exotic use cases, such as mapping object graphs directly from disk. Our internal testing leads us to believe that our current specific algorithms are now well-tuned enough to replace the previous default, for typical users. Thus we wish to switch the default for development builds of JDK 9, so that we can, as a wider community, verify this belief, debug it, or retract it. On Jun 4, 2015, at 6:44 AM, charlie hunt wrote: > > Wanted to come back to this thread, continue the dialog, reiterate the objective, (try to) summarize the concerns and put forth a potential plan for this JEP going forward. > > Intent: Use G1 GC as the default collector chosen by the JVM when no GC is explicitly set at the JVM command line. > > Points to consider: > - No new feature capabilities are being added or removed. Anyone who wants to use a particular GC can use his or her favorite GC. > - Potential impact, (positive or negative), is limited to those Java apps that do not specify a GC at the JVM command line. > . No impact to any app using CMS GC > . No impact to any app explicitly specifying Parallel GC > . No impact to any app using Serial GC > . No impact to any app using G1 GC > - G1 by design offers an improved mix, or balance of GC performance (throughput, latency and footprint) over Parallel GC which was designed to be a throughput collector. > - G1 ongoing enhancements will continue in JDK 9 through Dec 10, 2015, with bug fixes through April 21, 2016 [1]. > - There are, and will be G1 enhancements in JDK 9, that are not, and may not be back ported to a JDK 8 update release. > . It is possible should a G1 issue surface in JDK 8, it may be addressed via an enhancement in JDK 9. > > Concerns mentioned: > - Is G1 mature enough to make the default collector? > * Observations and experiences, (both positive and negative) ranging from pre-production support of G1 (pre JDK 7u4) through JDK 8u45. > ** Mention of potential G1 corrupting indexes in Lucene, bug report [2]. Dawid Weiss, a committer to Lucene, mentioned the issue is very hard to reproduce and pinpoint. More info on this below. [2] > - Should ergonomics be enhanced to better support the selection of a default GC? > > Suggested plan for moving forward: > - Make G1 the default collector in JDK 9, continue to evaluate G1 and enhance G1 in JDK 9 > - Mitigate risk by reverting back to Parallel GC before JDK 9 goes ?Generally Available? (Sept 22, 2016 [1]) if warranted by continuing to monitor observations and experiences with G1 in both JDK 9 pre-releases and latest JDK 8 update releases > - Address enhancing ergonomics for selecting a default GC as a separate JEP if future observations suggests its needed > > Comments? > > thanks, > > charlie > > [1]: http://openjdk.java.net/projects/jdk9/ > [2]: https://bugs.openjdk.java.net/browse/JDK-8038348 > Dawid Weiss and Vladimir Kozlov (HotSpot JIT compiler committer) have tried multiple times to reproduce to capture additional information without success. Based on the bug report, the issue was found in a 32-bit Windows JDK 7u25, seems to be limited to 32-bit platforms, perhaps only Windows? Current reaction from Dawid and Vladimir it is a heisenbug, (http://en.wikipedia.org/wiki/Heisenbug ). Both Dawid and Vladimir will continue to monitor the situation. From pujarimahesh_kumar at yahoo.com Fri Jun 5 05:22:59 2015 From: pujarimahesh_kumar at yahoo.com (Mahesh Pujari) Date: Fri, 5 Jun 2015 05:22:59 +0000 (UTC) Subject: Can not find systemtap-tapset.tar.gz/hotspot stp files in OpenJDK9 Message-ID: <1703106559.2779707.1433481779471.JavaMail.yahoo@mail.yahoo.com> Hi, ?I am building OpenJDK9 with dtrace enabled (on Ubuntu, its using systemtap, reference to mail list [1]). Can someone point me to where I can find systemtap-tapset.tar.gz, seems like this is needed, as this contains hotspot provider (files like tapset/hotspot-1.9.0.stp.in). [1] Issues with dtrace enabled in OpenJdk 9 ?thanks and regards,Mahesh Pujari From david.holmes at oracle.com Fri Jun 5 06:03:23 2015 From: david.holmes at oracle.com (David Holmes) Date: Fri, 05 Jun 2015 16:03:23 +1000 Subject: Can not find systemtap-tapset.tar.gz/hotspot stp files in OpenJDK9 In-Reply-To: <1703106559.2779707.1433481779471.JavaMail.yahoo@mail.yahoo.com> References: <1703106559.2779707.1433481779471.JavaMail.yahoo@mail.yahoo.com> Message-ID: <55713BAB.3020004@oracle.com> On 5/06/2015 3:22 PM, Mahesh Pujari wrote: > Hi, > I am building OpenJDK9 with dtrace enabled (on Ubuntu, its using systemtap, reference to mail list [1]). Can someone point me to where I can find systemtap-tapset.tar.gz, seems like this is needed, as this contains hotspot provider (files like tapset/hotspot-1.9.0.stp.in). These seem to be handled by FedoraProject but I don't see anything for 9: http://pkgs.fedoraproject.org/repo/pkgs/java-1.8.0-openjdk/systemtap-tapset.tar.gz/ David > [1] Issues with dtrace enabled in OpenJdk 9 > thanks and regards,Mahesh Pujari > From ben at jclarity.com Fri Jun 5 09:50:15 2015 From: ben at jclarity.com (Ben Evans) Date: Fri, 5 Jun 2015 10:50:15 +0100 Subject: JEP 248: Make G1 the Default Garbage Collector In-Reply-To: <20150604150835.278728@eggemoggin.niobe.net> References: <20150428220211.4355960845@eggemoggin.niobe.net> <5C5564BB-23ED-49AB-81C6-CFF85B56ACA4@kodewerk.com> <5540D689.6020407@oracle.com> <73855087-8BB2-4A8C-B9AD-080CD39FAB7A@kodewerk.com> <55423444.7040009@beckwithclan.com> <4391D841-07CD-4A37-8092-DABBA3C3A627@gmail.com> <20150604150835.278728@eggemoggin.niobe.net> Message-ID: (Resend from the account that's actually subscribed to hotspot-dev ...) Hi Mark & Charlie, Thanks for the summary. I'm cautiously optimistic about the plan - but I would like a bit more of an idea of what quantitative data & experiences we would need to prove whether G1 was ready or not. I've conducted a survey of apps via the user groups & should have some data on how many apps run with default collectors later on today. Thanks, Ben On Thu, Jun 4, 2015 at 11:08 PM, wrote: > 2015/6/4 6:44 -0700, charlie.hunt at oracle.com: >> Wanted to come back to this thread, continue the dialog, reiterate the >> objective, (try to) summarize the concerns and put forth a potential >> plan for this JEP going forward. >> >> Intent: Use G1 GC as the default collector chosen by the JVM when no >> GC is explicitly set at the JVM command line. >> >> ... > > Charlie -- thanks for the excellent summary of this wide-ranging > discussion! > >> ... >> >> Suggested plan for moving forward: >> - Make G1 the default collector in JDK 9, continue to evaluate G1 and >> enhance G1 in JDK 9 >> - Mitigate risk by reverting back to Parallel GC before JDK 9 goes >> ?Generally Available? (Sept 22, 2016 [1]) if warranted by continuing >> to monitor observations and experiences with G1 in both JDK 9 >> pre-releases and latest JDK 8 update releases >> - Address enhancing ergonomics for selecting a default GC as a >> separate JEP if future observations suggests its needed > > I think this is a fine plan. > > Stefan -- To move forward with JEP 248, could you please revise the > second item in the "Risks and Assumptions" section to note that there > is some concern that G1 might not be ready to become the default, that > making it the default now will allow us to get more feedback on it, and > that if it proves to be not ready then we'll revert the default to the > Parallel GC in time for JDK 9 GA? > > Ben -- Can you live with this plan? > > - Mark -- Ben Evans, Co-founder jClarity @jclarity From stefan.johansson at oracle.com Fri Jun 5 12:12:25 2015 From: stefan.johansson at oracle.com (Stefan Johansson) Date: Fri, 05 Jun 2015 14:12:25 +0200 Subject: JEP 248: Make G1 the Default Garbage Collector In-Reply-To: <20150604150835.278728@eggemoggin.niobe.net> References: <20150428220211.4355960845@eggemoggin.niobe.net>, , , <55423444.7040009@beckwithclan.com>, , , , , , , <4391D841-07CD-4A37-8092-DABBA3C3A627@gmail.com>, , , , , , , <20150604150835.278728@eggemoggin.niobe.n! et> Message-ID: <55719229.3060806@oracle.com> On 2015-06-05 00:08, mark.reinhold at oracle.com wrote: > 2015/6/4 6:44 -0700, charlie.hunt at oracle.com: >> Wanted to come back to this thread, continue the dialog, reiterate the >> objective, (try to) summarize the concerns and put forth a potential >> plan for this JEP going forward. >> >> Intent: Use G1 GC as the default collector chosen by the JVM when no >> GC is explicitly set at the JVM command line. >> >> ... > Charlie -- thanks for the excellent summary of this wide-ranging > discussion! > >> ... >> >> Suggested plan for moving forward: >> - Make G1 the default collector in JDK 9, continue to evaluate G1 and >> enhance G1 in JDK 9 >> - Mitigate risk by reverting back to Parallel GC before JDK 9 goes >> ?Generally Available? (Sept 22, 2016 [1]) if warranted by continuing >> to monitor observations and experiences with G1 in both JDK 9 >> pre-releases and latest JDK 8 update releases >> - Address enhancing ergonomics for selecting a default GC as a >> separate JEP if future observations suggests its needed > I think this is a fine plan. > > Stefan -- To move forward with JEP 248, could you please revise the > second item in the "Risks and Assumptions" section to note that there > is some concern that G1 might not be ready to become the default, that > making it the default now will allow us to get more feedback on it, and > that if it proves to be not ready then we'll revert the default to the > Parallel GC in time for JDK 9 GA? Mark, I've extended second item as follows: - G1 is seen as a robust and well-tested collector. It is not expected to have stability problems, but becoming the default collector will increase its visibility and may reveal previously-unknown issues. If a critical issue is found that can't be addressed in the JDK 9 time frame, we will revert back to use Parallel GC as the default for the JDK 9 GA. Thanks, Stefan > Ben -- Can you live with this plan? > > - Mark From magnus.ihse.bursie at oracle.com Fri Jun 5 14:07:20 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 05 Jun 2015 16:07:20 +0200 Subject: RFR: JDK-8085822 JEP 223: New Version-String Scheme (initial integration) Message-ID: <5571AD18.7080701@oracle.com> This review request covers the main part of the work for JEP-223, the new version string format [1]. Basically, we'll call this release Java "9", instead of Java "1.9.0". This patch is a folding of all work that has been done so far in the branch JEP-223-branch in jdk9/sandbox. As you can see, it mostly covers build changes, with some code changes in hotspot, jdk, nashorn and langtools that either are corresponding changes in the product code due to the compiler define flags changing from the build, or follow-up changes to handle the new format. The JEP-223 work is not finished by this patch. In fact, there are known issues remaining even after this patch, typically by code that reads the "java.version" property and tries to parse it. However, this patch is not directly destined for jdk9/dev, but will go into the special verona/stage forest. As for all patches destined for verona/stage it will be code reviewed as if going to jdk9/dev. Once in verona/stage it will bide its time, and it will be complemented with follow-up patches to address remaining issues. When all such issues are resolved and JEP-223 is fully implemented, all changes will be pushed at once (without further code reviews) into jdk9/dev. This patch has been contributed by Magnus Ihse Bursie, Kumar Srinivasan and Alejandro Murillo. Bug: https://bugs.openjdk.java.net/browse/JDK-8085822 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8085822-JEP-223-initial-patch/webrev.01 [1] http://openjdk.java.net/jeps/223 From mark.reinhold at oracle.com Fri Jun 5 14:37:25 2015 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Fri, 05 Jun 2015 07:37:25 -0700 Subject: JEP 248: Make G1 the Default Garbage Collector In-Reply-To: <55719229.3060806@oracle.com> References: <20150428220211.4355960845@eggemoggin.niobe.net>, <20150604150835.278728@eggemoggin.niobe.net>, <55719229.3060806@oracle.com> Message-ID: <20150605073725.747516@eggemoggin.niobe.net> 2015/6/5 5:12 -0700, stefan.johansson at oracle.com: > Mark, I've extended second item as follows: > > - G1 is seen as a robust and well-tested collector. It is not expected > to have stability problems, but becoming the default collector will > increase its visibility and may reveal previously-unknown issues. If > a critical issue is found that can't be addressed in the JDK 9 time > frame, we will revert back to use Parallel GC as the default for the > JDK 9 GA. Looks good, thanks! - Mark From omajid at redhat.com Fri Jun 5 15:05:26 2015 From: omajid at redhat.com (Omair Majid) Date: Fri, 5 Jun 2015 11:05:26 -0400 Subject: Can not find systemtap-tapset.tar.gz/hotspot stp files in OpenJDK9 In-Reply-To: <1703106559.2779707.1433481779471.JavaMail.yahoo@mail.yahoo.com> References: <1703106559.2779707.1433481779471.JavaMail.yahoo@mail.yahoo.com> Message-ID: <20150605150525.GB2972@redhat.com> * Mahesh Pujari [2015-06-05 01:23]: > ?I am building OpenJDK9 with dtrace enabled (on Ubuntu, its using > systemtap, reference to mail list [1]). Can someone point me to where > I can find systemtap-tapset.tar.gz, seems like this is needed, as this > contains hotspot provider (files like tapset/hotspot-1.9.0.stp.in). The various systemtap files are hosted in the IcedTea repositories. The latest version I know of is in IcedTea7: http://icedtea.classpath.org/hg/icedtea7/file/tip/tapset For Fedora, we rename the files to add the OpenJDK version and put it in a single tarball: systemtap-tapset.tar.gz. They should be unchanged otherwise. Thanks, Omair -- PGP Key: 66484681 (http://pgp.mit.edu/) Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681 From benjamin.john.evans at gmail.com Fri Jun 5 09:48:09 2015 From: benjamin.john.evans at gmail.com (Ben Evans) Date: Fri, 5 Jun 2015 10:48:09 +0100 Subject: JEP 248: Make G1 the Default Garbage Collector In-Reply-To: <20150604150835.278728@eggemoggin.niobe.net> References: <20150428220211.4355960845@eggemoggin.niobe.net> <5C5564BB-23ED-49AB-81C6-CFF85B56ACA4@kodewerk.com> <5540D689.6020407@oracle.com> <73855087-8BB2-4A8C-B9AD-080CD39FAB7A@kodewerk.com> <55423444.7040009@beckwithclan.com> <4391D841-07CD-4A37-8092-DABBA3C3A627@gmail.com> <20150604150835.278728@eggemoggin.niobe.net> Message-ID: Hi Mark & Charlie, Thanks for the summary. I'm cautiously optimistic about the plan - but I would like a bit more of an idea of what quantitative data & experiences we would need to prove whether G1 was ready or not. I've conducted a survey of apps via the user groups & should have some data on how many apps run with default collectors later on today. Thanks, Ben On Thu, Jun 4, 2015 at 11:08 PM, wrote: > 2015/6/4 6:44 -0700, charlie.hunt at oracle.com: >> Wanted to come back to this thread, continue the dialog, reiterate the >> objective, (try to) summarize the concerns and put forth a potential >> plan for this JEP going forward. >> >> Intent: Use G1 GC as the default collector chosen by the JVM when no >> GC is explicitly set at the JVM command line. >> >> ... > > Charlie -- thanks for the excellent summary of this wide-ranging > discussion! > >> ... >> >> Suggested plan for moving forward: >> - Make G1 the default collector in JDK 9, continue to evaluate G1 and >> enhance G1 in JDK 9 >> - Mitigate risk by reverting back to Parallel GC before JDK 9 goes >> ?Generally Available? (Sept 22, 2016 [1]) if warranted by continuing >> to monitor observations and experiences with G1 in both JDK 9 >> pre-releases and latest JDK 8 update releases >> - Address enhancing ergonomics for selecting a default GC as a >> separate JEP if future observations suggests its needed > > I think this is a fine plan. > > Stefan -- To move forward with JEP 248, could you please revise the > second item in the "Risks and Assumptions" section to note that there > is some concern that G1 might not be ready to become the default, that > making it the default now will allow us to get more feedback on it, and > that if it proves to be not ready then we'll revert the default to the > Parallel GC in time for JDK 9 GA? > > Ben -- Can you live with this plan? > > - Mark From ben at jclarity.com Fri Jun 5 17:11:39 2015 From: ben at jclarity.com (Ben Evans) Date: Fri, 5 Jun 2015 18:11:39 +0100 Subject: JEP 248: Make G1 the Default Garbage Collector In-Reply-To: <55719229.3060806@oracle.com> References: <20150428220211.4355960845@eggemoggin.niobe.net> <55423444.7040009@beckwithclan.com> <4391D841-07CD-4A37-8092-DABBA3C3A627@gmail.com> <20150604150835.278728@eggemoggin.niobe.net> <55719229.3060806@oracle.com> Message-ID: Hi, I like the plan, but this statement is really quite bullish, especially (IMO) on the available evidence. G1 was always marketed as the replacement for CMS. In field experience so far, that hasn't happened, and I feel that we are glossing over the fact that we are now thinking of G1 as a replacement for Parallel. Certainly none of the testing I've done has been about Parallel -> G1 - it's all been CMS vs G1. I will be happy to start working with clients to try to cover the Parallel vs G1 space, but that hasn't happened up until now. Neither do I think we should be under any illusions that a very large number of installs are going to be affected. It may not be all that representative, but here are the results of a quick community straw poll I ran over the last couple of days: A single question: "Which Garbage Collector Does Your Application Use? " yielded these results: Concurrent Mark & Sweep (CMS) 23.94% 85 ? Garbage First (G1GC) 10.70% 38 ? Parallel (because I explicitly set it) 5.07% 18 ? Default (this actually gives you Parallel) 39.15% 139 ? I Don't Know 21.13% 75 Total: 355 The clear, stand-out winner is Default, with ~40% of installs using this, and therefore being exposed to the proposed change. That makes me very nervous. So, whilst I'm not saying we shouldn't do this, and I know that community members, including Kirk, myself & the other jClarity folks will help to get some better data, I'd argue that we're still a long way from being certain that we're ready for this change. Thanks, Ben On Fri, Jun 5, 2015 at 1:12 PM, Stefan Johansson wrote: > On 2015-06-05 00:08, mark.reinhold at oracle.com wrote: >> >> 2015/6/4 6:44 -0700, charlie.hunt at oracle.com: >>> >>> Wanted to come back to this thread, continue the dialog, reiterate the >>> objective, (try to) summarize the concerns and put forth a potential >>> plan for this JEP going forward. >>> >>> Intent: Use G1 GC as the default collector chosen by the JVM when no >>> GC is explicitly set at the JVM command line. >>> >>> ... >> >> Charlie -- thanks for the excellent summary of this wide-ranging >> discussion! >> >>> ... >>> >>> Suggested plan for moving forward: >>> - Make G1 the default collector in JDK 9, continue to evaluate G1 and >>> enhance G1 in JDK 9 >>> - Mitigate risk by reverting back to Parallel GC before JDK 9 goes >>> ?Generally Available? (Sept 22, 2016 [1]) if warranted by continuing >>> to monitor observations and experiences with G1 in both JDK 9 >>> pre-releases and latest JDK 8 update releases >>> - Address enhancing ergonomics for selecting a default GC as a >>> separate JEP if future observations suggests its needed >> >> I think this is a fine plan. >> >> Stefan -- To move forward with JEP 248, could you please revise the >> second item in the "Risks and Assumptions" section to note that there >> is some concern that G1 might not be ready to become the default, that >> making it the default now will allow us to get more feedback on it, and >> that if it proves to be not ready then we'll revert the default to the >> Parallel GC in time for JDK 9 GA? > > Mark, I've extended second item as follows: > - G1 is seen as a robust and well-tested collector. It is not expected > to have stability problems, but becoming the default collector will > increase its visibility and may reveal previously-unknown issues. If > a critical issue is found that can't be addressed in the JDK 9 time > frame, we will revert back to use Parallel GC as the default for the > JDK 9 GA. > > Thanks, > Stefan > > >> Ben -- Can you live with this plan? >> >> - Mark > > -- Ben Evans, Co-founder jClarity @jclarity From jon.masamitsu at oracle.com Fri Jun 5 17:46:42 2015 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Fri, 05 Jun 2015 10:46:42 -0700 Subject: G1 as a CMS replacement In-Reply-To: References: <20150428220211.4355960845@eggemoggin.niobe.net> <55423444.7040009@beckwithclan.com> <4391D841-07CD-4A37-8092-DABBA3C3A627@gmail.com> <20150604150835.278728@eggemoggin.niobe.net> <55719229.3060806@oracle.com> Message-ID: <5571E082.4020909@oracle.com> Ben, From the mail below (from another thread) it sounds like you might have some suggestions about what is needed to make G1 a replacement for CMS. Perhaps some features that CMS has that G1 doesn't. Or some characterizations of applications (or even small benchmarks) where CMS is doing better. I'm aware of the applications which almost all of the heap is place in the young gen and promotions to the old/cms gen is very low and can be handled by the CMS concurrent collection. I also know that the static initiating occupancy of G1 can be a hindrance and that the larger G1 process footprint is a disadvantage. Are either of those blocker for transition to G1 for some applications. I'd appreciate anything you can share. Same applies to anyone else that would like to share blockers to migration from CMS to G1. Thanks. Jon On 6/5/2015 10:11 AM, Ben Evans wrote: > Hi, > > I like the plan, but this statement is really quite bullish, > especially (IMO) on the available evidence. > > G1 was always marketed as the replacement for CMS. In field experience > so far, that hasn't happened, and I feel that we are glossing over the > fact that we are now thinking of G1 as a replacement for Parallel. > > Certainly none of the testing I've done has been about Parallel -> G1 > - it's all been CMS vs G1. I will be happy to start working with > clients to try to cover the Parallel vs G1 space, but that hasn't > happened up until now. > > Neither do I think we should be under any illusions that a very large > number of installs are going to be affected. > > It may not be all that representative, but here are the results of a > quick community straw poll I ran over the last couple of days: > > A single question: "Which Garbage Collector Does Your Application Use? > " yielded these results: > > Concurrent Mark & Sweep (CMS) > 23.94% > 85 > ? > Garbage First (G1GC) > 10.70% > 38 > ? > Parallel (because I explicitly set it) > 5.07% > 18 > ? > Default (this actually gives you Parallel) > 39.15% > 139 > ? > I Don't Know > 21.13% > 75 > > Total: 355 > > The clear, stand-out winner is Default, with ~40% of installs using > this, and therefore being exposed to the proposed change. That makes > me very nervous. > > So, whilst I'm not saying we shouldn't do this, and I know that > community members, including Kirk, myself & the other jClarity folks > will help to get some better data, I'd argue that we're still a long > way from being certain that we're ready for this change. > > Thanks, > > Ben > > > From derek.white at oracle.com Fri Jun 5 18:39:53 2015 From: derek.white at oracle.com (Derek White) Date: Fri, 05 Jun 2015 14:39:53 -0400 Subject: Revision2: Corrected: RFR 8059557 (XL): Validate JVM Command-Line Flag Arguments In-Reply-To: <55663700.5050606@oracle.com> References: <5554FE2D.6020405@oracle.com> <555E0028.8070108@oracle.com> <55663700.5050606@oracle.com> Message-ID: <5571ECF9.5030105@oracle.com> On 5/27/15 5:28 PM, Gerard Ziemski wrote: > hi all, > > Here is a revision 2 of the feature taking into account feedback from > Dmitry, David, Kim and Alexander. Hi Gerard, I was looking over Sangheon's table of GC arguments looking for easy argument ranges to tighten, and saw an issue in your webrev: globals.hpp: 2013 manageable(intx, CMSTriggerInterval, -1, \ 2014 "Commence a CMS collection cycle (at least) every so many " \ 2015 "milliseconds (0 permanently, -1 disabled)") \ 2016 range(-1, 0) The correct range is -1..max_intx. - Derek From dmitry.samersoff at oracle.com Fri Jun 5 19:31:41 2015 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Fri, 05 Jun 2015 22:31:41 +0300 Subject: GCC 4.8.3+ Does anybody aware of Stack Smashing Protection ? Message-ID: <5571F91D.2020003@oracle.com> Hi Everybody, I'm not sure it affects hotspot but should we care about it? FYI: Beginning with GCC 4.8.3, Stack Smashing Protection (SSP) will be enabled by default. The 4.8 series will enable -fstack-protector while 4.9 and later enable -fstack-protector-strong. SSP is a security feature that attempts to mitigate stack-based buffer overflows by placing a canary value on the stack after the function return pointer and checking for that value before the function returns. If a buffer overflow occurs and the canary value is overwritten, the program aborts. There is a small performance cost to these features. They can be disabled with -fno-stack-protector. For more information these options, refer to the GCC Manual, or the following articles. http://en.wikipedia.org/wiki/Buffer_overflow_protection http://en.wikipedia.org/wiki/Stack_buffer_overflow https://securityblog.redhat.com/tag/stack-protector http://www.outflux.net/blog/archives/2014/01/27/fstack-protector-strong -Dmitry -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From kim.barrett at oracle.com Sat Jun 6 00:28:34 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Fri, 5 Jun 2015 20:28:34 -0400 Subject: GCC 4.8.3+ Does anybody aware of Stack Smashing Protection ? In-Reply-To: <5571F91D.2020003@oracle.com> References: <5571F91D.2020003@oracle.com> Message-ID: <4CEB39DA-005A-433E-86EC-8320377ECDA1@oracle.com> On Jun 5, 2015, at 3:31 PM, Dmitry Samersoff wrote: > > Hi Everybody, > > I'm not sure it affects hotspot but should we care about it? > > FYI: > > Beginning with GCC 4.8.3, Stack Smashing Protection (SSP) will be > enabled by default. The 4.8 series will enable -fstack-protector > while 4.9 and later enable -fstack-protector-strong. I think -fstack-protector (at least) has been the default configuration for Ubuntu?s gcc for some time. I recall this helping me track down a highly intermittent bug a couple years ago at my previous job. When we upgraded Ubuntu versions, suddenly the bug became quite apparent - a fixed sized stack allocated buffer in a third-party library was being overrun. From kirk at kodewerk.com Sun Jun 7 08:20:14 2015 From: kirk at kodewerk.com (Kirk Pepperdine) Date: Sun, 7 Jun 2015 10:20:14 +0200 Subject: G1 as a CMS replacement In-Reply-To: <5571E082.4020909@oracle.com> References: <20150428220211.4355960845@eggemoggin.niobe.net> <55423444.7040009@beckwithclan.com> <4391D841-07CD-4A37-8092-DABBA3C3A627@gmail.com> <20150604150835.278728@eggemoggin.niobe.net> <55719229.3060806@oracle.com> <5571E082.4020909@oracle.com> Message-ID: <57284F22-4912-4FFC-8F52-159441D4C67E@kodewerk.com> Hi Jon, I?ve been holding back on this because my thoughts are still not well formed but since we?re on the subject I thought I?d throw out my bad ideas in hopes that they inspire a better idea. > > I also know that the static initiating occupancy of G1 can be > a hindrance and that the larger G1 process footprint is a > disadvantage. Are either of those blocker for transition to > G1 for some applications. I?m not sure that a static IHOP is really the problem. From what I can see, it?s the accumulated cruft in regions that are not deemed ?ripe? enough to sweep that is a bigger problem. From the GC logs I?m getting from various customers trying to use G1 I where period calls to full collections are made, I can see that when this cruft gets cleaned up there is a corresponding and proportional drop in subsequent young collection pause times. Since this drop in pause all seems to be connected to RSet refinement/processing, it would seem to suggest that there might be some benefits if some how the RSets of target young regions could be cleaned during one of the concurrent phases of the concurrent mark in tenured. Maybe there could be a concurrent sweep (without the evacuation) phase added at the end of the cycle that could simply clean RSets of the pointers coming from said cruft. A full evacuation of a region would still be the domain of the young gen sweep. The current alternative is too simply make the collector more aggressive in how it selects regions. However, I feel tuning this way defeats the purpose or intent behind the G1. Regards, Kirk From jon.masamitsu at oracle.com Sun Jun 7 21:01:14 2015 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Sun, 07 Jun 2015 14:01:14 -0700 Subject: G1 as a CMS replacement In-Reply-To: <57284F22-4912-4FFC-8F52-159441D4C67E@kodewerk.com> References: <20150428220211.4355960845@eggemoggin.niobe.net> <4391D841-07CD-4A37-8092-DABBA3C3A627@gmail.com> <20150604150835.278728@eggemoggin.niobe.net> <55719229.3060806@oracle.com> <5571E082.4020909@oracle.com> <57284F22-4912-4FFC-8F52-159441D4C67E@kodewerk.com> Message-ID: <5574B11A.90908@oracle.com> On 6/7/2015 1:20 AM, Kirk Pepperdine wrote: > Hi Jon, > > I?ve been holding back on this because my thoughts are still not well formed but since we?re on the subject I thought I?d throw out my bad ideas in hopes that they inspire a better idea. > > >> I also know that the static initiating occupancy of G1 can be >> a hindrance and that the larger G1 process footprint is a >> disadvantage. Are either of those blocker for transition to >> G1 for some applications. Kirk, > I?m not sure that a static IHOP is really the problem. From what I can see, it?s the accumulated cruft in regions that are not deemed ?ripe? enough to sweep that is a bigger problem. From the GC logs I?m getting from various customers trying to use G1 I where period calls to full collections are made, I can see that when this cruft gets cleaned up there is a corresponding and proportional drop in subsequent young collection pause times. When you say cruft you mean live data spread throughout the heap, right? You're not talking about some side effect of floating garbage. > > Since this drop in pause all seems to be connected to RSet refinement/processing, it would seem to suggest that there might be some benefits if some how the RSets of target young regions could be cleaned during one of the concurrent phases of the concurrent mark in tenured. Maybe there could be a concurrent sweep (without the evacuation) phase added at the end of the cycle that could simply clean RSets of the pointers coming from said cruft. A full evacuation of a region would still be the domain of the young gen sweep. I'm going to have to read some code tomorrow to see what cleaning is done but one side effect of a full GC could be that the "cruft" that was spread out over 10 regions is compacted into 1 region. That would affect RSet's such that a young region collected before the full GC would have RSets for 10 regions. A collection of a young region after the full GC might only have a RSet for 1 region (where all the cruft is). Is this a possible interpretation of what you're seeing? If not, as I said, I'll look at what's done in terms of precleaning and get back. Thanks for asking. Jon > > The current alternative is too simply make the collector more aggressive in how it selects regions. However, I feel tuning this way defeats the purpose or intent behind the G1. > > Regards, > Kirk > From kirk at kodewerk.com Sun Jun 7 22:08:05 2015 From: kirk at kodewerk.com (Kirk Pepperdine) Date: Mon, 8 Jun 2015 00:08:05 +0200 Subject: G1 as a CMS replacement In-Reply-To: <5574B11A.90908@oracle.com> References: <20150428220211.4355960845@eggemoggin.niobe.net> <4391D841-07CD-4A37-8092-DABBA3C3A627@gmail.com> <20150604150835.278728@eggemoggin.niobe.net> <55719229.3060806@oracle.com> <5571E082.4020909@oracle.com> <57284F22-4912-4FFC-8F52-159441D4C67E@kodewerk.com> <5574B11A.90908@oracle.com> Message-ID: <190D265C-662A-482F-8E0F-9DFB53616062@kodewerk.com> Hi John, By cruft I meant zombies and/or floating garbage. I?ve always consider floating garbage as data that is dereferenced after the remark but I guess with the G1 that definition should be extended to include what I?ve called zombies. A zombie is a dead object that has been promoted because the root has yet to have been recognized as being dead because the pool hasn?t been marked. Floating garbage may (or may not) cause zombies but I reserve the term to describe data structures that are particularly prone to this phenomena. From a GC implementation POV it might make little difference. That said, from a diagnostic POV, it makes a huge difference as each condition triggers a different remedy. I would not expect there would be much to gain by collecting or should I say evacuating a region that is > 85% full. However dumping 15% of the cruft in these uncollectable regions always seems to produce a win. My naive idea was to some how sweep the references for the floating garbage out of the RSet. The space would be recovered when the region was finally evacuated. I have no idea how viable this idea is or even if the cost justifies the expense. What I?ve found in a number of situations is that if you have enough cores and you want better pause times it?s better to keep the current cycles running more frequently. When I configured the CMS collector to cope with a Scala compile (single threaded at the time) I managed to reduce the compile time by >30% (10 minutes just over 6). I?ve managed similar results with other applications and I?ve noticed that a number of trading applications (financials and ads) have been configuring CMS?s IOF so that it?s practically running continuously. My current guess is that we should be able to see the same types of improvements using the G1 by configuring it to soak up cores that aren?t used by the application. But in order to see gains I believe we have to improve the management of RSets. IME you can?t sort this out in the small. If you want to tune for large heaps with a reasonable rate of churn, you need an app that is large and has a reasonable rate of churn. In my case this translates to; I have to rely on the generosity of my customers to allow me to experiment. So, my biggest challenge is simply getting to enough applications where the teams will allow me to experiment. Kind regards, Kirk On Jun 7, 2015, at 11:01 PM, Jon Masamitsu wrote: > > > On 6/7/2015 1:20 AM, Kirk Pepperdine wrote: >> Hi Jon, >> >> I?ve been holding back on this because my thoughts are still not well formed but since we?re on the subject I thought I?d throw out my bad ideas in hopes that they inspire a better idea. >> >> >>> I also know that the static initiating occupancy of G1 can be >>> a hindrance and that the larger G1 process footprint is a >>> disadvantage. Are either of those blocker for transition to >>> G1 for some applications. > > Kirk, > >> I?m not sure that a static IHOP is really the problem. From what I can see, it?s the accumulated cruft in regions that are not deemed ?ripe? enough to sweep that is a bigger problem. From the GC logs I?m getting from various customers trying to use G1 I where period calls to full collections are made, I can see that when this cruft gets cleaned up there is a corresponding and proportional drop in subsequent young collection pause times. > > When you say cruft you mean live data spread throughout the heap, right? You're not > talking about some side effect of floating garbage. > >> >> Since this drop in pause all seems to be connected to RSet refinement/processing, it would seem to suggest that there might be some benefits if some how the RSets of target young regions could be cleaned during one of the concurrent phases of the concurrent mark in tenured. Maybe there could be a concurrent sweep (without the evacuation) phase added at the end of the cycle that could simply clean RSets of the pointers coming from said cruft. A full evacuation of a region would still be the domain of the young gen sweep. > > I'm going to have to read some code tomorrow to see what cleaning is done but one side effect > of a full GC could be that the "cruft" that was spread out over 10 regions is compacted into 1 > region. That would affect RSet's such that a young region collected before the full GC would > have RSets for 10 regions. A collection of a young region after the full GC might only have > a RSet for 1 region (where all the cruft is). Is this a possible interpretation of what you're > seeing? If not, as I said, I'll look at what's done in terms of precleaning and get back. Thanks > for asking. > > Jon > >> >> The current alternative is too simply make the collector more aggressive in how it selects regions. However, I feel tuning this way defeats the purpose or intent behind the G1. >> >> Regards, >> Kirk >> > From pujarimahesh_kumar at yahoo.com Mon Jun 8 06:09:49 2015 From: pujarimahesh_kumar at yahoo.com (Mahesh Pujari) Date: Mon, 8 Jun 2015 06:09:49 +0000 (UTC) Subject: Can not find systemtap-tapset.tar.gz/hotspot stp files in OpenJDK9 In-Reply-To: <20150605150525.GB2972@redhat.com> References: <20150605150525.GB2972@redhat.com> Message-ID: <575439006.3513890.1433743789722.JavaMail.yahoo@mail.yahoo.com> Thanks Omair Majid and David Holmes. With few minor adjustments I was able use the hotspot tapset from IcedTea repository. thanks and regards,Mahesh Pujari On Friday, June 5, 2015 8:35 PM, Omair Majid wrote: * Mahesh Pujari [2015-06-05 01:23]: > ?I am building OpenJDK9 with dtrace enabled (on Ubuntu, its using > systemtap, reference to mail list [1]). Can someone point me to where > I can find systemtap-tapset.tar.gz, seems like this is needed, as this > contains hotspot provider (files like tapset/hotspot-1.9.0.stp.in). The various systemtap files are hosted in the IcedTea repositories. The latest version I know of is in IcedTea7: http://icedtea.classpath.org/hg/icedtea7/file/tip/tapset For Fedora, we rename the files to add the OpenJDK version and put it in a single tarball: systemtap-tapset.tar.gz. They should be unchanged otherwise. Thanks, Omair -- PGP Key: 66484681 (http://pgp.mit.edu/) Fingerprint = F072 555B 0A17 3957 4E95? 0056 F286 F14F 6648 4681 From kirk at kodewerk.com Mon Jun 8 06:51:03 2015 From: kirk at kodewerk.com (Kirk Pepperdine) Date: Mon, 8 Jun 2015 08:51:03 +0200 Subject: G1 as a CMS replacement In-Reply-To: <5574B11A.90908@oracle.com> References: <20150428220211.4355960845@eggemoggin.niobe.net> <4391D841-07CD-4A37-8092-DABBA3C3A627@gmail.com> <20150604150835.278728@eggemoggin.niobe.net> <55719229.3060806@oracle.com> <5571E082.4020909@oracle.com> <57284F22-4912-4FFC-8F52-159441D4C67E@kodewerk.com> <5574B11A.90908@oracle.com> Message-ID: <4062355F-A666-49FC-96F9-FD6713BBFF66@kodewerk.com> Hi Jon, I should have added to my last email is what I?m looking for is to move the collector to be more useful in big server environments. I?m not sure that you?d want to, or can use the same strategies for smaller or mobile apps. This is why I believe the idea of a 1 size fits all collector fundamentally flawed. Regards, Kirk On Jun 7, 2015, at 11:01 PM, Jon Masamitsu wrote: > > > On 6/7/2015 1:20 AM, Kirk Pepperdine wrote: >> Hi Jon, >> >> I?ve been holding back on this because my thoughts are still not well formed but since we?re on the subject I thought I?d throw out my bad ideas in hopes that they inspire a better idea. >> >> >>> I also know that the static initiating occupancy of G1 can be >>> a hindrance and that the larger G1 process footprint is a >>> disadvantage. Are either of those blocker for transition to >>> G1 for some applications. > > Kirk, > >> I?m not sure that a static IHOP is really the problem. From what I can see, it?s the accumulated cruft in regions that are not deemed ?ripe? enough to sweep that is a bigger problem. From the GC logs I?m getting from various customers trying to use G1 I where period calls to full collections are made, I can see that when this cruft gets cleaned up there is a corresponding and proportional drop in subsequent young collection pause times. > > When you say cruft you mean live data spread throughout the heap, right? You're not > talking about some side effect of floating garbage. > >> >> Since this drop in pause all seems to be connected to RSet refinement/processing, it would seem to suggest that there might be some benefits if some how the RSets of target young regions could be cleaned during one of the concurrent phases of the concurrent mark in tenured. Maybe there could be a concurrent sweep (without the evacuation) phase added at the end of the cycle that could simply clean RSets of the pointers coming from said cruft. A full evacuation of a region would still be the domain of the young gen sweep. > > I'm going to have to read some code tomorrow to see what cleaning is done but one side effect > of a full GC could be that the "cruft" that was spread out over 10 regions is compacted into 1 > region. That would affect RSet's such that a young region collected before the full GC would > have RSets for 10 regions. A collection of a young region after the full GC might only have > a RSet for 1 region (where all the cruft is). Is this a possible interpretation of what you're > seeing? If not, as I said, I'll look at what's done in terms of precleaning and get back. Thanks > for asking. > > Jon > >> >> The current alternative is too simply make the collector more aggressive in how it selects regions. However, I feel tuning this way defeats the purpose or intent behind the G1. >> >> Regards, >> Kirk >> > From thomas.schatzl at oracle.com Mon Jun 8 07:21:16 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Mon, 08 Jun 2015 09:21:16 +0200 Subject: G1 as a CMS replacement In-Reply-To: <190D265C-662A-482F-8E0F-9DFB53616062@kodewerk.com> References: <20150428220211.4355960845@eggemoggin.niobe.net> <4391D841-07CD-4A37-8092-DABBA3C3A627@gmail.com> <20150604150835.278728@eggemoggin.niobe.net> <55719229.3060806@oracle.com> <5571E082.4020909@oracle.com> <57284F22-4912-4FFC-8F52-159441D4C67E@kodewerk.com> <5574B11A.90908@oracle.com> <190D265C-662A-482F-8E0F-9DFB53616062@kodewerk.com> Message-ID: <1433748076.2616.16.camel@oracle.com> Hi Kirk, On Mon, 2015-06-08 at 00:08 +0200, Kirk Pepperdine wrote: > Hi John, > [...] > I would not expect there would be much to gain by collecting or should I say > evacuating a region that is > 85% full. However dumping 15% of the cruft in > these uncollectable regions always seems to produce a win. > > My naive idea was to some how sweep the references for the floating garbage > out of the RSet. The space would be recovered when the region was finally > evacuated. I have no idea how viable this idea is or even if the cost During iterating over the remembered sets, known dead objects are not iterated over, i.e. their references are not followed. Dead (actually live) objects are determined by concurrent marking, so marking will keep the amount of "zombies" small. > justifies the expense. What I?ve found in a number of situations is that if > you have enough cores and you want better pause times it?s better to keep the > current cycles running more frequently. When I configured the CMS collector > to cope with a Scala compile (single threaded at the time) I managed to reduce > the compile time by >30% (10 minutes just over 6). I?ve managed similar > results with other applications and I?ve noticed that a number of trading > applications (financials and ads) have been configuring CMS?s IOF so that > it?s practically running continuously. My current guess is that we should > be able to see the same types of improvements using the G1 by configuring it > to soak up cores that aren?t used by the application. But in order to see > gains I believe we have to improve the management of RSets. > > IME you can?t sort this out in the small. If you want to tune for large heaps > with a reasonable rate of churn, you need an app that is large and has a > reasonable rate of churn. In my case this translates to; I have to rely on the > generosity of my customers to allow me to experiment. So, my biggest challenge > is simply getting to enough applications where the teams will allow me to > experiment. (some more comments below) > On Jun 7, 2015, at 11:01 PM, Jon Masamitsu wrote: > > > On 6/7/2015 1:20 AM, Kirk Pepperdine wrote: [...] > >> I?m not sure that a static IHOP is really the problem. From what I can see, > >>it?s the accumulated cruft in regions that are not deemed ?ripe? enough to >>>sweep that is a bigger problem. From the GC logs I?m getting from >>>various customers trying to use G1 I where period calls to full >>>collections are made, I can see that when this cruft gets cleaned up >>>there is a corresponding and proportional drop in subsequent young >>>collection pause times. [...] > > When you say cruft you mean live data spread throughout the heap, right? You're not > > talking about some side effect of floating garbage. > > > >> > >> Since this drop in pause all seems to be connected to RSet refinement/ >>>processing, it would seem to suggest that there might be some >>> benefits if some how the RSets of target young regions could be >>> cleaned during one of the concurrent phases of the concurrent mark >>> in tenured. Maybe there could be a concurrent sweep (without the >>> evacuation) phase added at the end of the cycle that could simply >>> clean RSets of the pointers coming from said cruft. A full >>> evacuation of a region would still be the domain of the young gen >>> sweep. > > > > I'm going to have to read some code tomorrow to see what cleaning is done but one side effect > > of a full GC could be that the "cruft" that was spread out over 10 regions is compacted into 1 > > region. That is one concern. > >That would affect RSet's such that a young region collected before the full GC would > > have RSets for 10 regions. A collection of a young region after the full GC might only have During full GC RSets are recreated from scratch. There is no cruft in there then. Also, full GC typically allows larger eden afterwards, which might cause a decrease in GC times if the object death rates are right. > > a RSet for 1 region (where all the cruft is). Is this a possible interpretation of what you're > > seeing? If not, as I said, I'll look at what's done in terms of precleaning and get back. Thanks > > for asking. > > The most likely explanation for this behavior is that in the internal representation the remembered set contents only ever get coarsened, i.e. from data structures that take less space but take more time to find the references. Even if a particular remembered becomes mostly empty (completely empty ones are removed of course), G1 never tries to go the other way, i.e. use a representation that is easier on the amount of work that needs to be done if possible. Thanks, Thomas From aph at redhat.com Mon Jun 8 08:36:34 2015 From: aph at redhat.com (Andrew Haley) Date: Mon, 08 Jun 2015 09:36:34 +0100 Subject: GCC 4.8.3+ Does anybody aware of Stack Smashing Protection ? In-Reply-To: <5571F91D.2020003@oracle.com> References: <5571F91D.2020003@oracle.com> Message-ID: <55755412.4040109@redhat.com> On 05/06/15 20:31, Dmitry Samersoff wrote: > I'm not sure it affects hotspot but should we care about it? I'm not sure that we need it as much as C programs do. By and large we don't allocate variable-sized objects on the stack, and of course there is no way for a Java programmer to do such a thing, so this protects against a risk that we don't have. I suppose this might protect our users if we have a bug in the runtime code or in scalar replacement. Andrew. From erik.joelsson at oracle.com Mon Jun 8 09:05:02 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 08 Jun 2015 11:05:02 +0200 Subject: RFR: JDK-8085822 JEP 223: New Version-String Scheme (initial integration) In-Reply-To: <5571AD18.7080701@oracle.com> References: <5571AD18.7080701@oracle.com> Message-ID: <55755ABE.9010000@oracle.com> Hello, Looks pretty good. Found some typos: jdk_util.c: 99: specia_update_version jdk-version.m4: 31: assing 124, 132: --with--version-pre-base has a dash too many? I see this pattern consistently used though, am I missing something? /Erik On 2015-06-05 16:07, Magnus Ihse Bursie wrote: > This review request covers the main part of the work for JEP-223, the > new version string format [1]. Basically, we'll call this release Java > "9", instead of Java "1.9.0". > > This patch is a folding of all work that has been done so far in the > branch JEP-223-branch in jdk9/sandbox. As you can see, it mostly > covers build changes, with some code changes in hotspot, jdk, nashorn > and langtools that either are corresponding changes in the product > code due to the compiler define flags changing from the build, or > follow-up changes to handle the new format. > > The JEP-223 work is not finished by this patch. In fact, there are > known issues remaining even after this patch, typically by code that > reads the "java.version" property and tries to parse it. However, this > patch is not directly destined for jdk9/dev, but will go into the > special verona/stage forest. As for all patches destined for > verona/stage it will be code reviewed as if going to jdk9/dev. Once in > verona/stage it will bide its time, and it will be complemented with > follow-up patches to address remaining issues. When all such issues > are resolved and JEP-223 is fully implemented, all changes will be > pushed at once (without further code reviews) into jdk9/dev. > > This patch has been contributed by Magnus Ihse Bursie, Kumar > Srinivasan and Alejandro Murillo. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8085822 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8085822-JEP-223-initial-patch/webrev.01 > > [1] http://openjdk.java.net/jeps/223 > From Alan.Bateman at oracle.com Mon Jun 8 09:34:12 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 08 Jun 2015 10:34:12 +0100 Subject: RFR: JDK-8085822 JEP 223: New Version-String Scheme (initial integration) In-Reply-To: <5571AD18.7080701@oracle.com> References: <5571AD18.7080701@oracle.com> Message-ID: <55756194.3080506@oracle.com> On 05/06/2015 15:07, Magnus Ihse Bursie wrote: > This review request covers the main part of the work for JEP-223, the > new version string format [1]. Basically, we'll call this release Java > "9", instead of Java "1.9.0". > > This patch is a folding of all work that has been done so far in the > branch JEP-223-branch in jdk9/sandbox. As you can see, it mostly > covers build changes, with some code changes in hotspot, jdk, nashorn > and langtools that either are corresponding changes in the product > code due to the compiler define flags changing from the build, or > follow-up changes to handle the new format. > > The JEP-223 work is not finished by this patch. In fact, there are > known issues remaining even after this patch, typically by code that > reads the "java.version" property and tries to parse it. However, this > patch is not directly destined for jdk9/dev, but will go into the > special verona/stage forest. As for all patches destined for > verona/stage it will be code reviewed as if going to jdk9/dev. Once in > verona/stage it will bide its time, and it will be complemented with > follow-up patches to address remaining issues. When all such issues > are resolved and JEP-223 is fully implemented, all changes will be > pushed at once (without further code reviews) into jdk9/dev. > > This patch has been contributed by Magnus Ihse Bursie, Kumar > Srinivasan and Alejandro Murillo. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8085822 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8085822-JEP-223-initial-patch/webrev.01 I looked through the code changes, skipping most of the make files :-) Version.java.template - the comment in jvmSecurityVersion() still talks about 1.6 and newer. Can this be replaced to just say that it returns the security version? Will the update_version and special_update_version fields eventually be dropped from the jvm_version_info stricture? Related, there seems to be a typo in the comment in jdk_util.c where it has "specia_update_version". The webrev shows a change to this comment in jvm.h: "Third, this file contains various I/O and network operations needed by the standard Java I/O and network APIs." I think this comment can be removed because those JVM_* functions were removed some time ago. Otherwise looks okay to me. -Alan. From erik.osterlund at lnu.se Mon Jun 8 09:59:43 2015 From: erik.osterlund at lnu.se (=?windows-1254?Q?Erik_=D6sterlund?=) Date: Mon, 8 Jun 2015 09:59:43 +0000 Subject: Dynamic G1 barrier elision for C2 in young In-Reply-To: References: Message-ID: Hi, Since this concerns compiler too, I decided to CC hotspot-dev. Thanks, /Erik Den 06/06/15 02:44 skrev Erik ?sterlund : >Hi guys, > >Making G1 run faster on GC-tuned applications that are designed to only >rarely spill objects into old, seems like an interesting and important >optimization goal at the moment. > >Today I tried an interesting experiment. I sample garbage during the >sweeping phase (phase 2) of System.gc() (G1MarkSweep) that stumbles >through garbage anyway, hoping to find classes with instances that are >used all the time, but /never/ make it into old. Then I deoptimize these >classes and recompile the relevant nmethods depending on the class to >elide the G1 write barriers (in C2). If the GC eventually needs to promote >any of these objects to old, I just deoptimize again and recompile with G1 >barriers turned back on. > >On some DaCapo benchmarks, it payed off very well for a few benchmarks >that supposedly use many temporary objects: >fop: -9.2% time <- this one was brutal!! >xalan: -6.9% time >jython: -5.9% time > >Results were measured with 40 warmup iterations, and then computed the >average of the following 10 iterations, so 50 iterations in total. Class >unloading was turned off (using my own patch to make -Xnoclassgc work, >because it seems to be broken currently) and 512M heaps. > > >The G1 barriers are already optimized to be faster for young objects, but >if the GC finds out that certain types of objects /never/ get old, telling >the compiler so allows complete elision of both the pre and post barriers >from the code which is nice. > >Are we conceptually interested in such a solution, potentially accompanied >with a flag like -XX:+G1DynamicallyOptimizeYoung? Thought I?d check if I >can get some feedback before going too far with this. > >Here is the code I used. > >Patch 1: -Xnoclassgc >http://cr.openjdk.java.net/~eosterlund/g1_experiments/noclassgc/webrev.00/ > >This just fixes an issue that -Xnoclassgc doesn?t work properly using G1 >(unfortunately I have yet to get the bug system work to report it...). >With this JVM flag, it should not do class unloading. I had to run my >experiments without class unloading because it killed the optimized >nmethods of the almost always dead objects I want to optimize in DaCapo, >because DaCapo does not retain their class loaders or something. > >Patch 2: Dynamic G1 barrier elision >http://cr.openjdk.java.net/~eosterlund/g1_experiments/dynamic_barrier_elis >i >on/webrev.00/ > >This is where the interesting stuff went if anyone is interested. This is >just a very basic prototype/concept to check if the approach seems >interesting to you guys. You probably want to add stuff like deoptimizing >less (only if there are fields to actually optimize/deoptimize - keep >track of that more accurately), and to sample garbage outside of >System.gc() - this was just a convenience for now, and being more accurate >with which class declared a field, not the canonical class, etc. > >Any comments are welcome. > >Thanks, >/Erik > > From pujarimahesh_kumar at yahoo.com Mon Jun 8 10:37:58 2015 From: pujarimahesh_kumar at yahoo.com (Mahesh Pujari) Date: Mon, 8 Jun 2015 10:37:58 +0000 (UTC) Subject: Can not find systemtap-tapset.tar.gz/hotspot stp files in OpenJDK9 In-Reply-To: <575439006.3513890.1433743789722.JavaMail.yahoo@mail.yahoo.com> References: <20150605150525.GB2972@redhat.com> <575439006.3513890.1433743789722.JavaMail.yahoo@mail.yahoo.com> Message-ID: <1088779057.3547403.1433759878164.JavaMail.yahoo@mail.yahoo.com> Missed to give the changes which I had to do manually on my local machine (very very minor). please see listing which contain links from which we can have tapsets and below steps were done from listing [2] 1. Place all files in a directy by removing ".in" extension i.e. from hotspot.stp.in to hotspot.stp 2. Remove hotspot_gc.stp.in file, as it seems the probes gc_collect_* don't exists in OpenJdk9. 3. Replace @ABS_CLIENT_LIBJVM_SO@ and @ABS_SERVER_LIBJVM_SO@ in all the files with JAVA_HOME/lib/amd64/client/libjvm.so and JAVA_HOME/lib/amd64/server/libjvm.so (give complete path) 4. In file hotspot-*.stp, find the probe object__alloc (in hotspot.object_alloc) and replace $HeapWordSize with 8 if we have 64 bit or else replace with 4 if its 32 bit. Example to run a sample with HelloWorld program as below stap -I /opt/jdk1.9.localbuild/tapset -e 'probe hotspot.object_alloc {log(probestr)}' -c '/opt/jdk1.9.localbuild/bin/java -XX:+ExtendedDTraceProbes HelloWorld' Note: In above example "/opt/jdk1.9.localbuild/tapset" is the location where all stp files are placed and /opt/jdk1.9.localbuild/bin/java is the build of OpenJDK9 with dtrace enabled. [1] http://icedtea.classpath.org/hg/icedtea7/file/tip/tapset [2] http://pkgs.fedoraproject.org/repo/pkgs/java-1.8.0-openjdk/systemtap-tapset.tar.gz/94ca5a45c3cb3b85c4577d0891166007/systemtap-tapset.tar.gz On Monday, June 8, 2015 11:39 AM, Mahesh Pujari wrote: Thanks Omair Majid and David Holmes. With few minor adjustments I was able use the hotspot tapset from IcedTea repository. thanks and regards, Mahesh Pujari On Friday, June 5, 2015 8:35 PM, Omair Majid wrote: * Mahesh Pujari [2015-06-05 01:23]: > I am building OpenJDK9 with dtrace enabled (on Ubuntu, its using > systemtap, reference to mail list [1]). Can someone point me to where > I can find systemtap-tapset.tar.gz, seems like this is needed, as this > contains hotspot provider (files like tapset/hotspot-1.9.0.stp.in). The various systemtap files are hosted in the IcedTea repositories. The latest version I know of is in IcedTea7: http://icedtea.classpath.org/hg/icedtea7/file/tip/tapset For Fedora, we rename the files to add the OpenJDK version and put it in a single tarball: systemtap-tapset.tar.gz. They should be unchanged otherwise. Thanks, Omair -- PGP Key: 66484681 (http://pgp.mit.edu/) Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681 From magnus.ihse.bursie at oracle.com Mon Jun 8 12:37:01 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 8 Jun 2015 14:37:01 +0200 Subject: RFR: JDK-8085822 JEP 223: New Version-String Scheme (initial integration) In-Reply-To: <55756194.3080506@oracle.com> References: <5571AD18.7080701@oracle.com> <55756194.3080506@oracle.com> Message-ID: <1136B10A-72A2-421D-8333-1943353F662C@oracle.com> > 8 jun 2015 kl. 11:34 skrev Alan Bateman : > >> On 05/06/2015 15:07, Magnus Ihse Bursie wrote: >> This review request covers the main part of the work for JEP-223, the new version string format [1]. Basically, we'll call this release Java "9", instead of Java "1.9.0". >> >> This patch is a folding of all work that has been done so far in the branch JEP-223-branch in jdk9/sandbox. As you can see, it mostly covers build changes, with some code changes in hotspot, jdk, nashorn and langtools that either are corresponding changes in the product code due to the compiler define flags changing from the build, or follow-up changes to handle the new format. >> >> The JEP-223 work is not finished by this patch. In fact, there are known issues remaining even after this patch, typically by code that reads the "java.version" property and tries to parse it. However, this patch is not directly destined for jdk9/dev, but will go into the special verona/stage forest. As for all patches destined for verona/stage it will be code reviewed as if going to jdk9/dev. Once in verona/stage it will bide its time, and it will be complemented with follow-up patches to address remaining issues. When all such issues are resolved and JEP-223 is fully implemented, all changes will be pushed at once (without further code reviews) into jdk9/dev. >> >> This patch has been contributed by Magnus Ihse Bursie, Kumar Srinivasan and Alejandro Murillo. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8085822 >> WebRev: http://cr.openjdk.java.net/~ihse/JDK-8085822-JEP-223-initial-patch/webrev.01 > > I looked through the code changes, skipping most of the make files :-) > > Version.java.template - the comment in jvmSecurityVersion() still talks about 1.6 and newer. Can this be replaced to just say that it returns the security version? > > Will the update_version and special_update_version fields eventually be dropped from the jvm_version_info stricture? Related, there seems to be a typo in the comment in jdk_util.c where it has "specia_update_version". > > The webrev shows a change to this comment in jvm.h: > "Third, this file contains various I/O and network operations needed by the standard Java I/O and network APIs." > I think this comment can be removed because those JVM_* functions were removed some time ago. > > Otherwise looks okay to me. The API functions in Version.java and jvm.h are not finished. The specification in the JEP talks about a java.util.Version, that I presume will replace the sun.misc.Version, and that will fully implement an API to access the version string and all it's parts, according to the JEP definition. Also, the native interface will have to be changed to accommodate a version number with an arbitrarily number of dot separated parts. These changes will be done later on in the verona/stage forest. Are you ok with addressing these concerns at such a later time? /Magnus > > -Alan. From goetz.lindenmaier at sap.com Mon Jun 8 14:00:40 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 8 Jun 2015 14:00:40 +0000 Subject: RFR(XS): 8085975: Fix warning "converting to jlong from double" of gcc 4.1.2 after 8079561 Message-ID: <4295855A5C1DE049A61835A1887419CC2CFE4F0E@DEWDFEMB12A.global.corp.sap> Hi, Since 8079561 our build with gcc 4.1.2 fails because of "timer.cpp:62: warning: converting to jlong from double". This change adds casts to fix this. Please review this change. I please need a sponsor. http://cr.openjdk.java.net/~goetz/webrevs/8085975-flt_conv/webrev.01/ This warning is enabled by default in gcc 4.1.2 and can only be turned off by turning off all warnings. We would like to avoid turning off all warnings, though. But because of Werror this breaks the gcc 4.1.2 build. The warning can be triggered by setting -Wconversion in gcc 4.8. This triggers a lot of undesired warnings, and thus is off since it got the current semantics in gcc 4.3. In gcc 4.9, the warning can be triggered with less extra noise by -Wfloat-conversion, which seems desireable to be turned on to me once that compiler is used. All similar code locations are fixed as required by 4.1.2 (e.g., see services/management.cpp:2170 return (jlong)(((double)ticks / (double)os::elapsed_frequency())), therefore I would like to fix this by adding casts. Best regards, Goetz. From volker.simonis at gmail.com Mon Jun 8 14:23:12 2015 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 8 Jun 2015 16:23:12 +0200 Subject: RFR(M): 8081674: EmptyStackException at startup if running with extended or unsupported charset In-Reply-To: References: Message-ID: Hi, can I please get a review at least for the part of this fix which is common for jdk8 and jdk9. It's only a few lines in src/share/vm/prims/jni.cpp for the hotspot repository and one line src/java.base/share/classes/java/lang/ClassLoader.java for the jdk repository. Thanks, Volker On Tue, Jun 2, 2015 at 6:12 PM, Volker Simonis wrote: > Hi, > > can I please have review (and a sponsor) for these changes: > > https://bugs.openjdk.java.net/browse/JDK-8081674 > http://cr.openjdk.java.net/~simonis/webrevs/2015/8081674.jdk > http://cr.openjdk.java.net/~simonis/webrevs/2015/8081674.hs > > Please notice that the fix requires synchronous changes in the jdk and the > hotspot forest. > > The changes themselves are by far not that big as this explanation but I > found the problem to be quite intricate so I tried to explain it as good as > I could. I'd suggest to read the HTML-formatted explanation in the webrev > although the content is equal to the one in this mail: > > Using an unsupported character encoding (e.g. vi_VN.TCVN on Linux) results > in an immediate VM failure with jdk 8 and 9: > > export LANG=vi_VN.TCVN > java -version > Error occurred during initialization of VM > java.util.EmptyStackException > at java.util.Stack.peek(Stack.java:102) > at java.lang.ClassLoader$NativeLibrary.getFromClass(ClassLoader.java:1751) > at java.lang.ClassLoader$NativeLibrary.findBuiltinLib(Native Method) > at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1862) > at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1835) > at java.lang.Runtime.loadLibrary0(Runtime.java:870) > at java.lang.System.loadLibrary(System.java:1119) > at java.lang.System.initializeSystemClass(System.java:1194) > > This is a consequence of "8005716: Enhance JNI specification to allow > support of static JNI libraries in Embedded JREs". > > With jdk 9 we get this error even if we're running with a supported charset > which is in the ExtendedCharsets (as opposed to being in the > StandardCharsets) class which is a consequence of delegating the loading of > the ExtendedCharsets class to the ServiceLoader in jdk 9. > > export LANG=eo.iso-8859-3 > output-jdk9/images/jdk/bin/java -version > Error occurred during initialization of VM > java.util.EmptyStackException > at java.util.Stack.peek(Stack.java:102) > at java.lang.ClassLoader$NativeLibrary.getFromClass(ClassLoader.java:1737) > at java.lang.ClassLoader$NativeLibrary.findBuiltinLib(Native Method) > at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1866) > at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1840) > at java.lang.Runtime.loadLibrary0(Runtime.java:874) > at java.lang.System.loadLibrary(System.java:1111) > at java.lang.System.initializeSystemClass(System.java:1186) > > Here's why the exception happens for an unsupported charset (see the mixed > stack trace below for the full details): > > java.lang.System.loadLibrary() wants to load libzip.so. It calls > java.lang.Runtime.loadLibrary0() which at the very beginning calls the > native method ClassLoader$NativeLibrary.findBuiltinLib() which checks if the > corresponding library is already statically linked into the VM (introduced > by 8005716). Java_java_lang_ClassLoader_00024NativeLibrary_findBuiltinLib(), > the native implementation of findBuiltinLib() in Classloader.c calls > GetStringPlatformChars() to convert the library name into the native > platform encoding. GetStringPlatformChars() calls the helper function > jnuEncodingSupported() to check if the platform encoding which is stored in > the property "sun.jnu.encoding" is supported by Java. jnuEncodingSupported() > is implemented as follows: > > static jboolean isJNUEncodingSupported = JNI_FALSE; > static jboolean jnuEncodingSupported(JNIEnv *env) { > jboolean exe; > if (isJNUEncodingSupported == JNI_TRUE) { > return JNI_TRUE; > } > isJNUEncodingSupported = (jboolean) JNU_CallStaticMethodByName ( > env, &exe, > "java/nio/charset/Charset", > "isSupported", > "(Ljava/lang/String;)Z", > jnuEncoding).z; > return isJNUEncodingSupported; > } > > Once the function finds that the platform encoding is supported (by calling > java.nio.charset.Charset.isSupported()) it caches this value and always > returns it on following calls. However if the platform encoding is not > supported, it ALWAYS calls java.nio.charset.Charset.isSupported() an every > subsequent invocation. > > In order to call the Java method Charset.isSupported() (in > JNU_CallStaticMethodByName() in file jni_util.c), we have to call > jni_FindClass() to convert the symbolic class name > "java.nio.charset.Charset" into a class reference. > > But unfortunately, jni_FindClass() (from jni.cpp in libjvm.so) has a special > handling if called from java.lang.ClassLoader$NativeLibrary to ensure that > JNI_OnLoad/JNI_OnUnload are executed in the correct class context: > > instanceKlassHandle k (THREAD, thread->security_get_caller_class(0)); > if (k.not_null()) { > loader = Handle(THREAD, k->class_loader()); > // Special handling to make sure JNI_OnLoad and JNI_OnUnload are > executed > // in the correct class context. > if (loader.is_null() && > k->name() == vmSymbols::java_lang_ClassLoader_NativeLibrary()) { > JavaValue result(T_OBJECT); > JavaCalls::call_static(&result, k, > vmSymbols::getFromClass_name(), > vmSymbols::void_class_signature(), > thread); > if (HAS_PENDING_EXCEPTION) { > Handle ex(thread, thread->pending_exception()); > CLEAR_PENDING_EXCEPTION; > THROW_HANDLE_0(ex); > } > > So if that's the case and jni_FindClass() was reallycalled from > ClassLoader$NativeLibrary, then jni_FindClass() calles > ClassLoader$NativeLibrary().getFromClass() to find out the corresponding > context class which is supposed to be saved there in a field of type > java.util.Stack named "nativeLibraryContext": > > // Invoked in the VM to determine the context class in > // JNI_Load/JNI_Unload > static Class getFromClass() { > return ClassLoader.nativeLibraryContext.peek().fromClass; > } > > Unfortunately, "nativeLibraryContext" doesn't contain any entry at this > point and the invocation of Stack.peek() will throw the exception shown > before. In general, the "nativeLibraryContext" stack will be filled later on > in Runtime.loadLibrary0() like this: > > NativeLibrary lib = new NativeLibrary(fromClass, name, isBuiltin); > nativeLibraryContext.push(lib); > try { > lib.load(name, isBuiltin); > } finally { > nativeLibraryContext.pop(); > } > > such that it always contains at least one element later when jni_FindClass() > will be invoked. > > So in summary, the problem is that the implementors of 8005716 didn't took > into account that calling ClassLoader$NativeLibrary.findBuiltinLib() may > trigger a call to jni_FindClass() if we are running on a system with an > unsupported character encoding. > > I'd suggest the following fix for this problem: > > Change ClassLoader$NativeLibrary().getFromClass() to return null if the > stack is empty instead of throwing an exception: > > static Class getFromClass() { > return ClassLoader.nativeLibraryContext.empty() ? > null : ClassLoader.nativeLibraryContext.peek().fromClass; > } > > Unfortunately this also requires a HotSpot change in jni_FindClass() in > order to properly handle the new 'null' return value: > > if (k.not_null()) { > loader = Handle(THREAD, k->class_loader()); > // Special handling to make sure JNI_OnLoad and JNI_OnUnload are > executed > // in the correct class context. > if (loader.is_null() && > k->name() == vmSymbols::java_lang_ClassLoader_NativeLibrary()) { > JavaValue result(T_OBJECT); > JavaCalls::call_static(&result, k, > vmSymbols::getFromClass_name(), > vmSymbols::void_class_signature(), > thread); > if (HAS_PENDING_EXCEPTION) { > Handle ex(thread, thread->pending_exception()); > CLEAR_PENDING_EXCEPTION; > THROW_HANDLE_0(ex); > } > oop mirror = (oop) result.get_jobject(); > if (oopDesc::is_null(mirror)) { > loader = Handle(THREAD, SystemDictionary::java_system_loader()); > } else { > loader = Handle(THREAD, > > InstanceKlass::cast(java_lang_Class::as_Klass(mirror))->class_loader()); > protection_domain = Handle(THREAD, > > InstanceKlass::cast(java_lang_Class::as_Klass(mirror))->protection_domain()); > } > } > } else { > // We call ClassLoader.getSystemClassLoader to obtain the system class > loader. > loader = Handle(THREAD, SystemDictionary::java_system_loader()); > } > > These changes are sufficient to solve the problem in Java 8. Unfortunately, > that's still not enough in Java 9 because there the loading of the extended > charsets has been delegated to ServiceLoader. But ServiceLoader calls > ClassLoader.getBootstrapResources() which calls > sun.misc.Launcher.getBootstrapClassPath(). This leads to another problem > during class initialization of sun.misc.Launcher if running on an > unsupported locale. > > The first thing done in sun.misc.Launcher. is the initialisation of > the bootstrap URLClassPath in the Launcher. However this initialisation will > eventually call Charset.isSupported() and if we are running on an > unsupported locale this will inevitably end in another recursive call to > ServiceLoader. But as explained below, ServiceLoader will query the > Launcher's bootstrap URLClassPath which will be still uninitialized at that > point. > > So we'll have to additionally guard guard against this situation on JDK 9 > like this: > > private static Charset lookupExtendedCharset(String charsetName) { > if (!sun.misc.VM.isBooted() || // see lookupViaProviders() > sun.misc.Launcher.getBootstrapClassPath() == null) > return null; > > This fixes the crashes, but still at the price of not having the extended > charsets available during initialization until > Launcher.getBootstrapClassPath is set up properly. This may be still a > problem if the jdk is installed in a directory which contains characters > specific to an extended encoding or if we have such characters in the > command line arguments. > > Thank you and best regards, > Volker > > > Mixed stack trace of the initial EmptyStackException for unsupported > charsets described before: > > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native > code) > j java.util.Stack.peek()Ljava/lang/Object;+1 > j java.lang.ClassLoader$NativeLibrary.getFromClass()Ljava/lang/Class;+3 > v ~StubRoutines::call_stub > V [libjvm.so+0x9d279a] JavaCalls::call_helper(JavaValue*, methodHandle*, > JavaCallArguments*, Thread*)+0x6b4 > V [libjvm.so+0xcad591] os::os_exception_wrapper(void (*)(JavaValue*, > methodHandle*, JavaCallArguments*, Thread*), JavaValue*, methodHandle*, > JavaCallArguments*, Thread*)+0x45 > V [libjvm.so+0x9d20cf] JavaCalls::call(JavaValue*, methodHandle, > JavaCallArguments*, Thread*)+0x8b > V [libjvm.so+0x9d1d3b] JavaCalls::call_static(JavaValue*, KlassHandle, > Symbol*, Symbol*, JavaCallArguments*, Thread*)+0x139 > V [libjvm.so+0x9d1e3f] JavaCalls::call_static(JavaValue*, KlassHandle, > Symbol*, Symbol*, Thread*)+0x9d > V [libjvm.so+0x9e6588] jni_FindClass+0x428 > C [libjava.so+0x20208] JNU_CallStaticMethodByName+0xff > C [libjava.so+0x21cae] jnuEncodingSupported+0x61 > C [libjava.so+0x22125] JNU_GetStringPlatformChars+0x125 > C [libjava.so+0xedcd] > Java_java_lang_ClassLoader_00024NativeLibrary_findBuiltinLib+0x8b > j > java.lang.ClassLoader$NativeLibrary.findBuiltinLib(Ljava/lang/String;)Ljava/lang/String;+0 > j java.lang.ClassLoader.loadLibrary0(Ljava/lang/Class;Ljava/io/File;)Z+4 > j > java.lang.ClassLoader.loadLibrary(Ljava/lang/Class;Ljava/lang/String;Z)V+228 > j java.lang.Runtime.loadLibrary0(Ljava/lang/Class;Ljava/lang/String;)V+54 > j java.lang.System.loadLibrary(Ljava/lang/String;)V+7 > j java.lang.System.initializeSystemClass()V+113 > v ~StubRoutines::call_stub > V [libjvm.so+0x9d279a] JavaCalls::call_helper(JavaValue*, methodHandle*, > JavaCallArguments*, Thread*)+0x6b4 > V [libjvm.so+0xcad591] os::os_exception_wrapper(void (*)(JavaValue*, > methodHandle*, JavaCallArguments*, Thread*), JavaValue*, methodHandle*, > JavaCallArguments*, Thread*)+0x45 > V [libjvm.so+0x9d20cf] JavaCalls::call(JavaValue*, methodHandle, > JavaCallArguments*, Thread*)+0x8b > V [libjvm.so+0x9d1d3b] JavaCalls::call_static(JavaValue*, KlassHandle, > Symbol*, Symbol*, JavaCallArguments*, Thread*)+0x139 > V [libjvm.so+0x9d1e3f] JavaCalls::call_static(JavaValue*, KlassHandle, > Symbol*, Symbol*, Thread*)+0x9d > V [libjvm.so+0xe3cceb] call_initializeSystemClass(Thread*)+0xb0 > V [libjvm.so+0xe44444] Threads::initialize_java_lang_classes(JavaThread*, > Thread*)+0x21a > V [libjvm.so+0xe44b12] Threads::create_vm(JavaVMInitArgs*, bool*)+0x4a6 > V [libjvm.so+0xa19bd7] JNI_CreateJavaVM+0xc7 > C [libjli.so+0xa520] InitializeJVM+0x154 > C [libjli.so+0x8024] JavaMain+0xcc > > From mikael.gerdin at oracle.com Mon Jun 8 14:25:45 2015 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Mon, 08 Jun 2015 16:25:45 +0200 Subject: RFR(XS): 8085975: Fix warning "converting to jlong from double" of gcc 4.1.2 after 8079561 In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CFE4F0E@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CFE4F0E@DEWDFEMB12A.global.corp.sap> Message-ID: <5575A5E9.6090602@oracle.com> Hi Goetz, On 2015-06-08 16:00, Lindenmaier, Goetz wrote: > Hi, > > Since 8079561 our build with gcc 4.1.2 fails because of "timer.cpp:62: warning: converting to jlong from double". > This change adds casts to fix this. > > Please review this change. I please need a sponsor. > http://cr.openjdk.java.net/~goetz/webrevs/8085975-flt_conv/webrev.01/ Looks good to me. /Mikael > > This warning is enabled by default in gcc 4.1.2 and can only be turned off by turning off all warnings. We would like to avoid turning off all warnings, though. But because of Werror this breaks the gcc 4.1.2 build. > The warning can be triggered by setting -Wconversion in gcc 4.8. This triggers a lot of undesired warnings, and thus is off since it got the current semantics in gcc 4.3. In gcc 4.9, the warning can be triggered with less extra noise by -Wfloat-conversion, which seems desireable to be turned on to me once that compiler is used. > > All similar code locations are fixed as required by 4.1.2 (e.g., see services/management.cpp:2170 return (jlong)(((double)ticks / (double)os::elapsed_frequency())), therefore I would like to fix this by adding casts. > > Best regards, > Goetz. > From gerard.ziemski at oracle.com Mon Jun 8 14:45:33 2015 From: gerard.ziemski at oracle.com (Gerard Ziemski) Date: Mon, 08 Jun 2015 09:45:33 -0500 Subject: Revision2: Corrected: RFR 8059557 (XL): Validate JVM Command-Line Flag Arguments In-Reply-To: <5571ECF9.5030105@oracle.com> References: <5554FE2D.6020405@oracle.com> <555E0028.8070108@oracle.com> <55663700.5050606@oracle.com> <5571ECF9.5030105@oracle.com> Message-ID: <5575AA8D.9080903@oracle.com> Excellent catch. Thank you Derek! On 6/5/2015 1:39 PM, Derek White wrote: > On 5/27/15 5:28 PM, Gerard Ziemski wrote: >> hi all, >> >> Here is a revision 2 of the feature taking into account feedback from >> Dmitry, David, Kim and Alexander. > > Hi Gerard, > > I was looking over Sangheon's table of GC arguments looking for easy > argument ranges to tighten, and saw an issue in your webrev: > > globals.hpp: > 2013 manageable(intx, CMSTriggerInterval, > -1, \ > 2014 "Commence a CMS collection cycle (at least) every so > many " \ > 2015 "milliseconds (0 permanently, -1 > disabled)") \ > 2016 range(-1, 0) > > The correct range is -1..max_intx. > > - Derek > > From sundararajan.athijegannathan at oracle.com Mon Jun 8 12:55:17 2015 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Mon, 08 Jun 2015 18:25:17 +0530 Subject: RFR: JDK-8085822 JEP 223: New Version-String Scheme (initial integration) In-Reply-To: <1136B10A-72A2-421D-8333-1943353F662C@oracle.com> References: <5571AD18.7080701@oracle.com> <55756194.3080506@oracle.com> <1136B10A-72A2-421D-8333-1943353F662C@oracle.com> Message-ID: <557590B5.8090906@oracle.com> +1 on Nashorn changes. -Sundar On Monday 08 June 2015 06:07 PM, Magnus Ihse Bursie wrote: >> 8 jun 2015 kl. 11:34 skrev Alan Bateman : >> >>> On 05/06/2015 15:07, Magnus Ihse Bursie wrote: >>> This review request covers the main part of the work for JEP-223, the new version string format [1]. Basically, we'll call this release Java "9", instead of Java "1.9.0". >>> >>> This patch is a folding of all work that has been done so far in the branch JEP-223-branch in jdk9/sandbox. As you can see, it mostly covers build changes, with some code changes in hotspot, jdk, nashorn and langtools that either are corresponding changes in the product code due to the compiler define flags changing from the build, or follow-up changes to handle the new format. >>> >>> The JEP-223 work is not finished by this patch. In fact, there are known issues remaining even after this patch, typically by code that reads the "java.version" property and tries to parse it. However, this patch is not directly destined for jdk9/dev, but will go into the special verona/stage forest. As for all patches destined for verona/stage it will be code reviewed as if going to jdk9/dev. Once in verona/stage it will bide its time, and it will be complemented with follow-up patches to address remaining issues. When all such issues are resolved and JEP-223 is fully implemented, all changes will be pushed at once (without further code reviews) into jdk9/dev. >>> >>> This patch has been contributed by Magnus Ihse Bursie, Kumar Srinivasan and Alejandro Murillo. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8085822 >>> WebRev: http://cr.openjdk.java.net/~ihse/JDK-8085822-JEP-223-initial-patch/webrev.01 >> I looked through the code changes, skipping most of the make files :-) >> >> Version.java.template - the comment in jvmSecurityVersion() still talks about 1.6 and newer. Can this be replaced to just say that it returns the security version? >> >> Will the update_version and special_update_version fields eventually be dropped from the jvm_version_info stricture? Related, there seems to be a typo in the comment in jdk_util.c where it has "specia_update_version". >> >> The webrev shows a change to this comment in jvm.h: >> "Third, this file contains various I/O and network operations needed by the standard Java I/O and network APIs." >> I think this comment can be removed because those JVM_* functions were removed some time ago. >> >> Otherwise looks okay to me. > The API functions in Version.java and jvm.h are not finished. The specification in the JEP talks about a java.util.Version, that I presume will replace the sun.misc.Version, and that will fully implement an API to access the version string and all it's parts, according to the JEP definition. Also, the native interface will have to be changed to accommodate a version number with an arbitrarily number of dot separated parts. These changes will be done later on in the verona/stage forest. > > Are you ok with addressing these concerns at such a later time? > > /Magnus > >> -Alan. From erik.helin at oracle.com Mon Jun 8 16:10:39 2015 From: erik.helin at oracle.com (Erik Helin) Date: Mon, 8 Jun 2015 18:10:39 +0200 Subject: RFR(XS): 8085975: Fix warning "converting to jlong from double" of gcc 4.1.2 after 8079561 In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CFE4F0E@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CFE4F0E@DEWDFEMB12A.global.corp.sap> Message-ID: <20150608161039.GB20782@ehelin.jrpg.bea.com> Looks good, Reviewed. I can sponsor the patch. Thanks, Erik On 2015-06-08, Lindenmaier, Goetz wrote: > Hi, > > Since 8079561 our build with gcc 4.1.2 fails because of "timer.cpp:62: warning: converting to jlong from double". > This change adds casts to fix this. > > Please review this change. I please need a sponsor. > http://cr.openjdk.java.net/~goetz/webrevs/8085975-flt_conv/webrev.01/ > > This warning is enabled by default in gcc 4.1.2 and can only be turned off by turning off all warnings. We would like to avoid turning off all warnings, though. But because of Werror this breaks the gcc 4.1.2 build. > The warning can be triggered by setting -Wconversion in gcc 4.8. This triggers a lot of undesired warnings, and thus is off since it got the current semantics in gcc 4.3. In gcc 4.9, the warning can be triggered with less extra noise by -Wfloat-conversion, which seems desireable to be turned on to me once that compiler is used. > > All similar code locations are fixed as required by 4.1.2 (e.g., see services/management.cpp:2170 return (jlong)(((double)ticks / (double)os::elapsed_frequency())), therefore I would like to fix this by adding casts. > > Best regards, > Goetz. From volker.simonis at gmail.com Mon Jun 8 18:31:41 2015 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 8 Jun 2015 20:31:41 +0200 Subject: RFR(S): 8080684: PPC64: Fix little-endian build after "8077838: Recent developments for ppc" In-Reply-To: References: Message-ID: Hi Sasha, you're right - my fix was too complicated. I should have just used function_entry() instead of emit_fd() because function_entry() already wraps either emit_fd() or pc() depending on the platform. That's exactly what I've done in the new patch: http://cr.openjdk.java.net/~simonis/webrevs/2015/8080684.v2/ As a bonus I've also fixed the Power 8 detection which was broken because we issued an illegal 'lqarx' instruction to determine if we're on Power 8. Regards, Volker PS: I was actually able to test this change on a REAL ppc64le machine this time :) On Wed, May 20, 2015 at 3:25 AM, Alexander Smundak wrote: > It fails to compile because the code still references FileDescriptor, > even if ABI_ELFv2 is defined. > The revised patch which succeeds is here: > http://cr.openjdk.java.net/~asmundak/8080684/hotspot/webrev > (it's for jdk8u-dev branch) > but IMHO the proposed change isn't semantically right -- > if a method is called emit_fd, it should create a FileDescriptor. > I am not sure that rationale behind this patch is right -- a > compile-time error is usually easy to fix and verify that the semantics > is correct while fixing it, whereas runtime error usually requires > more effort. > > > On Tue, May 19, 2015 at 9:41 AM, Volker Simonis > wrote: >> Hi, >> >> can I please get a review for the following fix of the ppc64le build. >> >> @Sasha, Tiago: I would be also especially interested if somebody with >> a little-endian ppc64 system can check if the fix really works there >> as I have currently no access to such a system. >> >> https://bugs.openjdk.java.net/browse/JDK-8080684 >> http://cr.openjdk.java.net/~simonis/webrevs/2015/8080684/ >> >> Following the details: >> >> On big-endian ppc64 we need so called 'function descriptors' instead >> of simple pointers in order to call functions. That's why the >> Assembler class on ppc64 offers an 'emit_fd()' method which can be >> used to create such a function descriptor. >> >> On little-endian ppc64 the ABI was changed (i.e. ABI_ELFv2) and >> function descriptors have been removed. That's why the before >> mentioned 'emit_fd()' is being excluded from the build with the help >> of preprocessor macros if the HotSpot is being build in a little >> endian environment: >> >> #if !defined(ABI_ELFv2) >> inline address emit_fd(...) >> #endif >> >> The drawback of this approach is that every call site which uses >> 'emit_fd()' has to conditionally handle the case where 'emit_fd()' >> isn't present as well. This was exactly the problem with change >> "8077838: Recent developments for ppc" which introduced an >> unconditional call to 'emit_fd()' in 'VM_Version::config_dscr() which >> lead to a build failure on little endian. >> >> A better approach would be to make 'emit_fd()' available on both, >> little- and big-endian platforms and handle the difference internally, >> within the function itself. On little-endian, the function will just >> return the current PC without emitting any code at all while the >> big-endian variant emits the required function descriptor. >> >> Thank you and best regards, >> Volker From Alan.Bateman at oracle.com Mon Jun 8 20:41:09 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 08 Jun 2015 21:41:09 +0100 Subject: RFR: JDK-8085822 JEP 223: New Version-String Scheme (initial integration) In-Reply-To: <1136B10A-72A2-421D-8333-1943353F662C@oracle.com> References: <5571AD18.7080701@oracle.com> <55756194.3080506@oracle.com> <1136B10A-72A2-421D-8333-1943353F662C@oracle.com> Message-ID: <5575FDE5.5020002@oracle.com> On 08/06/2015 13:37, Magnus Ihse Bursie wrote: > : > The API functions in Version.java and jvm.h are not finished. The specification in the JEP talks about a java.util.Version, that I presume will replace the sun.misc.Version, and that will fully implement an API to access the version string and all it's parts, according to the JEP definition. Also, the native interface will have to be changed to accommodate a version number with an arbitrarily number of dot separated parts. These changes will be done later on in the verona/stage forest. > > Are you ok with addressing these concerns at such a later time? > Sure, esp. since my comments are indeed in the area that isn't complete in this webrev. -Alan From daniel.daugherty at oracle.com Mon Jun 8 23:31:20 2015 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Mon, 08 Jun 2015 17:31:20 -0600 Subject: RFR: JDK-8085822 JEP 223: New Version-String Scheme (initial integration) In-Reply-To: <5571AD18.7080701@oracle.com> References: <5571AD18.7080701@oracle.com> Message-ID: <557625C8.5050200@oracle.com> > http://cr.openjdk.java.net/~ihse/JDK-8085822-JEP-223-initial-patch/webrev.01 General comment: Not all copyright years were updated. General comment: It looks like support for the 'patch' value is not completely implemented through all the Makefiles. I didn't audit for this, but it's just my impression. common/autoconf/configure.ac No comments. common/autoconf/flags.m4 No comments. common/autoconf/generated-configure.sh There are multiple Copyright notices in this file. Why? L4076: # Verify that a given string represent a valid version number, and assing it to L4077: # a variable. Fixed two typos and reformat a bit: # Verify that a given string represents a valid version number, and # assigning it to a variable. L20186-20189: indent for the block is off L20256-20259: indent for the block is off L20262: as_fn_error $? "--with--version-string must have a value" "$LINENO" 5 The '--with--version...' part doesn't match previous usages where '--with-version...' is used L20275: # Unspecified numerical fields is interpreted as 0. Grammar: 'is interpreted' -> 'are interpreted' L20286: as_fn_error $? "Version string contains + but both 'BUILD' and 'OPT' is missing" "$LINENO" 5 Grammar: 'is missing' -> 'are missing' L20292: as_fn_error $? "--with--version-string fails to parse The '--with--version...' part doesn't match previous usages where '--with-version...' is used L20297-L20302: indent for the block is off L20307: as_fn_error $? "--with--version-pre-base must have a value" "$LINENO" 5 L20315: { $as_echo "$as_me:${as_lineno-$LINENO}: WARNING: --with--version-pre-base value... L20316: $as_echo "$as_me: WARNING: --with--version-pre-base value... The '--with--version...' part doesn't match previous usages where '--with-version...' is used L20327-20332: indent for the block is off L20337: as_fn_error $? "--with--version-pre-debuglevel must have... L20345: { $as_echo "$as_me:${as_lineno-$LINENO}: WARNING: --with--version-pre-debuglevel value... L20346: $as_echo "$as_me: WARNING: --with--version-pre-debuglevel value The '--with--version...' part doesn't match previous usages where '--with-version...' is used L20361-20366: indent for the block is off L20371: as_fn_error $? "--with--version-opt must have... L20379: { $as_echo "$as_me:${as_lineno-$LINENO}: WARNING: --with--version-opt value L20380: $as_echo "$as_me: WARNING: --with--version-opt value has been The '--with--version...' part doesn't match previous usages where '--with-version...' is used At this point, I'm going to stop pointing out the '--with-version...' and '--with--version...' differences; don't know which usage is right. L20388-L20388: indent is off by one L20388: username=`$ECHO "$USER" | $TR -d -c '[a-z][A-Z][0-9]'` This assumes that the "USER" variable is set. Should there be a check for "" and perhaps use "no_user_specified" or something like that? Perhaps the build setup always makes sure that "USER" is set to something. Don't know. L20395-L20400: indent for the block is off L20413-L20431: indent of all blocks in this range are off L20444-L20449: indent for the block is off L20457-L20475: indent of all blocks in this range are off L20486-L20491: indent for the block is off L20504-L20522: indent of all blocks in this range are off L20533-L20538: indent for the block is off L20551-L20569: indent of all blocks in this range are off L20580-L20585: indent for the block is off L20598-L20616: indent of all blocks in this range are off common/autoconf/help.m4 No comments. common/autoconf/jdk-options.m4 Don't know why the 'elliptic curve crypto implementation' support is relocated as part of this changeset, but ... No comments. common/autoconf/spec.gmk.in No comments. common/autoconf/version-numbers No comments. common/nb_native/nbproject/configurations.xml No comments. make/Images.gmk No comments. make/Install.gmk No comments. make/Javadoc.gmk Did you mean to remove the 'clean' target? make/JrtfsJar.gmk No comments. make/MacBundles.gmk No comments. make/jprt.properties No comments. hotspot/make/Makefile No comments. hotspot/make/aix/Makefile No comments. hotspot/make/aix/makefiles/buildtree.make No comments. hotspot/make/aix/makefiles/defs.make No comments. hotspot/make/aix/makefiles/vm.make No comments. hotspot/make/bsd/Makefile No comments. hotspot/make/bsd/makefiles/buildtree.make No comments. hotspot/make/bsd/makefiles/defs.make No comments. hotspot/make/bsd/makefiles/vm.make No comments. hotspot/make/defs.make No comments. hotspot/make/jdk_version No comments. hotspot/make/linux/Makefile No comments. hotspot/make/linux/makefiles/buildtree.make No comments. hotspot/make/linux/makefiles/defs.make No comments. hotspot/make/linux/makefiles/vm.make No comments. hotspot/make/solaris/Makefile No comments. hotspot/make/solaris/makefiles/buildtree.make No comments. hotspot/make/solaris/makefiles/defs.make No comments. hotspot/make/solaris/makefiles/sparcWorks.make No comments. hotspot/make/solaris/makefiles/vm.make No comments. hotspot/make/windows/build.make No comments. hotspot/make/windows/makefiles/compile.make No changes in the frames view. Update: udiff view shows a blank line deleted at the end of the file. hotspot/make/windows/makefiles/debug.make No comments. hotspot/make/windows/makefiles/defs.make No comments. hotspot/make/windows/makefiles/fastdebug.make No comments. hotspot/make/windows/makefiles/product.make No comments. hotspot/make/windows/makefiles/vm.make No comments. hotspot/make/windows/projectfiles/common/Makefile No comments. hotspot/src/share/vm/prims/jvm.h No comments. hotspot/src/share/vm/runtime/arguments.cpp No comments. hotspot/src/share/vm/runtime/java.cpp L661: void JDK_Version::fully_initialize( L662: uint8_t major, uint8_t minor, uint8_t security, uint8_t update) { L663: // This is only called when current is less than 1.6 and we've gotten Since you're ripping out vestigial version support, I think this function can go away since this is version 9 and newer. Don't really know for sure, but based on that comment... hotspot/src/share/vm/runtime/java.hpp No comments. hotspot/src/share/vm/runtime/vmStructs.cpp L1240: please make the 'int' parameter align like the rest. hotspot/src/share/vm/runtime/vm_version.cpp L84: void Abstract_VM_Version::initialize() { L85: // FIXME: Initialization can probably be removed now. I agree, but that would entail also removing the _initialized and the uses of it... Follow on bug fix? hotspot/src/share/vm/runtime/vm_version.hpp No comments. hotspot/test/runtime/6981737/Test6981737.java No comments. jdk/make/CompileDemos.gmk No comments. jdk/make/data/mainmanifest/manifest.mf No comments. jdk/make/gensrc/GensrcMisc.gmk No comments. jdk/make/launcher/Launcher-jdk.accessibility.gmk No comments. jdk/make/launcher/Launcher-jdk.pack200.gmk No comments. jdk/make/launcher/LauncherCommon.gmk No comments. jdk/make/lib/CoreLibraries.gmk No comments. jdk/src/java.base/share/classes/sun/misc/Version.java.template L149: * Returns the security version of the running JVM if it's 1.6 or newer This JavaDoc update is wrong, but it might not be important if sun.misc.Version class is going away. jdk/src/java.base/share/native/include/jvm.h No comments. jdk/src/java.base/share/native/launcher/defines.h No comments. jdk/src/java.base/share/native/launcher/main.c No comments. jdk/src/java.base/share/native/libjava/System.c No comments. jdk/src/java.base/share/native/libjava/Version.c No comments. jdk/src/java.base/share/native/libjava/jdk_util.c No comments. jdk/src/java.base/windows/native/common/version.rc No comments. jdk/src/java.desktop/windows/native/libawt/windows/awt.rc No comments. jdk/src/jdk.accessibility/windows/native/common/AccessBridgeStatusWindow.RC No comments. jdk/test/sun/misc/Version/Version.java No comments. langtools/make/gensrc/GensrcCommon.gmk No comments. langtools/src/java.compiler/share/classes/javax/lang/model/SourceVersion.java old L171: case "1.9": new L171: case "9": Should this logic support both versions? Will dropping "1.9" here prevent a pre-version changeset JVM from being dropped into a JDK for triage purposes? Granted we don't often triage 'javac' with different JVMs, but... langtools/test/tools/javac/options/modes/InfoOptsTest.java No comments. langtools/test/tools/javac/options/modes/SourceTargetTest.java No comments. nashorn/make/BuildNashorn.gmk No comments. nashorn/make/build.xml No comments. nashorn/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/Version.java No comments. common/autoconf/jdk-version.m4 No comments. nashorn/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/resources/version.properties.template nashorn/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/resources/version.properties-template No comments. common/bin/test_builds.sh hotspot/make/jdk6_hotspot_distro No comments. Dan On 6/5/15 8:07 AM, Magnus Ihse Bursie wrote: > This review request covers the main part of the work for JEP-223, the > new version string format [1]. Basically, we'll call this release Java > "9", instead of Java "1.9.0". > > This patch is a folding of all work that has been done so far in the > branch JEP-223-branch in jdk9/sandbox. As you can see, it mostly > covers build changes, with some code changes in hotspot, jdk, nashorn > and langtools that either are corresponding changes in the product > code due to the compiler define flags changing from the build, or > follow-up changes to handle the new format. > > The JEP-223 work is not finished by this patch. In fact, there are > known issues remaining even after this patch, typically by code that > reads the "java.version" property and tries to parse it. However, this > patch is not directly destined for jdk9/dev, but will go into the > special verona/stage forest. As for all patches destined for > verona/stage it will be code reviewed as if going to jdk9/dev. Once in > verona/stage it will bide its time, and it will be complemented with > follow-up patches to address remaining issues. When all such issues > are resolved and JEP-223 is fully implemented, all changes will be > pushed at once (without further code reviews) into jdk9/dev. > > This patch has been contributed by Magnus Ihse Bursie, Kumar > Srinivasan and Alejandro Murillo. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8085822 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8085822-JEP-223-initial-patch/webrev.01 > > [1] http://openjdk.java.net/jeps/223 > From mandy.chung at oracle.com Mon Jun 8 23:35:06 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 08 Jun 2015 16:35:06 -0700 Subject: RFR(M): 8081674: EmptyStackException at startup if running with extended or unsupported charset In-Reply-To: References: Message-ID: <557626AA.6010008@oracle.com> Hi Volker, Your patch reminds me the question I have about loading zip library. In JDK 9 (and earlier release), zip library is loaded by the VM during startup (see ClassLoader::load_zip_library). I think loadLibrary("zip") is no longer needed to be called from System::initializeSystemClass method and instead it can be loaded by java.util.zip.ZipFile static initializer. Do you mind to try the patch (below)? That may be a simpler fix. I never like the way jni_FindClass to look for the class context by calling the NativeLibrary::getFromClass method. I will have to look deeper other alternative to clean that up. If taking out loadLibrary("zip") resolves your issue, this will give us time to come up with a better clean-up in the future. Mandy [1] https://bugs.openjdk.java.net/browse/JDK-4429040 diff --git a/src/share/classes/java/lang/System.java b/src/share/classes/java/lang/System.java --- a/src/share/classes/java/lang/System.java +++ b/src/share/classes/java/lang/System.java @@ -1192,10 +1192,6 @@ setOut0(newPrintStream(fdOut, props.getProperty("sun.stdout.encoding"))); setErr0(newPrintStream(fdErr, props.getProperty("sun.stderr.encoding"))); - // Load the zip library now in order to keep java.util.zip.ZipFile - // from trying to use itself to load this library later. - loadLibrary("zip"); - // Setup Java signal handlers for HUP, TERM, and INT (where available). Terminator.setup(); diff --git a/src/share/classes/java/util/zip/ZipFile.java b/src/share/classes/java/util/zip/ZipFile.java --- a/src/share/classes/java/util/zip/ZipFile.java +++ b/src/share/classes/java/util/zip/ZipFile.java @@ -83,6 +83,7 @@ static { /* Zip library is loaded from System.initializeSystemClass */ + System.loadLibrary("zip"); initIDs(); } On 06/08/2015 07:23 AM, Volker Simonis wrote: > Hi, > > can I please get a review at least for the part of this fix which is > common for jdk8 and jdk9. It's only a few lines in > src/share/vm/prims/jni.cpp for the hotspot repository and one line > src/java.base/share/classes/java/lang/ClassLoader.java for the jdk > repository. > > Thanks, > Volker > > > On Tue, Jun 2, 2015 at 6:12 PM, Volker Simonis wrote: >> Hi, >> >> can I please have review (and a sponsor) for these changes: >> >> https://bugs.openjdk.java.net/browse/JDK-8081674 >> http://cr.openjdk.java.net/~simonis/webrevs/2015/8081674.jdk >> http://cr.openjdk.java.net/~simonis/webrevs/2015/8081674.hs >> >> Please notice that the fix requires synchronous changes in the jdk and the >> hotspot forest. >> >> The changes themselves are by far not that big as this explanation but I >> found the problem to be quite intricate so I tried to explain it as good as >> I could. I'd suggest to read the HTML-formatted explanation in the webrev >> although the content is equal to the one in this mail: >> >> Using an unsupported character encoding (e.g. vi_VN.TCVN on Linux) results >> in an immediate VM failure with jdk 8 and 9: >> >> export LANG=vi_VN.TCVN >> java -version >> Error occurred during initialization of VM >> java.util.EmptyStackException >> at java.util.Stack.peek(Stack.java:102) >> at java.lang.ClassLoader$NativeLibrary.getFromClass(ClassLoader.java:1751) >> at java.lang.ClassLoader$NativeLibrary.findBuiltinLib(Native Method) >> at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1862) >> at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1835) >> at java.lang.Runtime.loadLibrary0(Runtime.java:870) >> at java.lang.System.loadLibrary(System.java:1119) >> at java.lang.System.initializeSystemClass(System.java:1194) >> >> This is a consequence of "8005716: Enhance JNI specification to allow >> support of static JNI libraries in Embedded JREs". >> >> With jdk 9 we get this error even if we're running with a supported charset >> which is in the ExtendedCharsets (as opposed to being in the >> StandardCharsets) class which is a consequence of delegating the loading of >> the ExtendedCharsets class to the ServiceLoader in jdk 9. >> >> export LANG=eo.iso-8859-3 >> output-jdk9/images/jdk/bin/java -version >> Error occurred during initialization of VM >> java.util.EmptyStackException >> at java.util.Stack.peek(Stack.java:102) >> at java.lang.ClassLoader$NativeLibrary.getFromClass(ClassLoader.java:1737) >> at java.lang.ClassLoader$NativeLibrary.findBuiltinLib(Native Method) >> at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1866) >> at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1840) >> at java.lang.Runtime.loadLibrary0(Runtime.java:874) >> at java.lang.System.loadLibrary(System.java:1111) >> at java.lang.System.initializeSystemClass(System.java:1186) >> >> Here's why the exception happens for an unsupported charset (see the mixed >> stack trace below for the full details): >> >> java.lang.System.loadLibrary() wants to load libzip.so. It calls >> java.lang.Runtime.loadLibrary0() which at the very beginning calls the >> native method ClassLoader$NativeLibrary.findBuiltinLib() which checks if the >> corresponding library is already statically linked into the VM (introduced >> by 8005716). Java_java_lang_ClassLoader_00024NativeLibrary_findBuiltinLib(), >> the native implementation of findBuiltinLib() in Classloader.c calls >> GetStringPlatformChars() to convert the library name into the native >> platform encoding. GetStringPlatformChars() calls the helper function >> jnuEncodingSupported() to check if the platform encoding which is stored in >> the property "sun.jnu.encoding" is supported by Java. jnuEncodingSupported() >> is implemented as follows: >> >> static jboolean isJNUEncodingSupported = JNI_FALSE; >> static jboolean jnuEncodingSupported(JNIEnv *env) { >> jboolean exe; >> if (isJNUEncodingSupported == JNI_TRUE) { >> return JNI_TRUE; >> } >> isJNUEncodingSupported = (jboolean) JNU_CallStaticMethodByName ( >> env, &exe, >> "java/nio/charset/Charset", >> "isSupported", >> "(Ljava/lang/String;)Z", >> jnuEncoding).z; >> return isJNUEncodingSupported; >> } >> >> Once the function finds that the platform encoding is supported (by calling >> java.nio.charset.Charset.isSupported()) it caches this value and always >> returns it on following calls. However if the platform encoding is not >> supported, it ALWAYS calls java.nio.charset.Charset.isSupported() an every >> subsequent invocation. >> >> In order to call the Java method Charset.isSupported() (in >> JNU_CallStaticMethodByName() in file jni_util.c), we have to call >> jni_FindClass() to convert the symbolic class name >> "java.nio.charset.Charset" into a class reference. >> >> But unfortunately, jni_FindClass() (from jni.cpp in libjvm.so) has a special >> handling if called from java.lang.ClassLoader$NativeLibrary to ensure that >> JNI_OnLoad/JNI_OnUnload are executed in the correct class context: >> >> instanceKlassHandle k (THREAD, thread->security_get_caller_class(0)); >> if (k.not_null()) { >> loader = Handle(THREAD, k->class_loader()); >> // Special handling to make sure JNI_OnLoad and JNI_OnUnload are >> executed >> // in the correct class context. >> if (loader.is_null() && >> k->name() == vmSymbols::java_lang_ClassLoader_NativeLibrary()) { >> JavaValue result(T_OBJECT); >> JavaCalls::call_static(&result, k, >> vmSymbols::getFromClass_name(), >> vmSymbols::void_class_signature(), >> thread); >> if (HAS_PENDING_EXCEPTION) { >> Handle ex(thread, thread->pending_exception()); >> CLEAR_PENDING_EXCEPTION; >> THROW_HANDLE_0(ex); >> } >> >> So if that's the case and jni_FindClass() was reallycalled from >> ClassLoader$NativeLibrary, then jni_FindClass() calles >> ClassLoader$NativeLibrary().getFromClass() to find out the corresponding >> context class which is supposed to be saved there in a field of type >> java.util.Stack named "nativeLibraryContext": >> >> // Invoked in the VM to determine the context class in >> // JNI_Load/JNI_Unload >> static Class getFromClass() { >> return ClassLoader.nativeLibraryContext.peek().fromClass; >> } >> >> Unfortunately, "nativeLibraryContext" doesn't contain any entry at this >> point and the invocation of Stack.peek() will throw the exception shown >> before. In general, the "nativeLibraryContext" stack will be filled later on >> in Runtime.loadLibrary0() like this: >> >> NativeLibrary lib = new NativeLibrary(fromClass, name, isBuiltin); >> nativeLibraryContext.push(lib); >> try { >> lib.load(name, isBuiltin); >> } finally { >> nativeLibraryContext.pop(); >> } >> >> such that it always contains at least one element later when jni_FindClass() >> will be invoked. >> >> So in summary, the problem is that the implementors of 8005716 didn't took >> into account that calling ClassLoader$NativeLibrary.findBuiltinLib() may >> trigger a call to jni_FindClass() if we are running on a system with an >> unsupported character encoding. >> >> I'd suggest the following fix for this problem: >> >> Change ClassLoader$NativeLibrary().getFromClass() to return null if the >> stack is empty instead of throwing an exception: >> >> static Class getFromClass() { >> return ClassLoader.nativeLibraryContext.empty() ? >> null : ClassLoader.nativeLibraryContext.peek().fromClass; >> } >> >> Unfortunately this also requires a HotSpot change in jni_FindClass() in >> order to properly handle the new 'null' return value: >> >> if (k.not_null()) { >> loader = Handle(THREAD, k->class_loader()); >> // Special handling to make sure JNI_OnLoad and JNI_OnUnload are >> executed >> // in the correct class context. >> if (loader.is_null() && >> k->name() == vmSymbols::java_lang_ClassLoader_NativeLibrary()) { >> JavaValue result(T_OBJECT); >> JavaCalls::call_static(&result, k, >> vmSymbols::getFromClass_name(), >> vmSymbols::void_class_signature(), >> thread); >> if (HAS_PENDING_EXCEPTION) { >> Handle ex(thread, thread->pending_exception()); >> CLEAR_PENDING_EXCEPTION; >> THROW_HANDLE_0(ex); >> } >> oop mirror = (oop) result.get_jobject(); >> if (oopDesc::is_null(mirror)) { >> loader = Handle(THREAD, SystemDictionary::java_system_loader()); >> } else { >> loader = Handle(THREAD, >> >> InstanceKlass::cast(java_lang_Class::as_Klass(mirror))->class_loader()); >> protection_domain = Handle(THREAD, >> >> InstanceKlass::cast(java_lang_Class::as_Klass(mirror))->protection_domain()); >> } >> } >> } else { >> // We call ClassLoader.getSystemClassLoader to obtain the system class >> loader. >> loader = Handle(THREAD, SystemDictionary::java_system_loader()); >> } >> >> These changes are sufficient to solve the problem in Java 8. Unfortunately, >> that's still not enough in Java 9 because there the loading of the extended >> charsets has been delegated to ServiceLoader. But ServiceLoader calls >> ClassLoader.getBootstrapResources() which calls >> sun.misc.Launcher.getBootstrapClassPath(). This leads to another problem >> during class initialization of sun.misc.Launcher if running on an >> unsupported locale. >> >> The first thing done in sun.misc.Launcher. is the initialisation of >> the bootstrap URLClassPath in the Launcher. However this initialisation will >> eventually call Charset.isSupported() and if we are running on an >> unsupported locale this will inevitably end in another recursive call to >> ServiceLoader. But as explained below, ServiceLoader will query the >> Launcher's bootstrap URLClassPath which will be still uninitialized at that >> point. >> >> So we'll have to additionally guard guard against this situation on JDK 9 >> like this: >> >> private static Charset lookupExtendedCharset(String charsetName) { >> if (!sun.misc.VM.isBooted() || // see lookupViaProviders() >> sun.misc.Launcher.getBootstrapClassPath() == null) >> return null; >> >> This fixes the crashes, but still at the price of not having the extended >> charsets available during initialization until >> Launcher.getBootstrapClassPath is set up properly. This may be still a >> problem if the jdk is installed in a directory which contains characters >> specific to an extended encoding or if we have such characters in the >> command line arguments. >> >> Thank you and best regards, >> Volker >> >> >> Mixed stack trace of the initial EmptyStackException for unsupported >> charsets described before: >> >> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native >> code) >> j java.util.Stack.peek()Ljava/lang/Object;+1 >> j java.lang.ClassLoader$NativeLibrary.getFromClass()Ljava/lang/Class;+3 >> v ~StubRoutines::call_stub >> V [libjvm.so+0x9d279a] JavaCalls::call_helper(JavaValue*, methodHandle*, >> JavaCallArguments*, Thread*)+0x6b4 >> V [libjvm.so+0xcad591] os::os_exception_wrapper(void (*)(JavaValue*, >> methodHandle*, JavaCallArguments*, Thread*), JavaValue*, methodHandle*, >> JavaCallArguments*, Thread*)+0x45 >> V [libjvm.so+0x9d20cf] JavaCalls::call(JavaValue*, methodHandle, >> JavaCallArguments*, Thread*)+0x8b >> V [libjvm.so+0x9d1d3b] JavaCalls::call_static(JavaValue*, KlassHandle, >> Symbol*, Symbol*, JavaCallArguments*, Thread*)+0x139 >> V [libjvm.so+0x9d1e3f] JavaCalls::call_static(JavaValue*, KlassHandle, >> Symbol*, Symbol*, Thread*)+0x9d >> V [libjvm.so+0x9e6588] jni_FindClass+0x428 >> C [libjava.so+0x20208] JNU_CallStaticMethodByName+0xff >> C [libjava.so+0x21cae] jnuEncodingSupported+0x61 >> C [libjava.so+0x22125] JNU_GetStringPlatformChars+0x125 >> C [libjava.so+0xedcd] >> Java_java_lang_ClassLoader_00024NativeLibrary_findBuiltinLib+0x8b >> j >> java.lang.ClassLoader$NativeLibrary.findBuiltinLib(Ljava/lang/String;)Ljava/lang/String;+0 >> j java.lang.ClassLoader.loadLibrary0(Ljava/lang/Class;Ljava/io/File;)Z+4 >> j >> java.lang.ClassLoader.loadLibrary(Ljava/lang/Class;Ljava/lang/String;Z)V+228 >> j java.lang.Runtime.loadLibrary0(Ljava/lang/Class;Ljava/lang/String;)V+54 >> j java.lang.System.loadLibrary(Ljava/lang/String;)V+7 >> j java.lang.System.initializeSystemClass()V+113 >> v ~StubRoutines::call_stub >> V [libjvm.so+0x9d279a] JavaCalls::call_helper(JavaValue*, methodHandle*, >> JavaCallArguments*, Thread*)+0x6b4 >> V [libjvm.so+0xcad591] os::os_exception_wrapper(void (*)(JavaValue*, >> methodHandle*, JavaCallArguments*, Thread*), JavaValue*, methodHandle*, >> JavaCallArguments*, Thread*)+0x45 >> V [libjvm.so+0x9d20cf] JavaCalls::call(JavaValue*, methodHandle, >> JavaCallArguments*, Thread*)+0x8b >> V [libjvm.so+0x9d1d3b] JavaCalls::call_static(JavaValue*, KlassHandle, >> Symbol*, Symbol*, JavaCallArguments*, Thread*)+0x139 >> V [libjvm.so+0x9d1e3f] JavaCalls::call_static(JavaValue*, KlassHandle, >> Symbol*, Symbol*, Thread*)+0x9d >> V [libjvm.so+0xe3cceb] call_initializeSystemClass(Thread*)+0xb0 >> V [libjvm.so+0xe44444] Threads::initialize_java_lang_classes(JavaThread*, >> Thread*)+0x21a >> V [libjvm.so+0xe44b12] Threads::create_vm(JavaVMInitArgs*, bool*)+0x4a6 >> V [libjvm.so+0xa19bd7] JNI_CreateJavaVM+0xc7 >> C [libjli.so+0xa520] InitializeJVM+0x154 >> C [libjli.so+0x8024] JavaMain+0xcc >> >> From asmundak at google.com Tue Jun 9 02:49:49 2015 From: asmundak at google.com (Alexander Smundak) Date: Mon, 8 Jun 2015 19:49:49 -0700 Subject: RFR(S): 8080684: PPC64: Fix little-endian build after "8077838: Recent developments for ppc" In-Reply-To: References: Message-ID: Looks good to me. Regards, Sasha On Mon, Jun 8, 2015 at 11:31 AM, Volker Simonis wrote: > Hi Sasha, > > you're right - my fix was too complicated. I should have just used > function_entry() instead of emit_fd() because function_entry() already > wraps either emit_fd() or pc() depending on the platform. That's > exactly what I've done in the new patch: > > http://cr.openjdk.java.net/~simonis/webrevs/2015/8080684.v2/ > > As a bonus I've also fixed the Power 8 detection which was broken > because we issued an illegal 'lqarx' instruction to determine if we're > on Power 8. > > Regards, > Volker > > PS: I was actually able to test this change on a REAL ppc64le machine > this time :) > > > > On Wed, May 20, 2015 at 3:25 AM, Alexander Smundak wrote: >> It fails to compile because the code still references FileDescriptor, >> even if ABI_ELFv2 is defined. >> The revised patch which succeeds is here: >> http://cr.openjdk.java.net/~asmundak/8080684/hotspot/webrev >> (it's for jdk8u-dev branch) >> but IMHO the proposed change isn't semantically right -- >> if a method is called emit_fd, it should create a FileDescriptor. >> I am not sure that rationale behind this patch is right -- a >> compile-time error is usually easy to fix and verify that the semantics >> is correct while fixing it, whereas runtime error usually requires >> more effort. >> >> >> On Tue, May 19, 2015 at 9:41 AM, Volker Simonis >> wrote: >>> Hi, >>> >>> can I please get a review for the following fix of the ppc64le build. >>> >>> @Sasha, Tiago: I would be also especially interested if somebody with >>> a little-endian ppc64 system can check if the fix really works there >>> as I have currently no access to such a system. >>> >>> https://bugs.openjdk.java.net/browse/JDK-8080684 >>> http://cr.openjdk.java.net/~simonis/webrevs/2015/8080684/ >>> >>> Following the details: >>> >>> On big-endian ppc64 we need so called 'function descriptors' instead >>> of simple pointers in order to call functions. That's why the >>> Assembler class on ppc64 offers an 'emit_fd()' method which can be >>> used to create such a function descriptor. >>> >>> On little-endian ppc64 the ABI was changed (i.e. ABI_ELFv2) and >>> function descriptors have been removed. That's why the before >>> mentioned 'emit_fd()' is being excluded from the build with the help >>> of preprocessor macros if the HotSpot is being build in a little >>> endian environment: >>> >>> #if !defined(ABI_ELFv2) >>> inline address emit_fd(...) >>> #endif >>> >>> The drawback of this approach is that every call site which uses >>> 'emit_fd()' has to conditionally handle the case where 'emit_fd()' >>> isn't present as well. This was exactly the problem with change >>> "8077838: Recent developments for ppc" which introduced an >>> unconditional call to 'emit_fd()' in 'VM_Version::config_dscr() which >>> lead to a build failure on little endian. >>> >>> A better approach would be to make 'emit_fd()' available on both, >>> little- and big-endian platforms and handle the difference internally, >>> within the function itself. On little-endian, the function will just >>> return the current PC without emitting any code at all while the >>> big-endian variant emits the required function descriptor. >>> >>> Thank you and best regards, >>> Volker From david.holmes at oracle.com Tue Jun 9 04:21:45 2015 From: david.holmes at oracle.com (David Holmes) Date: Tue, 09 Jun 2015 14:21:45 +1000 Subject: GCC 4.8.3+ Does anybody aware of Stack Smashing Protection ? In-Reply-To: <5571F91D.2020003@oracle.com> References: <5571F91D.2020003@oracle.com> Message-ID: <557669D9.704@oracle.com> Hi Dmitry, On 6/06/2015 5:31 AM, Dmitry Samersoff wrote: > Hi Everybody, > > I'm not sure it affects hotspot but should we care about it? > > FYI: > > Beginning with GCC 4.8.3, Stack Smashing Protection (SSP) will be > enabled by default. The 4.8 series will enable -fstack-protector > while 4.9 and later enable -fstack-protector-strong. We initially added -fstack-protector-all (and related settings under): https://bugs.openjdk.java.net/browse/JDK-8032045 We removed the -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 definitions under 8047952 as they broke fastdebug builds. If we were to make the official compiler one that enables this by default then we would have to re-examine its affects on all platforms and the costs involved - and then allow or disable as appropriate. Cheers, David > SSP is a security feature that attempts to mitigate stack-based buffer > overflows by placing a canary value on the stack after the function > return pointer and checking for that value before the function returns. > If a buffer overflow occurs and the canary value is overwritten, the > program aborts. > > There is a small performance cost to these features. They can be > disabled with -fno-stack-protector. > > For more information these options, refer to the GCC Manual, or the > following articles. > > http://en.wikipedia.org/wiki/Buffer_overflow_protection > http://en.wikipedia.org/wiki/Stack_buffer_overflow > https://securityblog.redhat.com/tag/stack-protector > http://www.outflux.net/blog/archives/2014/01/27/fstack-protector-strong > > -Dmitry > From kim.barrett at oracle.com Tue Jun 9 05:51:56 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 9 Jun 2015 01:51:56 -0400 Subject: RFR: 8086027: Multiple STATIC_ASSERTs at class scope doesn't work Message-ID: Third time's the charm? Please review this change to the STATIC_ASSERT macro, to allow multiple assertions in the same class scope. It seems we do need to make the typedef names used in the expansion unique per scope; see CR for details. We accomplish this with preprocessor token pasting with __LINE__ (done correctly, unlike in the change for JDK-8067306). Apparently my testing for JDK-8073994 missed the class scope case. With this change set I'm adding tests for all three of namespace, class, and function scope. As part of this, I'm also adding PASTE_TOKENS(x, y) utility macro. I'm willing to entertain alternative naming suggestions, though hoping to avoid a bikeshed discussion. CR: https://bugs.openjdk.java.net/browse/JDK-8086027 Webrev: http://cr.openjdk.java.net/~kbarrett/8086027/webrev.00/ Testing: JPRT From david.holmes at oracle.com Tue Jun 9 06:17:44 2015 From: david.holmes at oracle.com (David Holmes) Date: Tue, 09 Jun 2015 16:17:44 +1000 Subject: RFR: 8086027: Multiple STATIC_ASSERTs at class scope doesn't work In-Reply-To: References: Message-ID: <55768508.6090602@oracle.com> Hi Kim, On 9/06/2015 3:51 PM, Kim Barrett wrote: > Third time's the charm? > > Please review this change to the STATIC_ASSERT macro, to allow > multiple assertions in the same class scope. > > It seems we do need to make the typedef names used in the expansion > unique per scope; see CR for details. We accomplish this with > preprocessor token pasting with __LINE__ (done correctly, unlike in > the change for JDK-8067306). Seems okay to me (but then so did previous version ). > Apparently my testing for JDK-8073994 missed the class scope case. > With this change set I'm adding tests for all three of namespace, > class, and function scope. Ok. > As part of this, I'm also adding PASTE_TOKENS(x, y) utility macro. > I'm willing to entertain alternative naming suggestions, though hoping > to avoid a bikeshed discussion. As we already have XSTR for the single token case, what about XSTRCAT ? Thanks, David > CR: > https://bugs.openjdk.java.net/browse/JDK-8086027 > > Webrev: > http://cr.openjdk.java.net/~kbarrett/8086027/webrev.00/ > > Testing: > JPRT > From goetz.lindenmaier at sap.com Tue Jun 9 06:21:01 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 9 Jun 2015 06:21:01 +0000 Subject: RFR(S): 8080684: PPC64: Fix little-endian build after "8077838: Recent developments for ppc" In-Reply-To: References: Message-ID: <4295855A5C1DE049A61835A1887419CC2CFE508C@DEWDFEMB12A.global.corp.sap> HI Volker, the change looks good. Thanks for fixing this! Best regards, Goetz. -----Original Message----- From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Volker Simonis Sent: Montag, 8. Juni 2015 20:32 To: Alexander Smundak Cc: ppc-aix-port-dev at openjdk.java.net; HotSpot Open Source Developers; Tiago St?rmer Daitx Subject: Re: RFR(S): 8080684: PPC64: Fix little-endian build after "8077838: Recent developments for ppc" Hi Sasha, you're right - my fix was too complicated. I should have just used function_entry() instead of emit_fd() because function_entry() already wraps either emit_fd() or pc() depending on the platform. That's exactly what I've done in the new patch: http://cr.openjdk.java.net/~simonis/webrevs/2015/8080684.v2/ As a bonus I've also fixed the Power 8 detection which was broken because we issued an illegal 'lqarx' instruction to determine if we're on Power 8. Regards, Volker PS: I was actually able to test this change on a REAL ppc64le machine this time :) On Wed, May 20, 2015 at 3:25 AM, Alexander Smundak wrote: > It fails to compile because the code still references FileDescriptor, > even if ABI_ELFv2 is defined. > The revised patch which succeeds is here: > http://cr.openjdk.java.net/~asmundak/8080684/hotspot/webrev > (it's for jdk8u-dev branch) > but IMHO the proposed change isn't semantically right -- > if a method is called emit_fd, it should create a FileDescriptor. > I am not sure that rationale behind this patch is right -- a > compile-time error is usually easy to fix and verify that the semantics > is correct while fixing it, whereas runtime error usually requires > more effort. > > > On Tue, May 19, 2015 at 9:41 AM, Volker Simonis > wrote: >> Hi, >> >> can I please get a review for the following fix of the ppc64le build. >> >> @Sasha, Tiago: I would be also especially interested if somebody with >> a little-endian ppc64 system can check if the fix really works there >> as I have currently no access to such a system. >> >> https://bugs.openjdk.java.net/browse/JDK-8080684 >> http://cr.openjdk.java.net/~simonis/webrevs/2015/8080684/ >> >> Following the details: >> >> On big-endian ppc64 we need so called 'function descriptors' instead >> of simple pointers in order to call functions. That's why the >> Assembler class on ppc64 offers an 'emit_fd()' method which can be >> used to create such a function descriptor. >> >> On little-endian ppc64 the ABI was changed (i.e. ABI_ELFv2) and >> function descriptors have been removed. That's why the before >> mentioned 'emit_fd()' is being excluded from the build with the help >> of preprocessor macros if the HotSpot is being build in a little >> endian environment: >> >> #if !defined(ABI_ELFv2) >> inline address emit_fd(...) >> #endif >> >> The drawback of this approach is that every call site which uses >> 'emit_fd()' has to conditionally handle the case where 'emit_fd()' >> isn't present as well. This was exactly the problem with change >> "8077838: Recent developments for ppc" which introduced an >> unconditional call to 'emit_fd()' in 'VM_Version::config_dscr() which >> lead to a build failure on little endian. >> >> A better approach would be to make 'emit_fd()' available on both, >> little- and big-endian platforms and handle the difference internally, >> within the function itself. On little-endian, the function will just >> return the current PC without emitting any code at all while the >> big-endian variant emits the required function descriptor. >> >> Thank you and best regards, >> Volker From goetz.lindenmaier at sap.com Tue Jun 9 06:22:25 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 9 Jun 2015 06:22:25 +0000 Subject: RFR(XS): 8085975: Fix warning "converting to jlong from double" of gcc 4.1.2 after 8079561 In-Reply-To: <20150608161039.GB20782@ehelin.jrpg.bea.com> References: <4295855A5C1DE049A61835A1887419CC2CFE4F0E@DEWDFEMB12A.global.corp.sap> <20150608161039.GB20782@ehelin.jrpg.bea.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2CFE5113@DEWDFEMB12A.global.corp.sap> HI Erik, thanks for the review and sponsoring! Best regards, Goetz. -----Original Message----- From: Erik Helin [mailto:erik.helin at oracle.com] Sent: Montag, 8. Juni 2015 18:11 To: Lindenmaier, Goetz Cc: HotSpot Developers Subject: Re: RFR(XS): 8085975: Fix warning "converting to jlong from double" of gcc 4.1.2 after 8079561 Looks good, Reviewed. I can sponsor the patch. Thanks, Erik On 2015-06-08, Lindenmaier, Goetz wrote: > Hi, > > Since 8079561 our build with gcc 4.1.2 fails because of "timer.cpp:62: warning: converting to jlong from double". > This change adds casts to fix this. > > Please review this change. I please need a sponsor. > http://cr.openjdk.java.net/~goetz/webrevs/8085975-flt_conv/webrev.01/ > > This warning is enabled by default in gcc 4.1.2 and can only be turned off by turning off all warnings. We would like to avoid turning off all warnings, though. But because of Werror this breaks the gcc 4.1.2 build. > The warning can be triggered by setting -Wconversion in gcc 4.8. This triggers a lot of undesired warnings, and thus is off since it got the current semantics in gcc 4.3. In gcc 4.9, the warning can be triggered with less extra noise by -Wfloat-conversion, which seems desireable to be turned on to me once that compiler is used. > > All similar code locations are fixed as required by 4.1.2 (e.g., see services/management.cpp:2170 return (jlong)(((double)ticks / (double)os::elapsed_frequency())), therefore I would like to fix this by adding casts. > > Best regards, > Goetz. From goetz.lindenmaier at sap.com Tue Jun 9 06:22:47 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 9 Jun 2015 06:22:47 +0000 Subject: RFR(XS): 8085975: Fix warning "converting to jlong from double" of gcc 4.1.2 after 8079561 In-Reply-To: <5575A5E9.6090602@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CFE4F0E@DEWDFEMB12A.global.corp.sap> <5575A5E9.6090602@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2CFE5123@DEWDFEMB12A.global.corp.sap> Hi Mikael, thanks for looking at this! Best regards, Goetz. -----Original Message----- From: Mikael Gerdin [mailto:mikael.gerdin at oracle.com] Sent: Montag, 8. Juni 2015 16:26 To: Lindenmaier, Goetz; HotSpot Developers Subject: Re: RFR(XS): 8085975: Fix warning "converting to jlong from double" of gcc 4.1.2 after 8079561 Hi Goetz, On 2015-06-08 16:00, Lindenmaier, Goetz wrote: > Hi, > > Since 8079561 our build with gcc 4.1.2 fails because of "timer.cpp:62: warning: converting to jlong from double". > This change adds casts to fix this. > > Please review this change. I please need a sponsor. > http://cr.openjdk.java.net/~goetz/webrevs/8085975-flt_conv/webrev.01/ Looks good to me. /Mikael > > This warning is enabled by default in gcc 4.1.2 and can only be turned off by turning off all warnings. We would like to avoid turning off all warnings, though. But because of Werror this breaks the gcc 4.1.2 build. > The warning can be triggered by setting -Wconversion in gcc 4.8. This triggers a lot of undesired warnings, and thus is off since it got the current semantics in gcc 4.3. In gcc 4.9, the warning can be triggered with less extra noise by -Wfloat-conversion, which seems desireable to be turned on to me once that compiler is used. > > All similar code locations are fixed as required by 4.1.2 (e.g., see services/management.cpp:2170 return (jlong)(((double)ticks / (double)os::elapsed_frequency())), therefore I would like to fix this by adding casts. > > Best regards, > Goetz. > From bengt.rutisson at oracle.com Tue Jun 9 08:48:05 2015 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Tue, 09 Jun 2015 10:48:05 +0200 Subject: RFR: 8086027: Multiple STATIC_ASSERTs at class scope doesn't work In-Reply-To: References: Message-ID: <5576A845.9010507@oracle.com> Hi Kim, On 2015-06-09 07:51, Kim Barrett wrote: > Third time's the charm? :) > > Please review this change to the STATIC_ASSERT macro, to allow > multiple assertions in the same class scope. > > It seems we do need to make the typedef names used in the expansion > unique per scope; see CR for details. We accomplish this with > preprocessor token pasting with __LINE__ (done correctly, unlike in > the change for JDK-8067306). > > Apparently my testing for JDK-8073994 missed the class scope case. > With this change set I'm adding tests for all three of namespace, > class, and function scope. > > As part of this, I'm also adding PASTE_TOKENS(x, y) utility macro. > I'm willing to entertain alternative naming suggestions, though hoping > to avoid a bikeshed discussion. I don't have any better suggestions for the names. I would be fine with XSTRCAT as suggested by David Holmes. Or maybe just XCAT since we are dealing with tokens and not strings. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8086027 > > Webrev: > http://cr.openjdk.java.net/~kbarrett/8086027/webrev.00/ This looks good to me. One question about the test in debug.cpp: 792 // class scope 793 struct TestMultipleStaticAssertFormsInClassScope { I know struct and class are pretty much the same, but wouldn't it be more consistent to use class instead of struct here since the comment (and I think the spec) talk about class scope? Either way is fine with me and in any case you don't need to send out another webrev. Thanks, Bengt > > Testing: > JPRT > From magnus.ihse.bursie at oracle.com Tue Jun 9 13:12:19 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 09 Jun 2015 15:12:19 +0200 Subject: RFR: JDK-8085822 JEP 223: New Version-String Scheme (initial integration) In-Reply-To: <557625C8.5050200@oracle.com> References: <5571AD18.7080701@oracle.com> <557625C8.5050200@oracle.com> Message-ID: <5576E633.9050503@oracle.com> Hi Daniel, Thank you for your thorough review! On 2015-06-09 01:31, Daniel D. Daugherty wrote: > > > http://cr.openjdk.java.net/~ihse/JDK-8085822-JEP-223-initial-patch/webrev.01 > > > General comment: Not all copyright years were updated. > General comment: It looks like support for the 'patch' value is not > completely > implemented through all the Makefiles. I didn't audit for this, > but it's > just my impression. You are basically correct. The makefiles all propagate the patch value where needed, but the actual source code changes in hotspot and jdk ignores the patch field as of now. This will be corrected in a later add-on patch, submitted by someone from the jdk and/or hotspot team rather than the build team. > > common/autoconf/generated-configure.sh > There are multiple Copyright notices in this file. Why? Oh dear, you've reviewed the generated file. :-& I'm really impressed by your effort! However, the generated-configure.sh file is automatically created by the autoconf framework from the rest of the files in common/autoconf/*, so we cannot direcly modify it's contents - only indirectly. The reason it's checked in, is that otherwise every user would need to generate it before being able to run configure. In build reviews, we usually either revert changes to generated-configure.sh before posting a review to hide it (and re-generate it before pushing), or we just ignore it during reviews. I should have done that, or pointed out that it was not needed nor possible to review when I cross-posted. I'm sorry. > > L4076: # Verify that a given string represent a valid version > number, and assing it to > L4077: # a variable. > Fixed two typos and reformat a bit: > # Verify that a given string represents a valid version > number, and > # assigning it to a variable. I'll put that fix in the source .m4 file instead. Thanks. > > L20262: as_fn_error $? "--with--version-string must have a > value" "$LINENO" 5 > The '--with--version...' part doesn't match previous usages where > '--with-version...' is used Yes, you're right. Erik pointed it out as well. It's a typo in the error message. It's all over the place due to copied code. I'll fix it in the source .m4 file. (As a side note, I have a half-finished follow-up patch that will reduce the amount of code duplication, but it requires some framework changes so it'll have to be a separate thing.) > > L20275: # Unspecified numerical fields is interpreted as 0. > Grammar: 'is interpreted' -> 'are interpreted' > > L20286: as_fn_error $? "Version string contains + but both > 'BUILD' and 'OPT' is missing" "$LINENO" 5 > Grammar: 'is missing' -> 'are missing' Those darn English plural forms! Why can't you all do as we sensible Swedes and get rid of them? ;-) (I'll fix) > > L20388: username=`$ECHO "$USER" | $TR -d -c '[a-z][A-Z][0-9]'` > This assumes that the "USER" variable is set. Should there > be a check for "" and perhaps use "no_user_specified" or > something like that? Perhaps the build setup always makes > sure that "USER" is set to something. Don't know. Hm. I think the worst thing that'll happen is that the username part of the opt string gets empty. This part is basically copied right off the old build, where we have relied on the $USER variable being present for all the time with no problems, so I think it's quite safe to assume. > > common/autoconf/jdk-options.m4 > Don't know why the 'elliptic curve crypto implementation' support > is relocated as part of this changeset, but ... It was incorrectly placed not at the top indentation level, but in the middle of the function definition where the old versioning code were handled. (Which, mostly by chance, happens to work in autoconf, but is really bad style). > make/Javadoc.gmk > Did you mean to remove the 'clean' target? Yep. Cleaning is done by the top-level Main.gmk makefile nowadays, that's just some dead code. > > hotspot/make/windows/makefiles/compile.make > No changes in the frames view. > Update: udiff view shows a blank line deleted at the end of the file. That's probably the result of some change going forth and then back again during development. But then again, removing extra blank linkes is not a bad thing. (jcheck unfortunately does not enforce any style checks for make files :-( so they tend to detoriate over time.) > > hotspot/src/share/vm/runtime/java.cpp > L661: void JDK_Version::fully_initialize( > L662: uint8_t major, uint8_t minor, uint8_t security, uint8_t > update) { > L663: // This is only called when current is less than 1.6 and > we've gotten > > Since you're ripping out vestigial version support, I think this > function can go away since this is version 9 and newer. Don't > really > know for sure, but based on that comment... It probably can, yes. This and other core changes to the actual .cpp/.java files will be addressed in a follow-up patch. > > hotspot/src/share/vm/runtime/java.hpp > No comments. > > hotspot/src/share/vm/runtime/vmStructs.cpp > L1240: please make the 'int' parameter align like the rest. Are you okay with defering such a change to a follow-up patch? It's likely the entire struct will need changes to be able to handle a theoretically arbitrarily long version number. > > hotspot/src/share/vm/runtime/vm_version.cpp > L84: void Abstract_VM_Version::initialize() { > L85: // FIXME: Initialization can probably be removed now. > I agree, but that would entail also removing the > _initialized and the uses of it... Follow on bug fix? Definitely follow on. > jdk/src/java.base/share/classes/sun/misc/Version.java.template > L149: * Returns the security version of the running JVM if > it's 1.6 or newer > This JavaDoc update is wrong, but it might not be important > if sun.misc.Version class is going away. I'm not sure if it's going to be replaced by, or just complemented by java.util.Version, but in any case it will need a follow-up patch to clean up this and other issues. > langtools/src/java.compiler/share/classes/javax/lang/model/SourceVersion.java > > old L171: case "1.9": > new L171: case "9": > Should this logic support both versions? Will dropping > "1.9" here prevent a pre-version changeset JVM from > being dropped into a JDK for triage purposes? > > Granted we don't often triage 'javac' with different JVMs, but... I'll defer that question to Kumar, who wrote that piece of code. My guess is that when Hotspot express was dropped, the ability to use a JVM from another JDK release bit rotteded away. /Magnus From daniel.daugherty at oracle.com Tue Jun 9 13:20:27 2015 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 09 Jun 2015 07:20:27 -0600 Subject: RFR: JDK-8085822 JEP 223: New Version-String Scheme (initial integration) In-Reply-To: <5576E633.9050503@oracle.com> References: <5571AD18.7080701@oracle.com> <557625C8.5050200@oracle.com> <5576E633.9050503@oracle.com> Message-ID: <5576E81B.8050703@oracle.com> On 6/9/15 7:12 AM, Magnus Ihse Bursie wrote: > Hi Daniel, > > Thank you for your thorough review! This was my (failing) attempt at a "fast pass" review... :-) > > On 2015-06-09 01:31, Daniel D. Daugherty wrote: >> > >> http://cr.openjdk.java.net/~ihse/JDK-8085822-JEP-223-initial-patch/webrev.01 >> >> >> General comment: Not all copyright years were updated. >> General comment: It looks like support for the 'patch' value is not >> completely >> implemented through all the Makefiles. I didn't audit for this, >> but it's >> just my impression. > > You are basically correct. The makefiles all propagate the patch value > where needed, but the actual source code changes in hotspot and jdk > ignores the patch field as of now. This will be corrected in a later > add-on patch, submitted by someone from the jdk and/or hotspot team > rather than the build team. > >> >> common/autoconf/generated-configure.sh >> There are multiple Copyright notices in this file. Why? > Oh dear, you've reviewed the generated file. :-& I'm really impressed > by your effort! Ahhh... now that you say it... it sounds familiar... I may have made this same mistake before. I'll try to remember next time. > However, the generated-configure.sh file is automatically created by > the autoconf framework from the rest of the files in > common/autoconf/*, so we cannot direcly modify it's contents - only > indirectly. The reason it's checked in, is that otherwise every user > would need to generate it before being able to run configure. In build > reviews, we usually either revert changes to generated-configure.sh > before posting a review to hide it (and re-generate it before > pushing), or we just ignore it during reviews. I should have done > that, or pointed out that it was not needed nor possible to review > when I cross-posted. I'm sorry. > >> >> L4076: # Verify that a given string represent a valid version >> number, and assing it to >> L4077: # a variable. >> Fixed two typos and reformat a bit: >> # Verify that a given string represents a valid version >> number, and >> # assigning it to a variable. > I'll put that fix in the source .m4 file instead. Thanks. >> >> L20262: as_fn_error $? "--with--version-string must have a >> value" "$LINENO" 5 >> The '--with--version...' part doesn't match previous usages >> where >> '--with-version...' is used > Yes, you're right. Erik pointed it out as well. It's a typo in the > error message. It's all over the place due to copied code. I'll fix it > in the source .m4 file. > > (As a side note, I have a half-finished follow-up patch that will > reduce the amount of code duplication, but it requires some framework > changes so it'll have to be a separate thing.) > >> >> L20275: # Unspecified numerical fields is interpreted as 0. >> Grammar: 'is interpreted' -> 'are interpreted' >> >> L20286: as_fn_error $? "Version string contains + but >> both 'BUILD' and 'OPT' is missing" "$LINENO" 5 >> Grammar: 'is missing' -> 'are missing' > Those darn English plural forms! Why can't you all do as we sensible > Swedes and get rid of them? ;-) > > (I'll fix) > >> >> L20388: username=`$ECHO "$USER" | $TR -d -c >> '[a-z][A-Z][0-9]'` >> This assumes that the "USER" variable is set. Should there >> be a check for "" and perhaps use "no_user_specified" or >> something like that? Perhaps the build setup always makes >> sure that "USER" is set to something. Don't know. > Hm. I think the worst thing that'll happen is that the username part > of the opt string gets empty. This part is basically copied right off > the old build, where we have relied on the $USER variable being > present for all the time with no problems, so I think it's quite safe > to assume. >> >> common/autoconf/jdk-options.m4 >> Don't know why the 'elliptic curve crypto implementation' support >> is relocated as part of this changeset, but ... > It was incorrectly placed not at the top indentation level, but in the > middle of the function definition where the old versioning code were > handled. (Which, mostly by chance, happens to work in autoconf, but is > really bad style). > >> make/Javadoc.gmk >> Did you mean to remove the 'clean' target? > Yep. Cleaning is done by the top-level Main.gmk makefile nowadays, > that's just some dead code. > >> >> hotspot/make/windows/makefiles/compile.make >> No changes in the frames view. >> Update: udiff view shows a blank line deleted at the end of the >> file. > > That's probably the result of some change going forth and then back > again during development. But then again, removing extra blank linkes > is not a bad thing. (jcheck unfortunately does not enforce any style > checks for make files :-( so they tend to detoriate over time.) > >> >> hotspot/src/share/vm/runtime/java.cpp >> L661: void JDK_Version::fully_initialize( >> L662: uint8_t major, uint8_t minor, uint8_t security, uint8_t >> update) { >> L663: // This is only called when current is less than 1.6 and >> we've gotten >> >> Since you're ripping out vestigial version support, I think this >> function can go away since this is version 9 and newer. Don't >> really >> know for sure, but based on that comment... > It probably can, yes. This and other core changes to the actual > .cpp/.java files will be addressed in a follow-up patch. >> >> hotspot/src/share/vm/runtime/java.hpp >> No comments. >> >> hotspot/src/share/vm/runtime/vmStructs.cpp >> L1240: please make the 'int' parameter align like the rest. > Are you okay with defering such a change to a follow-up patch? Yes. > It's likely the entire struct will need changes to be able to handle a > theoretically arbitrarily long version number. > >> >> hotspot/src/share/vm/runtime/vm_version.cpp >> L84: void Abstract_VM_Version::initialize() { >> L85: // FIXME: Initialization can probably be removed now. >> I agree, but that would entail also removing the >> _initialized and the uses of it... Follow on bug fix? > Definitely follow on. > >> jdk/src/java.base/share/classes/sun/misc/Version.java.template >> L149: * Returns the security version of the running JVM if >> it's 1.6 or newer >> This JavaDoc update is wrong, but it might not be important >> if sun.misc.Version class is going away. > I'm not sure if it's going to be replaced by, or just complemented by > java.util.Version, but in any case it will need a follow-up patch to > clean up this and other issues. >> langtools/src/java.compiler/share/classes/javax/lang/model/SourceVersion.java >> >> old L171: case "1.9": >> new L171: case "9": >> Should this logic support both versions? Will dropping >> "1.9" here prevent a pre-version changeset JVM from >> being dropped into a JDK for triage purposes? >> >> Granted we don't often triage 'javac' with different JVMs, >> but... > I'll defer that question to Kumar, who wrote that piece of code. My > guess is that when Hotspot express was dropped, the ability to use a > JVM from another JDK release bit rotteded away. > > /Magnus Dan From sgehwolf at redhat.com Tue Jun 9 13:27:25 2015 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 09 Jun 2015 15:27:25 +0200 Subject: [8u60] Backport RFR: JDK-8078666 and JDK-8074312 Message-ID: <1433856445.3310.105.camel@redhat.com> Hi, Could I please get JDK-8078666 and JDK-8074312 backported to 8u60? I'd need a sponsor for this. We've been using the JDK-8078666 fix for Fedora 22 on JDK8 for a while now. Similarly, the fix for JDK-8074312 is now also required for Fedora 21 and we've had this patch in use since March. "Enable hotspot builds on 4.x Linux kernels" Bug: https://bugs.openjdk.java.net/browse/JDK-8074312 Webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8074312/8-backport/ Original review thread: http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-March/017463.html JDK 9 fix applies cleanly modulo copyright changes. "JVM fastdebug build compiled with GCC 5 asserts with "widen increases" Bug: https://bugs.openjdk.java.net/browse/JDK-8078666 Original review thread: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2015-April/017759.html JDK 9 fix applies cleanly to 8u forest. Thanks, Severin From claes.redestad at oracle.com Tue Jun 9 13:26:27 2015 From: claes.redestad at oracle.com (Claes Redestad) Date: Tue, 09 Jun 2015 15:26:27 +0200 Subject: RFR: JDK-8085822 JEP 223: New Version-String Scheme (initial integration) In-Reply-To: <5576E633.9050503@oracle.com> References: <5571AD18.7080701@oracle.com> <557625C8.5050200@oracle.com> <5576E633.9050503@oracle.com> Message-ID: <5576E983.5020902@oracle.com> On 2015-06-09 15:12, Magnus Ihse Bursie wrote: >> langtools/src/java.compiler/share/classes/javax/lang/model/SourceVersion.java >> >> old L171: case "1.9": >> new L171: case "9": >> Should this logic support both versions? Will dropping >> "1.9" here prevent a pre-version changeset JVM from >> being dropped into a JDK for triage purposes? >> >> Granted we don't often triage 'javac' with different JVMs, >> but... > I'll defer that question to Kumar, who wrote that piece of code. My > guess is that when Hotspot express was dropped, the ability to use a > JVM from another JDK release bit rotteded away. > > /Magnus While we know there's no guarantee that swapping in an older VM will work, in the face of a regression in a promoted build we still routinely (automatically, even) swap out the VM with a recent VM to get a rough estimate of whether the regression was caused by a HotSpot or JDK/tools change, mostly since this currently saves us time in narrowing down the changes to bisect over/investigate. So, there's at least some value in not intentionally breaking build-to-build backwards compatibility, but we don't expect it to always work and wouldn't make much fuss about it breaking. If an extra case "1.9" is all it takes to make it work with last week's VM, however... /Claes From magnus.ihse.bursie at oracle.com Tue Jun 9 13:36:55 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 09 Jun 2015 15:36:55 +0200 Subject: RFR: JDK-8085822 JEP 223: New Version-String Scheme (initial integration) In-Reply-To: <5576E983.5020902@oracle.com> References: <5571AD18.7080701@oracle.com> <557625C8.5050200@oracle.com> <5576E633.9050503@oracle.com> <5576E983.5020902@oracle.com> Message-ID: <5576EBF7.40607@oracle.com> On 2015-06-09 15:26, Claes Redestad wrote: > On 2015-06-09 15:12, Magnus Ihse Bursie wrote: >>> langtools/src/java.compiler/share/classes/javax/lang/model/SourceVersion.java >>> >>> old L171: case "1.9": >>> new L171: case "9": >>> Should this logic support both versions? Will dropping >>> "1.9" here prevent a pre-version changeset JVM from >>> being dropped into a JDK for triage purposes? >>> >>> Granted we don't often triage 'javac' with different JVMs, >>> but... >> I'll defer that question to Kumar, who wrote that piece of code. My >> guess is that when Hotspot express was dropped, the ability to use a >> JVM from another JDK release bit rotteded away. >> >> /Magnus > > While we know there's no guarantee that swapping in an older VM will > work, in the face of a regression in a promoted build we still > routinely (automatically, even) swap out the VM with a recent VM to > get a rough estimate of whether the regression was caused by a HotSpot > or JDK/tools change, mostly since this currently saves us time in > narrowing down the changes to bisect over/investigate. So, there's at > least some value in not intentionally breaking build-to-build > backwards compatibility, but we don't expect it to always work and > wouldn't make much fuss about it breaking. If an extra case "1.9" is > all it takes to make it work with last week's VM, however... Actually, I think I messed up a bit there. I believe the real question here was not about mixing different versions of Hotspot and the JDK, but mixing different versions of javac and the JDK. I think. :) /Magnus From magnus.ihse.bursie at oracle.com Tue Jun 9 13:52:20 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 09 Jun 2015 15:52:20 +0200 Subject: RFR: JDK-8085822 JEP 223: New Version-String Scheme (initial integration) In-Reply-To: <5576E81B.8050703@oracle.com> References: <5571AD18.7080701@oracle.com> <557625C8.5050200@oracle.com> <5576E633.9050503@oracle.com> <5576E81B.8050703@oracle.com> Message-ID: <5576EF94.3010500@oracle.com> Here's an updated webrev, which fixes the typos that were pointed out by reviewers: http://cr.openjdk.java.net/~ihse/JDK-8085822-JEP-223-initial-patch/webrev.02/ And here's a (much simpler) delta webrev which shows just these changes: http://cr.openjdk.java.net/~ihse/JDK-8085822-JEP-223-initial-patch-delta-01/webrev.01/ /Magnus On 2015-06-09 15:20, Daniel D. Daugherty wrote: > On 6/9/15 7:12 AM, Magnus Ihse Bursie wrote: >> Hi Daniel, >> >> Thank you for your thorough review! > > This was my (failing) attempt at a "fast pass" review... :-) > > >> >> On 2015-06-09 01:31, Daniel D. Daugherty wrote: >>> > >>> http://cr.openjdk.java.net/~ihse/JDK-8085822-JEP-223-initial-patch/webrev.01 >>> >>> >>> General comment: Not all copyright years were updated. >>> General comment: It looks like support for the 'patch' value is not >>> completely >>> implemented through all the Makefiles. I didn't audit for this, >>> but it's >>> just my impression. >> >> You are basically correct. The makefiles all propagate the patch >> value where needed, but the actual source code changes in hotspot and >> jdk ignores the patch field as of now. This will be corrected in a >> later add-on patch, submitted by someone from the jdk and/or hotspot >> team rather than the build team. >> >>> >>> common/autoconf/generated-configure.sh >>> There are multiple Copyright notices in this file. Why? >> Oh dear, you've reviewed the generated file. :-& I'm really impressed >> by your effort! > > Ahhh... now that you say it... it sounds familiar... I may have > made this same mistake before. I'll try to remember next time. > > >> However, the generated-configure.sh file is automatically created by >> the autoconf framework from the rest of the files in >> common/autoconf/*, so we cannot direcly modify it's contents - only >> indirectly. The reason it's checked in, is that otherwise every user >> would need to generate it before being able to run configure. In >> build reviews, we usually either revert changes to >> generated-configure.sh before posting a review to hide it (and >> re-generate it before pushing), or we just ignore it during reviews. >> I should have done that, or pointed out that it was not needed nor >> possible to review when I cross-posted. I'm sorry. >> >>> >>> L4076: # Verify that a given string represent a valid version >>> number, and assing it to >>> L4077: # a variable. >>> Fixed two typos and reformat a bit: >>> # Verify that a given string represents a valid version >>> number, and >>> # assigning it to a variable. >> I'll put that fix in the source .m4 file instead. Thanks. >>> >>> L20262: as_fn_error $? "--with--version-string must have a >>> value" "$LINENO" 5 >>> The '--with--version...' part doesn't match previous usages >>> where >>> '--with-version...' is used >> Yes, you're right. Erik pointed it out as well. It's a typo in the >> error message. It's all over the place due to copied code. I'll fix >> it in the source .m4 file. >> >> (As a side note, I have a half-finished follow-up patch that will >> reduce the amount of code duplication, but it requires some framework >> changes so it'll have to be a separate thing.) >> >>> >>> L20275: # Unspecified numerical fields is interpreted as 0. >>> Grammar: 'is interpreted' -> 'are interpreted' >>> >>> L20286: as_fn_error $? "Version string contains + but >>> both 'BUILD' and 'OPT' is missing" "$LINENO" 5 >>> Grammar: 'is missing' -> 'are missing' >> Those darn English plural forms! Why can't you all do as we sensible >> Swedes and get rid of them? ;-) >> >> (I'll fix) >> >>> >>> L20388: username=`$ECHO "$USER" | $TR -d -c >>> '[a-z][A-Z][0-9]'` >>> This assumes that the "USER" variable is set. Should there >>> be a check for "" and perhaps use "no_user_specified" or >>> something like that? Perhaps the build setup always makes >>> sure that "USER" is set to something. Don't know. >> Hm. I think the worst thing that'll happen is that the username part >> of the opt string gets empty. This part is basically copied right off >> the old build, where we have relied on the $USER variable being >> present for all the time with no problems, so I think it's quite safe >> to assume. >>> >>> common/autoconf/jdk-options.m4 >>> Don't know why the 'elliptic curve crypto implementation' support >>> is relocated as part of this changeset, but ... >> It was incorrectly placed not at the top indentation level, but in >> the middle of the function definition where the old versioning code >> were handled. (Which, mostly by chance, happens to work in autoconf, >> but is really bad style). >> >>> make/Javadoc.gmk >>> Did you mean to remove the 'clean' target? >> Yep. Cleaning is done by the top-level Main.gmk makefile nowadays, >> that's just some dead code. >> >>> >>> hotspot/make/windows/makefiles/compile.make >>> No changes in the frames view. >>> Update: udiff view shows a blank line deleted at the end of the >>> file. >> >> That's probably the result of some change going forth and then back >> again during development. But then again, removing extra blank linkes >> is not a bad thing. (jcheck unfortunately does not enforce any style >> checks for make files :-( so they tend to detoriate over time.) >> >>> >>> hotspot/src/share/vm/runtime/java.cpp >>> L661: void JDK_Version::fully_initialize( >>> L662: uint8_t major, uint8_t minor, uint8_t security, >>> uint8_t update) { >>> L663: // This is only called when current is less than 1.6 and >>> we've gotten >>> >>> Since you're ripping out vestigial version support, I think >>> this >>> function can go away since this is version 9 and newer. >>> Don't really >>> know for sure, but based on that comment... >> It probably can, yes. This and other core changes to the actual >> .cpp/.java files will be addressed in a follow-up patch. >>> >>> hotspot/src/share/vm/runtime/java.hpp >>> No comments. >>> >>> hotspot/src/share/vm/runtime/vmStructs.cpp >>> L1240: please make the 'int' parameter align like the rest. >> Are you okay with defering such a change to a follow-up patch? > > Yes. > > >> It's likely the entire struct will need changes to be able to handle >> a theoretically arbitrarily long version number. >> >>> >>> hotspot/src/share/vm/runtime/vm_version.cpp >>> L84: void Abstract_VM_Version::initialize() { >>> L85: // FIXME: Initialization can probably be removed now. >>> I agree, but that would entail also removing the >>> _initialized and the uses of it... Follow on bug fix? >> Definitely follow on. >> >>> jdk/src/java.base/share/classes/sun/misc/Version.java.template >>> L149: * Returns the security version of the running JVM if >>> it's 1.6 or newer >>> This JavaDoc update is wrong, but it might not be important >>> if sun.misc.Version class is going away. >> I'm not sure if it's going to be replaced by, or just complemented by >> java.util.Version, but in any case it will need a follow-up patch to >> clean up this and other issues. >>> langtools/src/java.compiler/share/classes/javax/lang/model/SourceVersion.java >>> >>> old L171: case "1.9": >>> new L171: case "9": >>> Should this logic support both versions? Will dropping >>> "1.9" here prevent a pre-version changeset JVM from >>> being dropped into a JDK for triage purposes? >>> >>> Granted we don't often triage 'javac' with different JVMs, >>> but... >> I'll defer that question to Kumar, who wrote that piece of code. My >> guess is that when Hotspot express was dropped, the ability to use a >> JVM from another JDK release bit rotteded away. >> >> /Magnus > > Dan From goetz.lindenmaier at sap.com Tue Jun 9 15:17:53 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 9 Jun 2015 15:17:53 +0000 Subject: RFR(M): 8086069: Adapt runtime calls to recent intrinsics to pass ints as long Message-ID: <4295855A5C1DE049A61835A1887419CC2CFE5374@DEWDFEMB12A.global.corp.sap> Hi, we are working on porting the recently* added intrinsics to PPC. As these use runtime calls, the calls must obey to the platform ABI, which requires that ints are passed as longs. We made a similar change in "8024342: PPC64 (part 111): Support for C calling conventions that require 64-bit ints." It adapts the calls if CCallingConventionRequiresIntsAsLongs is set. This change adapts the calls to multiplyToLen, CRC32, AES, SHA accordingly. Please review this change. I please need a sponsor. http://cr.openjdk.java.net/~goetz/webrevs/8086069-call_conv/webrev.01/ Best regards, Goetz * i.e., added after making our initial port From volker.simonis at gmail.com Tue Jun 9 17:09:04 2015 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 9 Jun 2015 19:09:04 +0200 Subject: RFR(M): 8081674: EmptyStackException at startup if running with extended or unsupported charset In-Reply-To: <557626AA.6010008@oracle.com> References: <557626AA.6010008@oracle.com> Message-ID: Hi Mandy, thanks for looking into this. Uunfortunately your fix only helps to fix "java -version" :( Running even a minimal HelloWorld will still fail with the following stack trace which is still caused by the same EmptyStackException: Error: A JNI error has occurred, please check your installation and try again Exception in thread "main" java.lang.ExceptionInInitializerError at sun.misc.Unsafe.ensureClassInitialized(Native Method) at sun.misc.SharedSecrets.getJavaUtilZipFileAccess(SharedSecrets.java:158) at sun.misc.URLClassPath$JarLoader.(URLClassPath.java:765) at sun.misc.URLClassPath$3.run(URLClassPath.java:530) at sun.misc.URLClassPath$3.run(URLClassPath.java:520) at java.security.AccessController.doPrivileged(Native Method) at sun.misc.URLClassPath.getLoader(URLClassPath.java:519) at sun.misc.URLClassPath.getLoader(URLClassPath.java:492) at sun.misc.URLClassPath.getNextLoader(URLClassPath.java:457) at sun.misc.URLClassPath.access$100(URLClassPath.java:64) at sun.misc.URLClassPath$1.next(URLClassPath.java:239) at sun.misc.URLClassPath$1.hasMoreElements(URLClassPath.java:250) at java.net.URLClassLoader$3$1.run(URLClassLoader.java:601) at java.net.URLClassLoader$3$1.run(URLClassLoader.java:599) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader$3.next(URLClassLoader.java:598) at java.net.URLClassLoader$3.hasMoreElements(URLClassLoader.java:623) at sun.misc.CompoundEnumeration.next(CompoundEnumeration.java:45) at sun.misc.CompoundEnumeration.hasMoreElements(CompoundEnumeration.java:54) at sun.misc.CompoundEnumeration.next(CompoundEnumeration.java:45) at sun.misc.CompoundEnumeration.hasMoreElements(CompoundEnumeration.java:54) at java.util.ServiceLoader$LazyIterator.hasNextService(ServiceLoader.java:354) at java.util.ServiceLoader$LazyIterator.hasNext(ServiceLoader.java:393) at java.util.ServiceLoader$1.hasNext(ServiceLoader.java:474) at java.nio.charset.Charset$1.getNext(Charset.java:350) at java.nio.charset.Charset$1.hasNext(Charset.java:365) at java.nio.charset.Charset$2.run(Charset.java:410) at java.nio.charset.Charset$2.run(Charset.java:407) at java.security.AccessController.doPrivileged(Native Method) at java.nio.charset.Charset.lookupViaProviders(Charset.java:406) at java.nio.charset.Charset.lookup2(Charset.java:477) at java.nio.charset.Charset.lookup(Charset.java:464) at java.nio.charset.Charset.isSupported(Charset.java:505) at sun.launcher.LauncherHelper.makePlatformString(LauncherHelper.java:580) Caused by: java.util.EmptyStackException at java.util.Stack.peek(Stack.java:102) at java.lang.ClassLoader$NativeLibrary.getFromClass(ClassLoader.java:1759) at java.lang.ClassLoader$NativeLibrary.findBuiltinLib(Native Method) at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1870) at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1843) at java.lang.Runtime.loadLibrary0(Runtime.java:870) at java.lang.System.loadLibrary(System.java:1122) at java.util.zip.ZipFile.(ZipFile.java:86) ... 34 more It's obvious that the way jni_FindClass is looking for the class context by calling the NativeLibrary::getFromClass method is hacky but I think that the proposed fix is the quite simple and non-intrusive. And we probably don't want a complete rework of this code for 8 anyway. So why not fix it the proposed way in 8 and 9 for now? That will still leave us time to come up with a better clean-up at least for 9. What do you think? Regards, Volker On Tue, Jun 9, 2015 at 1:35 AM, Mandy Chung wrote: > Hi Volker, > > Your patch reminds me the question I have about loading zip library. > > In JDK 9 (and earlier release), zip library is loaded by the VM during > startup (see ClassLoader::load_zip_library). I think loadLibrary("zip") is > no longer needed to be called from System::initializeSystemClass method and > instead it can be loaded by java.util.zip.ZipFile static initializer. > > Do you mind to try the patch (below)? That may be a simpler fix. > > I never like the way jni_FindClass to look for the class context by calling > the NativeLibrary::getFromClass method. I will have to look deeper other > alternative to clean that up. If taking out loadLibrary("zip") resolves > your issue, this will give us time to come up with a better clean-up in the > future. > > Mandy > [1] https://bugs.openjdk.java.net/browse/JDK-4429040 > > diff --git a/src/share/classes/java/lang/System.java > b/src/share/classes/java/lang/System.java > --- a/src/share/classes/java/lang/System.java > +++ b/src/share/classes/java/lang/System.java > @@ -1192,10 +1192,6 @@ > setOut0(newPrintStream(fdOut, > props.getProperty("sun.stdout.encoding"))); > setErr0(newPrintStream(fdErr, > props.getProperty("sun.stderr.encoding"))); > > - // Load the zip library now in order to keep java.util.zip.ZipFile > - // from trying to use itself to load this library later. > - loadLibrary("zip"); > - > // Setup Java signal handlers for HUP, TERM, and INT (where > available). > Terminator.setup(); > > diff --git a/src/share/classes/java/util/zip/ZipFile.java > b/src/share/classes/java/util/zip/ZipFile.java > --- a/src/share/classes/java/util/zip/ZipFile.java > +++ b/src/share/classes/java/util/zip/ZipFile.java > @@ -83,6 +83,7 @@ > > static { > /* Zip library is loaded from System.initializeSystemClass */ > + System.loadLibrary("zip"); > initIDs(); > > } > > > > On 06/08/2015 07:23 AM, Volker Simonis wrote: >> >> Hi, >> >> can I please get a review at least for the part of this fix which is >> common for jdk8 and jdk9. It's only a few lines in >> src/share/vm/prims/jni.cpp for the hotspot repository and one line >> src/java.base/share/classes/java/lang/ClassLoader.java for the jdk >> repository. >> >> Thanks, >> Volker >> >> >> On Tue, Jun 2, 2015 at 6:12 PM, Volker Simonis >> wrote: >>> >>> Hi, >>> >>> can I please have review (and a sponsor) for these changes: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8081674 >>> http://cr.openjdk.java.net/~simonis/webrevs/2015/8081674.jdk >>> http://cr.openjdk.java.net/~simonis/webrevs/2015/8081674.hs >>> >>> Please notice that the fix requires synchronous changes in the jdk and >>> the >>> hotspot forest. >>> >>> The changes themselves are by far not that big as this explanation but I >>> found the problem to be quite intricate so I tried to explain it as good >>> as >>> I could. I'd suggest to read the HTML-formatted explanation in the webrev >>> although the content is equal to the one in this mail: >>> >>> Using an unsupported character encoding (e.g. vi_VN.TCVN on Linux) >>> results >>> in an immediate VM failure with jdk 8 and 9: >>> >>> export LANG=vi_VN.TCVN >>> java -version >>> Error occurred during initialization of VM >>> java.util.EmptyStackException >>> at java.util.Stack.peek(Stack.java:102) >>> at >>> java.lang.ClassLoader$NativeLibrary.getFromClass(ClassLoader.java:1751) >>> at java.lang.ClassLoader$NativeLibrary.findBuiltinLib(Native >>> Method) >>> at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1862) >>> at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1835) >>> at java.lang.Runtime.loadLibrary0(Runtime.java:870) >>> at java.lang.System.loadLibrary(System.java:1119) >>> at java.lang.System.initializeSystemClass(System.java:1194) >>> >>> This is a consequence of "8005716: Enhance JNI specification to allow >>> support of static JNI libraries in Embedded JREs". >>> >>> With jdk 9 we get this error even if we're running with a supported >>> charset >>> which is in the ExtendedCharsets (as opposed to being in the >>> StandardCharsets) class which is a consequence of delegating the loading >>> of >>> the ExtendedCharsets class to the ServiceLoader in jdk 9. >>> >>> export LANG=eo.iso-8859-3 >>> output-jdk9/images/jdk/bin/java -version >>> Error occurred during initialization of VM >>> java.util.EmptyStackException >>> at java.util.Stack.peek(Stack.java:102) >>> at >>> java.lang.ClassLoader$NativeLibrary.getFromClass(ClassLoader.java:1737) >>> at java.lang.ClassLoader$NativeLibrary.findBuiltinLib(Native >>> Method) >>> at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1866) >>> at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1840) >>> at java.lang.Runtime.loadLibrary0(Runtime.java:874) >>> at java.lang.System.loadLibrary(System.java:1111) >>> at java.lang.System.initializeSystemClass(System.java:1186) >>> >>> Here's why the exception happens for an unsupported charset (see the >>> mixed >>> stack trace below for the full details): >>> >>> java.lang.System.loadLibrary() wants to load libzip.so. It calls >>> java.lang.Runtime.loadLibrary0() which at the very beginning calls the >>> native method ClassLoader$NativeLibrary.findBuiltinLib() which checks if >>> the >>> corresponding library is already statically linked into the VM >>> (introduced >>> by 8005716). >>> Java_java_lang_ClassLoader_00024NativeLibrary_findBuiltinLib(), >>> the native implementation of findBuiltinLib() in Classloader.c calls >>> GetStringPlatformChars() to convert the library name into the native >>> platform encoding. GetStringPlatformChars() calls the helper function >>> jnuEncodingSupported() to check if the platform encoding which is stored >>> in >>> the property "sun.jnu.encoding" is supported by Java. >>> jnuEncodingSupported() >>> is implemented as follows: >>> >>> static jboolean isJNUEncodingSupported = JNI_FALSE; >>> static jboolean jnuEncodingSupported(JNIEnv *env) { >>> jboolean exe; >>> if (isJNUEncodingSupported == JNI_TRUE) { >>> return JNI_TRUE; >>> } >>> isJNUEncodingSupported = (jboolean) JNU_CallStaticMethodByName ( >>> env, &exe, >>> "java/nio/charset/Charset", >>> "isSupported", >>> "(Ljava/lang/String;)Z", >>> jnuEncoding).z; >>> return isJNUEncodingSupported; >>> } >>> >>> Once the function finds that the platform encoding is supported (by >>> calling >>> java.nio.charset.Charset.isSupported()) it caches this value and always >>> returns it on following calls. However if the platform encoding is not >>> supported, it ALWAYS calls java.nio.charset.Charset.isSupported() an >>> every >>> subsequent invocation. >>> >>> In order to call the Java method Charset.isSupported() (in >>> JNU_CallStaticMethodByName() in file jni_util.c), we have to call >>> jni_FindClass() to convert the symbolic class name >>> "java.nio.charset.Charset" into a class reference. >>> >>> But unfortunately, jni_FindClass() (from jni.cpp in libjvm.so) has a >>> special >>> handling if called from java.lang.ClassLoader$NativeLibrary to ensure >>> that >>> JNI_OnLoad/JNI_OnUnload are executed in the correct class context: >>> >>> instanceKlassHandle k (THREAD, thread->security_get_caller_class(0)); >>> if (k.not_null()) { >>> loader = Handle(THREAD, k->class_loader()); >>> // Special handling to make sure JNI_OnLoad and JNI_OnUnload are >>> executed >>> // in the correct class context. >>> if (loader.is_null() && >>> k->name() == vmSymbols::java_lang_ClassLoader_NativeLibrary()) { >>> JavaValue result(T_OBJECT); >>> JavaCalls::call_static(&result, k, >>> vmSymbols::getFromClass_name(), >>> vmSymbols::void_class_signature(), >>> thread); >>> if (HAS_PENDING_EXCEPTION) { >>> Handle ex(thread, thread->pending_exception()); >>> CLEAR_PENDING_EXCEPTION; >>> THROW_HANDLE_0(ex); >>> } >>> >>> So if that's the case and jni_FindClass() was reallycalled from >>> ClassLoader$NativeLibrary, then jni_FindClass() calles >>> ClassLoader$NativeLibrary().getFromClass() to find out the corresponding >>> context class which is supposed to be saved there in a field of type >>> java.util.Stack named "nativeLibraryContext": >>> >>> // Invoked in the VM to determine the context class in >>> // JNI_Load/JNI_Unload >>> static Class getFromClass() { >>> return ClassLoader.nativeLibraryContext.peek().fromClass; >>> } >>> >>> Unfortunately, "nativeLibraryContext" doesn't contain any entry at this >>> point and the invocation of Stack.peek() will throw the exception shown >>> before. In general, the "nativeLibraryContext" stack will be filled later >>> on >>> in Runtime.loadLibrary0() like this: >>> >>> NativeLibrary lib = new NativeLibrary(fromClass, name, isBuiltin); >>> nativeLibraryContext.push(lib); >>> try { >>> lib.load(name, isBuiltin); >>> } finally { >>> nativeLibraryContext.pop(); >>> } >>> >>> such that it always contains at least one element later when >>> jni_FindClass() >>> will be invoked. >>> >>> So in summary, the problem is that the implementors of 8005716 didn't >>> took >>> into account that calling ClassLoader$NativeLibrary.findBuiltinLib() may >>> trigger a call to jni_FindClass() if we are running on a system with an >>> unsupported character encoding. >>> >>> I'd suggest the following fix for this problem: >>> >>> Change ClassLoader$NativeLibrary().getFromClass() to return null if the >>> stack is empty instead of throwing an exception: >>> >>> static Class getFromClass() { >>> return ClassLoader.nativeLibraryContext.empty() ? >>> null : ClassLoader.nativeLibraryContext.peek().fromClass; >>> } >>> >>> Unfortunately this also requires a HotSpot change in jni_FindClass() in >>> order to properly handle the new 'null' return value: >>> >>> if (k.not_null()) { >>> loader = Handle(THREAD, k->class_loader()); >>> // Special handling to make sure JNI_OnLoad and JNI_OnUnload are >>> executed >>> // in the correct class context. >>> if (loader.is_null() && >>> k->name() == vmSymbols::java_lang_ClassLoader_NativeLibrary()) { >>> JavaValue result(T_OBJECT); >>> JavaCalls::call_static(&result, k, >>> vmSymbols::getFromClass_name(), >>> vmSymbols::void_class_signature(), >>> thread); >>> if (HAS_PENDING_EXCEPTION) { >>> Handle ex(thread, thread->pending_exception()); >>> CLEAR_PENDING_EXCEPTION; >>> THROW_HANDLE_0(ex); >>> } >>> oop mirror = (oop) result.get_jobject(); >>> if (oopDesc::is_null(mirror)) { >>> loader = Handle(THREAD, SystemDictionary::java_system_loader()); >>> } else { >>> loader = Handle(THREAD, >>> >>> InstanceKlass::cast(java_lang_Class::as_Klass(mirror))->class_loader()); >>> protection_domain = Handle(THREAD, >>> >>> >>> InstanceKlass::cast(java_lang_Class::as_Klass(mirror))->protection_domain()); >>> } >>> } >>> } else { >>> // We call ClassLoader.getSystemClassLoader to obtain the system >>> class >>> loader. >>> loader = Handle(THREAD, SystemDictionary::java_system_loader()); >>> } >>> >>> These changes are sufficient to solve the problem in Java 8. >>> Unfortunately, >>> that's still not enough in Java 9 because there the loading of the >>> extended >>> charsets has been delegated to ServiceLoader. But ServiceLoader calls >>> ClassLoader.getBootstrapResources() which calls >>> sun.misc.Launcher.getBootstrapClassPath(). This leads to another problem >>> during class initialization of sun.misc.Launcher if running on an >>> unsupported locale. >>> >>> The first thing done in sun.misc.Launcher. is the initialisation >>> of >>> the bootstrap URLClassPath in the Launcher. However this initialisation >>> will >>> eventually call Charset.isSupported() and if we are running on an >>> unsupported locale this will inevitably end in another recursive call to >>> ServiceLoader. But as explained below, ServiceLoader will query the >>> Launcher's bootstrap URLClassPath which will be still uninitialized at >>> that >>> point. >>> >>> So we'll have to additionally guard guard against this situation on JDK 9 >>> like this: >>> >>> private static Charset lookupExtendedCharset(String charsetName) { >>> if (!sun.misc.VM.isBooted() || // see >>> lookupViaProviders() >>> sun.misc.Launcher.getBootstrapClassPath() == null) >>> return null; >>> >>> This fixes the crashes, but still at the price of not having the extended >>> charsets available during initialization until >>> Launcher.getBootstrapClassPath is set up properly. This may be still a >>> problem if the jdk is installed in a directory which contains characters >>> specific to an extended encoding or if we have such characters in the >>> command line arguments. >>> >>> Thank you and best regards, >>> Volker >>> >>> >>> Mixed stack trace of the initial EmptyStackException for unsupported >>> charsets described before: >>> >>> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native >>> code) >>> j java.util.Stack.peek()Ljava/lang/Object;+1 >>> j java.lang.ClassLoader$NativeLibrary.getFromClass()Ljava/lang/Class;+3 >>> v ~StubRoutines::call_stub >>> V [libjvm.so+0x9d279a] JavaCalls::call_helper(JavaValue*, >>> methodHandle*, >>> JavaCallArguments*, Thread*)+0x6b4 >>> V [libjvm.so+0xcad591] os::os_exception_wrapper(void (*)(JavaValue*, >>> methodHandle*, JavaCallArguments*, Thread*), JavaValue*, methodHandle*, >>> JavaCallArguments*, Thread*)+0x45 >>> V [libjvm.so+0x9d20cf] JavaCalls::call(JavaValue*, methodHandle, >>> JavaCallArguments*, Thread*)+0x8b >>> V [libjvm.so+0x9d1d3b] JavaCalls::call_static(JavaValue*, KlassHandle, >>> Symbol*, Symbol*, JavaCallArguments*, Thread*)+0x139 >>> V [libjvm.so+0x9d1e3f] JavaCalls::call_static(JavaValue*, KlassHandle, >>> Symbol*, Symbol*, Thread*)+0x9d >>> V [libjvm.so+0x9e6588] jni_FindClass+0x428 >>> C [libjava.so+0x20208] JNU_CallStaticMethodByName+0xff >>> C [libjava.so+0x21cae] jnuEncodingSupported+0x61 >>> C [libjava.so+0x22125] JNU_GetStringPlatformChars+0x125 >>> C [libjava.so+0xedcd] >>> Java_java_lang_ClassLoader_00024NativeLibrary_findBuiltinLib+0x8b >>> j >>> >>> java.lang.ClassLoader$NativeLibrary.findBuiltinLib(Ljava/lang/String;)Ljava/lang/String;+0 >>> j java.lang.ClassLoader.loadLibrary0(Ljava/lang/Class;Ljava/io/File;)Z+4 >>> j >>> >>> java.lang.ClassLoader.loadLibrary(Ljava/lang/Class;Ljava/lang/String;Z)V+228 >>> j >>> java.lang.Runtime.loadLibrary0(Ljava/lang/Class;Ljava/lang/String;)V+54 >>> j java.lang.System.loadLibrary(Ljava/lang/String;)V+7 >>> j java.lang.System.initializeSystemClass()V+113 >>> v ~StubRoutines::call_stub >>> V [libjvm.so+0x9d279a] JavaCalls::call_helper(JavaValue*, >>> methodHandle*, >>> JavaCallArguments*, Thread*)+0x6b4 >>> V [libjvm.so+0xcad591] os::os_exception_wrapper(void (*)(JavaValue*, >>> methodHandle*, JavaCallArguments*, Thread*), JavaValue*, methodHandle*, >>> JavaCallArguments*, Thread*)+0x45 >>> V [libjvm.so+0x9d20cf] JavaCalls::call(JavaValue*, methodHandle, >>> JavaCallArguments*, Thread*)+0x8b >>> V [libjvm.so+0x9d1d3b] JavaCalls::call_static(JavaValue*, KlassHandle, >>> Symbol*, Symbol*, JavaCallArguments*, Thread*)+0x139 >>> V [libjvm.so+0x9d1e3f] JavaCalls::call_static(JavaValue*, KlassHandle, >>> Symbol*, Symbol*, Thread*)+0x9d >>> V [libjvm.so+0xe3cceb] call_initializeSystemClass(Thread*)+0xb0 >>> V [libjvm.so+0xe44444] >>> Threads::initialize_java_lang_classes(JavaThread*, >>> Thread*)+0x21a >>> V [libjvm.so+0xe44b12] Threads::create_vm(JavaVMInitArgs*, bool*)+0x4a6 >>> V [libjvm.so+0xa19bd7] JNI_CreateJavaVM+0xc7 >>> C [libjli.so+0xa520] InitializeJVM+0x154 >>> C [libjli.so+0x8024] JavaMain+0xcc >>> >>> > From edward.nevill at linaro.org Tue Jun 9 17:10:55 2015 From: edward.nevill at linaro.org (Edward Nevill) Date: Tue, 09 Jun 2015 18:10:55 +0100 Subject: RFR: 8086087: aarch64: add support for 64 bit vectors Message-ID: <1433869855.11860.20.camel@mylittlepony.linaroharston> Hi, http://cr.openjdk.java.net/~enevill/8086087/webrev/ This adds support for 64 bit vectors on aarch64. Previously the vector code only supported 128 bit vectors. 32 bit vectors are not supported directly as aarch64 has no support for 32 bit vectors, however the above webrev will permit 32 bit vectors but just place them in a 64 bit vector. I have tested this with JTreg hotspot and get the same results before and after the change, viz, Test results: passed: 845; failed: 12; error: 6 I have also benchmarked the Test*Vect tests from 6340864 in the hotspot test suite. The following are the average results I get on one of our partners HW (lower number is better). TestByteVect: 128-bit (11.77), 64-bit (4.36) TestShortVect: 128-bit (5.02), 64-bit (5.22) TestIntVect: 128-bit (7.81), 64-bit (7.70) TestLongVect: 128-bit (11.67), 64-bit (11.71) TestFloatVect: 128-bit (16.75), 64-bit (17.29) TestDoubleVect:128-bit (32.37), 64-bit (32.43) So the only test which shows an improvement is TestByteVect which shows a 2.7x speedup. The other tests are the same within the bounds of experimental error. The reason TestByteVect shows such an improvement is that with 128 bit vectors it is not being vectorized at all because the loop is not unrolled sufficiently to allow it to be vectorized, wheras with 64 bit vectors it is. Please review and let me know if this is OK to push? Ed. From bourges.laurent at gmail.com Tue Jun 9 17:28:47 2015 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Tue, 9 Jun 2015 19:28:47 +0200 Subject: GCC 4.8.3+ Does anybody aware of Stack Smashing Protection ? In-Reply-To: <5571F91D.2020003@oracle.com> References: <5571F91D.2020003@oracle.com> Message-ID: Hi, I wonder if it affects the release builds too on my laptop ? I have Ubuntu 14.4 with gcc 4.8.4. I ran gcc -Q -help=common but it said fstack-protector is disabled. I am running map rendering benchmarks comparing ductus, pisces and Marlin, a new fast renderer (I am contributing to OpenJDK 9). I am experiencing my openjdk9 build is a bit slower than oracle jdk8 ~ 5% ! I will try adding f-no-stack-protection to my custom CFLAGS to check any impact. Regards, Laurent Le 5 juin 2015 21:34, "Dmitry Samersoff" a ?crit : > Hi Everybody, > > I'm not sure it affects hotspot but should we care about it? > > FYI: > > Beginning with GCC 4.8.3, Stack Smashing Protection (SSP) will be > enabled by default. The 4.8 series will enable -fstack-protector > while 4.9 and later enable -fstack-protector-strong. > > SSP is a security feature that attempts to mitigate stack-based buffer > overflows by placing a canary value on the stack after the function > return pointer and checking for that value before the function returns. > If a buffer overflow occurs and the canary value is overwritten, the > program aborts. > > There is a small performance cost to these features. They can be > disabled with -fno-stack-protector. > > For more information these options, refer to the GCC Manual, or the > following articles. > > http://en.wikipedia.org/wiki/Buffer_overflow_protection > http://en.wikipedia.org/wiki/Stack_buffer_overflow > https://securityblog.redhat.com/tag/stack-protector > http://www.outflux.net/blog/archives/2014/01/27/fstack-protector-strong > > -Dmitry > > -- > Dmitry Samersoff > Oracle Java development team, Saint Petersburg, Russia > * I would love to change the world, but they won't give me the sources. > From mandy.chung at oracle.com Tue Jun 9 18:03:02 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 09 Jun 2015 11:03:02 -0700 Subject: RFR(M): 8081674: EmptyStackException at startup if running with extended or unsupported charset In-Reply-To: References: <557626AA.6010008@oracle.com> Message-ID: <55772A56.2030308@oracle.com> Does my patch work fine on 8u? If it works fine, I prefer to get that simple fix in 8u and take the time to have a better fix in 9 (jdk9 is still under development and I have assumed that it's not a show stopper to you. Let me know if it blocks you). A question to Sherman - do we have adequate tests to verify the move of System.loadLibrary("zip") from system initialization to ZipFile initialization for 8u? Mandy On 06/09/2015 10:09 AM, Volker Simonis wrote: > Hi Mandy, > > thanks for looking into this. > Uunfortunately your fix only helps to fix "java -version" :( > > Running even a minimal HelloWorld will still fail with the following > stack trace which is still caused by the same EmptyStackException: > > Error: A JNI error has occurred, please check your installation and try again > Exception in thread "main" java.lang.ExceptionInInitializerError > at sun.misc.Unsafe.ensureClassInitialized(Native Method) > at sun.misc.SharedSecrets.getJavaUtilZipFileAccess(SharedSecrets.java:158) > at sun.misc.URLClassPath$JarLoader.(URLClassPath.java:765) > at sun.misc.URLClassPath$3.run(URLClassPath.java:530) > at sun.misc.URLClassPath$3.run(URLClassPath.java:520) > at java.security.AccessController.doPrivileged(Native Method) > at sun.misc.URLClassPath.getLoader(URLClassPath.java:519) > at sun.misc.URLClassPath.getLoader(URLClassPath.java:492) > at sun.misc.URLClassPath.getNextLoader(URLClassPath.java:457) > at sun.misc.URLClassPath.access$100(URLClassPath.java:64) > at sun.misc.URLClassPath$1.next(URLClassPath.java:239) > at sun.misc.URLClassPath$1.hasMoreElements(URLClassPath.java:250) > at java.net.URLClassLoader$3$1.run(URLClassLoader.java:601) > at java.net.URLClassLoader$3$1.run(URLClassLoader.java:599) > at java.security.AccessController.doPrivileged(Native Method) > at java.net.URLClassLoader$3.next(URLClassLoader.java:598) > at java.net.URLClassLoader$3.hasMoreElements(URLClassLoader.java:623) > at sun.misc.CompoundEnumeration.next(CompoundEnumeration.java:45) > at sun.misc.CompoundEnumeration.hasMoreElements(CompoundEnumeration.java:54) > at sun.misc.CompoundEnumeration.next(CompoundEnumeration.java:45) > at sun.misc.CompoundEnumeration.hasMoreElements(CompoundEnumeration.java:54) > at java.util.ServiceLoader$LazyIterator.hasNextService(ServiceLoader.java:354) > at java.util.ServiceLoader$LazyIterator.hasNext(ServiceLoader.java:393) > at java.util.ServiceLoader$1.hasNext(ServiceLoader.java:474) > at java.nio.charset.Charset$1.getNext(Charset.java:350) > at java.nio.charset.Charset$1.hasNext(Charset.java:365) > at java.nio.charset.Charset$2.run(Charset.java:410) > at java.nio.charset.Charset$2.run(Charset.java:407) > at java.security.AccessController.doPrivileged(Native Method) > at java.nio.charset.Charset.lookupViaProviders(Charset.java:406) > at java.nio.charset.Charset.lookup2(Charset.java:477) > at java.nio.charset.Charset.lookup(Charset.java:464) > at java.nio.charset.Charset.isSupported(Charset.java:505) > at sun.launcher.LauncherHelper.makePlatformString(LauncherHelper.java:580) > Caused by: java.util.EmptyStackException > at java.util.Stack.peek(Stack.java:102) > at java.lang.ClassLoader$NativeLibrary.getFromClass(ClassLoader.java:1759) > at java.lang.ClassLoader$NativeLibrary.findBuiltinLib(Native Method) > at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1870) > at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1843) > at java.lang.Runtime.loadLibrary0(Runtime.java:870) > at java.lang.System.loadLibrary(System.java:1122) > at java.util.zip.ZipFile.(ZipFile.java:86) > ... 34 more > > It's obvious that the way jni_FindClass is looking for the class > context by calling the NativeLibrary::getFromClass method is hacky but > I think that the proposed fix is the quite simple and non-intrusive. > And we probably don't want a complete rework of this code for 8 > anyway. So why not fix it the proposed way in 8 and 9 for now? That > will still leave us time to come up with a better clean-up at least > for 9. > > What do you think? > > Regards, > Volker > > On Tue, Jun 9, 2015 at 1:35 AM, Mandy Chung wrote: >> Hi Volker, >> >> Your patch reminds me the question I have about loading zip library. >> >> In JDK 9 (and earlier release), zip library is loaded by the VM during >> startup (see ClassLoader::load_zip_library). I think loadLibrary("zip") is >> no longer needed to be called from System::initializeSystemClass method and >> instead it can be loaded by java.util.zip.ZipFile static initializer. >> >> Do you mind to try the patch (below)? That may be a simpler fix. >> >> I never like the way jni_FindClass to look for the class context by calling >> the NativeLibrary::getFromClass method. I will have to look deeper other >> alternative to clean that up. If taking out loadLibrary("zip") resolves >> your issue, this will give us time to come up with a better clean-up in the >> future. >> >> Mandy >> [1] https://bugs.openjdk.java.net/browse/JDK-4429040 >> >> diff --git a/src/share/classes/java/lang/System.java >> b/src/share/classes/java/lang/System.java >> --- a/src/share/classes/java/lang/System.java >> +++ b/src/share/classes/java/lang/System.java >> @@ -1192,10 +1192,6 @@ >> setOut0(newPrintStream(fdOut, >> props.getProperty("sun.stdout.encoding"))); >> setErr0(newPrintStream(fdErr, >> props.getProperty("sun.stderr.encoding"))); >> >> - // Load the zip library now in order to keep java.util.zip.ZipFile >> - // from trying to use itself to load this library later. >> - loadLibrary("zip"); >> - >> // Setup Java signal handlers for HUP, TERM, and INT (where >> available). >> Terminator.setup(); >> >> diff --git a/src/share/classes/java/util/zip/ZipFile.java >> b/src/share/classes/java/util/zip/ZipFile.java >> --- a/src/share/classes/java/util/zip/ZipFile.java >> +++ b/src/share/classes/java/util/zip/ZipFile.java >> @@ -83,6 +83,7 @@ >> >> static { >> /* Zip library is loaded from System.initializeSystemClass */ >> + System.loadLibrary("zip"); >> initIDs(); >> >> } >> >> >> >> On 06/08/2015 07:23 AM, Volker Simonis wrote: >>> Hi, >>> >>> can I please get a review at least for the part of this fix which is >>> common for jdk8 and jdk9. It's only a few lines in >>> src/share/vm/prims/jni.cpp for the hotspot repository and one line >>> src/java.base/share/classes/java/lang/ClassLoader.java for the jdk >>> repository. >>> >>> Thanks, >>> Volker >>> >>> >>> On Tue, Jun 2, 2015 at 6:12 PM, Volker Simonis >>> wrote: >>>> Hi, >>>> >>>> can I please have review (and a sponsor) for these changes: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8081674 >>>> http://cr.openjdk.java.net/~simonis/webrevs/2015/8081674.jdk >>>> http://cr.openjdk.java.net/~simonis/webrevs/2015/8081674.hs >>>> >>>> Please notice that the fix requires synchronous changes in the jdk and >>>> the >>>> hotspot forest. >>>> >>>> The changes themselves are by far not that big as this explanation but I >>>> found the problem to be quite intricate so I tried to explain it as good >>>> as >>>> I could. I'd suggest to read the HTML-formatted explanation in the webrev >>>> although the content is equal to the one in this mail: >>>> >>>> Using an unsupported character encoding (e.g. vi_VN.TCVN on Linux) >>>> results >>>> in an immediate VM failure with jdk 8 and 9: >>>> >>>> export LANG=vi_VN.TCVN >>>> java -version >>>> Error occurred during initialization of VM >>>> java.util.EmptyStackException >>>> at java.util.Stack.peek(Stack.java:102) >>>> at >>>> java.lang.ClassLoader$NativeLibrary.getFromClass(ClassLoader.java:1751) >>>> at java.lang.ClassLoader$NativeLibrary.findBuiltinLib(Native >>>> Method) >>>> at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1862) >>>> at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1835) >>>> at java.lang.Runtime.loadLibrary0(Runtime.java:870) >>>> at java.lang.System.loadLibrary(System.java:1119) >>>> at java.lang.System.initializeSystemClass(System.java:1194) >>>> >>>> This is a consequence of "8005716: Enhance JNI specification to allow >>>> support of static JNI libraries in Embedded JREs". >>>> >>>> With jdk 9 we get this error even if we're running with a supported >>>> charset >>>> which is in the ExtendedCharsets (as opposed to being in the >>>> StandardCharsets) class which is a consequence of delegating the loading >>>> of >>>> the ExtendedCharsets class to the ServiceLoader in jdk 9. >>>> >>>> export LANG=eo.iso-8859-3 >>>> output-jdk9/images/jdk/bin/java -version >>>> Error occurred during initialization of VM >>>> java.util.EmptyStackException >>>> at java.util.Stack.peek(Stack.java:102) >>>> at >>>> java.lang.ClassLoader$NativeLibrary.getFromClass(ClassLoader.java:1737) >>>> at java.lang.ClassLoader$NativeLibrary.findBuiltinLib(Native >>>> Method) >>>> at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1866) >>>> at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1840) >>>> at java.lang.Runtime.loadLibrary0(Runtime.java:874) >>>> at java.lang.System.loadLibrary(System.java:1111) >>>> at java.lang.System.initializeSystemClass(System.java:1186) >>>> >>>> Here's why the exception happens for an unsupported charset (see the >>>> mixed >>>> stack trace below for the full details): >>>> >>>> java.lang.System.loadLibrary() wants to load libzip.so. It calls >>>> java.lang.Runtime.loadLibrary0() which at the very beginning calls the >>>> native method ClassLoader$NativeLibrary.findBuiltinLib() which checks if >>>> the >>>> corresponding library is already statically linked into the VM >>>> (introduced >>>> by 8005716). >>>> Java_java_lang_ClassLoader_00024NativeLibrary_findBuiltinLib(), >>>> the native implementation of findBuiltinLib() in Classloader.c calls >>>> GetStringPlatformChars() to convert the library name into the native >>>> platform encoding. GetStringPlatformChars() calls the helper function >>>> jnuEncodingSupported() to check if the platform encoding which is stored >>>> in >>>> the property "sun.jnu.encoding" is supported by Java. >>>> jnuEncodingSupported() >>>> is implemented as follows: >>>> >>>> static jboolean isJNUEncodingSupported = JNI_FALSE; >>>> static jboolean jnuEncodingSupported(JNIEnv *env) { >>>> jboolean exe; >>>> if (isJNUEncodingSupported == JNI_TRUE) { >>>> return JNI_TRUE; >>>> } >>>> isJNUEncodingSupported = (jboolean) JNU_CallStaticMethodByName ( >>>> env, &exe, >>>> "java/nio/charset/Charset", >>>> "isSupported", >>>> "(Ljava/lang/String;)Z", >>>> jnuEncoding).z; >>>> return isJNUEncodingSupported; >>>> } >>>> >>>> Once the function finds that the platform encoding is supported (by >>>> calling >>>> java.nio.charset.Charset.isSupported()) it caches this value and always >>>> returns it on following calls. However if the platform encoding is not >>>> supported, it ALWAYS calls java.nio.charset.Charset.isSupported() an >>>> every >>>> subsequent invocation. >>>> >>>> In order to call the Java method Charset.isSupported() (in >>>> JNU_CallStaticMethodByName() in file jni_util.c), we have to call >>>> jni_FindClass() to convert the symbolic class name >>>> "java.nio.charset.Charset" into a class reference. >>>> >>>> But unfortunately, jni_FindClass() (from jni.cpp in libjvm.so) has a >>>> special >>>> handling if called from java.lang.ClassLoader$NativeLibrary to ensure >>>> that >>>> JNI_OnLoad/JNI_OnUnload are executed in the correct class context: >>>> >>>> instanceKlassHandle k (THREAD, thread->security_get_caller_class(0)); >>>> if (k.not_null()) { >>>> loader = Handle(THREAD, k->class_loader()); >>>> // Special handling to make sure JNI_OnLoad and JNI_OnUnload are >>>> executed >>>> // in the correct class context. >>>> if (loader.is_null() && >>>> k->name() == vmSymbols::java_lang_ClassLoader_NativeLibrary()) { >>>> JavaValue result(T_OBJECT); >>>> JavaCalls::call_static(&result, k, >>>> vmSymbols::getFromClass_name(), >>>> vmSymbols::void_class_signature(), >>>> thread); >>>> if (HAS_PENDING_EXCEPTION) { >>>> Handle ex(thread, thread->pending_exception()); >>>> CLEAR_PENDING_EXCEPTION; >>>> THROW_HANDLE_0(ex); >>>> } >>>> >>>> So if that's the case and jni_FindClass() was reallycalled from >>>> ClassLoader$NativeLibrary, then jni_FindClass() calles >>>> ClassLoader$NativeLibrary().getFromClass() to find out the corresponding >>>> context class which is supposed to be saved there in a field of type >>>> java.util.Stack named "nativeLibraryContext": >>>> >>>> // Invoked in the VM to determine the context class in >>>> // JNI_Load/JNI_Unload >>>> static Class getFromClass() { >>>> return ClassLoader.nativeLibraryContext.peek().fromClass; >>>> } >>>> >>>> Unfortunately, "nativeLibraryContext" doesn't contain any entry at this >>>> point and the invocation of Stack.peek() will throw the exception shown >>>> before. In general, the "nativeLibraryContext" stack will be filled later >>>> on >>>> in Runtime.loadLibrary0() like this: >>>> >>>> NativeLibrary lib = new NativeLibrary(fromClass, name, isBuiltin); >>>> nativeLibraryContext.push(lib); >>>> try { >>>> lib.load(name, isBuiltin); >>>> } finally { >>>> nativeLibraryContext.pop(); >>>> } >>>> >>>> such that it always contains at least one element later when >>>> jni_FindClass() >>>> will be invoked. >>>> >>>> So in summary, the problem is that the implementors of 8005716 didn't >>>> took >>>> into account that calling ClassLoader$NativeLibrary.findBuiltinLib() may >>>> trigger a call to jni_FindClass() if we are running on a system with an >>>> unsupported character encoding. >>>> >>>> I'd suggest the following fix for this problem: >>>> >>>> Change ClassLoader$NativeLibrary().getFromClass() to return null if the >>>> stack is empty instead of throwing an exception: >>>> >>>> static Class getFromClass() { >>>> return ClassLoader.nativeLibraryContext.empty() ? >>>> null : ClassLoader.nativeLibraryContext.peek().fromClass; >>>> } >>>> >>>> Unfortunately this also requires a HotSpot change in jni_FindClass() in >>>> order to properly handle the new 'null' return value: >>>> >>>> if (k.not_null()) { >>>> loader = Handle(THREAD, k->class_loader()); >>>> // Special handling to make sure JNI_OnLoad and JNI_OnUnload are >>>> executed >>>> // in the correct class context. >>>> if (loader.is_null() && >>>> k->name() == vmSymbols::java_lang_ClassLoader_NativeLibrary()) { >>>> JavaValue result(T_OBJECT); >>>> JavaCalls::call_static(&result, k, >>>> vmSymbols::getFromClass_name(), >>>> vmSymbols::void_class_signature(), >>>> thread); >>>> if (HAS_PENDING_EXCEPTION) { >>>> Handle ex(thread, thread->pending_exception()); >>>> CLEAR_PENDING_EXCEPTION; >>>> THROW_HANDLE_0(ex); >>>> } >>>> oop mirror = (oop) result.get_jobject(); >>>> if (oopDesc::is_null(mirror)) { >>>> loader = Handle(THREAD, SystemDictionary::java_system_loader()); >>>> } else { >>>> loader = Handle(THREAD, >>>> >>>> InstanceKlass::cast(java_lang_Class::as_Klass(mirror))->class_loader()); >>>> protection_domain = Handle(THREAD, >>>> >>>> >>>> InstanceKlass::cast(java_lang_Class::as_Klass(mirror))->protection_domain()); >>>> } >>>> } >>>> } else { >>>> // We call ClassLoader.getSystemClassLoader to obtain the system >>>> class >>>> loader. >>>> loader = Handle(THREAD, SystemDictionary::java_system_loader()); >>>> } >>>> >>>> These changes are sufficient to solve the problem in Java 8. >>>> Unfortunately, >>>> that's still not enough in Java 9 because there the loading of the >>>> extended >>>> charsets has been delegated to ServiceLoader. But ServiceLoader calls >>>> ClassLoader.getBootstrapResources() which calls >>>> sun.misc.Launcher.getBootstrapClassPath(). This leads to another problem >>>> during class initialization of sun.misc.Launcher if running on an >>>> unsupported locale. >>>> >>>> The first thing done in sun.misc.Launcher. is the initialisation >>>> of >>>> the bootstrap URLClassPath in the Launcher. However this initialisation >>>> will >>>> eventually call Charset.isSupported() and if we are running on an >>>> unsupported locale this will inevitably end in another recursive call to >>>> ServiceLoader. But as explained below, ServiceLoader will query the >>>> Launcher's bootstrap URLClassPath which will be still uninitialized at >>>> that >>>> point. >>>> >>>> So we'll have to additionally guard guard against this situation on JDK 9 >>>> like this: >>>> >>>> private static Charset lookupExtendedCharset(String charsetName) { >>>> if (!sun.misc.VM.isBooted() || // see >>>> lookupViaProviders() >>>> sun.misc.Launcher.getBootstrapClassPath() == null) >>>> return null; >>>> >>>> This fixes the crashes, but still at the price of not having the extended >>>> charsets available during initialization until >>>> Launcher.getBootstrapClassPath is set up properly. This may be still a >>>> problem if the jdk is installed in a directory which contains characters >>>> specific to an extended encoding or if we have such characters in the >>>> command line arguments. >>>> >>>> Thank you and best regards, >>>> Volker >>>> >>>> >>>> Mixed stack trace of the initial EmptyStackException for unsupported >>>> charsets described before: >>>> >>>> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native >>>> code) >>>> j java.util.Stack.peek()Ljava/lang/Object;+1 >>>> j java.lang.ClassLoader$NativeLibrary.getFromClass()Ljava/lang/Class;+3 >>>> v ~StubRoutines::call_stub >>>> V [libjvm.so+0x9d279a] JavaCalls::call_helper(JavaValue*, >>>> methodHandle*, >>>> JavaCallArguments*, Thread*)+0x6b4 >>>> V [libjvm.so+0xcad591] os::os_exception_wrapper(void (*)(JavaValue*, >>>> methodHandle*, JavaCallArguments*, Thread*), JavaValue*, methodHandle*, >>>> JavaCallArguments*, Thread*)+0x45 >>>> V [libjvm.so+0x9d20cf] JavaCalls::call(JavaValue*, methodHandle, >>>> JavaCallArguments*, Thread*)+0x8b >>>> V [libjvm.so+0x9d1d3b] JavaCalls::call_static(JavaValue*, KlassHandle, >>>> Symbol*, Symbol*, JavaCallArguments*, Thread*)+0x139 >>>> V [libjvm.so+0x9d1e3f] JavaCalls::call_static(JavaValue*, KlassHandle, >>>> Symbol*, Symbol*, Thread*)+0x9d >>>> V [libjvm.so+0x9e6588] jni_FindClass+0x428 >>>> C [libjava.so+0x20208] JNU_CallStaticMethodByName+0xff >>>> C [libjava.so+0x21cae] jnuEncodingSupported+0x61 >>>> C [libjava.so+0x22125] JNU_GetStringPlatformChars+0x125 >>>> C [libjava.so+0xedcd] >>>> Java_java_lang_ClassLoader_00024NativeLibrary_findBuiltinLib+0x8b >>>> j >>>> >>>> java.lang.ClassLoader$NativeLibrary.findBuiltinLib(Ljava/lang/String;)Ljava/lang/String;+0 >>>> j java.lang.ClassLoader.loadLibrary0(Ljava/lang/Class;Ljava/io/File;)Z+4 >>>> j >>>> >>>> java.lang.ClassLoader.loadLibrary(Ljava/lang/Class;Ljava/lang/String;Z)V+228 >>>> j >>>> java.lang.Runtime.loadLibrary0(Ljava/lang/Class;Ljava/lang/String;)V+54 >>>> j java.lang.System.loadLibrary(Ljava/lang/String;)V+7 >>>> j java.lang.System.initializeSystemClass()V+113 >>>> v ~StubRoutines::call_stub >>>> V [libjvm.so+0x9d279a] JavaCalls::call_helper(JavaValue*, >>>> methodHandle*, >>>> JavaCallArguments*, Thread*)+0x6b4 >>>> V [libjvm.so+0xcad591] os::os_exception_wrapper(void (*)(JavaValue*, >>>> methodHandle*, JavaCallArguments*, Thread*), JavaValue*, methodHandle*, >>>> JavaCallArguments*, Thread*)+0x45 >>>> V [libjvm.so+0x9d20cf] JavaCalls::call(JavaValue*, methodHandle, >>>> JavaCallArguments*, Thread*)+0x8b >>>> V [libjvm.so+0x9d1d3b] JavaCalls::call_static(JavaValue*, KlassHandle, >>>> Symbol*, Symbol*, JavaCallArguments*, Thread*)+0x139 >>>> V [libjvm.so+0x9d1e3f] JavaCalls::call_static(JavaValue*, KlassHandle, >>>> Symbol*, Symbol*, Thread*)+0x9d >>>> V [libjvm.so+0xe3cceb] call_initializeSystemClass(Thread*)+0xb0 >>>> V [libjvm.so+0xe44444] >>>> Threads::initialize_java_lang_classes(JavaThread*, >>>> Thread*)+0x21a >>>> V [libjvm.so+0xe44b12] Threads::create_vm(JavaVMInitArgs*, bool*)+0x4a6 >>>> V [libjvm.so+0xa19bd7] JNI_CreateJavaVM+0xc7 >>>> C [libjli.so+0xa520] InitializeJVM+0x154 >>>> C [libjli.so+0x8024] JavaMain+0xcc >>>> >>>> From kim.barrett at oracle.com Tue Jun 9 18:39:21 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 9 Jun 2015 14:39:21 -0400 Subject: RFR: 8086027: Multiple STATIC_ASSERTs at class scope doesn't work In-Reply-To: <55768508.6090602@oracle.com> References: <55768508.6090602@oracle.com> Message-ID: <68EA45AA-7199-4C86-9F3C-EEE6F0371940@oracle.com> On Jun 9, 2015, at 2:17 AM, David Holmes wrote: > > Hi Kim, > > On 9/06/2015 3:51 PM, Kim Barrett wrote: >> Third time's the charm? >> >> Please review this change to the STATIC_ASSERT macro, to allow >> multiple assertions in the same class scope. >> >> It seems we do need to make the typedef names used in the expansion >> unique per scope; see CR for details. We accomplish this with >> preprocessor token pasting with __LINE__ (done correctly, unlike in >> the change for JDK-8067306). > > Seems okay to me (but then so did previous version ). Thanks for reviewing. And yeah, sorry about that. >> As part of this, I'm also adding PASTE_TOKENS(x, y) utility macro. >> I'm willing to entertain alternative naming suggestions, though hoping >> to avoid a bikeshed discussion. > > As we already have XSTR for the single token case, what about XSTRCAT ? As there aren?t any strings involved, only pp tokens, I don?t care for a name related to strings. Bengt?s suggestion of XCAT is a better match for the existing XSTR, but I dislike short global macro names as being too easy for collisions to occur. For an example of the problem, see the little dance around STR in os/solaris/vm/attachListener_solaris.cpp. And I?m not sure what the X prefix is supposed to indicate. Maybe XCAT is supposed to be eXtended conCATenation? I prefer words. I chose the current name based on a common name for ## being the ?token pasting operator?. It?s also sometimes referred to as joining rather than pasting, though that seems less frequent. C++ standards just call it the ?## operator?, though there?s an example in C++11 that defines a macro called ?join? that uses it. And some commonly used libraries do use ?cat?. (Boost has both BOOST_PP_CAT and BOOST_JOIN, which have different implementations because they use different approaches to detecting and working around preprocessor deficiencies.) But I wouldn?t want to use ?JOIN? because that already has other meanings, such as with thread joining. I guess that?s a long-winded way of saying I?m planning to stick with PASTE_TOKENS. From jan.lahoda at oracle.com Tue Jun 9 04:57:58 2015 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Tue, 09 Jun 2015 06:57:58 +0200 Subject: RFR: JDK-8085822 JEP 223: New Version-String Scheme (initial integration) In-Reply-To: <557625C8.5050200@oracle.com> References: <5571AD18.7080701@oracle.com> <557625C8.5050200@oracle.com> Message-ID: <55767256.3030802@oracle.com> On 9.6.2015 01:31, Daniel D. Daugherty wrote: > > > http://cr.openjdk.java.net/~ihse/JDK-8085822-JEP-223-initial-patch/webrev.01 > langtools/src/java.compiler/share/classes/javax/lang/model/SourceVersion.java > > old L171: case "1.9": > new L171: case "9": > Should this logic support both versions? Will dropping > "1.9" here prevent a pre-version changeset JVM from > being dropped into a JDK for triage purposes? > > Granted we don't often triage 'javac' with different JVMs, but... > +1 on keeping both "1.9" and "9" here. javac can be used independently on the rest of JDK to some extent, so support for running it on older builds of JDK 9 seems reasonable to me. (I wonder if current JDK 9 javac should be prepared for the new version scheme in advance.) Jan From kumar.x.srinivasan at oracle.com Tue Jun 9 14:25:45 2015 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Tue, 09 Jun 2015 07:25:45 -0700 Subject: RFR: JDK-8085822 JEP 223: New Version-String Scheme (initial integration) In-Reply-To: <55767256.3030802@oracle.com> References: <5571AD18.7080701@oracle.com> <557625C8.5050200@oracle.com> <55767256.3030802@oracle.com> Message-ID: <5576F769.3060002@oracle.com> On 6/8/2015 9:57 PM, Jan Lahoda wrote: > On 9.6.2015 01:31, Daniel D. Daugherty wrote: >> > >> http://cr.openjdk.java.net/~ihse/JDK-8085822-JEP-223-initial-patch/webrev.01 >> >> langtools/src/java.compiler/share/classes/javax/lang/model/SourceVersion.java >> >> >> old L171: case "1.9": >> new L171: case "9": >> Should this logic support both versions? Will dropping >> "1.9" here prevent a pre-version changeset JVM from >> being dropped into a JDK for triage purposes? >> >> Granted we don't often triage 'javac' with different JVMs, >> but... >> > > +1 on keeping both "1.9" and "9" here. javac can be used independently > on the rest of JDK to some extent, so support for running it on older > builds of JDK 9 seems reasonable to me. (I wonder if current JDK 9 > javac should be prepared for the new version scheme in advance.) Yes, I think for the most part langtools seems to be working in the sandbox repo, with these changes, the remaining work is to align the version and fullversion of langtools/test to be compliant to the JDK version. Kumar > > Jan From kim.barrett at oracle.com Tue Jun 9 19:10:48 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 9 Jun 2015 15:10:48 -0400 Subject: RFR: 8086027: Multiple STATIC_ASSERTs at class scope doesn't work In-Reply-To: <5576A845.9010507@oracle.com> References: <5576A845.9010507@oracle.com> Message-ID: On Jun 9, 2015, at 4:48 AM, Bengt Rutisson wrote: > >> CR: >> https://bugs.openjdk.java.net/browse/JDK-8086027 >> >> Webrev: >> http://cr.openjdk.java.net/~kbarrett/8086027/webrev.00/ > > This looks good to me. One question about the test in debug.cpp: > > 792 // class scope > 793 struct TestMultipleStaticAssertFormsInClassScope { > > I know struct and class are pretty much the same, but wouldn't it be more consistent to use class instead of struct here since the comment (and I think the spec) talk about class scope? The definition of ?class scope? makes no distinction for the introducing class-key. The ?class? and ?struct? class-keys are (so far as I can tell) identical other than their implications for initial accessibility. (Despite some compilers warning about mismatches in class-key usage between forward declarations and definitions.) If I used ?class? here rather than ?struct? I would probably add ?public:? to avoid any possibility of some compiler whining about the unused typedefs. (Although gcc -Wunused-local-typedefs will still hit us in the function scope case; but I don?t think that?s a very interesting warning anyway, though as of gcc4.8 it?s part of -Wall, which annoyed lots of people.) > > Either way is fine with me and in any case you don't need to send out another webrev. > > Thanks, > Bengt Thanks for reviewing. From goetz.lindenmaier at sap.com Wed Jun 10 06:46:40 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 10 Jun 2015 06:46:40 +0000 Subject: RFR(XXS): 8086073: Fix PrintStubCode for empty StubCodeGenerator. Message-ID: <4295855A5C1DE049A61835A1887419CC2CFEC7EA@DEWDFEMB12A.global.corp.sap> Hi, PrintStubCode runs into an assertion if a StubCodeGenerator that never generated a stub is deleted. This happens for ICacheStubGenerator on ppc, as we implement the flushing with inline assembly and don't generate a stub. The fix is to check for an empty list in the assertion. Please review and sponsor this tiny fix. http://cr.openjdk.java.net/~goetz/webrevs/8086073-PSC/webrev.01/ Best regards and thanks, Goetz. From vladimir.kozlov at oracle.com Wed Jun 10 06:51:00 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 09 Jun 2015 23:51:00 -0700 Subject: RFR(XXS): 8086073: Fix PrintStubCode for empty StubCodeGenerator. In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CFEC7EA@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CFEC7EA@DEWDFEMB12A.global.corp.sap> Message-ID: <5577DE54.4030408@oracle.com> Looks good. Thanks, Vladimir On 6/9/15 11:46 PM, Lindenmaier, Goetz wrote: > Hi, > > PrintStubCode runs into an assertion if a StubCodeGenerator that never generated > a stub is deleted. This happens for ICacheStubGenerator on ppc, as we implement > the flushing with inline assembly and don't generate a stub. > > The fix is to check for an empty list in the assertion. > > Please review and sponsor this tiny fix. > http://cr.openjdk.java.net/~goetz/webrevs/8086073-PSC/webrev.01/ > > > Best regards and thanks, > Goetz. > From roland.westrelin at oracle.com Wed Jun 10 07:09:20 2015 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Wed, 10 Jun 2015 09:09:20 +0200 Subject: [8u] backport of 8078866: compiler/eliminateAutobox/6934604/TestIntBoxing.java assert(p_f->Opcode() == Op_IfFalse) failed Message-ID: 8u backport request. 8078866 was pushed to jdk9 friday last week and it hasn?t caused any new failures during nightly testing. The change applies cleanly to 8u. https://bugs.openjdk.java.net/browse/JDK-8078866 http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/ac1a9d805f11 Roland. From erik.joelsson at oracle.com Wed Jun 10 07:18:03 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 10 Jun 2015 09:18:03 +0200 Subject: RFR: JDK-8085822 JEP 223: New Version-String Scheme (initial integration) In-Reply-To: <5576EF94.3010500@oracle.com> References: <5571AD18.7080701@oracle.com> <557625C8.5050200@oracle.com> <5576E633.9050503@oracle.com> <5576E81B.8050703@oracle.com> <5576EF94.3010500@oracle.com> Message-ID: <5577E4AB.4090305@oracle.com> Looks good. /Erik On 2015-06-09 15:52, Magnus Ihse Bursie wrote: > Here's an updated webrev, which fixes the typos that were pointed out > by reviewers: > http://cr.openjdk.java.net/~ihse/JDK-8085822-JEP-223-initial-patch/webrev.02/ > > > And here's a (much simpler) delta webrev which shows just these changes: > http://cr.openjdk.java.net/~ihse/JDK-8085822-JEP-223-initial-patch-delta-01/webrev.01/ > > > /Magnus > > On 2015-06-09 15:20, Daniel D. Daugherty wrote: >> On 6/9/15 7:12 AM, Magnus Ihse Bursie wrote: >>> Hi Daniel, >>> >>> Thank you for your thorough review! >> >> This was my (failing) attempt at a "fast pass" review... :-) >> >> >>> >>> On 2015-06-09 01:31, Daniel D. Daugherty wrote: >>>> > >>>> http://cr.openjdk.java.net/~ihse/JDK-8085822-JEP-223-initial-patch/webrev.01 >>>> >>>> >>>> General comment: Not all copyright years were updated. >>>> General comment: It looks like support for the 'patch' value is not >>>> completely >>>> implemented through all the Makefiles. I didn't audit for this, >>>> but it's >>>> just my impression. >>> >>> You are basically correct. The makefiles all propagate the patch >>> value where needed, but the actual source code changes in hotspot >>> and jdk ignores the patch field as of now. This will be corrected in >>> a later add-on patch, submitted by someone from the jdk and/or >>> hotspot team rather than the build team. >>> >>>> >>>> common/autoconf/generated-configure.sh >>>> There are multiple Copyright notices in this file. Why? >>> Oh dear, you've reviewed the generated file. :-& I'm really >>> impressed by your effort! >> >> Ahhh... now that you say it... it sounds familiar... I may have >> made this same mistake before. I'll try to remember next time. >> >> >>> However, the generated-configure.sh file is automatically created by >>> the autoconf framework from the rest of the files in >>> common/autoconf/*, so we cannot direcly modify it's contents - only >>> indirectly. The reason it's checked in, is that otherwise every user >>> would need to generate it before being able to run configure. In >>> build reviews, we usually either revert changes to >>> generated-configure.sh before posting a review to hide it (and >>> re-generate it before pushing), or we just ignore it during reviews. >>> I should have done that, or pointed out that it was not needed nor >>> possible to review when I cross-posted. I'm sorry. >>> >>>> >>>> L4076: # Verify that a given string represent a valid version >>>> number, and assing it to >>>> L4077: # a variable. >>>> Fixed two typos and reformat a bit: >>>> # Verify that a given string represents a valid version >>>> number, and >>>> # assigning it to a variable. >>> I'll put that fix in the source .m4 file instead. Thanks. >>>> >>>> L20262: as_fn_error $? "--with--version-string must have a >>>> value" "$LINENO" 5 >>>> The '--with--version...' part doesn't match previous usages >>>> where >>>> '--with-version...' is used >>> Yes, you're right. Erik pointed it out as well. It's a typo in the >>> error message. It's all over the place due to copied code. I'll fix >>> it in the source .m4 file. >>> >>> (As a side note, I have a half-finished follow-up patch that will >>> reduce the amount of code duplication, but it requires some >>> framework changes so it'll have to be a separate thing.) >>> >>>> >>>> L20275: # Unspecified numerical fields is interpreted as 0. >>>> Grammar: 'is interpreted' -> 'are interpreted' >>>> >>>> L20286: as_fn_error $? "Version string contains + but >>>> both 'BUILD' and 'OPT' is missing" "$LINENO" 5 >>>> Grammar: 'is missing' -> 'are missing' >>> Those darn English plural forms! Why can't you all do as we sensible >>> Swedes and get rid of them? ;-) >>> >>> (I'll fix) >>> >>>> >>>> L20388: username=`$ECHO "$USER" | $TR -d -c >>>> '[a-z][A-Z][0-9]'` >>>> This assumes that the "USER" variable is set. Should there >>>> be a check for "" and perhaps use "no_user_specified" or >>>> something like that? Perhaps the build setup always makes >>>> sure that "USER" is set to something. Don't know. >>> Hm. I think the worst thing that'll happen is that the username part >>> of the opt string gets empty. This part is basically copied right >>> off the old build, where we have relied on the $USER variable being >>> present for all the time with no problems, so I think it's quite >>> safe to assume. >>>> >>>> common/autoconf/jdk-options.m4 >>>> Don't know why the 'elliptic curve crypto implementation' support >>>> is relocated as part of this changeset, but ... >>> It was incorrectly placed not at the top indentation level, but in >>> the middle of the function definition where the old versioning code >>> were handled. (Which, mostly by chance, happens to work in autoconf, >>> but is really bad style). >>> >>>> make/Javadoc.gmk >>>> Did you mean to remove the 'clean' target? >>> Yep. Cleaning is done by the top-level Main.gmk makefile nowadays, >>> that's just some dead code. >>> >>>> >>>> hotspot/make/windows/makefiles/compile.make >>>> No changes in the frames view. >>>> Update: udiff view shows a blank line deleted at the end of the >>>> file. >>> >>> That's probably the result of some change going forth and then back >>> again during development. But then again, removing extra blank >>> linkes is not a bad thing. (jcheck unfortunately does not enforce >>> any style checks for make files :-( so they tend to detoriate over >>> time.) >>> >>>> >>>> hotspot/src/share/vm/runtime/java.cpp >>>> L661: void JDK_Version::fully_initialize( >>>> L662: uint8_t major, uint8_t minor, uint8_t security, >>>> uint8_t update) { >>>> L663: // This is only called when current is less than 1.6 >>>> and we've gotten >>>> >>>> Since you're ripping out vestigial version support, I think >>>> this >>>> function can go away since this is version 9 and newer. >>>> Don't really >>>> know for sure, but based on that comment... >>> It probably can, yes. This and other core changes to the actual >>> .cpp/.java files will be addressed in a follow-up patch. >>>> >>>> hotspot/src/share/vm/runtime/java.hpp >>>> No comments. >>>> >>>> hotspot/src/share/vm/runtime/vmStructs.cpp >>>> L1240: please make the 'int' parameter align like the rest. >>> Are you okay with defering such a change to a follow-up patch? >> >> Yes. >> >> >>> It's likely the entire struct will need changes to be able to handle >>> a theoretically arbitrarily long version number. >>> >>>> >>>> hotspot/src/share/vm/runtime/vm_version.cpp >>>> L84: void Abstract_VM_Version::initialize() { >>>> L85: // FIXME: Initialization can probably be removed now. >>>> I agree, but that would entail also removing the >>>> _initialized and the uses of it... Follow on bug fix? >>> Definitely follow on. >>> >>>> jdk/src/java.base/share/classes/sun/misc/Version.java.template >>>> L149: * Returns the security version of the running JVM if >>>> it's 1.6 or newer >>>> This JavaDoc update is wrong, but it might not be important >>>> if sun.misc.Version class is going away. >>> I'm not sure if it's going to be replaced by, or just complemented >>> by java.util.Version, but in any case it will need a follow-up patch >>> to clean up this and other issues. >>>> langtools/src/java.compiler/share/classes/javax/lang/model/SourceVersion.java >>>> >>>> old L171: case "1.9": >>>> new L171: case "9": >>>> Should this logic support both versions? Will dropping >>>> "1.9" here prevent a pre-version changeset JVM from >>>> being dropped into a JDK for triage purposes? >>>> >>>> Granted we don't often triage 'javac' with different JVMs, >>>> but... >>> I'll defer that question to Kumar, who wrote that piece of code. My >>> guess is that when Hotspot express was dropped, the ability to use a >>> JVM from another JDK release bit rotteded away. >>> >>> /Magnus >> >> Dan > From vladimir.kozlov at oracle.com Wed Jun 10 07:27:38 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 10 Jun 2015 00:27:38 -0700 Subject: [8u] backport of 8078866: compiler/eliminateAutobox/6934604/TestIntBoxing.java assert(p_f->Opcode() == Op_IfFalse) failed In-Reply-To: References: Message-ID: <5577E6EA.7000102@oracle.com> Looks good. Thanks, Vladimir On 6/10/15 12:09 AM, Roland Westrelin wrote: > 8u backport request. 8078866 was pushed to jdk9 friday last week and it hasn?t caused any new failures during nightly testing. The change applies cleanly to 8u. > > https://bugs.openjdk.java.net/browse/JDK-8078866 > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/ac1a9d805f11 > > Roland. > From roland.westrelin at oracle.com Wed Jun 10 07:32:59 2015 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Wed, 10 Jun 2015 09:32:59 +0200 Subject: [8u] backport of 8078866: compiler/eliminateAutobox/6934604/TestIntBoxing.java assert(p_f->Opcode() == Op_IfFalse) failed In-Reply-To: <5577E6EA.7000102@oracle.com> References: <5577E6EA.7000102@oracle.com> Message-ID: <9B6464F5-5869-454B-BF25-C9B8D73B5C41@oracle.com> Thanks, Vladimir. Roland. > On Jun 10, 2015, at 9:27 AM, Vladimir Kozlov wrote: > > Looks good. > > Thanks, > Vladimir > > On 6/10/15 12:09 AM, Roland Westrelin wrote: >> 8u backport request. 8078866 was pushed to jdk9 friday last week and it hasn?t caused any new failures during nightly testing. The change applies cleanly to 8u. >> >> https://bugs.openjdk.java.net/browse/JDK-8078866 >> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/ac1a9d805f11 >> >> Roland. >> From volker.simonis at gmail.com Wed Jun 10 07:34:11 2015 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 10 Jun 2015 09:34:11 +0200 Subject: RFR(M): 8081674: EmptyStackException at startup if running with extended or unsupported charset In-Reply-To: <55772A56.2030308@oracle.com> References: <557626AA.6010008@oracle.com> <55772A56.2030308@oracle.com> Message-ID: Mandy, the example/stacktrace I sent was with 8u. The problem isn't related to libzip, it is only the first library which gets loaded with System.loadLibrary(). The problem will occur with every library which gets loaded by System.loadLibrary() because java.lang.ClassLoader$NativeLibrary.findBuiltinLib() always calls jni_FindClass() if we're running on a unsupported locale. On Tue, Jun 9, 2015 at 8:03 PM, Mandy Chung wrote: > Does my patch work fine on 8u? If it works fine, I prefer to get that > simple fix in 8u and take the time to have a better fix in 9 (jdk9 is still > under development and I have assumed that it's not a show stopper to you. > Let me know if it blocks you). > > A question to Sherman - do we have adequate tests to verify the move of > System.loadLibrary("zip") from system initialization to ZipFile > initialization for 8u? > > Mandy > > > On 06/09/2015 10:09 AM, Volker Simonis wrote: >> >> Hi Mandy, >> >> thanks for looking into this. >> Uunfortunately your fix only helps to fix "java -version" :( >> >> Running even a minimal HelloWorld will still fail with the following >> stack trace which is still caused by the same EmptyStackException: >> >> Error: A JNI error has occurred, please check your installation and try >> again >> Exception in thread "main" java.lang.ExceptionInInitializerError >> at sun.misc.Unsafe.ensureClassInitialized(Native Method) >> at >> sun.misc.SharedSecrets.getJavaUtilZipFileAccess(SharedSecrets.java:158) >> at sun.misc.URLClassPath$JarLoader.(URLClassPath.java:765) >> at sun.misc.URLClassPath$3.run(URLClassPath.java:530) >> at sun.misc.URLClassPath$3.run(URLClassPath.java:520) >> at java.security.AccessController.doPrivileged(Native Method) >> at sun.misc.URLClassPath.getLoader(URLClassPath.java:519) >> at sun.misc.URLClassPath.getLoader(URLClassPath.java:492) >> at sun.misc.URLClassPath.getNextLoader(URLClassPath.java:457) >> at sun.misc.URLClassPath.access$100(URLClassPath.java:64) >> at sun.misc.URLClassPath$1.next(URLClassPath.java:239) >> at sun.misc.URLClassPath$1.hasMoreElements(URLClassPath.java:250) >> at java.net.URLClassLoader$3$1.run(URLClassLoader.java:601) >> at java.net.URLClassLoader$3$1.run(URLClassLoader.java:599) >> at java.security.AccessController.doPrivileged(Native Method) >> at java.net.URLClassLoader$3.next(URLClassLoader.java:598) >> at java.net.URLClassLoader$3.hasMoreElements(URLClassLoader.java:623) >> at sun.misc.CompoundEnumeration.next(CompoundEnumeration.java:45) >> at >> sun.misc.CompoundEnumeration.hasMoreElements(CompoundEnumeration.java:54) >> at sun.misc.CompoundEnumeration.next(CompoundEnumeration.java:45) >> at >> sun.misc.CompoundEnumeration.hasMoreElements(CompoundEnumeration.java:54) >> at >> java.util.ServiceLoader$LazyIterator.hasNextService(ServiceLoader.java:354) >> at >> java.util.ServiceLoader$LazyIterator.hasNext(ServiceLoader.java:393) >> at java.util.ServiceLoader$1.hasNext(ServiceLoader.java:474) >> at java.nio.charset.Charset$1.getNext(Charset.java:350) >> at java.nio.charset.Charset$1.hasNext(Charset.java:365) >> at java.nio.charset.Charset$2.run(Charset.java:410) >> at java.nio.charset.Charset$2.run(Charset.java:407) >> at java.security.AccessController.doPrivileged(Native Method) >> at java.nio.charset.Charset.lookupViaProviders(Charset.java:406) >> at java.nio.charset.Charset.lookup2(Charset.java:477) >> at java.nio.charset.Charset.lookup(Charset.java:464) >> at java.nio.charset.Charset.isSupported(Charset.java:505) >> at >> sun.launcher.LauncherHelper.makePlatformString(LauncherHelper.java:580) >> Caused by: java.util.EmptyStackException >> at java.util.Stack.peek(Stack.java:102) >> at >> java.lang.ClassLoader$NativeLibrary.getFromClass(ClassLoader.java:1759) >> at java.lang.ClassLoader$NativeLibrary.findBuiltinLib(Native Method) >> at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1870) >> at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1843) >> at java.lang.Runtime.loadLibrary0(Runtime.java:870) >> at java.lang.System.loadLibrary(System.java:1122) >> at java.util.zip.ZipFile.(ZipFile.java:86) >> ... 34 more >> >> It's obvious that the way jni_FindClass is looking for the class >> context by calling the NativeLibrary::getFromClass method is hacky but >> I think that the proposed fix is the quite simple and non-intrusive. >> And we probably don't want a complete rework of this code for 8 >> anyway. So why not fix it the proposed way in 8 and 9 for now? That >> will still leave us time to come up with a better clean-up at least >> for 9. >> >> What do you think? >> >> Regards, >> Volker >> >> On Tue, Jun 9, 2015 at 1:35 AM, Mandy Chung >> wrote: >>> >>> Hi Volker, >>> >>> Your patch reminds me the question I have about loading zip library. >>> >>> In JDK 9 (and earlier release), zip library is loaded by the VM during >>> startup (see ClassLoader::load_zip_library). I think loadLibrary("zip") >>> is >>> no longer needed to be called from System::initializeSystemClass method >>> and >>> instead it can be loaded by java.util.zip.ZipFile static initializer. >>> >>> Do you mind to try the patch (below)? That may be a simpler fix. >>> >>> I never like the way jni_FindClass to look for the class context by >>> calling >>> the NativeLibrary::getFromClass method. I will have to look deeper other >>> alternative to clean that up. If taking out loadLibrary("zip") resolves >>> your issue, this will give us time to come up with a better clean-up in >>> the >>> future. >>> >>> Mandy >>> [1] https://bugs.openjdk.java.net/browse/JDK-4429040 >>> >>> diff --git a/src/share/classes/java/lang/System.java >>> b/src/share/classes/java/lang/System.java >>> --- a/src/share/classes/java/lang/System.java >>> +++ b/src/share/classes/java/lang/System.java >>> @@ -1192,10 +1192,6 @@ >>> setOut0(newPrintStream(fdOut, >>> props.getProperty("sun.stdout.encoding"))); >>> setErr0(newPrintStream(fdErr, >>> props.getProperty("sun.stderr.encoding"))); >>> >>> - // Load the zip library now in order to keep >>> java.util.zip.ZipFile >>> - // from trying to use itself to load this library later. >>> - loadLibrary("zip"); >>> - >>> // Setup Java signal handlers for HUP, TERM, and INT (where >>> available). >>> Terminator.setup(); >>> >>> diff --git a/src/share/classes/java/util/zip/ZipFile.java >>> b/src/share/classes/java/util/zip/ZipFile.java >>> --- a/src/share/classes/java/util/zip/ZipFile.java >>> +++ b/src/share/classes/java/util/zip/ZipFile.java >>> @@ -83,6 +83,7 @@ >>> >>> static { >>> /* Zip library is loaded from System.initializeSystemClass */ >>> + System.loadLibrary("zip"); >>> initIDs(); >>> >>> } >>> >>> >>> >>> On 06/08/2015 07:23 AM, Volker Simonis wrote: >>>> >>>> Hi, >>>> >>>> can I please get a review at least for the part of this fix which is >>>> common for jdk8 and jdk9. It's only a few lines in >>>> src/share/vm/prims/jni.cpp for the hotspot repository and one line >>>> src/java.base/share/classes/java/lang/ClassLoader.java for the jdk >>>> repository. >>>> >>>> Thanks, >>>> Volker >>>> >>>> >>>> On Tue, Jun 2, 2015 at 6:12 PM, Volker Simonis >>>> >>>> wrote: >>>>> >>>>> Hi, >>>>> >>>>> can I please have review (and a sponsor) for these changes: >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8081674 >>>>> http://cr.openjdk.java.net/~simonis/webrevs/2015/8081674.jdk >>>>> http://cr.openjdk.java.net/~simonis/webrevs/2015/8081674.hs >>>>> >>>>> Please notice that the fix requires synchronous changes in the jdk and >>>>> the >>>>> hotspot forest. >>>>> >>>>> The changes themselves are by far not that big as this explanation but >>>>> I >>>>> found the problem to be quite intricate so I tried to explain it as >>>>> good >>>>> as >>>>> I could. I'd suggest to read the HTML-formatted explanation in the >>>>> webrev >>>>> although the content is equal to the one in this mail: >>>>> >>>>> Using an unsupported character encoding (e.g. vi_VN.TCVN on Linux) >>>>> results >>>>> in an immediate VM failure with jdk 8 and 9: >>>>> >>>>> export LANG=vi_VN.TCVN >>>>> java -version >>>>> Error occurred during initialization of VM >>>>> java.util.EmptyStackException >>>>> at java.util.Stack.peek(Stack.java:102) >>>>> at >>>>> java.lang.ClassLoader$NativeLibrary.getFromClass(ClassLoader.java:1751) >>>>> at java.lang.ClassLoader$NativeLibrary.findBuiltinLib(Native >>>>> Method) >>>>> at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1862) >>>>> at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1835) >>>>> at java.lang.Runtime.loadLibrary0(Runtime.java:870) >>>>> at java.lang.System.loadLibrary(System.java:1119) >>>>> at java.lang.System.initializeSystemClass(System.java:1194) >>>>> >>>>> This is a consequence of "8005716: Enhance JNI specification to allow >>>>> support of static JNI libraries in Embedded JREs". >>>>> >>>>> With jdk 9 we get this error even if we're running with a supported >>>>> charset >>>>> which is in the ExtendedCharsets (as opposed to being in the >>>>> StandardCharsets) class which is a consequence of delegating the >>>>> loading >>>>> of >>>>> the ExtendedCharsets class to the ServiceLoader in jdk 9. >>>>> >>>>> export LANG=eo.iso-8859-3 >>>>> output-jdk9/images/jdk/bin/java -version >>>>> Error occurred during initialization of VM >>>>> java.util.EmptyStackException >>>>> at java.util.Stack.peek(Stack.java:102) >>>>> at >>>>> java.lang.ClassLoader$NativeLibrary.getFromClass(ClassLoader.java:1737) >>>>> at java.lang.ClassLoader$NativeLibrary.findBuiltinLib(Native >>>>> Method) >>>>> at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1866) >>>>> at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1840) >>>>> at java.lang.Runtime.loadLibrary0(Runtime.java:874) >>>>> at java.lang.System.loadLibrary(System.java:1111) >>>>> at java.lang.System.initializeSystemClass(System.java:1186) >>>>> >>>>> Here's why the exception happens for an unsupported charset (see the >>>>> mixed >>>>> stack trace below for the full details): >>>>> >>>>> java.lang.System.loadLibrary() wants to load libzip.so. It calls >>>>> java.lang.Runtime.loadLibrary0() which at the very beginning calls the >>>>> native method ClassLoader$NativeLibrary.findBuiltinLib() which checks >>>>> if >>>>> the >>>>> corresponding library is already statically linked into the VM >>>>> (introduced >>>>> by 8005716). >>>>> Java_java_lang_ClassLoader_00024NativeLibrary_findBuiltinLib(), >>>>> the native implementation of findBuiltinLib() in Classloader.c calls >>>>> GetStringPlatformChars() to convert the library name into the native >>>>> platform encoding. GetStringPlatformChars() calls the helper function >>>>> jnuEncodingSupported() to check if the platform encoding which is >>>>> stored >>>>> in >>>>> the property "sun.jnu.encoding" is supported by Java. >>>>> jnuEncodingSupported() >>>>> is implemented as follows: >>>>> >>>>> static jboolean isJNUEncodingSupported = JNI_FALSE; >>>>> static jboolean jnuEncodingSupported(JNIEnv *env) { >>>>> jboolean exe; >>>>> if (isJNUEncodingSupported == JNI_TRUE) { >>>>> return JNI_TRUE; >>>>> } >>>>> isJNUEncodingSupported = (jboolean) JNU_CallStaticMethodByName ( >>>>> env, &exe, >>>>> "java/nio/charset/Charset", >>>>> "isSupported", >>>>> "(Ljava/lang/String;)Z", >>>>> jnuEncoding).z; >>>>> return isJNUEncodingSupported; >>>>> } >>>>> >>>>> Once the function finds that the platform encoding is supported (by >>>>> calling >>>>> java.nio.charset.Charset.isSupported()) it caches this value and always >>>>> returns it on following calls. However if the platform encoding is not >>>>> supported, it ALWAYS calls java.nio.charset.Charset.isSupported() an >>>>> every >>>>> subsequent invocation. >>>>> >>>>> In order to call the Java method Charset.isSupported() (in >>>>> JNU_CallStaticMethodByName() in file jni_util.c), we have to call >>>>> jni_FindClass() to convert the symbolic class name >>>>> "java.nio.charset.Charset" into a class reference. >>>>> >>>>> But unfortunately, jni_FindClass() (from jni.cpp in libjvm.so) has a >>>>> special >>>>> handling if called from java.lang.ClassLoader$NativeLibrary to ensure >>>>> that >>>>> JNI_OnLoad/JNI_OnUnload are executed in the correct class context: >>>>> >>>>> instanceKlassHandle k (THREAD, >>>>> thread->security_get_caller_class(0)); >>>>> if (k.not_null()) { >>>>> loader = Handle(THREAD, k->class_loader()); >>>>> // Special handling to make sure JNI_OnLoad and JNI_OnUnload are >>>>> executed >>>>> // in the correct class context. >>>>> if (loader.is_null() && >>>>> k->name() == >>>>> vmSymbols::java_lang_ClassLoader_NativeLibrary()) { >>>>> JavaValue result(T_OBJECT); >>>>> JavaCalls::call_static(&result, k, >>>>> vmSymbols::getFromClass_name(), >>>>> >>>>> vmSymbols::void_class_signature(), >>>>> thread); >>>>> if (HAS_PENDING_EXCEPTION) { >>>>> Handle ex(thread, thread->pending_exception()); >>>>> CLEAR_PENDING_EXCEPTION; >>>>> THROW_HANDLE_0(ex); >>>>> } >>>>> >>>>> So if that's the case and jni_FindClass() was reallycalled from >>>>> ClassLoader$NativeLibrary, then jni_FindClass() calles >>>>> ClassLoader$NativeLibrary().getFromClass() to find out the >>>>> corresponding >>>>> context class which is supposed to be saved there in a field of type >>>>> java.util.Stack named "nativeLibraryContext": >>>>> >>>>> // Invoked in the VM to determine the context class in >>>>> // JNI_Load/JNI_Unload >>>>> static Class getFromClass() { >>>>> return ClassLoader.nativeLibraryContext.peek().fromClass; >>>>> } >>>>> >>>>> Unfortunately, "nativeLibraryContext" doesn't contain any entry at this >>>>> point and the invocation of Stack.peek() will throw the exception shown >>>>> before. In general, the "nativeLibraryContext" stack will be filled >>>>> later >>>>> on >>>>> in Runtime.loadLibrary0() like this: >>>>> >>>>> NativeLibrary lib = new NativeLibrary(fromClass, name, isBuiltin); >>>>> nativeLibraryContext.push(lib); >>>>> try { >>>>> lib.load(name, isBuiltin); >>>>> } finally { >>>>> nativeLibraryContext.pop(); >>>>> } >>>>> >>>>> such that it always contains at least one element later when >>>>> jni_FindClass() >>>>> will be invoked. >>>>> >>>>> So in summary, the problem is that the implementors of 8005716 didn't >>>>> took >>>>> into account that calling ClassLoader$NativeLibrary.findBuiltinLib() >>>>> may >>>>> trigger a call to jni_FindClass() if we are running on a system with an >>>>> unsupported character encoding. >>>>> >>>>> I'd suggest the following fix for this problem: >>>>> >>>>> Change ClassLoader$NativeLibrary().getFromClass() to return null if the >>>>> stack is empty instead of throwing an exception: >>>>> >>>>> static Class getFromClass() { >>>>> return ClassLoader.nativeLibraryContext.empty() ? >>>>> null : ClassLoader.nativeLibraryContext.peek().fromClass; >>>>> } >>>>> >>>>> Unfortunately this also requires a HotSpot change in jni_FindClass() in >>>>> order to properly handle the new 'null' return value: >>>>> >>>>> if (k.not_null()) { >>>>> loader = Handle(THREAD, k->class_loader()); >>>>> // Special handling to make sure JNI_OnLoad and JNI_OnUnload are >>>>> executed >>>>> // in the correct class context. >>>>> if (loader.is_null() && >>>>> k->name() == >>>>> vmSymbols::java_lang_ClassLoader_NativeLibrary()) { >>>>> JavaValue result(T_OBJECT); >>>>> JavaCalls::call_static(&result, k, >>>>> vmSymbols::getFromClass_name(), >>>>> >>>>> vmSymbols::void_class_signature(), >>>>> thread); >>>>> if (HAS_PENDING_EXCEPTION) { >>>>> Handle ex(thread, thread->pending_exception()); >>>>> CLEAR_PENDING_EXCEPTION; >>>>> THROW_HANDLE_0(ex); >>>>> } >>>>> oop mirror = (oop) result.get_jobject(); >>>>> if (oopDesc::is_null(mirror)) { >>>>> loader = Handle(THREAD, >>>>> SystemDictionary::java_system_loader()); >>>>> } else { >>>>> loader = Handle(THREAD, >>>>> >>>>> >>>>> InstanceKlass::cast(java_lang_Class::as_Klass(mirror))->class_loader()); >>>>> protection_domain = Handle(THREAD, >>>>> >>>>> >>>>> >>>>> InstanceKlass::cast(java_lang_Class::as_Klass(mirror))->protection_domain()); >>>>> } >>>>> } >>>>> } else { >>>>> // We call ClassLoader.getSystemClassLoader to obtain the system >>>>> class >>>>> loader. >>>>> loader = Handle(THREAD, SystemDictionary::java_system_loader()); >>>>> } >>>>> >>>>> These changes are sufficient to solve the problem in Java 8. >>>>> Unfortunately, >>>>> that's still not enough in Java 9 because there the loading of the >>>>> extended >>>>> charsets has been delegated to ServiceLoader. But ServiceLoader calls >>>>> ClassLoader.getBootstrapResources() which calls >>>>> sun.misc.Launcher.getBootstrapClassPath(). This leads to another >>>>> problem >>>>> during class initialization of sun.misc.Launcher if running on an >>>>> unsupported locale. >>>>> >>>>> The first thing done in sun.misc.Launcher. is the >>>>> initialisation >>>>> of >>>>> the bootstrap URLClassPath in the Launcher. However this initialisation >>>>> will >>>>> eventually call Charset.isSupported() and if we are running on an >>>>> unsupported locale this will inevitably end in another recursive call >>>>> to >>>>> ServiceLoader. But as explained below, ServiceLoader will query the >>>>> Launcher's bootstrap URLClassPath which will be still uninitialized at >>>>> that >>>>> point. >>>>> >>>>> So we'll have to additionally guard guard against this situation on JDK >>>>> 9 >>>>> like this: >>>>> >>>>> private static Charset lookupExtendedCharset(String charsetName) { >>>>> if (!sun.misc.VM.isBooted() || // see >>>>> lookupViaProviders() >>>>> sun.misc.Launcher.getBootstrapClassPath() == null) >>>>> return null; >>>>> >>>>> This fixes the crashes, but still at the price of not having the >>>>> extended >>>>> charsets available during initialization until >>>>> Launcher.getBootstrapClassPath is set up properly. This may be still a >>>>> problem if the jdk is installed in a directory which contains >>>>> characters >>>>> specific to an extended encoding or if we have such characters in the >>>>> command line arguments. >>>>> >>>>> Thank you and best regards, >>>>> Volker >>>>> >>>>> >>>>> Mixed stack trace of the initial EmptyStackException for unsupported >>>>> charsets described before: >>>>> >>>>> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, >>>>> C=native >>>>> code) >>>>> j java.util.Stack.peek()Ljava/lang/Object;+1 >>>>> j >>>>> java.lang.ClassLoader$NativeLibrary.getFromClass()Ljava/lang/Class;+3 >>>>> v ~StubRoutines::call_stub >>>>> V [libjvm.so+0x9d279a] JavaCalls::call_helper(JavaValue*, >>>>> methodHandle*, >>>>> JavaCallArguments*, Thread*)+0x6b4 >>>>> V [libjvm.so+0xcad591] os::os_exception_wrapper(void (*)(JavaValue*, >>>>> methodHandle*, JavaCallArguments*, Thread*), JavaValue*, methodHandle*, >>>>> JavaCallArguments*, Thread*)+0x45 >>>>> V [libjvm.so+0x9d20cf] JavaCalls::call(JavaValue*, methodHandle, >>>>> JavaCallArguments*, Thread*)+0x8b >>>>> V [libjvm.so+0x9d1d3b] JavaCalls::call_static(JavaValue*, >>>>> KlassHandle, >>>>> Symbol*, Symbol*, JavaCallArguments*, Thread*)+0x139 >>>>> V [libjvm.so+0x9d1e3f] JavaCalls::call_static(JavaValue*, >>>>> KlassHandle, >>>>> Symbol*, Symbol*, Thread*)+0x9d >>>>> V [libjvm.so+0x9e6588] jni_FindClass+0x428 >>>>> C [libjava.so+0x20208] JNU_CallStaticMethodByName+0xff >>>>> C [libjava.so+0x21cae] jnuEncodingSupported+0x61 >>>>> C [libjava.so+0x22125] JNU_GetStringPlatformChars+0x125 >>>>> C [libjava.so+0xedcd] >>>>> Java_java_lang_ClassLoader_00024NativeLibrary_findBuiltinLib+0x8b >>>>> j >>>>> >>>>> >>>>> java.lang.ClassLoader$NativeLibrary.findBuiltinLib(Ljava/lang/String;)Ljava/lang/String;+0 >>>>> j >>>>> java.lang.ClassLoader.loadLibrary0(Ljava/lang/Class;Ljava/io/File;)Z+4 >>>>> j >>>>> >>>>> >>>>> java.lang.ClassLoader.loadLibrary(Ljava/lang/Class;Ljava/lang/String;Z)V+228 >>>>> j >>>>> java.lang.Runtime.loadLibrary0(Ljava/lang/Class;Ljava/lang/String;)V+54 >>>>> j java.lang.System.loadLibrary(Ljava/lang/String;)V+7 >>>>> j java.lang.System.initializeSystemClass()V+113 >>>>> v ~StubRoutines::call_stub >>>>> V [libjvm.so+0x9d279a] JavaCalls::call_helper(JavaValue*, >>>>> methodHandle*, >>>>> JavaCallArguments*, Thread*)+0x6b4 >>>>> V [libjvm.so+0xcad591] os::os_exception_wrapper(void (*)(JavaValue*, >>>>> methodHandle*, JavaCallArguments*, Thread*), JavaValue*, methodHandle*, >>>>> JavaCallArguments*, Thread*)+0x45 >>>>> V [libjvm.so+0x9d20cf] JavaCalls::call(JavaValue*, methodHandle, >>>>> JavaCallArguments*, Thread*)+0x8b >>>>> V [libjvm.so+0x9d1d3b] JavaCalls::call_static(JavaValue*, >>>>> KlassHandle, >>>>> Symbol*, Symbol*, JavaCallArguments*, Thread*)+0x139 >>>>> V [libjvm.so+0x9d1e3f] JavaCalls::call_static(JavaValue*, >>>>> KlassHandle, >>>>> Symbol*, Symbol*, Thread*)+0x9d >>>>> V [libjvm.so+0xe3cceb] call_initializeSystemClass(Thread*)+0xb0 >>>>> V [libjvm.so+0xe44444] >>>>> Threads::initialize_java_lang_classes(JavaThread*, >>>>> Thread*)+0x21a >>>>> V [libjvm.so+0xe44b12] Threads::create_vm(JavaVMInitArgs*, >>>>> bool*)+0x4a6 >>>>> V [libjvm.so+0xa19bd7] JNI_CreateJavaVM+0xc7 >>>>> C [libjli.so+0xa520] InitializeJVM+0x154 >>>>> C [libjli.so+0x8024] JavaMain+0xcc >>>>> >>>>> > From sgehwolf at redhat.com Wed Jun 10 09:52:36 2015 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 10 Jun 2015 11:52:36 +0200 Subject: [8u60] Backport RFR: JDK-8078666 and JDK-8074312 In-Reply-To: <1433856445.3310.105.camel@redhat.com> References: <1433856445.3310.105.camel@redhat.com> Message-ID: <1433929956.3385.48.camel@redhat.com> Adding in jdk8u-dev. On Tue, 2015-06-09 at 15:27 +0200, Severin Gehwolf wrote: > Hi, > > Could I please get JDK-8078666 and JDK-8074312 backported to 8u60? I'd > need a sponsor for this. > > We've been using the JDK-8078666 fix for Fedora 22 on JDK8 for a while > now. Similarly, the fix for JDK-8074312 is now also required for Fedora > 21 and we've had this patch in use since March. > > "Enable hotspot builds on 4.x Linux kernels" > Bug: https://bugs.openjdk.java.net/browse/JDK-8074312 > Webrev: > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8074312/8-backport/ > Original review thread: > http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-March/017463.html > JDK 9 fix applies cleanly modulo copyright changes. > > > "JVM fastdebug build compiled with GCC 5 asserts with "widen increases" > Bug: https://bugs.openjdk.java.net/browse/JDK-8078666 > Original review thread: > http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2015-April/017759.html > JDK 9 fix applies cleanly to 8u forest. > > Thanks, > Severin > From david.holmes at oracle.com Wed Jun 10 09:58:11 2015 From: david.holmes at oracle.com (David Holmes) Date: Wed, 10 Jun 2015 19:58:11 +1000 Subject: RFR: JDK-8085822 JEP 223: New Version-String Scheme (initial integration) In-Reply-To: <5576EF94.3010500@oracle.com> References: <5571AD18.7080701@oracle.com> <557625C8.5050200@oracle.com> <5576E633.9050503@oracle.com> <5576E81B.8050703@oracle.com> <5576EF94.3010500@oracle.com> Message-ID: <55780A33.1010302@oracle.com> Hi Magnus, Generally looks good - a few comments/queries below. On 9/06/2015 11:52 PM, Magnus Ihse Bursie wrote: > Here's an updated webrev, which fixes the typos that were pointed out by > reviewers: > http://cr.openjdk.java.net/~ihse/JDK-8085822-JEP-223-initial-patch/webrev.02/ common/autoconf/version-numbers Shouldn't there be a DEFAULT_VERSION_XXX for each of the XXX parts of the version info? (Even if all zeroes presently.) --- Looking at hotspot changes I can't convince myself that the new streamlined "version" variables will capture things like "fastdebug". Will that filter through via configure variables? --- make/*/makefiles/vm.make Shouldn't the -DVERSION_XX=$(VERSION_XX) definitions be taken from the VERSION_CFLAGS in spec.gmk? (Or are you still allowing for a stand-alone hotspot build?) --- hotspot/src/share/vm/prims/jvm.h jdk/src/java.base/share/native/include/jvm.h I think this comment is way out of date: /* Build number is available only for RE build (i.e. JDK_BUILD_NUMBER is set to bNN) * It will be zero for internal builds. */ and can be completely removed. Even if still true, mention of an "RE build" has no place in OpenJDK sources. --- hotspot/src/share/vm/runtime/java.cpp I think a lot of the modified code is obsolete post Hotspot Express - which makes it hard to determine if the changes make sense. --- hotspot/src/share/vm/runtime/vmStructs.cpp Please fix the alignment (3 extra spaces on modified line): 1239 static_field(Abstract_VM_Version, _vm_minor_version, int) \ 1240 static_field(Abstract_VM_Version, _vm_security_version, int) \ --- hotspot/test/runtime/6981737/Test6981737.java This test is really only valid for the new version scheme now, so it should probably be rewritten - and in that case it really isn't testing 6981737 but should be replaced by a new test for the new version format. --- jdk/src/java.base/share/classes/sun/misc/Version.java.template This comment is nonsensical: /** ! * Returns the security version of the running JVM if it's 1.6 or newer * or any RE VM build. It will return 0 if it's an internal 1.5 or * 1.4.x build. * @since 1.6 */ as security version does not exist pre 9. Normally you should be adding a new method and deprecating the old one. The new one is @since 9. /** ! * Returns the security version of the running JDK. * @since 1.6 */ Ditto: @since 9 (but again old should be deprecated and new method added) 253 /** 254 * Returns the build number of the running JDK if it's a RE build 255 * It will return 0 if it's an internal build. As with jvm.h this seems obsolete commentary these days - not only RE builds define a build number. Thanks, David > > And here's a (much simpler) delta webrev which shows just these changes: > http://cr.openjdk.java.net/~ihse/JDK-8085822-JEP-223-initial-patch-delta-01/webrev.01/ > > > /Magnus > > On 2015-06-09 15:20, Daniel D. Daugherty wrote: >> On 6/9/15 7:12 AM, Magnus Ihse Bursie wrote: >>> Hi Daniel, >>> >>> Thank you for your thorough review! >> >> This was my (failing) attempt at a "fast pass" review... :-) >> >> >>> >>> On 2015-06-09 01:31, Daniel D. Daugherty wrote: >>>> > >>>> http://cr.openjdk.java.net/~ihse/JDK-8085822-JEP-223-initial-patch/webrev.01 >>>> >>>> >>>> General comment: Not all copyright years were updated. >>>> General comment: It looks like support for the 'patch' value is not >>>> completely >>>> implemented through all the Makefiles. I didn't audit for this, >>>> but it's >>>> just my impression. >>> >>> You are basically correct. The makefiles all propagate the patch >>> value where needed, but the actual source code changes in hotspot and >>> jdk ignores the patch field as of now. This will be corrected in a >>> later add-on patch, submitted by someone from the jdk and/or hotspot >>> team rather than the build team. >>> >>>> >>>> common/autoconf/generated-configure.sh >>>> There are multiple Copyright notices in this file. Why? >>> Oh dear, you've reviewed the generated file. :-& I'm really impressed >>> by your effort! >> >> Ahhh... now that you say it... it sounds familiar... I may have >> made this same mistake before. I'll try to remember next time. >> >> >>> However, the generated-configure.sh file is automatically created by >>> the autoconf framework from the rest of the files in >>> common/autoconf/*, so we cannot direcly modify it's contents - only >>> indirectly. The reason it's checked in, is that otherwise every user >>> would need to generate it before being able to run configure. In >>> build reviews, we usually either revert changes to >>> generated-configure.sh before posting a review to hide it (and >>> re-generate it before pushing), or we just ignore it during reviews. >>> I should have done that, or pointed out that it was not needed nor >>> possible to review when I cross-posted. I'm sorry. >>> >>>> >>>> L4076: # Verify that a given string represent a valid version >>>> number, and assing it to >>>> L4077: # a variable. >>>> Fixed two typos and reformat a bit: >>>> # Verify that a given string represents a valid version >>>> number, and >>>> # assigning it to a variable. >>> I'll put that fix in the source .m4 file instead. Thanks. >>>> >>>> L20262: as_fn_error $? "--with--version-string must have a >>>> value" "$LINENO" 5 >>>> The '--with--version...' part doesn't match previous usages >>>> where >>>> '--with-version...' is used >>> Yes, you're right. Erik pointed it out as well. It's a typo in the >>> error message. It's all over the place due to copied code. I'll fix >>> it in the source .m4 file. >>> >>> (As a side note, I have a half-finished follow-up patch that will >>> reduce the amount of code duplication, but it requires some framework >>> changes so it'll have to be a separate thing.) >>> >>>> >>>> L20275: # Unspecified numerical fields is interpreted as 0. >>>> Grammar: 'is interpreted' -> 'are interpreted' >>>> >>>> L20286: as_fn_error $? "Version string contains + but >>>> both 'BUILD' and 'OPT' is missing" "$LINENO" 5 >>>> Grammar: 'is missing' -> 'are missing' >>> Those darn English plural forms! Why can't you all do as we sensible >>> Swedes and get rid of them? ;-) >>> >>> (I'll fix) >>> >>>> >>>> L20388: username=`$ECHO "$USER" | $TR -d -c >>>> '[a-z][A-Z][0-9]'` >>>> This assumes that the "USER" variable is set. Should there >>>> be a check for "" and perhaps use "no_user_specified" or >>>> something like that? Perhaps the build setup always makes >>>> sure that "USER" is set to something. Don't know. >>> Hm. I think the worst thing that'll happen is that the username part >>> of the opt string gets empty. This part is basically copied right off >>> the old build, where we have relied on the $USER variable being >>> present for all the time with no problems, so I think it's quite safe >>> to assume. >>>> >>>> common/autoconf/jdk-options.m4 >>>> Don't know why the 'elliptic curve crypto implementation' support >>>> is relocated as part of this changeset, but ... >>> It was incorrectly placed not at the top indentation level, but in >>> the middle of the function definition where the old versioning code >>> were handled. (Which, mostly by chance, happens to work in autoconf, >>> but is really bad style). >>> >>>> make/Javadoc.gmk >>>> Did you mean to remove the 'clean' target? >>> Yep. Cleaning is done by the top-level Main.gmk makefile nowadays, >>> that's just some dead code. >>> >>>> >>>> hotspot/make/windows/makefiles/compile.make >>>> No changes in the frames view. >>>> Update: udiff view shows a blank line deleted at the end of the >>>> file. >>> >>> That's probably the result of some change going forth and then back >>> again during development. But then again, removing extra blank linkes >>> is not a bad thing. (jcheck unfortunately does not enforce any style >>> checks for make files :-( so they tend to detoriate over time.) >>> >>>> >>>> hotspot/src/share/vm/runtime/java.cpp >>>> L661: void JDK_Version::fully_initialize( >>>> L662: uint8_t major, uint8_t minor, uint8_t security, >>>> uint8_t update) { >>>> L663: // This is only called when current is less than 1.6 and >>>> we've gotten >>>> >>>> Since you're ripping out vestigial version support, I think >>>> this >>>> function can go away since this is version 9 and newer. >>>> Don't really >>>> know for sure, but based on that comment... >>> It probably can, yes. This and other core changes to the actual >>> .cpp/.java files will be addressed in a follow-up patch. >>>> >>>> hotspot/src/share/vm/runtime/java.hpp >>>> No comments. >>>> >>>> hotspot/src/share/vm/runtime/vmStructs.cpp >>>> L1240: please make the 'int' parameter align like the rest. >>> Are you okay with defering such a change to a follow-up patch? >> >> Yes. >> >> >>> It's likely the entire struct will need changes to be able to handle >>> a theoretically arbitrarily long version number. >>> >>>> >>>> hotspot/src/share/vm/runtime/vm_version.cpp >>>> L84: void Abstract_VM_Version::initialize() { >>>> L85: // FIXME: Initialization can probably be removed now. >>>> I agree, but that would entail also removing the >>>> _initialized and the uses of it... Follow on bug fix? >>> Definitely follow on. >>> >>>> jdk/src/java.base/share/classes/sun/misc/Version.java.template >>>> L149: * Returns the security version of the running JVM if >>>> it's 1.6 or newer >>>> This JavaDoc update is wrong, but it might not be important >>>> if sun.misc.Version class is going away. >>> I'm not sure if it's going to be replaced by, or just complemented by >>> java.util.Version, but in any case it will need a follow-up patch to >>> clean up this and other issues. >>>> langtools/src/java.compiler/share/classes/javax/lang/model/SourceVersion.java >>>> >>>> old L171: case "1.9": >>>> new L171: case "9": >>>> Should this logic support both versions? Will dropping >>>> "1.9" here prevent a pre-version changeset JVM from >>>> being dropped into a JDK for triage purposes? >>>> >>>> Granted we don't often triage 'javac' with different JVMs, >>>> but... >>> I'll defer that question to Kumar, who wrote that piece of code. My >>> guess is that when Hotspot express was dropped, the ability to use a >>> JVM from another JDK release bit rotteded away. >>> >>> /Magnus >> >> Dan > From sean.coffey at oracle.com Wed Jun 10 10:56:27 2015 From: sean.coffey at oracle.com (=?UTF-8?B?U2XDoW4gQ29mZmV5?=) Date: Wed, 10 Jun 2015 11:56:27 +0100 Subject: [8u60] Backport RFR: JDK-8078666 and JDK-8074312 In-Reply-To: <1433929956.3385.48.camel@redhat.com> References: <1433856445.3310.105.camel@redhat.com> <1433929956.3385.48.camel@redhat.com> Message-ID: <557817DB.2030806@oracle.com> Hopefully, someone from the hotspot team can help out here. These fixes can enter via the hotspot team forest (jdk8u/hs-dev) and don't need approval since Alejandro looks after that Regards, Sean. On 10/06/15 10:52, Severin Gehwolf wrote: > Adding in jdk8u-dev. > > On Tue, 2015-06-09 at 15:27 +0200, Severin Gehwolf wrote: >> Hi, >> >> Could I please get JDK-8078666 and JDK-8074312 backported to 8u60? I'd >> need a sponsor for this. >> >> We've been using the JDK-8078666 fix for Fedora 22 on JDK8 for a while >> now. Similarly, the fix for JDK-8074312 is now also required for Fedora >> 21 and we've had this patch in use since March. >> >> "Enable hotspot builds on 4.x Linux kernels" >> Bug: https://bugs.openjdk.java.net/browse/JDK-8074312 >> Webrev: >> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8074312/8-backport/ >> Original review thread: >> http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-March/017463.html >> JDK 9 fix applies cleanly modulo copyright changes. >> >> >> "JVM fastdebug build compiled with GCC 5 asserts with "widen increases" >> Bug: https://bugs.openjdk.java.net/browse/JDK-8078666 >> Original review thread: >> http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2015-April/017759.html >> JDK 9 fix applies cleanly to 8u forest. >> >> Thanks, >> Severin >> > > From lois.foltan at oracle.com Wed Jun 10 11:14:19 2015 From: lois.foltan at oracle.com (Lois Foltan) Date: Wed, 10 Jun 2015 07:14:19 -0400 Subject: RFR(XXS): 8086073: Fix PrintStubCode for empty StubCodeGenerator. In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CFEC7EA@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CFEC7EA@DEWDFEMB12A.global.corp.sap> Message-ID: <55781C0B.1050102@oracle.com> Looks good. Lois On 6/10/2015 2:46 AM, Lindenmaier, Goetz wrote: > Hi, > > PrintStubCode runs into an assertion if a StubCodeGenerator that never generated > a stub is deleted. This happens for ICacheStubGenerator on ppc, as we implement > the flushing with inline assembly and don't generate a stub. > > The fix is to check for an empty list in the assertion. > > Please review and sponsor this tiny fix. > http://cr.openjdk.java.net/~goetz/webrevs/8086073-PSC/webrev.01/ > > > Best regards and thanks, > Goetz. From magnus.ihse.bursie at oracle.com Wed Jun 10 12:13:16 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 10 Jun 2015 14:13:16 +0200 Subject: RFR: JDK-8085822 JEP 223: New Version-String Scheme (initial integration) In-Reply-To: <55780A33.1010302@oracle.com> References: <5571AD18.7080701@oracle.com> <557625C8.5050200@oracle.com> <5576E633.9050503@oracle.com> <5576E81B.8050703@oracle.com> <5576EF94.3010500@oracle.com> <55780A33.1010302@oracle.com> Message-ID: <557829DC.8000405@oracle.com> On 2015-06-10 11:58, David Holmes wrote: > Hi Magnus, > > Generally looks good - a few comments/queries below. In general, I believe most issues you found are valid. :-) However, as I said before in this thread, I'd like to see them resolved in the needed follow-up patches. The source code changes in Hotspot and JDK are inadequate to fully implement JEP-223, so these areas will need to be rewritten anyhow. Are you okay with resolving these issues later? > > On 9/06/2015 11:52 PM, Magnus Ihse Bursie wrote: >> Here's an updated webrev, which fixes the typos that were pointed out by >> reviewers: >> http://cr.openjdk.java.net/~ihse/JDK-8085822-JEP-223-initial-patch/webrev.02/ >> > > common/autoconf/version-numbers > > Shouldn't there be a DEFAULT_VERSION_XXX for each of the XXX parts of > the version info? (Even if all zeroes presently.) So that's a tricky one. :-& The question here is, I think, does it make sense to update version-numbers when we do a security (9.0.1) or minor (9.1.0) release? Looking historically, the version-numbers file have not been changed for the 8u family. The only change was going from 8 to 9 when creating the new jdk9 forest. That was what I based my decition to only have the major number in the file. (The rest of the version string is set by configure flags when building, in Oracle case by the RE team.) If it makes sense to put the minor/security/patch numbers here, I won't oppose it, but I guess we have until the first such release to figure out what's best, and that likely includes discussion with RE and possibly other consumers in the community (RedHat etc). > > --- > > Looking at hotspot changes I can't convince myself that the new > streamlined "version" variables will capture things like "fastdebug". > Will that filter through via configure variables? The "fastdebug" label has been handled as a less valued token in the JEP-223 process. Right now there's no mention of it at all in the version string proposal in the JEP. As I understand it, Iris is about to propose an amendment which will just make fastdebug be a part of the OPT string. I'm not entirely happy with that myself, but that's the way it's decided. So wherever you can see the OPT string, you'll see the debug level tag. Currently, however, that's not how it is implemented in this patch. Since no decision was made on this (and it's still not formally decided), I had to pick a route to go forward. The current patch will instead put the "fastdebug" label as part of the PRE string (that's the reason for the pre-base and pre-debuglevel arguments to configure). If the planned changes goes into the JEP, this'll change to make the debuglevel tag a part of the OPT string instead. > --- > > make/*/makefiles/vm.make > > Shouldn't the -DVERSION_XX=$(VERSION_XX) definitions be taken from the > VERSION_CFLAGS in spec.gmk? (Or are you still allowing for a > stand-alone hotspot build?) The hotspot JEP-223 work initially made by Alejandro kept support for stand-alone hotspot builds. I made additional changes on top of that, which still tried to cater for stand-alone builds. At this very moment I'm not sure if stand-alone hotspot builds are supposed to work or not, but I've tried to not change the situation with this patch. There are two future changes coming down the pipe: One is the additional JEP-223 work needed for Hotspot. I know Alejandro had plans for redesigning the API between Hotspot and the JDK, so no JDK version strings should be compiled into the JVM, but all of it extracted during an API in runtime. That would make most (all?) of the makefile changes in hotspot irrelevant. However, that implementation is not even started, so it's needed for the time being. The second change is the build-infra hotspot makefile rewrite. When that happens, stand-alone builds will definitely disappear, and if Hotspot still needs make support for version strings, then the logical choice is to use VERSION_CFLAGS. Ok? > > --- > > hotspot/src/share/vm/prims/jvm.h > jdk/src/java.base/share/native/include/jvm.h > > I think this comment is way out of date: > > /* Build number is available only for RE build (i.e. JDK_BUILD_NUMBER > is set to bNN) > * It will be zero for internal builds. > */ > > and can be completely removed. Even if still true, mention of an "RE > build" has no place in OpenJDK sources. Yep, agree. Follow-up patch, right? > > --- > > hotspot/src/share/vm/runtime/java.cpp > > I think a lot of the modified code is obsolete post Hotspot Express - > which makes it hard to determine if the changes make sense. Yep, agree. Follow-up patch, right? > > --- > > hotspot/src/share/vm/runtime/vmStructs.cpp > > Please fix the alignment (3 extra spaces on modified line): > > 1239 static_field(Abstract_VM_Version, _vm_minor_version, > int) \ > 1240 static_field(Abstract_VM_Version, > _vm_security_version, int) \ I was about to say "follow-up patch", but ugly indentation really sucks so I can fix this. Ok if I skip redoing the review for that? > > --- > > hotspot/test/runtime/6981737/Test6981737.java > > This test is really only valid for the new version scheme now, so it > should probably be rewritten - and in that case it really isn't > testing 6981737 but should be replaced by a new test for the new > version format. Yep, agree. Follow-up patch, right? > > --- > > jdk/src/java.base/share/classes/sun/misc/Version.java.template > > This comment is nonsensical: > > /** > ! * Returns the security version of the running JVM if it's 1.6 > or newer > * or any RE VM build. It will return 0 if it's an internal 1.5 or > * 1.4.x build. > * @since 1.6 > */ > > as security version does not exist pre 9. Normally you should be > adding a new method and deprecating the old one. The new one is @since 9. Yep, agree. Follow-up patch, right? > > /** > ! * Returns the security version of the running JDK. > * @since 1.6 > */ > > Ditto: @since 9 (but again old should be deprecated and new method added) > > 253 /** > 254 * Returns the build number of the running JDK if it's a RE > build > 255 * It will return 0 if it's an internal build. > > As with jvm.h this seems obsolete commentary these days - not only RE > builds define a build number. Yep, agree. Follow-up patch, right? /Magnus > > Thanks, > David From stefan.johansson at oracle.com Wed Jun 10 12:16:44 2015 From: stefan.johansson at oracle.com (Stefan Johansson) Date: Wed, 10 Jun 2015 14:16:44 +0200 Subject: JEP 248: Make G1 the Default Garbage Collector In-Reply-To: References: <20150428220211.4355960845@eggemoggin.niobe.net> <55423444.7040009@beckwithclan.com> <4391D841-07CD-4A37-8092-DABBA3C3A627@gmail.com> <20150604150835.278728@eggemoggin.niobe.net> <55719229.3060806@oracle.com> Message-ID: <55782AAC.5080509@oracle.com> Hi Ben, I read your statement below as you're good with us moving forward and targeting the JEP for JDK 9, but that you want to stress that we need to spend time on verifying that G1 is ready to be the default. I understand your concern and it is great to hear that you and others in the community are willing to help with this work. Thanks, Stefan On 2015-06-05 19:11, Ben Evans wrote: > Hi, > > I like the plan, but this statement is really quite bullish, > especially (IMO) on the available evidence. > > G1 was always marketed as the replacement for CMS. In field experience > so far, that hasn't happened, and I feel that we are glossing over the > fact that we are now thinking of G1 as a replacement for Parallel. > > Certainly none of the testing I've done has been about Parallel -> G1 > - it's all been CMS vs G1. I will be happy to start working with > clients to try to cover the Parallel vs G1 space, but that hasn't > happened up until now. > > Neither do I think we should be under any illusions that a very large > number of installs are going to be affected. > > It may not be all that representative, but here are the results of a > quick community straw poll I ran over the last couple of days: > > A single question: "Which Garbage Collector Does Your Application Use? > " yielded these results: > > Concurrent Mark & Sweep (CMS) > 23.94% > 85 > ? > Garbage First (G1GC) > 10.70% > 38 > ? > Parallel (because I explicitly set it) > 5.07% > 18 > ? > Default (this actually gives you Parallel) > 39.15% > 139 > ? > I Don't Know > 21.13% > 75 > > Total: 355 > > The clear, stand-out winner is Default, with ~40% of installs using > this, and therefore being exposed to the proposed change. That makes > me very nervous. > > So, whilst I'm not saying we shouldn't do this, and I know that > community members, including Kirk, myself & the other jClarity folks > will help to get some better data, I'd argue that we're still a long > way from being certain that we're ready for this change. > > Thanks, > > Ben > > > On Fri, Jun 5, 2015 at 1:12 PM, Stefan Johansson > wrote: >> On 2015-06-05 00:08, mark.reinhold at oracle.com wrote: >>> 2015/6/4 6:44 -0700, charlie.hunt at oracle.com: >>>> Wanted to come back to this thread, continue the dialog, reiterate the >>>> objective, (try to) summarize the concerns and put forth a potential >>>> plan for this JEP going forward. >>>> >>>> Intent: Use G1 GC as the default collector chosen by the JVM when no >>>> GC is explicitly set at the JVM command line. >>>> >>>> ... >>> Charlie -- thanks for the excellent summary of this wide-ranging >>> discussion! >>> >>>> ... >>>> >>>> Suggested plan for moving forward: >>>> - Make G1 the default collector in JDK 9, continue to evaluate G1 and >>>> enhance G1 in JDK 9 >>>> - Mitigate risk by reverting back to Parallel GC before JDK 9 goes >>>> ?Generally Available? (Sept 22, 2016 [1]) if warranted by continuing >>>> to monitor observations and experiences with G1 in both JDK 9 >>>> pre-releases and latest JDK 8 update releases >>>> - Address enhancing ergonomics for selecting a default GC as a >>>> separate JEP if future observations suggests its needed >>> I think this is a fine plan. >>> >>> Stefan -- To move forward with JEP 248, could you please revise the >>> second item in the "Risks and Assumptions" section to note that there >>> is some concern that G1 might not be ready to become the default, that >>> making it the default now will allow us to get more feedback on it, and >>> that if it proves to be not ready then we'll revert the default to the >>> Parallel GC in time for JDK 9 GA? >> Mark, I've extended second item as follows: >> - G1 is seen as a robust and well-tested collector. It is not expected >> to have stability problems, but becoming the default collector will >> increase its visibility and may reveal previously-unknown issues. If >> a critical issue is found that can't be addressed in the JDK 9 time >> frame, we will revert back to use Parallel GC as the default for the >> JDK 9 GA. >> >> Thanks, >> Stefan >> >> >>> Ben -- Can you live with this plan? >>> >>> - Mark >> > > From edward.nevill at linaro.org Wed Jun 10 12:58:51 2015 From: edward.nevill at linaro.org (Edward Nevill) Date: Wed, 10 Jun 2015 13:58:51 +0100 Subject: RFR: 8085805: aarch64: AdvancedThresholdPolicy lacks tuning of InlineSmallCode size Message-ID: <1433941131.11860.74.camel@mylittlepony.linaroharston> Hi, http://cr.openjdk.java.net/~enevill/8085805/webrev/ adds tuning of InlineSmallCode for aarch64. src/share/vm/runtime/advancedThresholdPolicy.cpp contains the following code which tunes the value of InlineSmallCode for X86 and SPARC. // Some inlining tuning #ifdef X86 if (FLAG_IS_DEFAULT(InlineSmallCode)) { FLAG_SET_DEFAULT(InlineSmallCode, 2000); } #endif #ifdef SPARC if (FLAG_IS_DEFAULT(InlineSmallCode)) { FLAG_SET_DEFAULT(InlineSmallCode, 2500); } #endif set_increase_threshold_at_ratio(); set_start_time(os::javaTimeMillis()); } This webrev proposes changing this so that InlineSmallCode is increased to 2500 on aarch64 rather than the default of 1000. The change is simply to add AARCH64 to the conditional. IE. #if defined SPARC || defined AARCH64 if (FLAG_IS_DEFAULT(InlineSmallCode)) { FLAG_SET_DEFAULT(InlineSmallCode, 2500); } #endif This change request was triggered by one of our partners reporting a 6x improvement in one benchmark when the size of InlineSmallCode is increased. I have done some testing to find the optimal size of InlineCodeSize for aarch64. The following shows the performance of various benchmarks against different sizes of InlineSmallCode. InlineSmallCode 100 1000 1500 2000 2500 3000 5000 Grinderbench 440543 589792 595603 659213 665973 664663 667865 Stringtest 65182 65304 65211 339946 329314 326831 296886 SpecJVM2008 76.4 90.8 90.9 91.9 89.6 89.2 88.3 The optimal value seems to be about 2000/2500. I have elected for the slightly higher value. Tested with JTreg/hotspot. In both cases, before and after the patch Test results: passed: 845; failed: 12; error: 6 Please review, Thanks, Ed. From magnus.ihse.bursie at oracle.com Wed Jun 10 13:44:41 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 10 Jun 2015 15:44:41 +0200 Subject: RFR: JDK-8085822 JEP 223: New Version-String Scheme (initial integration) In-Reply-To: <557625C8.5050200@oracle.com> References: <5571AD18.7080701@oracle.com> <557625C8.5050200@oracle.com> Message-ID: <55783F49.6030906@oracle.com> On 2015-06-09 01:31, Daniel D. Daugherty wrote: > > > http://cr.openjdk.java.net/~ihse/JDK-8085822-JEP-223-initial-patch/webrev.01 > > > General comment: Not all copyright years were updated. I realize I missed that part of the review. :-( I have now updated the copyright years. Here's a delta review: http://cr.openjdk.java.net/~ihse/JDK-8085822-JEP-223-initial-patch-delta-02/webrev.01/ Here's the complete review once again: http://cr.openjdk.java.net/~ihse/JDK-8085822-JEP-223-initial-patch/webrev.03 Hopefully this is now the final version to be pushed to verona, and that any additional problems can be resolved with follow-up patches. /Magnus From sgehwolf at redhat.com Wed Jun 10 13:49:21 2015 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 10 Jun 2015 15:49:21 +0200 Subject: RFR(XS) 8087120: [GCC5] java.lang.StackOverflowError on Zero JVM initialization on non x86 platforms Message-ID: <1433944161.3385.97.camel@redhat.com> Hi, Could somebody please review this Zero only change? I'd also need a sponsor who can push the change for me once reviewed. Bug: https://bugs.openjdk.java.net/browse/JDK-8087120 webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8087120/webrev.01/ The issue is that Zero relies on undefined behaviour for getting the current stack pointer by allocating a variable on the stack and returning its address. With GCC 5 returning an address of a local variable will always be 0, thus causing the issue. It worked fine with older GCC versions, because they returned the actual address of the variable. The fix is to use GCC's built-in function "__builtin_frame_address". This also works on GCC 5. It's GCC specific, though. On the other hand, I don't know if anybody builds Zero without GCC. An alternative would be to use alloca, but that has strange semantics if the stack pointer cannot be extended. Thoughts? Thanks, Severin From aph at redhat.com Wed Jun 10 13:53:31 2015 From: aph at redhat.com (Andrew Haley) Date: Wed, 10 Jun 2015 14:53:31 +0100 Subject: RFR(XS) 8087120: [GCC5] java.lang.StackOverflowError on Zero JVM initialization on non x86 platforms In-Reply-To: <1433944161.3385.97.camel@redhat.com> References: <1433944161.3385.97.camel@redhat.com> Message-ID: <5578415B.1090200@redhat.com> On 06/10/2015 02:49 PM, Severin Gehwolf wrote: > e fix is to use GCC's built-in function "__builtin_frame_address". > This also works on GCC 5. It's GCC specific, though. On the other hand, > I don't know if anybody builds Zero without GCC. An alternative would be > to use alloca, but that has strange semantics if the stack pointer > cannot be extended. Thoughts? Returning the address of an alloca() would be no better. I'd stick with __builtin_frame_address(0). Andrew. From goetz.lindenmaier at sap.com Wed Jun 10 15:01:01 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 10 Jun 2015 15:01:01 +0000 Subject: RFR(XXS): 8086073: Fix PrintStubCode for empty StubCodeGenerator. In-Reply-To: <55781C0B.1050102@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CFEC7EA@DEWDFEMB12A.global.corp.sap> <55781C0B.1050102@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2CFF2AD3@DEWDFEMB12A.global.corp.sap> Vladimir, Lois, thanks for the review! Could one of you please sponsor this? Iadded the Reviewed-by comment, so you can take the change as-is. Thanks and best regards, Goetz. -----Original Message----- From: Lois Foltan [mailto:lois.foltan at oracle.com] Sent: Mittwoch, 10. Juni 2015 13:14 To: Lindenmaier, Goetz Cc: HotSpot Developers Subject: Re: RFR(XXS): 8086073: Fix PrintStubCode for empty StubCodeGenerator. Looks good. Lois On 6/10/2015 2:46 AM, Lindenmaier, Goetz wrote: > Hi, > > PrintStubCode runs into an assertion if a StubCodeGenerator that never generated > a stub is deleted. This happens for ICacheStubGenerator on ppc, as we implement > the flushing with inline assembly and don't generate a stub. > > The fix is to check for an empty list in the assertion. > > Please review and sponsor this tiny fix. > http://cr.openjdk.java.net/~goetz/webrevs/8086073-PSC/webrev.01/ > > > Best regards and thanks, > Goetz. From mandy.chung at oracle.com Wed Jun 10 15:14:53 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 10 Jun 2015 08:14:53 -0700 Subject: RFR(M): 8081674: EmptyStackException at startup if running with extended or unsupported charset In-Reply-To: References: <557626AA.6010008@oracle.com> <55772A56.2030308@oracle.com> Message-ID: Have you checked out this patch moving out findBuiltinLib from NativeLibrary class? http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8081674/webrev.00/ Mandy > On Jun 10, 2015, at 12:34 AM, Volker Simonis wrote: > > Mandy, the example/stacktrace I sent was with 8u. > > The problem isn't related to libzip, it is only the first library > which gets loaded with System.loadLibrary(). > > The problem will occur with every library which gets loaded by > System.loadLibrary() because > java.lang.ClassLoader$NativeLibrary.findBuiltinLib() always calls > jni_FindClass() if we're running on a unsupported locale. > > On Tue, Jun 9, 2015 at 8:03 PM, Mandy Chung wrote: >> Does my patch work fine on 8u? If it works fine, I prefer to get that >> simple fix in 8u and take the time to have a better fix in 9 (jdk9 is still >> under development and I have assumed that it's not a show stopper to you. >> Let me know if it blocks you). >> >> A question to Sherman - do we have adequate tests to verify the move of >> System.loadLibrary("zip") from system initialization to ZipFile >> initialization for 8u? >> >> Mandy >> >> >> On 06/09/2015 10:09 AM, Volker Simonis wrote: >>> >>> Hi Mandy, >>> >>> thanks for looking into this. >>> Uunfortunately your fix only helps to fix "java -version" :( >>> >>> Running even a minimal HelloWorld will still fail with the following >>> stack trace which is still caused by the same EmptyStackException: >>> >>> Error: A JNI error has occurred, please check your installation and try >>> again >>> Exception in thread "main" java.lang.ExceptionInInitializerError >>> at sun.misc.Unsafe.ensureClassInitialized(Native Method) >>> at >>> sun.misc.SharedSecrets.getJavaUtilZipFileAccess(SharedSecrets.java:158) >>> at sun.misc.URLClassPath$JarLoader.(URLClassPath.java:765) >>> at sun.misc.URLClassPath$3.run(URLClassPath.java:530) >>> at sun.misc.URLClassPath$3.run(URLClassPath.java:520) >>> at java.security.AccessController.doPrivileged(Native Method) >>> at sun.misc.URLClassPath.getLoader(URLClassPath.java:519) >>> at sun.misc.URLClassPath.getLoader(URLClassPath.java:492) >>> at sun.misc.URLClassPath.getNextLoader(URLClassPath.java:457) >>> at sun.misc.URLClassPath.access$100(URLClassPath.java:64) >>> at sun.misc.URLClassPath$1.next(URLClassPath.java:239) >>> at sun.misc.URLClassPath$1.hasMoreElements(URLClassPath.java:250) >>> at java.net.URLClassLoader$3$1.run(URLClassLoader.java:601) >>> at java.net.URLClassLoader$3$1.run(URLClassLoader.java:599) >>> at java.security.AccessController.doPrivileged(Native Method) >>> at java.net.URLClassLoader$3.next(URLClassLoader.java:598) >>> at java.net.URLClassLoader$3.hasMoreElements(URLClassLoader.java:623) >>> at sun.misc.CompoundEnumeration.next(CompoundEnumeration.java:45) >>> at >>> sun.misc.CompoundEnumeration.hasMoreElements(CompoundEnumeration.java:54) >>> at sun.misc.CompoundEnumeration.next(CompoundEnumeration.java:45) >>> at >>> sun.misc.CompoundEnumeration.hasMoreElements(CompoundEnumeration.java:54) >>> at >>> java.util.ServiceLoader$LazyIterator.hasNextService(ServiceLoader.java:354) >>> at >>> java.util.ServiceLoader$LazyIterator.hasNext(ServiceLoader.java:393) >>> at java.util.ServiceLoader$1.hasNext(ServiceLoader.java:474) >>> at java.nio.charset.Charset$1.getNext(Charset.java:350) >>> at java.nio.charset.Charset$1.hasNext(Charset.java:365) >>> at java.nio.charset.Charset$2.run(Charset.java:410) >>> at java.nio.charset.Charset$2.run(Charset.java:407) >>> at java.security.AccessController.doPrivileged(Native Method) >>> at java.nio.charset.Charset.lookupViaProviders(Charset.java:406) >>> at java.nio.charset.Charset.lookup2(Charset.java:477) >>> at java.nio.charset.Charset.lookup(Charset.java:464) >>> at java.nio.charset.Charset.isSupported(Charset.java:505) >>> at >>> sun.launcher.LauncherHelper.makePlatformString(LauncherHelper.java:580) >>> Caused by: java.util.EmptyStackException >>> at java.util.Stack.peek(Stack.java:102) >>> at >>> java.lang.ClassLoader$NativeLibrary.getFromClass(ClassLoader.java:1759) >>> at java.lang.ClassLoader$NativeLibrary.findBuiltinLib(Native Method) >>> at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1870) >>> at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1843) >>> at java.lang.Runtime.loadLibrary0(Runtime.java:870) >>> at java.lang.System.loadLibrary(System.java:1122) >>> at java.util.zip.ZipFile.(ZipFile.java:86) >>> ... 34 more >>> >>> It's obvious that the way jni_FindClass is looking for the class >>> context by calling the NativeLibrary::getFromClass method is hacky but >>> I think that the proposed fix is the quite simple and non-intrusive. >>> And we probably don't want a complete rework of this code for 8 >>> anyway. So why not fix it the proposed way in 8 and 9 for now? That >>> will still leave us time to come up with a better clean-up at least >>> for 9. >>> >>> What do you think? >>> >>> Regards, >>> Volker >>> >>> On Tue, Jun 9, 2015 at 1:35 AM, Mandy Chung >>> wrote: >>>> >>>> Hi Volker, >>>> >>>> Your patch reminds me the question I have about loading zip library. >>>> >>>> In JDK 9 (and earlier release), zip library is loaded by the VM during >>>> startup (see ClassLoader::load_zip_library). I think loadLibrary("zip") >>>> is >>>> no longer needed to be called from System::initializeSystemClass method >>>> and >>>> instead it can be loaded by java.util.zip.ZipFile static initializer. >>>> >>>> Do you mind to try the patch (below)? That may be a simpler fix. >>>> >>>> I never like the way jni_FindClass to look for the class context by >>>> calling >>>> the NativeLibrary::getFromClass method. I will have to look deeper other >>>> alternative to clean that up. If taking out loadLibrary("zip") resolves >>>> your issue, this will give us time to come up with a better clean-up in >>>> the >>>> future. >>>> >>>> Mandy >>>> [1] https://bugs.openjdk.java.net/browse/JDK-4429040 >>>> >>>> diff --git a/src/share/classes/java/lang/System.java >>>> b/src/share/classes/java/lang/System.java >>>> --- a/src/share/classes/java/lang/System.java >>>> +++ b/src/share/classes/java/lang/System.java >>>> @@ -1192,10 +1192,6 @@ >>>> setOut0(newPrintStream(fdOut, >>>> props.getProperty("sun.stdout.encoding"))); >>>> setErr0(newPrintStream(fdErr, >>>> props.getProperty("sun.stderr.encoding"))); >>>> >>>> - // Load the zip library now in order to keep >>>> java.util.zip.ZipFile >>>> - // from trying to use itself to load this library later. >>>> - loadLibrary("zip"); >>>> - >>>> // Setup Java signal handlers for HUP, TERM, and INT (where >>>> available). >>>> Terminator.setup(); >>>> >>>> diff --git a/src/share/classes/java/util/zip/ZipFile.java >>>> b/src/share/classes/java/util/zip/ZipFile.java >>>> --- a/src/share/classes/java/util/zip/ZipFile.java >>>> +++ b/src/share/classes/java/util/zip/ZipFile.java >>>> @@ -83,6 +83,7 @@ >>>> >>>> static { >>>> /* Zip library is loaded from System.initializeSystemClass */ >>>> + System.loadLibrary("zip"); >>>> initIDs(); >>>> >>>> } >>>> >>>> >>>> >>>> On 06/08/2015 07:23 AM, Volker Simonis wrote: >>>>> >>>>> Hi, >>>>> >>>>> can I please get a review at least for the part of this fix which is >>>>> common for jdk8 and jdk9. It's only a few lines in >>>>> src/share/vm/prims/jni.cpp for the hotspot repository and one line >>>>> src/java.base/share/classes/java/lang/ClassLoader.java for the jdk >>>>> repository. >>>>> >>>>> Thanks, >>>>> Volker >>>>> >>>>> >>>>> On Tue, Jun 2, 2015 at 6:12 PM, Volker Simonis >>>>> >>>>> wrote: >>>>>> >>>>>> Hi, >>>>>> >>>>>> can I please have review (and a sponsor) for these changes: >>>>>> >>>>>> https://bugs.openjdk.java.net/browse/JDK-8081674 >>>>>> http://cr.openjdk.java.net/~simonis/webrevs/2015/8081674.jdk >>>>>> http://cr.openjdk.java.net/~simonis/webrevs/2015/8081674.hs >>>>>> >>>>>> Please notice that the fix requires synchronous changes in the jdk and >>>>>> the >>>>>> hotspot forest. >>>>>> >>>>>> The changes themselves are by far not that big as this explanation but >>>>>> I >>>>>> found the problem to be quite intricate so I tried to explain it as >>>>>> good >>>>>> as >>>>>> I could. I'd suggest to read the HTML-formatted explanation in the >>>>>> webrev >>>>>> although the content is equal to the one in this mail: >>>>>> >>>>>> Using an unsupported character encoding (e.g. vi_VN.TCVN on Linux) >>>>>> results >>>>>> in an immediate VM failure with jdk 8 and 9: >>>>>> >>>>>> export LANG=vi_VN.TCVN >>>>>> java -version >>>>>> Error occurred during initialization of VM >>>>>> java.util.EmptyStackException >>>>>> at java.util.Stack.peek(Stack.java:102) >>>>>> at >>>>>> java.lang.ClassLoader$NativeLibrary.getFromClass(ClassLoader.java:1751) >>>>>> at java.lang.ClassLoader$NativeLibrary.findBuiltinLib(Native >>>>>> Method) >>>>>> at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1862) >>>>>> at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1835) >>>>>> at java.lang.Runtime.loadLibrary0(Runtime.java:870) >>>>>> at java.lang.System.loadLibrary(System.java:1119) >>>>>> at java.lang.System.initializeSystemClass(System.java:1194) >>>>>> >>>>>> This is a consequence of "8005716: Enhance JNI specification to allow >>>>>> support of static JNI libraries in Embedded JREs". >>>>>> >>>>>> With jdk 9 we get this error even if we're running with a supported >>>>>> charset >>>>>> which is in the ExtendedCharsets (as opposed to being in the >>>>>> StandardCharsets) class which is a consequence of delegating the >>>>>> loading >>>>>> of >>>>>> the ExtendedCharsets class to the ServiceLoader in jdk 9. >>>>>> >>>>>> export LANG=eo.iso-8859-3 >>>>>> output-jdk9/images/jdk/bin/java -version >>>>>> Error occurred during initialization of VM >>>>>> java.util.EmptyStackException >>>>>> at java.util.Stack.peek(Stack.java:102) >>>>>> at >>>>>> java.lang.ClassLoader$NativeLibrary.getFromClass(ClassLoader.java:1737) >>>>>> at java.lang.ClassLoader$NativeLibrary.findBuiltinLib(Native >>>>>> Method) >>>>>> at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1866) >>>>>> at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1840) >>>>>> at java.lang.Runtime.loadLibrary0(Runtime.java:874) >>>>>> at java.lang.System.loadLibrary(System.java:1111) >>>>>> at java.lang.System.initializeSystemClass(System.java:1186) >>>>>> >>>>>> Here's why the exception happens for an unsupported charset (see the >>>>>> mixed >>>>>> stack trace below for the full details): >>>>>> >>>>>> java.lang.System.loadLibrary() wants to load libzip.so. It calls >>>>>> java.lang.Runtime.loadLibrary0() which at the very beginning calls the >>>>>> native method ClassLoader$NativeLibrary.findBuiltinLib() which checks >>>>>> if >>>>>> the >>>>>> corresponding library is already statically linked into the VM >>>>>> (introduced >>>>>> by 8005716). >>>>>> Java_java_lang_ClassLoader_00024NativeLibrary_findBuiltinLib(), >>>>>> the native implementation of findBuiltinLib() in Classloader.c calls >>>>>> GetStringPlatformChars() to convert the library name into the native >>>>>> platform encoding. GetStringPlatformChars() calls the helper function >>>>>> jnuEncodingSupported() to check if the platform encoding which is >>>>>> stored >>>>>> in >>>>>> the property "sun.jnu.encoding" is supported by Java. >>>>>> jnuEncodingSupported() >>>>>> is implemented as follows: >>>>>> >>>>>> static jboolean isJNUEncodingSupported = JNI_FALSE; >>>>>> static jboolean jnuEncodingSupported(JNIEnv *env) { >>>>>> jboolean exe; >>>>>> if (isJNUEncodingSupported == JNI_TRUE) { >>>>>> return JNI_TRUE; >>>>>> } >>>>>> isJNUEncodingSupported = (jboolean) JNU_CallStaticMethodByName ( >>>>>> env, &exe, >>>>>> "java/nio/charset/Charset", >>>>>> "isSupported", >>>>>> "(Ljava/lang/String;)Z", >>>>>> jnuEncoding).z; >>>>>> return isJNUEncodingSupported; >>>>>> } >>>>>> >>>>>> Once the function finds that the platform encoding is supported (by >>>>>> calling >>>>>> java.nio.charset.Charset.isSupported()) it caches this value and always >>>>>> returns it on following calls. However if the platform encoding is not >>>>>> supported, it ALWAYS calls java.nio.charset.Charset.isSupported() an >>>>>> every >>>>>> subsequent invocation. >>>>>> >>>>>> In order to call the Java method Charset.isSupported() (in >>>>>> JNU_CallStaticMethodByName() in file jni_util.c), we have to call >>>>>> jni_FindClass() to convert the symbolic class name >>>>>> "java.nio.charset.Charset" into a class reference. >>>>>> >>>>>> But unfortunately, jni_FindClass() (from jni.cpp in libjvm.so) has a >>>>>> special >>>>>> handling if called from java.lang.ClassLoader$NativeLibrary to ensure >>>>>> that >>>>>> JNI_OnLoad/JNI_OnUnload are executed in the correct class context: >>>>>> >>>>>> instanceKlassHandle k (THREAD, >>>>>> thread->security_get_caller_class(0)); >>>>>> if (k.not_null()) { >>>>>> loader = Handle(THREAD, k->class_loader()); >>>>>> // Special handling to make sure JNI_OnLoad and JNI_OnUnload are >>>>>> executed >>>>>> // in the correct class context. >>>>>> if (loader.is_null() && >>>>>> k->name() == >>>>>> vmSymbols::java_lang_ClassLoader_NativeLibrary()) { >>>>>> JavaValue result(T_OBJECT); >>>>>> JavaCalls::call_static(&result, k, >>>>>> vmSymbols::getFromClass_name(), >>>>>> >>>>>> vmSymbols::void_class_signature(), >>>>>> thread); >>>>>> if (HAS_PENDING_EXCEPTION) { >>>>>> Handle ex(thread, thread->pending_exception()); >>>>>> CLEAR_PENDING_EXCEPTION; >>>>>> THROW_HANDLE_0(ex); >>>>>> } >>>>>> >>>>>> So if that's the case and jni_FindClass() was reallycalled from >>>>>> ClassLoader$NativeLibrary, then jni_FindClass() calles >>>>>> ClassLoader$NativeLibrary().getFromClass() to find out the >>>>>> corresponding >>>>>> context class which is supposed to be saved there in a field of type >>>>>> java.util.Stack named "nativeLibraryContext": >>>>>> >>>>>> // Invoked in the VM to determine the context class in >>>>>> // JNI_Load/JNI_Unload >>>>>> static Class getFromClass() { >>>>>> return ClassLoader.nativeLibraryContext.peek().fromClass; >>>>>> } >>>>>> >>>>>> Unfortunately, "nativeLibraryContext" doesn't contain any entry at this >>>>>> point and the invocation of Stack.peek() will throw the exception shown >>>>>> before. In general, the "nativeLibraryContext" stack will be filled >>>>>> later >>>>>> on >>>>>> in Runtime.loadLibrary0() like this: >>>>>> >>>>>> NativeLibrary lib = new NativeLibrary(fromClass, name, isBuiltin); >>>>>> nativeLibraryContext.push(lib); >>>>>> try { >>>>>> lib.load(name, isBuiltin); >>>>>> } finally { >>>>>> nativeLibraryContext.pop(); >>>>>> } >>>>>> >>>>>> such that it always contains at least one element later when >>>>>> jni_FindClass() >>>>>> will be invoked. >>>>>> >>>>>> So in summary, the problem is that the implementors of 8005716 didn't >>>>>> took >>>>>> into account that calling ClassLoader$NativeLibrary.findBuiltinLib() >>>>>> may >>>>>> trigger a call to jni_FindClass() if we are running on a system with an >>>>>> unsupported character encoding. >>>>>> >>>>>> I'd suggest the following fix for this problem: >>>>>> >>>>>> Change ClassLoader$NativeLibrary().getFromClass() to return null if the >>>>>> stack is empty instead of throwing an exception: >>>>>> >>>>>> static Class getFromClass() { >>>>>> return ClassLoader.nativeLibraryContext.empty() ? >>>>>> null : ClassLoader.nativeLibraryContext.peek().fromClass; >>>>>> } >>>>>> >>>>>> Unfortunately this also requires a HotSpot change in jni_FindClass() in >>>>>> order to properly handle the new 'null' return value: >>>>>> >>>>>> if (k.not_null()) { >>>>>> loader = Handle(THREAD, k->class_loader()); >>>>>> // Special handling to make sure JNI_OnLoad and JNI_OnUnload are >>>>>> executed >>>>>> // in the correct class context. >>>>>> if (loader.is_null() && >>>>>> k->name() == >>>>>> vmSymbols::java_lang_ClassLoader_NativeLibrary()) { >>>>>> JavaValue result(T_OBJECT); >>>>>> JavaCalls::call_static(&result, k, >>>>>> vmSymbols::getFromClass_name(), >>>>>> >>>>>> vmSymbols::void_class_signature(), >>>>>> thread); >>>>>> if (HAS_PENDING_EXCEPTION) { >>>>>> Handle ex(thread, thread->pending_exception()); >>>>>> CLEAR_PENDING_EXCEPTION; >>>>>> THROW_HANDLE_0(ex); >>>>>> } >>>>>> oop mirror = (oop) result.get_jobject(); >>>>>> if (oopDesc::is_null(mirror)) { >>>>>> loader = Handle(THREAD, >>>>>> SystemDictionary::java_system_loader()); >>>>>> } else { >>>>>> loader = Handle(THREAD, >>>>>> >>>>>> >>>>>> InstanceKlass::cast(java_lang_Class::as_Klass(mirror))->class_loader()); >>>>>> protection_domain = Handle(THREAD, >>>>>> >>>>>> >>>>>> >>>>>> InstanceKlass::cast(java_lang_Class::as_Klass(mirror))->protection_domain()); >>>>>> } >>>>>> } >>>>>> } else { >>>>>> // We call ClassLoader.getSystemClassLoader to obtain the system >>>>>> class >>>>>> loader. >>>>>> loader = Handle(THREAD, SystemDictionary::java_system_loader()); >>>>>> } >>>>>> >>>>>> These changes are sufficient to solve the problem in Java 8. >>>>>> Unfortunately, >>>>>> that's still not enough in Java 9 because there the loading of the >>>>>> extended >>>>>> charsets has been delegated to ServiceLoader. But ServiceLoader calls >>>>>> ClassLoader.getBootstrapResources() which calls >>>>>> sun.misc.Launcher.getBootstrapClassPath(). This leads to another >>>>>> problem >>>>>> during class initialization of sun.misc.Launcher if running on an >>>>>> unsupported locale. >>>>>> >>>>>> The first thing done in sun.misc.Launcher. is the >>>>>> initialisation >>>>>> of >>>>>> the bootstrap URLClassPath in the Launcher. However this initialisation >>>>>> will >>>>>> eventually call Charset.isSupported() and if we are running on an >>>>>> unsupported locale this will inevitably end in another recursive call >>>>>> to >>>>>> ServiceLoader. But as explained below, ServiceLoader will query the >>>>>> Launcher's bootstrap URLClassPath which will be still uninitialized at >>>>>> that >>>>>> point. >>>>>> >>>>>> So we'll have to additionally guard guard against this situation on JDK >>>>>> 9 >>>>>> like this: >>>>>> >>>>>> private static Charset lookupExtendedCharset(String charsetName) { >>>>>> if (!sun.misc.VM.isBooted() || // see >>>>>> lookupViaProviders() >>>>>> sun.misc.Launcher.getBootstrapClassPath() == null) >>>>>> return null; >>>>>> >>>>>> This fixes the crashes, but still at the price of not having the >>>>>> extended >>>>>> charsets available during initialization until >>>>>> Launcher.getBootstrapClassPath is set up properly. This may be still a >>>>>> problem if the jdk is installed in a directory which contains >>>>>> characters >>>>>> specific to an extended encoding or if we have such characters in the >>>>>> command line arguments. >>>>>> >>>>>> Thank you and best regards, >>>>>> Volker >>>>>> >>>>>> >>>>>> Mixed stack trace of the initial EmptyStackException for unsupported >>>>>> charsets described before: >>>>>> >>>>>> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, >>>>>> C=native >>>>>> code) >>>>>> j java.util.Stack.peek()Ljava/lang/Object;+1 >>>>>> j >>>>>> java.lang.ClassLoader$NativeLibrary.getFromClass()Ljava/lang/Class;+3 >>>>>> v ~StubRoutines::call_stub >>>>>> V [libjvm.so+0x9d279a] JavaCalls::call_helper(JavaValue*, >>>>>> methodHandle*, >>>>>> JavaCallArguments*, Thread*)+0x6b4 >>>>>> V [libjvm.so+0xcad591] os::os_exception_wrapper(void (*)(JavaValue*, >>>>>> methodHandle*, JavaCallArguments*, Thread*), JavaValue*, methodHandle*, >>>>>> JavaCallArguments*, Thread*)+0x45 >>>>>> V [libjvm.so+0x9d20cf] JavaCalls::call(JavaValue*, methodHandle, >>>>>> JavaCallArguments*, Thread*)+0x8b >>>>>> V [libjvm.so+0x9d1d3b] JavaCalls::call_static(JavaValue*, >>>>>> KlassHandle, >>>>>> Symbol*, Symbol*, JavaCallArguments*, Thread*)+0x139 >>>>>> V [libjvm.so+0x9d1e3f] JavaCalls::call_static(JavaValue*, >>>>>> KlassHandle, >>>>>> Symbol*, Symbol*, Thread*)+0x9d >>>>>> V [libjvm.so+0x9e6588] jni_FindClass+0x428 >>>>>> C [libjava.so+0x20208] JNU_CallStaticMethodByName+0xff >>>>>> C [libjava.so+0x21cae] jnuEncodingSupported+0x61 >>>>>> C [libjava.so+0x22125] JNU_GetStringPlatformChars+0x125 >>>>>> C [libjava.so+0xedcd] >>>>>> Java_java_lang_ClassLoader_00024NativeLibrary_findBuiltinLib+0x8b >>>>>> j >>>>>> >>>>>> >>>>>> java.lang.ClassLoader$NativeLibrary.findBuiltinLib(Ljava/lang/String;)Ljava/lang/String;+0 >>>>>> j >>>>>> java.lang.ClassLoader.loadLibrary0(Ljava/lang/Class;Ljava/io/File;)Z+4 >>>>>> j >>>>>> >>>>>> >>>>>> java.lang.ClassLoader.loadLibrary(Ljava/lang/Class;Ljava/lang/String;Z)V+228 >>>>>> j >>>>>> java.lang.Runtime.loadLibrary0(Ljava/lang/Class;Ljava/lang/String;)V+54 >>>>>> j java.lang.System.loadLibrary(Ljava/lang/String;)V+7 >>>>>> j java.lang.System.initializeSystemClass()V+113 >>>>>> v ~StubRoutines::call_stub >>>>>> V [libjvm.so+0x9d279a] JavaCalls::call_helper(JavaValue*, >>>>>> methodHandle*, >>>>>> JavaCallArguments*, Thread*)+0x6b4 >>>>>> V [libjvm.so+0xcad591] os::os_exception_wrapper(void (*)(JavaValue*, >>>>>> methodHandle*, JavaCallArguments*, Thread*), JavaValue*, methodHandle*, >>>>>> JavaCallArguments*, Thread*)+0x45 >>>>>> V [libjvm.so+0x9d20cf] JavaCalls::call(JavaValue*, methodHandle, >>>>>> JavaCallArguments*, Thread*)+0x8b >>>>>> V [libjvm.so+0x9d1d3b] JavaCalls::call_static(JavaValue*, >>>>>> KlassHandle, >>>>>> Symbol*, Symbol*, JavaCallArguments*, Thread*)+0x139 >>>>>> V [libjvm.so+0x9d1e3f] JavaCalls::call_static(JavaValue*, >>>>>> KlassHandle, >>>>>> Symbol*, Symbol*, Thread*)+0x9d >>>>>> V [libjvm.so+0xe3cceb] call_initializeSystemClass(Thread*)+0xb0 >>>>>> V [libjvm.so+0xe44444] >>>>>> Threads::initialize_java_lang_classes(JavaThread*, >>>>>> Thread*)+0x21a >>>>>> V [libjvm.so+0xe44b12] Threads::create_vm(JavaVMInitArgs*, >>>>>> bool*)+0x4a6 >>>>>> V [libjvm.so+0xa19bd7] JNI_CreateJavaVM+0xc7 >>>>>> C [libjli.so+0xa520] InitializeJVM+0x154 >>>>>> C [libjli.so+0x8024] JavaMain+0xcc >>>>>> >>>>>> >> From volker.simonis at gmail.com Wed Jun 10 16:23:47 2015 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 10 Jun 2015 18:23:47 +0200 Subject: RFR(M): 8081674: EmptyStackException at startup if running with extended or unsupported charset In-Reply-To: References: <557626AA.6010008@oracle.com> <55772A56.2030308@oracle.com> Message-ID: Hy Mandy, that's a real good proposal and it only requires changes in the jdk repository which makes it even more attractive. I've just checked and it does indeed solve the initial EmptyStackException problem in both jdk8 and jdk9. Here are the corresponding webrevs: http://cr.openjdk.java.net/~simonis/webrevs/2015/8081674.jdk8/ http://cr.openjdk.java.net/~simonis/webrevs/2015/8081674.jdk9/ The only difference between 8 and 9 is the different location of the source files. Compared to your proposal I've only updated the copyright years where necessary and removed one comment in Java_java_lang_ClassLoader_findBuiltinLib() which seemed unnecessary to me now that findBuiltinLib() isn't located in NativeLibrary anymore. On jdk9 we are now running in another problem which is caused by the fact that the extended charsets are now being loaded by ServiceLoader (I've detailed that already in the bug report). But I think we can leave the fix of that problem to another change as this seems to require some more reasoning (see Alan's comments in the bug report). So are you OK now with pushing this change to jdk9 and requesting a downport to 8u-dev afterwards? Thank you and best regards, Volker On Wed, Jun 10, 2015 at 5:14 PM, Mandy Chung wrote: > Have you checked out this patch moving out findBuiltinLib from NativeLibrary class? > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8081674/webrev.00/ > > Mandy > >> On Jun 10, 2015, at 12:34 AM, Volker Simonis wrote: >> >> Mandy, the example/stacktrace I sent was with 8u. >> >> The problem isn't related to libzip, it is only the first library >> which gets loaded with System.loadLibrary(). >> >> The problem will occur with every library which gets loaded by >> System.loadLibrary() because >> java.lang.ClassLoader$NativeLibrary.findBuiltinLib() always calls >> jni_FindClass() if we're running on a unsupported locale. >> >> On Tue, Jun 9, 2015 at 8:03 PM, Mandy Chung wrote: >>> Does my patch work fine on 8u? If it works fine, I prefer to get that >>> simple fix in 8u and take the time to have a better fix in 9 (jdk9 is still >>> under development and I have assumed that it's not a show stopper to you. >>> Let me know if it blocks you). >>> >>> A question to Sherman - do we have adequate tests to verify the move of >>> System.loadLibrary("zip") from system initialization to ZipFile >>> initialization for 8u? >>> >>> Mandy >>> >>> >>> On 06/09/2015 10:09 AM, Volker Simonis wrote: >>>> >>>> Hi Mandy, >>>> >>>> thanks for looking into this. >>>> Uunfortunately your fix only helps to fix "java -version" :( >>>> >>>> Running even a minimal HelloWorld will still fail with the following >>>> stack trace which is still caused by the same EmptyStackException: >>>> >>>> Error: A JNI error has occurred, please check your installation and try >>>> again >>>> Exception in thread "main" java.lang.ExceptionInInitializerError >>>> at sun.misc.Unsafe.ensureClassInitialized(Native Method) >>>> at >>>> sun.misc.SharedSecrets.getJavaUtilZipFileAccess(SharedSecrets.java:158) >>>> at sun.misc.URLClassPath$JarLoader.(URLClassPath.java:765) >>>> at sun.misc.URLClassPath$3.run(URLClassPath.java:530) >>>> at sun.misc.URLClassPath$3.run(URLClassPath.java:520) >>>> at java.security.AccessController.doPrivileged(Native Method) >>>> at sun.misc.URLClassPath.getLoader(URLClassPath.java:519) >>>> at sun.misc.URLClassPath.getLoader(URLClassPath.java:492) >>>> at sun.misc.URLClassPath.getNextLoader(URLClassPath.java:457) >>>> at sun.misc.URLClassPath.access$100(URLClassPath.java:64) >>>> at sun.misc.URLClassPath$1.next(URLClassPath.java:239) >>>> at sun.misc.URLClassPath$1.hasMoreElements(URLClassPath.java:250) >>>> at java.net.URLClassLoader$3$1.run(URLClassLoader.java:601) >>>> at java.net.URLClassLoader$3$1.run(URLClassLoader.java:599) >>>> at java.security.AccessController.doPrivileged(Native Method) >>>> at java.net.URLClassLoader$3.next(URLClassLoader.java:598) >>>> at java.net.URLClassLoader$3.hasMoreElements(URLClassLoader.java:623) >>>> at sun.misc.CompoundEnumeration.next(CompoundEnumeration.java:45) >>>> at >>>> sun.misc.CompoundEnumeration.hasMoreElements(CompoundEnumeration.java:54) >>>> at sun.misc.CompoundEnumeration.next(CompoundEnumeration.java:45) >>>> at >>>> sun.misc.CompoundEnumeration.hasMoreElements(CompoundEnumeration.java:54) >>>> at >>>> java.util.ServiceLoader$LazyIterator.hasNextService(ServiceLoader.java:354) >>>> at >>>> java.util.ServiceLoader$LazyIterator.hasNext(ServiceLoader.java:393) >>>> at java.util.ServiceLoader$1.hasNext(ServiceLoader.java:474) >>>> at java.nio.charset.Charset$1.getNext(Charset.java:350) >>>> at java.nio.charset.Charset$1.hasNext(Charset.java:365) >>>> at java.nio.charset.Charset$2.run(Charset.java:410) >>>> at java.nio.charset.Charset$2.run(Charset.java:407) >>>> at java.security.AccessController.doPrivileged(Native Method) >>>> at java.nio.charset.Charset.lookupViaProviders(Charset.java:406) >>>> at java.nio.charset.Charset.lookup2(Charset.java:477) >>>> at java.nio.charset.Charset.lookup(Charset.java:464) >>>> at java.nio.charset.Charset.isSupported(Charset.java:505) >>>> at >>>> sun.launcher.LauncherHelper.makePlatformString(LauncherHelper.java:580) >>>> Caused by: java.util.EmptyStackException >>>> at java.util.Stack.peek(Stack.java:102) >>>> at >>>> java.lang.ClassLoader$NativeLibrary.getFromClass(ClassLoader.java:1759) >>>> at java.lang.ClassLoader$NativeLibrary.findBuiltinLib(Native Method) >>>> at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1870) >>>> at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1843) >>>> at java.lang.Runtime.loadLibrary0(Runtime.java:870) >>>> at java.lang.System.loadLibrary(System.java:1122) >>>> at java.util.zip.ZipFile.(ZipFile.java:86) >>>> ... 34 more >>>> >>>> It's obvious that the way jni_FindClass is looking for the class >>>> context by calling the NativeLibrary::getFromClass method is hacky but >>>> I think that the proposed fix is the quite simple and non-intrusive. >>>> And we probably don't want a complete rework of this code for 8 >>>> anyway. So why not fix it the proposed way in 8 and 9 for now? That >>>> will still leave us time to come up with a better clean-up at least >>>> for 9. >>>> >>>> What do you think? >>>> >>>> Regards, >>>> Volker >>>> >>>> On Tue, Jun 9, 2015 at 1:35 AM, Mandy Chung >>>> wrote: >>>>> >>>>> Hi Volker, >>>>> >>>>> Your patch reminds me the question I have about loading zip library. >>>>> >>>>> In JDK 9 (and earlier release), zip library is loaded by the VM during >>>>> startup (see ClassLoader::load_zip_library). I think loadLibrary("zip") >>>>> is >>>>> no longer needed to be called from System::initializeSystemClass method >>>>> and >>>>> instead it can be loaded by java.util.zip.ZipFile static initializer. >>>>> >>>>> Do you mind to try the patch (below)? That may be a simpler fix. >>>>> >>>>> I never like the way jni_FindClass to look for the class context by >>>>> calling >>>>> the NativeLibrary::getFromClass method. I will have to look deeper other >>>>> alternative to clean that up. If taking out loadLibrary("zip") resolves >>>>> your issue, this will give us time to come up with a better clean-up in >>>>> the >>>>> future. >>>>> >>>>> Mandy >>>>> [1] https://bugs.openjdk.java.net/browse/JDK-4429040 >>>>> >>>>> diff --git a/src/share/classes/java/lang/System.java >>>>> b/src/share/classes/java/lang/System.java >>>>> --- a/src/share/classes/java/lang/System.java >>>>> +++ b/src/share/classes/java/lang/System.java >>>>> @@ -1192,10 +1192,6 @@ >>>>> setOut0(newPrintStream(fdOut, >>>>> props.getProperty("sun.stdout.encoding"))); >>>>> setErr0(newPrintStream(fdErr, >>>>> props.getProperty("sun.stderr.encoding"))); >>>>> >>>>> - // Load the zip library now in order to keep >>>>> java.util.zip.ZipFile >>>>> - // from trying to use itself to load this library later. >>>>> - loadLibrary("zip"); >>>>> - >>>>> // Setup Java signal handlers for HUP, TERM, and INT (where >>>>> available). >>>>> Terminator.setup(); >>>>> >>>>> diff --git a/src/share/classes/java/util/zip/ZipFile.java >>>>> b/src/share/classes/java/util/zip/ZipFile.java >>>>> --- a/src/share/classes/java/util/zip/ZipFile.java >>>>> +++ b/src/share/classes/java/util/zip/ZipFile.java >>>>> @@ -83,6 +83,7 @@ >>>>> >>>>> static { >>>>> /* Zip library is loaded from System.initializeSystemClass */ >>>>> + System.loadLibrary("zip"); >>>>> initIDs(); >>>>> >>>>> } >>>>> >>>>> >>>>> >>>>> On 06/08/2015 07:23 AM, Volker Simonis wrote: >>>>>> >>>>>> Hi, >>>>>> >>>>>> can I please get a review at least for the part of this fix which is >>>>>> common for jdk8 and jdk9. It's only a few lines in >>>>>> src/share/vm/prims/jni.cpp for the hotspot repository and one line >>>>>> src/java.base/share/classes/java/lang/ClassLoader.java for the jdk >>>>>> repository. >>>>>> >>>>>> Thanks, >>>>>> Volker >>>>>> >>>>>> >>>>>> On Tue, Jun 2, 2015 at 6:12 PM, Volker Simonis >>>>>> >>>>>> wrote: >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> can I please have review (and a sponsor) for these changes: >>>>>>> >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8081674 >>>>>>> http://cr.openjdk.java.net/~simonis/webrevs/2015/8081674.jdk >>>>>>> http://cr.openjdk.java.net/~simonis/webrevs/2015/8081674.hs >>>>>>> >>>>>>> Please notice that the fix requires synchronous changes in the jdk and >>>>>>> the >>>>>>> hotspot forest. >>>>>>> >>>>>>> The changes themselves are by far not that big as this explanation but >>>>>>> I >>>>>>> found the problem to be quite intricate so I tried to explain it as >>>>>>> good >>>>>>> as >>>>>>> I could. I'd suggest to read the HTML-formatted explanation in the >>>>>>> webrev >>>>>>> although the content is equal to the one in this mail: >>>>>>> >>>>>>> Using an unsupported character encoding (e.g. vi_VN.TCVN on Linux) >>>>>>> results >>>>>>> in an immediate VM failure with jdk 8 and 9: >>>>>>> >>>>>>> export LANG=vi_VN.TCVN >>>>>>> java -version >>>>>>> Error occurred during initialization of VM >>>>>>> java.util.EmptyStackException >>>>>>> at java.util.Stack.peek(Stack.java:102) >>>>>>> at >>>>>>> java.lang.ClassLoader$NativeLibrary.getFromClass(ClassLoader.java:1751) >>>>>>> at java.lang.ClassLoader$NativeLibrary.findBuiltinLib(Native >>>>>>> Method) >>>>>>> at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1862) >>>>>>> at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1835) >>>>>>> at java.lang.Runtime.loadLibrary0(Runtime.java:870) >>>>>>> at java.lang.System.loadLibrary(System.java:1119) >>>>>>> at java.lang.System.initializeSystemClass(System.java:1194) >>>>>>> >>>>>>> This is a consequence of "8005716: Enhance JNI specification to allow >>>>>>> support of static JNI libraries in Embedded JREs". >>>>>>> >>>>>>> With jdk 9 we get this error even if we're running with a supported >>>>>>> charset >>>>>>> which is in the ExtendedCharsets (as opposed to being in the >>>>>>> StandardCharsets) class which is a consequence of delegating the >>>>>>> loading >>>>>>> of >>>>>>> the ExtendedCharsets class to the ServiceLoader in jdk 9. >>>>>>> >>>>>>> export LANG=eo.iso-8859-3 >>>>>>> output-jdk9/images/jdk/bin/java -version >>>>>>> Error occurred during initialization of VM >>>>>>> java.util.EmptyStackException >>>>>>> at java.util.Stack.peek(Stack.java:102) >>>>>>> at >>>>>>> java.lang.ClassLoader$NativeLibrary.getFromClass(ClassLoader.java:1737) >>>>>>> at java.lang.ClassLoader$NativeLibrary.findBuiltinLib(Native >>>>>>> Method) >>>>>>> at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1866) >>>>>>> at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1840) >>>>>>> at java.lang.Runtime.loadLibrary0(Runtime.java:874) >>>>>>> at java.lang.System.loadLibrary(System.java:1111) >>>>>>> at java.lang.System.initializeSystemClass(System.java:1186) >>>>>>> >>>>>>> Here's why the exception happens for an unsupported charset (see the >>>>>>> mixed >>>>>>> stack trace below for the full details): >>>>>>> >>>>>>> java.lang.System.loadLibrary() wants to load libzip.so. It calls >>>>>>> java.lang.Runtime.loadLibrary0() which at the very beginning calls the >>>>>>> native method ClassLoader$NativeLibrary.findBuiltinLib() which checks >>>>>>> if >>>>>>> the >>>>>>> corresponding library is already statically linked into the VM >>>>>>> (introduced >>>>>>> by 8005716). >>>>>>> Java_java_lang_ClassLoader_00024NativeLibrary_findBuiltinLib(), >>>>>>> the native implementation of findBuiltinLib() in Classloader.c calls >>>>>>> GetStringPlatformChars() to convert the library name into the native >>>>>>> platform encoding. GetStringPlatformChars() calls the helper function >>>>>>> jnuEncodingSupported() to check if the platform encoding which is >>>>>>> stored >>>>>>> in >>>>>>> the property "sun.jnu.encoding" is supported by Java. >>>>>>> jnuEncodingSupported() >>>>>>> is implemented as follows: >>>>>>> >>>>>>> static jboolean isJNUEncodingSupported = JNI_FALSE; >>>>>>> static jboolean jnuEncodingSupported(JNIEnv *env) { >>>>>>> jboolean exe; >>>>>>> if (isJNUEncodingSupported == JNI_TRUE) { >>>>>>> return JNI_TRUE; >>>>>>> } >>>>>>> isJNUEncodingSupported = (jboolean) JNU_CallStaticMethodByName ( >>>>>>> env, &exe, >>>>>>> "java/nio/charset/Charset", >>>>>>> "isSupported", >>>>>>> "(Ljava/lang/String;)Z", >>>>>>> jnuEncoding).z; >>>>>>> return isJNUEncodingSupported; >>>>>>> } >>>>>>> >>>>>>> Once the function finds that the platform encoding is supported (by >>>>>>> calling >>>>>>> java.nio.charset.Charset.isSupported()) it caches this value and always >>>>>>> returns it on following calls. However if the platform encoding is not >>>>>>> supported, it ALWAYS calls java.nio.charset.Charset.isSupported() an >>>>>>> every >>>>>>> subsequent invocation. >>>>>>> >>>>>>> In order to call the Java method Charset.isSupported() (in >>>>>>> JNU_CallStaticMethodByName() in file jni_util.c), we have to call >>>>>>> jni_FindClass() to convert the symbolic class name >>>>>>> "java.nio.charset.Charset" into a class reference. >>>>>>> >>>>>>> But unfortunately, jni_FindClass() (from jni.cpp in libjvm.so) has a >>>>>>> special >>>>>>> handling if called from java.lang.ClassLoader$NativeLibrary to ensure >>>>>>> that >>>>>>> JNI_OnLoad/JNI_OnUnload are executed in the correct class context: >>>>>>> >>>>>>> instanceKlassHandle k (THREAD, >>>>>>> thread->security_get_caller_class(0)); >>>>>>> if (k.not_null()) { >>>>>>> loader = Handle(THREAD, k->class_loader()); >>>>>>> // Special handling to make sure JNI_OnLoad and JNI_OnUnload are >>>>>>> executed >>>>>>> // in the correct class context. >>>>>>> if (loader.is_null() && >>>>>>> k->name() == >>>>>>> vmSymbols::java_lang_ClassLoader_NativeLibrary()) { >>>>>>> JavaValue result(T_OBJECT); >>>>>>> JavaCalls::call_static(&result, k, >>>>>>> vmSymbols::getFromClass_name(), >>>>>>> >>>>>>> vmSymbols::void_class_signature(), >>>>>>> thread); >>>>>>> if (HAS_PENDING_EXCEPTION) { >>>>>>> Handle ex(thread, thread->pending_exception()); >>>>>>> CLEAR_PENDING_EXCEPTION; >>>>>>> THROW_HANDLE_0(ex); >>>>>>> } >>>>>>> >>>>>>> So if that's the case and jni_FindClass() was reallycalled from >>>>>>> ClassLoader$NativeLibrary, then jni_FindClass() calles >>>>>>> ClassLoader$NativeLibrary().getFromClass() to find out the >>>>>>> corresponding >>>>>>> context class which is supposed to be saved there in a field of type >>>>>>> java.util.Stack named "nativeLibraryContext": >>>>>>> >>>>>>> // Invoked in the VM to determine the context class in >>>>>>> // JNI_Load/JNI_Unload >>>>>>> static Class getFromClass() { >>>>>>> return ClassLoader.nativeLibraryContext.peek().fromClass; >>>>>>> } >>>>>>> >>>>>>> Unfortunately, "nativeLibraryContext" doesn't contain any entry at this >>>>>>> point and the invocation of Stack.peek() will throw the exception shown >>>>>>> before. In general, the "nativeLibraryContext" stack will be filled >>>>>>> later >>>>>>> on >>>>>>> in Runtime.loadLibrary0() like this: >>>>>>> >>>>>>> NativeLibrary lib = new NativeLibrary(fromClass, name, isBuiltin); >>>>>>> nativeLibraryContext.push(lib); >>>>>>> try { >>>>>>> lib.load(name, isBuiltin); >>>>>>> } finally { >>>>>>> nativeLibraryContext.pop(); >>>>>>> } >>>>>>> >>>>>>> such that it always contains at least one element later when >>>>>>> jni_FindClass() >>>>>>> will be invoked. >>>>>>> >>>>>>> So in summary, the problem is that the implementors of 8005716 didn't >>>>>>> took >>>>>>> into account that calling ClassLoader$NativeLibrary.findBuiltinLib() >>>>>>> may >>>>>>> trigger a call to jni_FindClass() if we are running on a system with an >>>>>>> unsupported character encoding. >>>>>>> >>>>>>> I'd suggest the following fix for this problem: >>>>>>> >>>>>>> Change ClassLoader$NativeLibrary().getFromClass() to return null if the >>>>>>> stack is empty instead of throwing an exception: >>>>>>> >>>>>>> static Class getFromClass() { >>>>>>> return ClassLoader.nativeLibraryContext.empty() ? >>>>>>> null : ClassLoader.nativeLibraryContext.peek().fromClass; >>>>>>> } >>>>>>> >>>>>>> Unfortunately this also requires a HotSpot change in jni_FindClass() in >>>>>>> order to properly handle the new 'null' return value: >>>>>>> >>>>>>> if (k.not_null()) { >>>>>>> loader = Handle(THREAD, k->class_loader()); >>>>>>> // Special handling to make sure JNI_OnLoad and JNI_OnUnload are >>>>>>> executed >>>>>>> // in the correct class context. >>>>>>> if (loader.is_null() && >>>>>>> k->name() == >>>>>>> vmSymbols::java_lang_ClassLoader_NativeLibrary()) { >>>>>>> JavaValue result(T_OBJECT); >>>>>>> JavaCalls::call_static(&result, k, >>>>>>> vmSymbols::getFromClass_name(), >>>>>>> >>>>>>> vmSymbols::void_class_signature(), >>>>>>> thread); >>>>>>> if (HAS_PENDING_EXCEPTION) { >>>>>>> Handle ex(thread, thread->pending_exception()); >>>>>>> CLEAR_PENDING_EXCEPTION; >>>>>>> THROW_HANDLE_0(ex); >>>>>>> } >>>>>>> oop mirror = (oop) result.get_jobject(); >>>>>>> if (oopDesc::is_null(mirror)) { >>>>>>> loader = Handle(THREAD, >>>>>>> SystemDictionary::java_system_loader()); >>>>>>> } else { >>>>>>> loader = Handle(THREAD, >>>>>>> >>>>>>> >>>>>>> InstanceKlass::cast(java_lang_Class::as_Klass(mirror))->class_loader()); >>>>>>> protection_domain = Handle(THREAD, >>>>>>> >>>>>>> >>>>>>> >>>>>>> InstanceKlass::cast(java_lang_Class::as_Klass(mirror))->protection_domain()); >>>>>>> } >>>>>>> } >>>>>>> } else { >>>>>>> // We call ClassLoader.getSystemClassLoader to obtain the system >>>>>>> class >>>>>>> loader. >>>>>>> loader = Handle(THREAD, SystemDictionary::java_system_loader()); >>>>>>> } >>>>>>> >>>>>>> These changes are sufficient to solve the problem in Java 8. >>>>>>> Unfortunately, >>>>>>> that's still not enough in Java 9 because there the loading of the >>>>>>> extended >>>>>>> charsets has been delegated to ServiceLoader. But ServiceLoader calls >>>>>>> ClassLoader.getBootstrapResources() which calls >>>>>>> sun.misc.Launcher.getBootstrapClassPath(). This leads to another >>>>>>> problem >>>>>>> during class initialization of sun.misc.Launcher if running on an >>>>>>> unsupported locale. >>>>>>> >>>>>>> The first thing done in sun.misc.Launcher. is the >>>>>>> initialisation >>>>>>> of >>>>>>> the bootstrap URLClassPath in the Launcher. However this initialisation >>>>>>> will >>>>>>> eventually call Charset.isSupported() and if we are running on an >>>>>>> unsupported locale this will inevitably end in another recursive call >>>>>>> to >>>>>>> ServiceLoader. But as explained below, ServiceLoader will query the >>>>>>> Launcher's bootstrap URLClassPath which will be still uninitialized at >>>>>>> that >>>>>>> point. >>>>>>> >>>>>>> So we'll have to additionally guard guard against this situation on JDK >>>>>>> 9 >>>>>>> like this: >>>>>>> >>>>>>> private static Charset lookupExtendedCharset(String charsetName) { >>>>>>> if (!sun.misc.VM.isBooted() || // see >>>>>>> lookupViaProviders() >>>>>>> sun.misc.Launcher.getBootstrapClassPath() == null) >>>>>>> return null; >>>>>>> >>>>>>> This fixes the crashes, but still at the price of not having the >>>>>>> extended >>>>>>> charsets available during initialization until >>>>>>> Launcher.getBootstrapClassPath is set up properly. This may be still a >>>>>>> problem if the jdk is installed in a directory which contains >>>>>>> characters >>>>>>> specific to an extended encoding or if we have such characters in the >>>>>>> command line arguments. >>>>>>> >>>>>>> Thank you and best regards, >>>>>>> Volker >>>>>>> >>>>>>> >>>>>>> Mixed stack trace of the initial EmptyStackException for unsupported >>>>>>> charsets described before: >>>>>>> >>>>>>> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, >>>>>>> C=native >>>>>>> code) >>>>>>> j java.util.Stack.peek()Ljava/lang/Object;+1 >>>>>>> j >>>>>>> java.lang.ClassLoader$NativeLibrary.getFromClass()Ljava/lang/Class;+3 >>>>>>> v ~StubRoutines::call_stub >>>>>>> V [libjvm.so+0x9d279a] JavaCalls::call_helper(JavaValue*, >>>>>>> methodHandle*, >>>>>>> JavaCallArguments*, Thread*)+0x6b4 >>>>>>> V [libjvm.so+0xcad591] os::os_exception_wrapper(void (*)(JavaValue*, >>>>>>> methodHandle*, JavaCallArguments*, Thread*), JavaValue*, methodHandle*, >>>>>>> JavaCallArguments*, Thread*)+0x45 >>>>>>> V [libjvm.so+0x9d20cf] JavaCalls::call(JavaValue*, methodHandle, >>>>>>> JavaCallArguments*, Thread*)+0x8b >>>>>>> V [libjvm.so+0x9d1d3b] JavaCalls::call_static(JavaValue*, >>>>>>> KlassHandle, >>>>>>> Symbol*, Symbol*, JavaCallArguments*, Thread*)+0x139 >>>>>>> V [libjvm.so+0x9d1e3f] JavaCalls::call_static(JavaValue*, >>>>>>> KlassHandle, >>>>>>> Symbol*, Symbol*, Thread*)+0x9d >>>>>>> V [libjvm.so+0x9e6588] jni_FindClass+0x428 >>>>>>> C [libjava.so+0x20208] JNU_CallStaticMethodByName+0xff >>>>>>> C [libjava.so+0x21cae] jnuEncodingSupported+0x61 >>>>>>> C [libjava.so+0x22125] JNU_GetStringPlatformChars+0x125 >>>>>>> C [libjava.so+0xedcd] >>>>>>> Java_java_lang_ClassLoader_00024NativeLibrary_findBuiltinLib+0x8b >>>>>>> j >>>>>>> >>>>>>> >>>>>>> java.lang.ClassLoader$NativeLibrary.findBuiltinLib(Ljava/lang/String;)Ljava/lang/String;+0 >>>>>>> j >>>>>>> java.lang.ClassLoader.loadLibrary0(Ljava/lang/Class;Ljava/io/File;)Z+4 >>>>>>> j >>>>>>> >>>>>>> >>>>>>> java.lang.ClassLoader.loadLibrary(Ljava/lang/Class;Ljava/lang/String;Z)V+228 >>>>>>> j >>>>>>> java.lang.Runtime.loadLibrary0(Ljava/lang/Class;Ljava/lang/String;)V+54 >>>>>>> j java.lang.System.loadLibrary(Ljava/lang/String;)V+7 >>>>>>> j java.lang.System.initializeSystemClass()V+113 >>>>>>> v ~StubRoutines::call_stub >>>>>>> V [libjvm.so+0x9d279a] JavaCalls::call_helper(JavaValue*, >>>>>>> methodHandle*, >>>>>>> JavaCallArguments*, Thread*)+0x6b4 >>>>>>> V [libjvm.so+0xcad591] os::os_exception_wrapper(void (*)(JavaValue*, >>>>>>> methodHandle*, JavaCallArguments*, Thread*), JavaValue*, methodHandle*, >>>>>>> JavaCallArguments*, Thread*)+0x45 >>>>>>> V [libjvm.so+0x9d20cf] JavaCalls::call(JavaValue*, methodHandle, >>>>>>> JavaCallArguments*, Thread*)+0x8b >>>>>>> V [libjvm.so+0x9d1d3b] JavaCalls::call_static(JavaValue*, >>>>>>> KlassHandle, >>>>>>> Symbol*, Symbol*, JavaCallArguments*, Thread*)+0x139 >>>>>>> V [libjvm.so+0x9d1e3f] JavaCalls::call_static(JavaValue*, >>>>>>> KlassHandle, >>>>>>> Symbol*, Symbol*, Thread*)+0x9d >>>>>>> V [libjvm.so+0xe3cceb] call_initializeSystemClass(Thread*)+0xb0 >>>>>>> V [libjvm.so+0xe44444] >>>>>>> Threads::initialize_java_lang_classes(JavaThread*, >>>>>>> Thread*)+0x21a >>>>>>> V [libjvm.so+0xe44b12] Threads::create_vm(JavaVMInitArgs*, >>>>>>> bool*)+0x4a6 >>>>>>> V [libjvm.so+0xa19bd7] JNI_CreateJavaVM+0xc7 >>>>>>> C [libjli.so+0xa520] InitializeJVM+0x154 >>>>>>> C [libjli.so+0x8024] JavaMain+0xcc >>>>>>> >>>>>>> >>> > From alejandro.murillo at oracle.com Wed Jun 10 17:21:59 2015 From: alejandro.murillo at oracle.com (Alejandro E Murillo) Date: Wed, 10 Jun 2015 11:21:59 -0600 Subject: RFR: JDK-8085822 JEP 223: New Version-String Scheme (initial integration) In-Reply-To: <557829DC.8000405@oracle.com> References: <5571AD18.7080701@oracle.com> <557625C8.5050200@oracle.com> <5576E633.9050503@oracle.com> <5576E81B.8050703@oracle.com> <5576EF94.3010500@oracle.com> <55780A33.1010302@oracle.com> <557829DC.8000405@oracle.com> Message-ID: <55787237.20802@oracle.com> On 6/10/2015 6:13 AM, Magnus Ihse Bursie wrote: > On 2015-06-10 11:58, David Holmes wrote: >> Hi Magnus, >> >> Generally looks good - a few comments/queries below. > > In general, I believe most issues you found are valid. :-) However, as > I said before in this thread, I'd like to see them resolved in the > needed follow-up patches. The source code changes in Hotspot and JDK > are inadequate to fully implement JEP-223, so these areas will need to > be rewritten anyhow. Are you okay with resolving these issues later? > >> >> On 9/06/2015 11:52 PM, Magnus Ihse Bursie wrote: >>> Here's an updated webrev, which fixes the typos that were pointed >>> out by >>> reviewers: >>> http://cr.openjdk.java.net/~ihse/JDK-8085822-JEP-223-initial-patch/webrev.02/ >>> >> >> common/autoconf/version-numbers >> >> Shouldn't there be a DEFAULT_VERSION_XXX for each of the XXX parts of >> the version info? (Even if all zeroes presently.) > So that's a tricky one. :-& The question here is, I think, does it > make sense to update version-numbers when we do a security (9.0.1) or > minor (9.1.0) release? Looking historically, the version-numbers file > have not been changed for the 8u family. The only change was going > from 8 to 9 when creating the new jdk9 forest. That was what I based > my decition to only have the major number in the file. (The rest of > the version string is set by configure flags when building, in Oracle > case by the RE team.) > > If it makes sense to put the minor/security/patch numbers here, I > won't oppose it, but I guess we have until the first such release to > figure out what's best, and that likely includes discussion with RE > and possibly other consumers in the community (RedHat etc). > >> >> --- >> >> Looking at hotspot changes I can't convince myself that the new >> streamlined "version" variables will capture things like "fastdebug". >> Will that filter through via configure variables? > > The "fastdebug" label has been handled as a less valued token in the > JEP-223 process. Right now there's no mention of it at all in the > version string proposal in the JEP. As I understand it, Iris is about > to propose an amendment which will just make fastdebug be a part of > the OPT string. I'm not entirely happy with that myself, but that's > the way it's decided. So wherever you can see the OPT string, you'll > see the debug level tag. > > Currently, however, that's not how it is implemented in this patch. > Since no decision was made on this (and it's still not formally > decided), I had to pick a route to go forward. The current patch will > instead put the "fastdebug" label as part of the PRE string (that's > the reason for the pre-base and pre-debuglevel arguments to > configure). If the planned changes goes into the JEP, this'll change > to make the debuglevel tag a part of the OPT string instead. > >> --- >> >> make/*/makefiles/vm.make >> >> Shouldn't the -DVERSION_XX=$(VERSION_XX) definitions be taken from >> the VERSION_CFLAGS in spec.gmk? (Or are you still allowing for a >> stand-alone hotspot build?) > The hotspot JEP-223 work initially made by Alejandro kept support for > stand-alone hotspot builds. I made additional changes on top of that, > which still tried to cater for stand-alone builds. At this very moment > I'm not sure if stand-alone hotspot builds are supposed to work or > not, but I've tried to not change the situation with this patch. > > There are two future changes coming down the pipe: One is the > additional JEP-223 work needed for Hotspot. I know Alejandro had plans > for redesigning the API between Hotspot and the JDK, so no JDK version > strings should be compiled into the JVM, but all of it extracted > during an API in runtime. That would make most (all?) of the makefile > changes in hotspot irrelevant. However, that implementation is not > even started, so it's needed for the time being. There's already an API used by Hotspot to get JDK version values. I'm investigating using that and extend it if required. yes, there is a lot stuff in the hotspot code that should be removed (mostly in the makefiles) and I'm not against making those changes now, I just think they are somewhat out of the scope of this project. And should be done as individual RFEs or as part of the upcoming hotspot makefile refactoring. Alejandro > > The second change is the build-infra hotspot makefile rewrite. When > that happens, stand-alone builds will definitely disappear, and if > Hotspot still needs make support for version strings, then the logical > choice is to use VERSION_CFLAGS. > > Ok? > >> >> --- >> >> hotspot/src/share/vm/prims/jvm.h >> jdk/src/java.base/share/native/include/jvm.h >> >> I think this comment is way out of date: >> >> /* Build number is available only for RE build (i.e. >> JDK_BUILD_NUMBER is set to bNN) >> * It will be zero for internal builds. >> */ >> >> and can be completely removed. Even if still true, mention of an "RE >> build" has no place in OpenJDK sources. > Yep, agree. Follow-up patch, right? > >> >> --- >> >> hotspot/src/share/vm/runtime/java.cpp >> >> I think a lot of the modified code is obsolete post Hotspot Express - >> which makes it hard to determine if the changes make sense. > Yep, agree. Follow-up patch, right? >> >> --- >> >> hotspot/src/share/vm/runtime/vmStructs.cpp >> >> Please fix the alignment (3 extra spaces on modified line): >> >> 1239 static_field(Abstract_VM_Version, _vm_minor_version, >> int) \ >> 1240 static_field(Abstract_VM_Version, _vm_security_version, >> int) \ > > I was about to say "follow-up patch", but ugly indentation really > sucks so I can fix this. Ok if I skip redoing the review for that? > >> >> --- >> >> hotspot/test/runtime/6981737/Test6981737.java >> >> This test is really only valid for the new version scheme now, so it >> should probably be rewritten - and in that case it really isn't >> testing 6981737 but should be replaced by a new test for the new >> version format. > Yep, agree. Follow-up patch, right? >> >> --- >> >> jdk/src/java.base/share/classes/sun/misc/Version.java.template >> >> This comment is nonsensical: >> >> /** >> ! * Returns the security version of the running JVM if it's 1.6 >> or newer >> * or any RE VM build. It will return 0 if it's an internal 1.5 or >> * 1.4.x build. >> * @since 1.6 >> */ >> >> as security version does not exist pre 9. Normally you should be >> adding a new method and deprecating the old one. The new one is >> @since 9. > Yep, agree. Follow-up patch, right? >> >> /** >> ! * Returns the security version of the running JDK. >> * @since 1.6 >> */ >> >> Ditto: @since 9 (but again old should be deprecated and new method >> added) >> >> 253 /** >> 254 * Returns the build number of the running JDK if it's a RE >> build >> 255 * It will return 0 if it's an internal build. >> >> As with jvm.h this seems obsolete commentary these days - not only RE >> builds define a build number. > Yep, agree. Follow-up patch, right? > > /Magnus > >> >> Thanks, >> David > -- Alejandro From vladimir.kozlov at oracle.com Wed Jun 10 18:01:25 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 10 Jun 2015 11:01:25 -0700 Subject: RFR: 8085805: aarch64: AdvancedThresholdPolicy lacks tuning of InlineSmallCode size In-Reply-To: <1433941131.11860.74.camel@mylittlepony.linaroharston> References: <1433941131.11860.74.camel@mylittlepony.linaroharston> Message-ID: <55787B75.8010009@oracle.com> Looks good to me. Thanks, Vladimir On 6/10/15 5:58 AM, Edward Nevill wrote: > Hi, > > http://cr.openjdk.java.net/~enevill/8085805/webrev/ > > adds tuning of InlineSmallCode for aarch64. > > src/share/vm/runtime/advancedThresholdPolicy.cpp contains the following code which tunes the value of InlineSmallCode for X86 and SPARC. > > // Some inlining tuning > #ifdef X86 > if (FLAG_IS_DEFAULT(InlineSmallCode)) { > FLAG_SET_DEFAULT(InlineSmallCode, 2000); > } > #endif > > #ifdef SPARC > if (FLAG_IS_DEFAULT(InlineSmallCode)) { > FLAG_SET_DEFAULT(InlineSmallCode, 2500); > } > #endif > > set_increase_threshold_at_ratio(); > set_start_time(os::javaTimeMillis()); > } > > This webrev proposes changing this so that InlineSmallCode is increased to 2500 on aarch64 rather than the default of 1000. The change is simply to add AARCH64 to the conditional. IE. > > #if defined SPARC || defined AARCH64 > if (FLAG_IS_DEFAULT(InlineSmallCode)) { > FLAG_SET_DEFAULT(InlineSmallCode, 2500); > } > #endif > > This change request was triggered by one of our partners reporting a 6x improvement in one benchmark when the size of InlineSmallCode is increased. > > I have done some testing to find the optimal size of InlineCodeSize for aarch64. The following shows the performance of various benchmarks against different sizes of InlineSmallCode. > > InlineSmallCode 100 1000 1500 2000 2500 3000 5000 > > Grinderbench 440543 589792 595603 659213 665973 664663 667865 > Stringtest 65182 65304 65211 339946 329314 326831 296886 > SpecJVM2008 76.4 90.8 90.9 91.9 89.6 89.2 88.3 > > The optimal value seems to be about 2000/2500. I have elected for the slightly higher value. > > Tested with JTreg/hotspot. In both cases, before and after the patch > > Test results: passed: 845; failed: 12; error: 6 > > Please review, > Thanks, > Ed. > > > From mandy.chung at oracle.com Wed Jun 10 19:02:35 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 10 Jun 2015 12:02:35 -0700 Subject: RFR(M): 8081674: EmptyStackException at startup if running with extended or unsupported charset In-Reply-To: References: <557626AA.6010008@oracle.com> <55772A56.2030308@oracle.com> Message-ID: <7B3C08CF-028E-4AD2-B7F8-C803F2BA3C7D@oracle.com> > On Jun 10, 2015, at 9:23 AM, Volker Simonis wrote: > > Hy Mandy, > > that's a real good proposal and it only requires changes in the jdk > repository which makes it even more attractive. > > I've just checked and it does indeed solve the initial > EmptyStackException problem in both jdk8 and jdk9. Here are the > corresponding webrevs: > > http://cr.openjdk.java.net/~simonis/webrevs/2015/8081674.jdk8/ ClassLoader.java It should have done that. Nit: Can you move line 1693 to 1868 closer to loadLibrary0 (the caller of findBuiltinLib)? Also make it private. Same applies to jdk9. Otherwise looks good. No need to generate a webrev as long as you make the change before the push. > http://cr.openjdk.java.net/~simonis/webrevs/2015/8081674.jdk9/ > > The only difference between 8 and 9 is the different location of the > source files. > Compared to your proposal I've only updated the copyright years where > necessary and removed one comment in > Java_java_lang_ClassLoader_findBuiltinLib() which seemed unnecessary > to me now that findBuiltinLib() isn't located in NativeLibrary > anymore. > Thanks for taking it out. > On jdk9 we are now running in another problem which is caused by the > fact that the extended charsets are now being loaded by ServiceLoader > (I've detailed that already in the bug report). But I think we can > leave the fix of that problem to another change as this seems to > require some more reasoning (see Alan's comments in the bug report). Yes this is a harder problem that have to investigate further. > > So are you OK now with pushing this change to jdk9 and requesting a > downport to 8u-dev afterwards? > Yes. Approved. Mandy > Thank you and best regards, > Volker > > > On Wed, Jun 10, 2015 at 5:14 PM, Mandy Chung wrote: >> Have you checked out this patch moving out findBuiltinLib from NativeLibrary class? >> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8081674/webrev.00/ >> >> Mandy >> >>> On Jun 10, 2015, at 12:34 AM, Volker Simonis wrote: >>> >>> Mandy, the example/stacktrace I sent was with 8u. >>> >>> The problem isn't related to libzip, it is only the first library >>> which gets loaded with System.loadLibrary(). >>> >>> The problem will occur with every library which gets loaded by >>> System.loadLibrary() because >>> java.lang.ClassLoader$NativeLibrary.findBuiltinLib() always calls >>> jni_FindClass() if we're running on a unsupported locale. >>> >>> On Tue, Jun 9, 2015 at 8:03 PM, Mandy Chung wrote: >>>> Does my patch work fine on 8u? If it works fine, I prefer to get that >>>> simple fix in 8u and take the time to have a better fix in 9 (jdk9 is still >>>> under development and I have assumed that it's not a show stopper to you. >>>> Let me know if it blocks you). >>>> >>>> A question to Sherman - do we have adequate tests to verify the move of >>>> System.loadLibrary("zip") from system initialization to ZipFile >>>> initialization for 8u? >>>> >>>> Mandy >>>> >>>> >>>> On 06/09/2015 10:09 AM, Volker Simonis wrote: >>>>> >>>>> Hi Mandy, >>>>> >>>>> thanks for looking into this. >>>>> Uunfortunately your fix only helps to fix "java -version" :( >>>>> >>>>> Running even a minimal HelloWorld will still fail with the following >>>>> stack trace which is still caused by the same EmptyStackException: >>>>> >>>>> Error: A JNI error has occurred, please check your installation and try >>>>> again >>>>> Exception in thread "main" java.lang.ExceptionInInitializerError >>>>> at sun.misc.Unsafe.ensureClassInitialized(Native Method) >>>>> at >>>>> sun.misc.SharedSecrets.getJavaUtilZipFileAccess(SharedSecrets.java:158) >>>>> at sun.misc.URLClassPath$JarLoader.(URLClassPath.java:765) >>>>> at sun.misc.URLClassPath$3.run(URLClassPath.java:530) >>>>> at sun.misc.URLClassPath$3.run(URLClassPath.java:520) >>>>> at java.security.AccessController.doPrivileged(Native Method) >>>>> at sun.misc.URLClassPath.getLoader(URLClassPath.java:519) >>>>> at sun.misc.URLClassPath.getLoader(URLClassPath.java:492) >>>>> at sun.misc.URLClassPath.getNextLoader(URLClassPath.java:457) >>>>> at sun.misc.URLClassPath.access$100(URLClassPath.java:64) >>>>> at sun.misc.URLClassPath$1.next(URLClassPath.java:239) >>>>> at sun.misc.URLClassPath$1.hasMoreElements(URLClassPath.java:250) >>>>> at java.net.URLClassLoader$3$1.run(URLClassLoader.java:601) >>>>> at java.net.URLClassLoader$3$1.run(URLClassLoader.java:599) >>>>> at java.security.AccessController.doPrivileged(Native Method) >>>>> at java.net.URLClassLoader$3.next(URLClassLoader.java:598) >>>>> at java.net.URLClassLoader$3.hasMoreElements(URLClassLoader.java:623) >>>>> at sun.misc.CompoundEnumeration.next(CompoundEnumeration.java:45) >>>>> at >>>>> sun.misc.CompoundEnumeration.hasMoreElements(CompoundEnumeration.java:54) >>>>> at sun.misc.CompoundEnumeration.next(CompoundEnumeration.java:45) >>>>> at >>>>> sun.misc.CompoundEnumeration.hasMoreElements(CompoundEnumeration.java:54) >>>>> at >>>>> java.util.ServiceLoader$LazyIterator.hasNextService(ServiceLoader.java:354) >>>>> at >>>>> java.util.ServiceLoader$LazyIterator.hasNext(ServiceLoader.java:393) >>>>> at java.util.ServiceLoader$1.hasNext(ServiceLoader.java:474) >>>>> at java.nio.charset.Charset$1.getNext(Charset.java:350) >>>>> at java.nio.charset.Charset$1.hasNext(Charset.java:365) >>>>> at java.nio.charset.Charset$2.run(Charset.java:410) >>>>> at java.nio.charset.Charset$2.run(Charset.java:407) >>>>> at java.security.AccessController.doPrivileged(Native Method) >>>>> at java.nio.charset.Charset.lookupViaProviders(Charset.java:406) >>>>> at java.nio.charset.Charset.lookup2(Charset.java:477) >>>>> at java.nio.charset.Charset.lookup(Charset.java:464) >>>>> at java.nio.charset.Charset.isSupported(Charset.java:505) >>>>> at >>>>> sun.launcher.LauncherHelper.makePlatformString(LauncherHelper.java:580) >>>>> Caused by: java.util.EmptyStackException >>>>> at java.util.Stack.peek(Stack.java:102) >>>>> at >>>>> java.lang.ClassLoader$NativeLibrary.getFromClass(ClassLoader.java:1759) >>>>> at java.lang.ClassLoader$NativeLibrary.findBuiltinLib(Native Method) >>>>> at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1870) >>>>> at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1843) >>>>> at java.lang.Runtime.loadLibrary0(Runtime.java:870) >>>>> at java.lang.System.loadLibrary(System.java:1122) >>>>> at java.util.zip.ZipFile.(ZipFile.java:86) >>>>> ... 34 more >>>>> >>>>> It's obvious that the way jni_FindClass is looking for the class >>>>> context by calling the NativeLibrary::getFromClass method is hacky but >>>>> I think that the proposed fix is the quite simple and non-intrusive. >>>>> And we probably don't want a complete rework of this code for 8 >>>>> anyway. So why not fix it the proposed way in 8 and 9 for now? That >>>>> will still leave us time to come up with a better clean-up at least >>>>> for 9. >>>>> >>>>> What do you think? >>>>> >>>>> Regards, >>>>> Volker >>>>> >>>>> On Tue, Jun 9, 2015 at 1:35 AM, Mandy Chung >>>>> wrote: >>>>>> >>>>>> Hi Volker, >>>>>> >>>>>> Your patch reminds me the question I have about loading zip library. >>>>>> >>>>>> In JDK 9 (and earlier release), zip library is loaded by the VM during >>>>>> startup (see ClassLoader::load_zip_library). I think loadLibrary("zip") >>>>>> is >>>>>> no longer needed to be called from System::initializeSystemClass method >>>>>> and >>>>>> instead it can be loaded by java.util.zip.ZipFile static initializer. >>>>>> >>>>>> Do you mind to try the patch (below)? That may be a simpler fix. >>>>>> >>>>>> I never like the way jni_FindClass to look for the class context by >>>>>> calling >>>>>> the NativeLibrary::getFromClass method. I will have to look deeper other >>>>>> alternative to clean that up. If taking out loadLibrary("zip") resolves >>>>>> your issue, this will give us time to come up with a better clean-up in >>>>>> the >>>>>> future. >>>>>> >>>>>> Mandy >>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-4429040 >>>>>> >>>>>> diff --git a/src/share/classes/java/lang/System.java >>>>>> b/src/share/classes/java/lang/System.java >>>>>> --- a/src/share/classes/java/lang/System.java >>>>>> +++ b/src/share/classes/java/lang/System.java >>>>>> @@ -1192,10 +1192,6 @@ >>>>>> setOut0(newPrintStream(fdOut, >>>>>> props.getProperty("sun.stdout.encoding"))); >>>>>> setErr0(newPrintStream(fdErr, >>>>>> props.getProperty("sun.stderr.encoding"))); >>>>>> >>>>>> - // Load the zip library now in order to keep >>>>>> java.util.zip.ZipFile >>>>>> - // from trying to use itself to load this library later. >>>>>> - loadLibrary("zip"); >>>>>> - >>>>>> // Setup Java signal handlers for HUP, TERM, and INT (where >>>>>> available). >>>>>> Terminator.setup(); >>>>>> >>>>>> diff --git a/src/share/classes/java/util/zip/ZipFile.java >>>>>> b/src/share/classes/java/util/zip/ZipFile.java >>>>>> --- a/src/share/classes/java/util/zip/ZipFile.java >>>>>> +++ b/src/share/classes/java/util/zip/ZipFile.java >>>>>> @@ -83,6 +83,7 @@ >>>>>> >>>>>> static { >>>>>> /* Zip library is loaded from System.initializeSystemClass */ >>>>>> + System.loadLibrary("zip"); >>>>>> initIDs(); >>>>>> >>>>>> } >>>>>> >>>>>> >>>>>> >>>>>> On 06/08/2015 07:23 AM, Volker Simonis wrote: >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> can I please get a review at least for the part of this fix which is >>>>>>> common for jdk8 and jdk9. It's only a few lines in >>>>>>> src/share/vm/prims/jni.cpp for the hotspot repository and one line >>>>>>> src/java.base/share/classes/java/lang/ClassLoader.java for the jdk >>>>>>> repository. >>>>>>> >>>>>>> Thanks, >>>>>>> Volker >>>>>>> >>>>>>> >>>>>>> On Tue, Jun 2, 2015 at 6:12 PM, Volker Simonis >>>>>>> >>>>>>> wrote: >>>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> can I please have review (and a sponsor) for these changes: >>>>>>>> >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8081674 >>>>>>>> http://cr.openjdk.java.net/~simonis/webrevs/2015/8081674.jdk >>>>>>>> http://cr.openjdk.java.net/~simonis/webrevs/2015/8081674.hs >>>>>>>> >>>>>>>> Please notice that the fix requires synchronous changes in the jdk and >>>>>>>> the >>>>>>>> hotspot forest. >>>>>>>> >>>>>>>> The changes themselves are by far not that big as this explanation but >>>>>>>> I >>>>>>>> found the problem to be quite intricate so I tried to explain it as >>>>>>>> good >>>>>>>> as >>>>>>>> I could. I'd suggest to read the HTML-formatted explanation in the >>>>>>>> webrev >>>>>>>> although the content is equal to the one in this mail: >>>>>>>> >>>>>>>> Using an unsupported character encoding (e.g. vi_VN.TCVN on Linux) >>>>>>>> results >>>>>>>> in an immediate VM failure with jdk 8 and 9: >>>>>>>> >>>>>>>> export LANG=vi_VN.TCVN >>>>>>>> java -version >>>>>>>> Error occurred during initialization of VM >>>>>>>> java.util.EmptyStackException >>>>>>>> at java.util.Stack.peek(Stack.java:102) >>>>>>>> at >>>>>>>> java.lang.ClassLoader$NativeLibrary.getFromClass(ClassLoader.java:1751) >>>>>>>> at java.lang.ClassLoader$NativeLibrary.findBuiltinLib(Native >>>>>>>> Method) >>>>>>>> at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1862) >>>>>>>> at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1835) >>>>>>>> at java.lang.Runtime.loadLibrary0(Runtime.java:870) >>>>>>>> at java.lang.System.loadLibrary(System.java:1119) >>>>>>>> at java.lang.System.initializeSystemClass(System.java:1194) >>>>>>>> >>>>>>>> This is a consequence of "8005716: Enhance JNI specification to allow >>>>>>>> support of static JNI libraries in Embedded JREs". >>>>>>>> >>>>>>>> With jdk 9 we get this error even if we're running with a supported >>>>>>>> charset >>>>>>>> which is in the ExtendedCharsets (as opposed to being in the >>>>>>>> StandardCharsets) class which is a consequence of delegating the >>>>>>>> loading >>>>>>>> of >>>>>>>> the ExtendedCharsets class to the ServiceLoader in jdk 9. >>>>>>>> >>>>>>>> export LANG=eo.iso-8859-3 >>>>>>>> output-jdk9/images/jdk/bin/java -version >>>>>>>> Error occurred during initialization of VM >>>>>>>> java.util.EmptyStackException >>>>>>>> at java.util.Stack.peek(Stack.java:102) >>>>>>>> at >>>>>>>> java.lang.ClassLoader$NativeLibrary.getFromClass(ClassLoader.java:1737) >>>>>>>> at java.lang.ClassLoader$NativeLibrary.findBuiltinLib(Native >>>>>>>> Method) >>>>>>>> at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1866) >>>>>>>> at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1840) >>>>>>>> at java.lang.Runtime.loadLibrary0(Runtime.java:874) >>>>>>>> at java.lang.System.loadLibrary(System.java:1111) >>>>>>>> at java.lang.System.initializeSystemClass(System.java:1186) >>>>>>>> >>>>>>>> Here's why the exception happens for an unsupported charset (see the >>>>>>>> mixed >>>>>>>> stack trace below for the full details): >>>>>>>> >>>>>>>> java.lang.System.loadLibrary() wants to load libzip.so. It calls >>>>>>>> java.lang.Runtime.loadLibrary0() which at the very beginning calls the >>>>>>>> native method ClassLoader$NativeLibrary.findBuiltinLib() which checks >>>>>>>> if >>>>>>>> the >>>>>>>> corresponding library is already statically linked into the VM >>>>>>>> (introduced >>>>>>>> by 8005716). >>>>>>>> Java_java_lang_ClassLoader_00024NativeLibrary_findBuiltinLib(), >>>>>>>> the native implementation of findBuiltinLib() in Classloader.c calls >>>>>>>> GetStringPlatformChars() to convert the library name into the native >>>>>>>> platform encoding. GetStringPlatformChars() calls the helper function >>>>>>>> jnuEncodingSupported() to check if the platform encoding which is >>>>>>>> stored >>>>>>>> in >>>>>>>> the property "sun.jnu.encoding" is supported by Java. >>>>>>>> jnuEncodingSupported() >>>>>>>> is implemented as follows: >>>>>>>> >>>>>>>> static jboolean isJNUEncodingSupported = JNI_FALSE; >>>>>>>> static jboolean jnuEncodingSupported(JNIEnv *env) { >>>>>>>> jboolean exe; >>>>>>>> if (isJNUEncodingSupported == JNI_TRUE) { >>>>>>>> return JNI_TRUE; >>>>>>>> } >>>>>>>> isJNUEncodingSupported = (jboolean) JNU_CallStaticMethodByName ( >>>>>>>> env, &exe, >>>>>>>> "java/nio/charset/Charset", >>>>>>>> "isSupported", >>>>>>>> "(Ljava/lang/String;)Z", >>>>>>>> jnuEncoding).z; >>>>>>>> return isJNUEncodingSupported; >>>>>>>> } >>>>>>>> >>>>>>>> Once the function finds that the platform encoding is supported (by >>>>>>>> calling >>>>>>>> java.nio.charset.Charset.isSupported()) it caches this value and always >>>>>>>> returns it on following calls. However if the platform encoding is not >>>>>>>> supported, it ALWAYS calls java.nio.charset.Charset.isSupported() an >>>>>>>> every >>>>>>>> subsequent invocation. >>>>>>>> >>>>>>>> In order to call the Java method Charset.isSupported() (in >>>>>>>> JNU_CallStaticMethodByName() in file jni_util.c), we have to call >>>>>>>> jni_FindClass() to convert the symbolic class name >>>>>>>> "java.nio.charset.Charset" into a class reference. >>>>>>>> >>>>>>>> But unfortunately, jni_FindClass() (from jni.cpp in libjvm.so) has a >>>>>>>> special >>>>>>>> handling if called from java.lang.ClassLoader$NativeLibrary to ensure >>>>>>>> that >>>>>>>> JNI_OnLoad/JNI_OnUnload are executed in the correct class context: >>>>>>>> >>>>>>>> instanceKlassHandle k (THREAD, >>>>>>>> thread->security_get_caller_class(0)); >>>>>>>> if (k.not_null()) { >>>>>>>> loader = Handle(THREAD, k->class_loader()); >>>>>>>> // Special handling to make sure JNI_OnLoad and JNI_OnUnload are >>>>>>>> executed >>>>>>>> // in the correct class context. >>>>>>>> if (loader.is_null() && >>>>>>>> k->name() == >>>>>>>> vmSymbols::java_lang_ClassLoader_NativeLibrary()) { >>>>>>>> JavaValue result(T_OBJECT); >>>>>>>> JavaCalls::call_static(&result, k, >>>>>>>> vmSymbols::getFromClass_name(), >>>>>>>> >>>>>>>> vmSymbols::void_class_signature(), >>>>>>>> thread); >>>>>>>> if (HAS_PENDING_EXCEPTION) { >>>>>>>> Handle ex(thread, thread->pending_exception()); >>>>>>>> CLEAR_PENDING_EXCEPTION; >>>>>>>> THROW_HANDLE_0(ex); >>>>>>>> } >>>>>>>> >>>>>>>> So if that's the case and jni_FindClass() was reallycalled from >>>>>>>> ClassLoader$NativeLibrary, then jni_FindClass() calles >>>>>>>> ClassLoader$NativeLibrary().getFromClass() to find out the >>>>>>>> corresponding >>>>>>>> context class which is supposed to be saved there in a field of type >>>>>>>> java.util.Stack named "nativeLibraryContext": >>>>>>>> >>>>>>>> // Invoked in the VM to determine the context class in >>>>>>>> // JNI_Load/JNI_Unload >>>>>>>> static Class getFromClass() { >>>>>>>> return ClassLoader.nativeLibraryContext.peek().fromClass; >>>>>>>> } >>>>>>>> >>>>>>>> Unfortunately, "nativeLibraryContext" doesn't contain any entry at this >>>>>>>> point and the invocation of Stack.peek() will throw the exception shown >>>>>>>> before. In general, the "nativeLibraryContext" stack will be filled >>>>>>>> later >>>>>>>> on >>>>>>>> in Runtime.loadLibrary0() like this: >>>>>>>> >>>>>>>> NativeLibrary lib = new NativeLibrary(fromClass, name, isBuiltin); >>>>>>>> nativeLibraryContext.push(lib); >>>>>>>> try { >>>>>>>> lib.load(name, isBuiltin); >>>>>>>> } finally { >>>>>>>> nativeLibraryContext.pop(); >>>>>>>> } >>>>>>>> >>>>>>>> such that it always contains at least one element later when >>>>>>>> jni_FindClass() >>>>>>>> will be invoked. >>>>>>>> >>>>>>>> So in summary, the problem is that the implementors of 8005716 didn't >>>>>>>> took >>>>>>>> into account that calling ClassLoader$NativeLibrary.findBuiltinLib() >>>>>>>> may >>>>>>>> trigger a call to jni_FindClass() if we are running on a system with an >>>>>>>> unsupported character encoding. >>>>>>>> >>>>>>>> I'd suggest the following fix for this problem: >>>>>>>> >>>>>>>> Change ClassLoader$NativeLibrary().getFromClass() to return null if the >>>>>>>> stack is empty instead of throwing an exception: >>>>>>>> >>>>>>>> static Class getFromClass() { >>>>>>>> return ClassLoader.nativeLibraryContext.empty() ? >>>>>>>> null : ClassLoader.nativeLibraryContext.peek().fromClass; >>>>>>>> } >>>>>>>> >>>>>>>> Unfortunately this also requires a HotSpot change in jni_FindClass() in >>>>>>>> order to properly handle the new 'null' return value: >>>>>>>> >>>>>>>> if (k.not_null()) { >>>>>>>> loader = Handle(THREAD, k->class_loader()); >>>>>>>> // Special handling to make sure JNI_OnLoad and JNI_OnUnload are >>>>>>>> executed >>>>>>>> // in the correct class context. >>>>>>>> if (loader.is_null() && >>>>>>>> k->name() == >>>>>>>> vmSymbols::java_lang_ClassLoader_NativeLibrary()) { >>>>>>>> JavaValue result(T_OBJECT); >>>>>>>> JavaCalls::call_static(&result, k, >>>>>>>> vmSymbols::getFromClass_name(), >>>>>>>> >>>>>>>> vmSymbols::void_class_signature(), >>>>>>>> thread); >>>>>>>> if (HAS_PENDING_EXCEPTION) { >>>>>>>> Handle ex(thread, thread->pending_exception()); >>>>>>>> CLEAR_PENDING_EXCEPTION; >>>>>>>> THROW_HANDLE_0(ex); >>>>>>>> } >>>>>>>> oop mirror = (oop) result.get_jobject(); >>>>>>>> if (oopDesc::is_null(mirror)) { >>>>>>>> loader = Handle(THREAD, >>>>>>>> SystemDictionary::java_system_loader()); >>>>>>>> } else { >>>>>>>> loader = Handle(THREAD, >>>>>>>> >>>>>>>> >>>>>>>> InstanceKlass::cast(java_lang_Class::as_Klass(mirror))->class_loader()); >>>>>>>> protection_domain = Handle(THREAD, >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> InstanceKlass::cast(java_lang_Class::as_Klass(mirror))->protection_domain()); >>>>>>>> } >>>>>>>> } >>>>>>>> } else { >>>>>>>> // We call ClassLoader.getSystemClassLoader to obtain the system >>>>>>>> class >>>>>>>> loader. >>>>>>>> loader = Handle(THREAD, SystemDictionary::java_system_loader()); >>>>>>>> } >>>>>>>> >>>>>>>> These changes are sufficient to solve the problem in Java 8. >>>>>>>> Unfortunately, >>>>>>>> that's still not enough in Java 9 because there the loading of the >>>>>>>> extended >>>>>>>> charsets has been delegated to ServiceLoader. But ServiceLoader calls >>>>>>>> ClassLoader.getBootstrapResources() which calls >>>>>>>> sun.misc.Launcher.getBootstrapClassPath(). This leads to another >>>>>>>> problem >>>>>>>> during class initialization of sun.misc.Launcher if running on an >>>>>>>> unsupported locale. >>>>>>>> >>>>>>>> The first thing done in sun.misc.Launcher. is the >>>>>>>> initialisation >>>>>>>> of >>>>>>>> the bootstrap URLClassPath in the Launcher. However this initialisation >>>>>>>> will >>>>>>>> eventually call Charset.isSupported() and if we are running on an >>>>>>>> unsupported locale this will inevitably end in another recursive call >>>>>>>> to >>>>>>>> ServiceLoader. But as explained below, ServiceLoader will query the >>>>>>>> Launcher's bootstrap URLClassPath which will be still uninitialized at >>>>>>>> that >>>>>>>> point. >>>>>>>> >>>>>>>> So we'll have to additionally guard guard against this situation on JDK >>>>>>>> 9 >>>>>>>> like this: >>>>>>>> >>>>>>>> private static Charset lookupExtendedCharset(String charsetName) { >>>>>>>> if (!sun.misc.VM.isBooted() || // see >>>>>>>> lookupViaProviders() >>>>>>>> sun.misc.Launcher.getBootstrapClassPath() == null) >>>>>>>> return null; >>>>>>>> >>>>>>>> This fixes the crashes, but still at the price of not having the >>>>>>>> extended >>>>>>>> charsets available during initialization until >>>>>>>> Launcher.getBootstrapClassPath is set up properly. This may be still a >>>>>>>> problem if the jdk is installed in a directory which contains >>>>>>>> characters >>>>>>>> specific to an extended encoding or if we have such characters in the >>>>>>>> command line arguments. >>>>>>>> >>>>>>>> Thank you and best regards, >>>>>>>> Volker >>>>>>>> >>>>>>>> >>>>>>>> Mixed stack trace of the initial EmptyStackException for unsupported >>>>>>>> charsets described before: >>>>>>>> >>>>>>>> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, >>>>>>>> C=native >>>>>>>> code) >>>>>>>> j java.util.Stack.peek()Ljava/lang/Object;+1 >>>>>>>> j >>>>>>>> java.lang.ClassLoader$NativeLibrary.getFromClass()Ljava/lang/Class;+3 >>>>>>>> v ~StubRoutines::call_stub >>>>>>>> V [libjvm.so+0x9d279a] JavaCalls::call_helper(JavaValue*, >>>>>>>> methodHandle*, >>>>>>>> JavaCallArguments*, Thread*)+0x6b4 >>>>>>>> V [libjvm.so+0xcad591] os::os_exception_wrapper(void (*)(JavaValue*, >>>>>>>> methodHandle*, JavaCallArguments*, Thread*), JavaValue*, methodHandle*, >>>>>>>> JavaCallArguments*, Thread*)+0x45 >>>>>>>> V [libjvm.so+0x9d20cf] JavaCalls::call(JavaValue*, methodHandle, >>>>>>>> JavaCallArguments*, Thread*)+0x8b >>>>>>>> V [libjvm.so+0x9d1d3b] JavaCalls::call_static(JavaValue*, >>>>>>>> KlassHandle, >>>>>>>> Symbol*, Symbol*, JavaCallArguments*, Thread*)+0x139 >>>>>>>> V [libjvm.so+0x9d1e3f] JavaCalls::call_static(JavaValue*, >>>>>>>> KlassHandle, >>>>>>>> Symbol*, Symbol*, Thread*)+0x9d >>>>>>>> V [libjvm.so+0x9e6588] jni_FindClass+0x428 >>>>>>>> C [libjava.so+0x20208] JNU_CallStaticMethodByName+0xff >>>>>>>> C [libjava.so+0x21cae] jnuEncodingSupported+0x61 >>>>>>>> C [libjava.so+0x22125] JNU_GetStringPlatformChars+0x125 >>>>>>>> C [libjava.so+0xedcd] >>>>>>>> Java_java_lang_ClassLoader_00024NativeLibrary_findBuiltinLib+0x8b >>>>>>>> j >>>>>>>> >>>>>>>> >>>>>>>> java.lang.ClassLoader$NativeLibrary.findBuiltinLib(Ljava/lang/String;)Ljava/lang/String;+0 >>>>>>>> j >>>>>>>> java.lang.ClassLoader.loadLibrary0(Ljava/lang/Class;Ljava/io/File;)Z+4 >>>>>>>> j >>>>>>>> >>>>>>>> >>>>>>>> java.lang.ClassLoader.loadLibrary(Ljava/lang/Class;Ljava/lang/String;Z)V+228 >>>>>>>> j >>>>>>>> java.lang.Runtime.loadLibrary0(Ljava/lang/Class;Ljava/lang/String;)V+54 >>>>>>>> j java.lang.System.loadLibrary(Ljava/lang/String;)V+7 >>>>>>>> j java.lang.System.initializeSystemClass()V+113 >>>>>>>> v ~StubRoutines::call_stub >>>>>>>> V [libjvm.so+0x9d279a] JavaCalls::call_helper(JavaValue*, >>>>>>>> methodHandle*, >>>>>>>> JavaCallArguments*, Thread*)+0x6b4 >>>>>>>> V [libjvm.so+0xcad591] os::os_exception_wrapper(void (*)(JavaValue*, >>>>>>>> methodHandle*, JavaCallArguments*, Thread*), JavaValue*, methodHandle*, >>>>>>>> JavaCallArguments*, Thread*)+0x45 >>>>>>>> V [libjvm.so+0x9d20cf] JavaCalls::call(JavaValue*, methodHandle, >>>>>>>> JavaCallArguments*, Thread*)+0x8b >>>>>>>> V [libjvm.so+0x9d1d3b] JavaCalls::call_static(JavaValue*, >>>>>>>> KlassHandle, >>>>>>>> Symbol*, Symbol*, JavaCallArguments*, Thread*)+0x139 >>>>>>>> V [libjvm.so+0x9d1e3f] JavaCalls::call_static(JavaValue*, >>>>>>>> KlassHandle, >>>>>>>> Symbol*, Symbol*, Thread*)+0x9d >>>>>>>> V [libjvm.so+0xe3cceb] call_initializeSystemClass(Thread*)+0xb0 >>>>>>>> V [libjvm.so+0xe44444] >>>>>>>> Threads::initialize_java_lang_classes(JavaThread*, >>>>>>>> Thread*)+0x21a >>>>>>>> V [libjvm.so+0xe44b12] Threads::create_vm(JavaVMInitArgs*, >>>>>>>> bool*)+0x4a6 >>>>>>>> V [libjvm.so+0xa19bd7] JNI_CreateJavaVM+0xc7 >>>>>>>> C [libjli.so+0xa520] InitializeJVM+0x154 >>>>>>>> C [libjli.so+0x8024] JavaMain+0xcc >>>>>>>> >>>>>>>> >>>> >> From lois.foltan at oracle.com Wed Jun 10 20:07:30 2015 From: lois.foltan at oracle.com (Lois Foltan) Date: Wed, 10 Jun 2015 16:07:30 -0400 Subject: RFR(XXS): 8086073: Fix PrintStubCode for empty StubCodeGenerator. In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CFF2AD3@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CFEC7EA@DEWDFEMB12A.global.corp.sap> <55781C0B.1050102@oracle.com> <4295855A5C1DE049A61835A1887419CC2CFF2AD3@DEWDFEMB12A.global.corp.sap> Message-ID: <55789901.7020500@oracle.com> On 6/10/2015 11:01 AM, Lindenmaier, Goetz wrote: > Vladimir, Lois, thanks for the review! > > Could one of you please sponsor this? Iadded the Reviewed-by comment, > so you can take the change as-is. Sure, I would be happy to. I will let you know when it has been committed. Lois > > Thanks and best regards, > Goetz. > > -----Original Message----- > From: Lois Foltan [mailto:lois.foltan at oracle.com] > Sent: Mittwoch, 10. Juni 2015 13:14 > To: Lindenmaier, Goetz > Cc: HotSpot Developers > Subject: Re: RFR(XXS): 8086073: Fix PrintStubCode for empty StubCodeGenerator. > > Looks good. > Lois > > On 6/10/2015 2:46 AM, Lindenmaier, Goetz wrote: >> Hi, >> >> PrintStubCode runs into an assertion if a StubCodeGenerator that never generated >> a stub is deleted. This happens for ICacheStubGenerator on ppc, as we implement >> the flushing with inline assembly and don't generate a stub. >> >> The fix is to check for an empty list in the assertion. >> >> Please review and sponsor this tiny fix. >> http://cr.openjdk.java.net/~goetz/webrevs/8086073-PSC/webrev.01/ >> >> >> Best regards and thanks, >> Goetz. From volker.simonis at gmail.com Wed Jun 10 23:02:39 2015 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 11 Jun 2015 01:02:39 +0200 Subject: RFR(M): 8081674: EmptyStackException at startup if running with extended or unsupported charset In-Reply-To: <7B3C08CF-028E-4AD2-B7F8-C803F2BA3C7D@oracle.com> References: <557626AA.6010008@oracle.com> <55772A56.2030308@oracle.com> <7B3C08CF-028E-4AD2-B7F8-C803F2BA3C7D@oracle.com> Message-ID: On Wednesday, June 10, 2015, Mandy Chung wrote: > > > On Jun 10, 2015, at 9:23 AM, Volker Simonis > wrote: > > > > Hy Mandy, > > > > that's a real good proposal and it only requires changes in the jdk > > repository which makes it even more attractive. > > > > I've just checked and it does indeed solve the initial > > EmptyStackException problem in both jdk8 and jdk9. Here are the > > corresponding webrevs: > > > > http://cr.openjdk.java.net/~simonis/webrevs/2015/8081674.jdk8/ > > ClassLoader.java > It should have done that. Nit: > Can you move line 1693 to 1868 closer to loadLibrary0 (the caller of > findBuiltinLib)? > Also make it private. > > Same applies to jdk9. > > Sure, I'll do that. Otherwise looks good. No need to generate a webrev as long as you make the > change before the push. > > Thanks for the review! Regards, Volker > > http://cr.openjdk.java.net/~simonis/webrevs/2015/8081674.jdk9/ > > > > The only difference between 8 and 9 is the different location of the > > source files. > > Compared to your proposal I've only updated the copyright years where > > necessary and removed one comment in > > Java_java_lang_ClassLoader_findBuiltinLib() which seemed unnecessary > > to me now that findBuiltinLib() isn't located in NativeLibrary > > anymore. > > > > Thanks for taking it out. > > > On jdk9 we are now running in another problem which is caused by the > > fact that the extended charsets are now being loaded by ServiceLoader > > (I've detailed that already in the bug report). But I think we can > > leave the fix of that problem to another change as this seems to > > require some more reasoning (see Alan's comments in the bug report). > > Yes this is a harder problem that have to investigate further. > > > > > So are you OK now with pushing this change to jdk9 and requesting a > > downport to 8u-dev afterwards? > > > > Yes. Approved. > > Mandy > > > Thank you and best regards, > > Volker > > > > > > On Wed, Jun 10, 2015 at 5:14 PM, Mandy Chung > wrote: > >> Have you checked out this patch moving out findBuiltinLib from > NativeLibrary class? > >> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8081674/webrev.00/ > >> > >> Mandy > >> > >>> On Jun 10, 2015, at 12:34 AM, Volker Simonis > wrote: > >>> > >>> Mandy, the example/stacktrace I sent was with 8u. > >>> > >>> The problem isn't related to libzip, it is only the first library > >>> which gets loaded with System.loadLibrary(). > >>> > >>> The problem will occur with every library which gets loaded by > >>> System.loadLibrary() because > >>> java.lang.ClassLoader$NativeLibrary.findBuiltinLib() always calls > >>> jni_FindClass() if we're running on a unsupported locale. > >>> > >>> On Tue, Jun 9, 2015 at 8:03 PM, Mandy Chung > wrote: > >>>> Does my patch work fine on 8u? If it works fine, I prefer to get > that > >>>> simple fix in 8u and take the time to have a better fix in 9 (jdk9 is > still > >>>> under development and I have assumed that it's not a show stopper to > you. > >>>> Let me know if it blocks you). > >>>> > >>>> A question to Sherman - do we have adequate tests to verify the move > of > >>>> System.loadLibrary("zip") from system initialization to ZipFile > >>>> initialization for 8u? > >>>> > >>>> Mandy > >>>> > >>>> > >>>> On 06/09/2015 10:09 AM, Volker Simonis wrote: > >>>>> > >>>>> Hi Mandy, > >>>>> > >>>>> thanks for looking into this. > >>>>> Uunfortunately your fix only helps to fix "java -version" :( > >>>>> > >>>>> Running even a minimal HelloWorld will still fail with the following > >>>>> stack trace which is still caused by the same EmptyStackException: > >>>>> > >>>>> Error: A JNI error has occurred, please check your installation and > try > >>>>> again > >>>>> Exception in thread "main" java.lang.ExceptionInInitializerError > >>>>> at sun.misc.Unsafe.ensureClassInitialized(Native Method) > >>>>> at > >>>>> > sun.misc.SharedSecrets.getJavaUtilZipFileAccess(SharedSecrets.java:158) > >>>>> at sun.misc.URLClassPath$JarLoader.(URLClassPath.java:765) > >>>>> at sun.misc.URLClassPath$3.run(URLClassPath.java:530) > >>>>> at sun.misc.URLClassPath$3.run(URLClassPath.java:520) > >>>>> at java.security.AccessController.doPrivileged(Native Method) > >>>>> at sun.misc.URLClassPath.getLoader(URLClassPath.java:519) > >>>>> at sun.misc.URLClassPath.getLoader(URLClassPath.java:492) > >>>>> at sun.misc.URLClassPath.getNextLoader(URLClassPath.java:457) > >>>>> at sun.misc.URLClassPath.access$100(URLClassPath.java:64) > >>>>> at sun.misc.URLClassPath$1.next(URLClassPath.java:239) > >>>>> at sun.misc.URLClassPath$1.hasMoreElements(URLClassPath.java:250) > >>>>> at java.net.URLClassLoader$3$1.run(URLClassLoader.java:601) > >>>>> at java.net.URLClassLoader$3$1.run(URLClassLoader.java:599) > >>>>> at java.security.AccessController.doPrivileged(Native Method) > >>>>> at java.net.URLClassLoader$3.next(URLClassLoader.java:598) > >>>>> at > java.net.URLClassLoader$3.hasMoreElements(URLClassLoader.java:623) > >>>>> at sun.misc.CompoundEnumeration.next(CompoundEnumeration.java:45) > >>>>> at > >>>>> > sun.misc.CompoundEnumeration.hasMoreElements(CompoundEnumeration.java:54) > >>>>> at sun.misc.CompoundEnumeration.next(CompoundEnumeration.java:45) > >>>>> at > >>>>> > sun.misc.CompoundEnumeration.hasMoreElements(CompoundEnumeration.java:54) > >>>>> at > >>>>> > java.util.ServiceLoader$LazyIterator.hasNextService(ServiceLoader.java:354) > >>>>> at > >>>>> java.util.ServiceLoader$LazyIterator.hasNext(ServiceLoader.java:393) > >>>>> at java.util.ServiceLoader$1.hasNext(ServiceLoader.java:474) > >>>>> at java.nio.charset.Charset$1.getNext(Charset.java:350) > >>>>> at java.nio.charset.Charset$1.hasNext(Charset.java:365) > >>>>> at java.nio.charset.Charset$2.run(Charset.java:410) > >>>>> at java.nio.charset.Charset$2.run(Charset.java:407) > >>>>> at java.security.AccessController.doPrivileged(Native Method) > >>>>> at java.nio.charset.Charset.lookupViaProviders(Charset.java:406) > >>>>> at java.nio.charset.Charset.lookup2(Charset.java:477) > >>>>> at java.nio.charset.Charset.lookup(Charset.java:464) > >>>>> at java.nio.charset.Charset.isSupported(Charset.java:505) > >>>>> at > >>>>> > sun.launcher.LauncherHelper.makePlatformString(LauncherHelper.java:580) > >>>>> Caused by: java.util.EmptyStackException > >>>>> at java.util.Stack.peek(Stack.java:102) > >>>>> at > >>>>> > java.lang.ClassLoader$NativeLibrary.getFromClass(ClassLoader.java:1759) > >>>>> at java.lang.ClassLoader$NativeLibrary.findBuiltinLib(Native > Method) > >>>>> at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1870) > >>>>> at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1843) > >>>>> at java.lang.Runtime.loadLibrary0(Runtime.java:870) > >>>>> at java.lang.System.loadLibrary(System.java:1122) > >>>>> at java.util.zip.ZipFile.(ZipFile.java:86) > >>>>> ... 34 more > >>>>> > >>>>> It's obvious that the way jni_FindClass is looking for the class > >>>>> context by calling the NativeLibrary::getFromClass method is hacky > but > >>>>> I think that the proposed fix is the quite simple and non-intrusive. > >>>>> And we probably don't want a complete rework of this code for 8 > >>>>> anyway. So why not fix it the proposed way in 8 and 9 for now? That > >>>>> will still leave us time to come up with a better clean-up at least > >>>>> for 9. > >>>>> > >>>>> What do you think? > >>>>> > >>>>> Regards, > >>>>> Volker > >>>>> > >>>>> On Tue, Jun 9, 2015 at 1:35 AM, Mandy Chung > > >>>>> wrote: > >>>>>> > >>>>>> Hi Volker, > >>>>>> > >>>>>> Your patch reminds me the question I have about loading zip library. > >>>>>> > >>>>>> In JDK 9 (and earlier release), zip library is loaded by the VM > during > >>>>>> startup (see ClassLoader::load_zip_library). I think > loadLibrary("zip") > >>>>>> is > >>>>>> no longer needed to be called from System::initializeSystemClass > method > >>>>>> and > >>>>>> instead it can be loaded by java.util.zip.ZipFile static > initializer. > >>>>>> > >>>>>> Do you mind to try the patch (below)? That may be a simpler fix. > >>>>>> > >>>>>> I never like the way jni_FindClass to look for the class context by > >>>>>> calling > >>>>>> the NativeLibrary::getFromClass method. I will have to look deeper > other > >>>>>> alternative to clean that up. If taking out loadLibrary("zip") > resolves > >>>>>> your issue, this will give us time to come up with a better > clean-up in > >>>>>> the > >>>>>> future. > >>>>>> > >>>>>> Mandy > >>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-4429040 > >>>>>> > >>>>>> diff --git a/src/share/classes/java/lang/System.java > >>>>>> b/src/share/classes/java/lang/System.java > >>>>>> --- a/src/share/classes/java/lang/System.java > >>>>>> +++ b/src/share/classes/java/lang/System.java > >>>>>> @@ -1192,10 +1192,6 @@ > >>>>>> setOut0(newPrintStream(fdOut, > >>>>>> props.getProperty("sun.stdout.encoding"))); > >>>>>> setErr0(newPrintStream(fdErr, > >>>>>> props.getProperty("sun.stderr.encoding"))); > >>>>>> > >>>>>> - // Load the zip library now in order to keep > >>>>>> java.util.zip.ZipFile > >>>>>> - // from trying to use itself to load this library later. > >>>>>> - loadLibrary("zip"); > >>>>>> - > >>>>>> // Setup Java signal handlers for HUP, TERM, and INT (where > >>>>>> available). > >>>>>> Terminator.setup(); > >>>>>> > >>>>>> diff --git a/src/share/classes/java/util/zip/ZipFile.java > >>>>>> b/src/share/classes/java/util/zip/ZipFile.java > >>>>>> --- a/src/share/classes/java/util/zip/ZipFile.java > >>>>>> +++ b/src/share/classes/java/util/zip/ZipFile.java > >>>>>> @@ -83,6 +83,7 @@ > >>>>>> > >>>>>> static { > >>>>>> /* Zip library is loaded from System.initializeSystemClass > */ > >>>>>> + System.loadLibrary("zip"); > >>>>>> initIDs(); > >>>>>> > >>>>>> } > >>>>>> > >>>>>> > >>>>>> > >>>>>> On 06/08/2015 07:23 AM, Volker Simonis wrote: > >>>>>>> > >>>>>>> Hi, > >>>>>>> > >>>>>>> can I please get a review at least for the part of this fix which > is > >>>>>>> common for jdk8 and jdk9. It's only a few lines in > >>>>>>> src/share/vm/prims/jni.cpp for the hotspot repository and one line > >>>>>>> src/java.base/share/classes/java/lang/ClassLoader.java for the jdk > >>>>>>> repository. > >>>>>>> > >>>>>>> Thanks, > >>>>>>> Volker > >>>>>>> > >>>>>>> > >>>>>>> On Tue, Jun 2, 2015 at 6:12 PM, Volker Simonis > >>>>>>> > > >>>>>>> wrote: > >>>>>>>> > >>>>>>>> Hi, > >>>>>>>> > >>>>>>>> can I please have review (and a sponsor) for these changes: > >>>>>>>> > >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8081674 > >>>>>>>> http://cr.openjdk.java.net/~simonis/webrevs/2015/8081674.jdk > >>>>>>>> http://cr.openjdk.java.net/~simonis/webrevs/2015/8081674.hs > >>>>>>>> > >>>>>>>> Please notice that the fix requires synchronous changes in the > jdk and > >>>>>>>> the > >>>>>>>> hotspot forest. > >>>>>>>> > >>>>>>>> The changes themselves are by far not that big as this > explanation but > >>>>>>>> I > >>>>>>>> found the problem to be quite intricate so I tried to explain it > as > >>>>>>>> good > >>>>>>>> as > >>>>>>>> I could. I'd suggest to read the HTML-formatted explanation in the > >>>>>>>> webrev > >>>>>>>> although the content is equal to the one in this mail: > >>>>>>>> > >>>>>>>> Using an unsupported character encoding (e.g. vi_VN.TCVN on Linux) > >>>>>>>> results > >>>>>>>> in an immediate VM failure with jdk 8 and 9: > >>>>>>>> > >>>>>>>> export LANG=vi_VN.TCVN > >>>>>>>> java -version > >>>>>>>> Error occurred during initialization of VM > >>>>>>>> java.util.EmptyStackException > >>>>>>>> at java.util.Stack.peek(Stack.java:102) > >>>>>>>> at > >>>>>>>> > java.lang.ClassLoader$NativeLibrary.getFromClass(ClassLoader.java:1751) > >>>>>>>> at > java.lang.ClassLoader$NativeLibrary.findBuiltinLib(Native > >>>>>>>> Method) > >>>>>>>> at > java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1862) > >>>>>>>> at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1835) > >>>>>>>> at java.lang.Runtime.loadLibrary0(Runtime.java:870) > >>>>>>>> at java.lang.System.loadLibrary(System.java:1119) > >>>>>>>> at java.lang.System.initializeSystemClass(System.java:1194) > >>>>>>>> > >>>>>>>> This is a consequence of "8005716: Enhance JNI specification to > allow > >>>>>>>> support of static JNI libraries in Embedded JREs". > >>>>>>>> > >>>>>>>> With jdk 9 we get this error even if we're running with a > supported > >>>>>>>> charset > >>>>>>>> which is in the ExtendedCharsets (as opposed to being in the > >>>>>>>> StandardCharsets) class which is a consequence of delegating the > >>>>>>>> loading > >>>>>>>> of > >>>>>>>> the ExtendedCharsets class to the ServiceLoader in jdk 9. > >>>>>>>> > >>>>>>>> export LANG=eo.iso-8859-3 > >>>>>>>> output-jdk9/images/jdk/bin/java -version > >>>>>>>> Error occurred during initialization of VM > >>>>>>>> java.util.EmptyStackException > >>>>>>>> at java.util.Stack.peek(Stack.java:102) > >>>>>>>> at > >>>>>>>> > java.lang.ClassLoader$NativeLibrary.getFromClass(ClassLoader.java:1737) > >>>>>>>> at > java.lang.ClassLoader$NativeLibrary.findBuiltinLib(Native > >>>>>>>> Method) > >>>>>>>> at > java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1866) > >>>>>>>> at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1840) > >>>>>>>> at java.lang.Runtime.loadLibrary0(Runtime.java:874) > >>>>>>>> at java.lang.System.loadLibrary(System.java:1111) > >>>>>>>> at java.lang.System.initializeSystemClass(System.java:1186) > >>>>>>>> > >>>>>>>> Here's why the exception happens for an unsupported charset (see > the > >>>>>>>> mixed > >>>>>>>> stack trace below for the full details): > >>>>>>>> > >>>>>>>> java.lang.System.loadLibrary() wants to load libzip.so. It calls > >>>>>>>> java.lang.Runtime.loadLibrary0() which at the very beginning > calls the > >>>>>>>> native method ClassLoader$NativeLibrary.findBuiltinLib() which > checks > >>>>>>>> if > >>>>>>>> the > >>>>>>>> corresponding library is already statically linked into the VM > >>>>>>>> (introduced > >>>>>>>> by 8005716). > >>>>>>>> Java_java_lang_ClassLoader_00024NativeLibrary_findBuiltinLib(), > >>>>>>>> the native implementation of findBuiltinLib() in Classloader.c > calls > >>>>>>>> GetStringPlatformChars() to convert the library name into the > native > >>>>>>>> platform encoding. GetStringPlatformChars() calls the helper > function > >>>>>>>> jnuEncodingSupported() to check if the platform encoding which is > >>>>>>>> stored > >>>>>>>> in > >>>>>>>> the property "sun.jnu.encoding" is supported by Java. > >>>>>>>> jnuEncodingSupported() > >>>>>>>> is implemented as follows: > >>>>>>>> > >>>>>>>> static jboolean isJNUEncodingSupported = JNI_FALSE; > >>>>>>>> static jboolean jnuEncodingSupported(JNIEnv *env) { > >>>>>>>> jboolean exe; > >>>>>>>> if (isJNUEncodingSupported == JNI_TRUE) { > >>>>>>>> return JNI_TRUE; > >>>>>>>> } > >>>>>>>> isJNUEncodingSupported = (jboolean) > JNU_CallStaticMethodByName ( > >>>>>>>> env, &exe, > >>>>>>>> "java/nio/charset/Charset", > >>>>>>>> "isSupported", > >>>>>>>> "(Ljava/lang/String;)Z", > >>>>>>>> jnuEncoding).z; > >>>>>>>> return isJNUEncodingSupported; > >>>>>>>> } > >>>>>>>> > >>>>>>>> Once the function finds that the platform encoding is supported > (by > >>>>>>>> calling > >>>>>>>> java.nio.charset.Charset.isSupported()) it caches this value and > always > >>>>>>>> returns it on following calls. However if the platform encoding > is not > >>>>>>>> supported, it ALWAYS calls java.nio.charset.Charset.isSupported() > an > >>>>>>>> every > >>>>>>>> subsequent invocation. > >>>>>>>> > >>>>>>>> In order to call the Java method Charset.isSupported() (in > >>>>>>>> JNU_CallStaticMethodByName() in file jni_util.c), we have to call > >>>>>>>> jni_FindClass() to convert the symbolic class name > >>>>>>>> "java.nio.charset.Charset" into a class reference. > >>>>>>>> > >>>>>>>> But unfortunately, jni_FindClass() (from jni.cpp in libjvm.so) > has a > >>>>>>>> special > >>>>>>>> handling if called from java.lang.ClassLoader$NativeLibrary to > ensure > >>>>>>>> that > >>>>>>>> JNI_OnLoad/JNI_OnUnload are executed in the correct class context: > >>>>>>>> > >>>>>>>> instanceKlassHandle k (THREAD, > >>>>>>>> thread->security_get_caller_class(0)); > >>>>>>>> if (k.not_null()) { > >>>>>>>> loader = Handle(THREAD, k->class_loader()); > >>>>>>>> // Special handling to make sure JNI_OnLoad and JNI_OnUnload > are > >>>>>>>> executed > >>>>>>>> // in the correct class context. > >>>>>>>> if (loader.is_null() && > >>>>>>>> k->name() == > >>>>>>>> vmSymbols::java_lang_ClassLoader_NativeLibrary()) { > >>>>>>>> JavaValue result(T_OBJECT); > >>>>>>>> JavaCalls::call_static(&result, k, > >>>>>>>> > vmSymbols::getFromClass_name(), > >>>>>>>> > >>>>>>>> vmSymbols::void_class_signature(), > >>>>>>>> thread); > >>>>>>>> if (HAS_PENDING_EXCEPTION) { > >>>>>>>> Handle ex(thread, thread->pending_exception()); > >>>>>>>> CLEAR_PENDING_EXCEPTION; > >>>>>>>> THROW_HANDLE_0(ex); > >>>>>>>> } > >>>>>>>> > >>>>>>>> So if that's the case and jni_FindClass() was reallycalled from > >>>>>>>> ClassLoader$NativeLibrary, then jni_FindClass() calles > >>>>>>>> ClassLoader$NativeLibrary().getFromClass() to find out the > >>>>>>>> corresponding > >>>>>>>> context class which is supposed to be saved there in a field of > type > >>>>>>>> java.util.Stack named "nativeLibraryContext": > >>>>>>>> > >>>>>>>> // Invoked in the VM to determine the context class in > >>>>>>>> // JNI_Load/JNI_Unload > >>>>>>>> static Class getFromClass() { > >>>>>>>> return ClassLoader.nativeLibraryContext.peek().fromClass; > >>>>>>>> } > >>>>>>>> > >>>>>>>> Unfortunately, "nativeLibraryContext" doesn't contain any entry > at this > >>>>>>>> point and the invocation of Stack.peek() will throw the exception > shown > >>>>>>>> before. In general, the "nativeLibraryContext" stack will be > filled > >>>>>>>> later > >>>>>>>> on > >>>>>>>> in Runtime.loadLibrary0() like this: > >>>>>>>> > >>>>>>>> NativeLibrary lib = new NativeLibrary(fromClass, name, isBuiltin); > >>>>>>>> nativeLibraryContext.push(lib); > >>>>>>>> try { > >>>>>>>> lib.load(name, isBuiltin); > >>>>>>>> } finally { > >>>>>>>> nativeLibraryContext.pop(); > >>>>>>>> } > >>>>>>>> > >>>>>>>> such that it always contains at least one element later when > >>>>>>>> jni_FindClass() > >>>>>>>> will be invoked. > >>>>>>>> > >>>>>>>> So in summary, the problem is that the implementors of 8005716 > didn't > >>>>>>>> took > >>>>>>>> into account that calling > ClassLoader$NativeLibrary.findBuiltinLib() > >>>>>>>> may > >>>>>>>> trigger a call to jni_FindClass() if we are running on a system > with an > >>>>>>>> unsupported character encoding. > >>>>>>>> > >>>>>>>> I'd suggest the following fix for this problem: > >>>>>>>> > >>>>>>>> Change ClassLoader$NativeLibrary().getFromClass() to return null > if the > >>>>>>>> stack is empty instead of throwing an exception: > >>>>>>>> > >>>>>>>> static Class getFromClass() { > >>>>>>>> return ClassLoader.nativeLibraryContext.empty() ? > >>>>>>>> null : ClassLoader.nativeLibraryContext.peek().fromClass; > >>>>>>>> } > >>>>>>>> > >>>>>>>> Unfortunately this also requires a HotSpot change in > jni_FindClass() in > >>>>>>>> order to properly handle the new 'null' return value: > >>>>>>>> > >>>>>>>> if (k.not_null()) { > >>>>>>>> loader = Handle(THREAD, k->class_loader()); > >>>>>>>> // Special handling to make sure JNI_OnLoad and JNI_OnUnload > are > >>>>>>>> executed > >>>>>>>> // in the correct class context. > >>>>>>>> if (loader.is_null() && > >>>>>>>> k->name() == > >>>>>>>> vmSymbols::java_lang_ClassLoader_NativeLibrary()) { > >>>>>>>> JavaValue result(T_OBJECT); > >>>>>>>> JavaCalls::call_static(&result, k, > >>>>>>>> > vmSymbols::getFromClass_name(), > >>>>>>>> > >>>>>>>> vmSymbols::void_class_signature(), > >>>>>>>> thread); > >>>>>>>> if (HAS_PENDING_EXCEPTION) { > >>>>>>>> Handle ex(thread, thread->pending_exception()); > >>>>>>>> CLEAR_PENDING_EXCEPTION; > >>>>>>>> THROW_HANDLE_0(ex); > >>>>>>>> } > >>>>>>>> oop mirror = (oop) result.get_jobject(); > >>>>>>>> if (oopDesc::is_null(mirror)) { > >>>>>>>> loader = Handle(THREAD, > >>>>>>>> SystemDictionary::java_system_loader()); > >>>>>>>> } else { > >>>>>>>> loader = Handle(THREAD, > >>>>>>>> > >>>>>>>> > >>>>>>>> > InstanceKlass::cast(java_lang_Class::as_Klass(mirror))->class_loader()); > >>>>>>>> protection_domain = Handle(THREAD, > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > InstanceKlass::cast(java_lang_Class::as_Klass(mirror))->protection_domain()); > >>>>>>>> } > >>>>>>>> } > >>>>>>>> } else { > >>>>>>>> // We call ClassLoader.getSystemClassLoader to obtain the > system > >>>>>>>> class > >>>>>>>> loader. > >>>>>>>> loader = Handle(THREAD, > SystemDictionary::java_system_loader()); > >>>>>>>> } > >>>>>>>> > >>>>>>>> These changes are sufficient to solve the problem in Java 8. > >>>>>>>> Unfortunately, > >>>>>>>> that's still not enough in Java 9 because there the loading of the > >>>>>>>> extended > >>>>>>>> charsets has been delegated to ServiceLoader. But ServiceLoader > calls > >>>>>>>> ClassLoader.getBootstrapResources() which calls > >>>>>>>> sun.misc.Launcher.getBootstrapClassPath(). This leads to another > >>>>>>>> problem > >>>>>>>> during class initialization of sun.misc.Launcher if running on an > >>>>>>>> unsupported locale. > >>>>>>>> > >>>>>>>> The first thing done in sun.misc.Launcher. is the > >>>>>>>> initialisation > >>>>>>>> of > >>>>>>>> the bootstrap URLClassPath in the Launcher. However this > initialisation > >>>>>>>> will > >>>>>>>> eventually call Charset.isSupported() and if we are running on an > >>>>>>>> unsupported locale this will inevitably end in another recursive > call > >>>>>>>> to > >>>>>>>> ServiceLoader. But as explained below, ServiceLoader will query > the > >>>>>>>> Launcher's bootstrap URLClassPath which will be still > uninitialized at > >>>>>>>> that > >>>>>>>> point. > >>>>>>>> > >>>>>>>> So we'll have to additionally guard guard against this situation > on JDK > >>>>>>>> 9 > >>>>>>>> like this: > >>>>>>>> > >>>>>>>> private static Charset lookupExtendedCharset(String charsetName) { > >>>>>>>> if (!sun.misc.VM.isBooted() || // see > >>>>>>>> lookupViaProviders() > >>>>>>>> sun.misc.Launcher.getBootstrapClassPath() == null) > >>>>>>>> return null; > >>>>>>>> > >>>>>>>> This fixes the crashes, but still at the price of not having the > >>>>>>>> extended > >>>>>>>> charsets available during initialization until > >>>>>>>> Launcher.getBootstrapClassPath is set up properly. This may be > still a > >>>>>>>> problem if the jdk is installed in a directory which contains > >>>>>>>> characters > >>>>>>>> specific to an extended encoding or if we have such characters in > the > >>>>>>>> command line arguments. > >>>>>>>> > >>>>>>>> Thank you and best regards, > >>>>>>>> Volker > >>>>>>>> > >>>>>>>> > >>>>>>>> Mixed stack trace of the initial EmptyStackException for > unsupported > >>>>>>>> charsets described before: > >>>>>>>> > >>>>>>>> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, > >>>>>>>> C=native > >>>>>>>> code) > >>>>>>>> j java.util.Stack.peek()Ljava/lang/Object;+1 > >>>>>>>> j > >>>>>>>> > java.lang.ClassLoader$NativeLibrary.getFromClass()Ljava/lang/Class;+3 > >>>>>>>> v ~StubRoutines::call_stub > >>>>>>>> V [libjvm.so+0x9d279a] JavaCalls::call_helper(JavaValue*, > >>>>>>>> methodHandle*, > >>>>>>>> JavaCallArguments*, Thread*)+0x6b4 > >>>>>>>> V [libjvm.so+0xcad591] os::os_exception_wrapper(void > (*)(JavaValue*, > >>>>>>>> methodHandle*, JavaCallArguments*, Thread*), JavaValue*, > methodHandle*, > >>>>>>>> JavaCallArguments*, Thread*)+0x45 > >>>>>>>> V [libjvm.so+0x9d20cf] JavaCalls::call(JavaValue*, methodHandle, > >>>>>>>> JavaCallArguments*, Thread*)+0x8b > >>>>>>>> V [libjvm.so+0x9d1d3b] JavaCalls::call_static(JavaValue*, > >>>>>>>> KlassHandle, > >>>>>>>> Symbol*, Symbol*, JavaCallArguments*, Thread*)+0x139 > >>>>>>>> V [libjvm.so+0x9d1e3f] JavaCalls::call_static(JavaValue*, > >>>>>>>> KlassHandle, > >>>>>>>> Symbol*, Symbol*, Thread*)+0x9d > >>>>>>>> V [libjvm.so+0x9e6588] jni_FindClass+0x428 > >>>>>>>> C [libjava.so+0x20208] JNU_CallStaticMethodByName+0xff > >>>>>>>> C [libjava.so+0x21cae] jnuEncodingSupported+0x61 > >>>>>>>> C [libjava.so+0x22125] JNU_GetStringPlatformChars+0x125 > >>>>>>>> C [libjava.so+0xedcd] > >>>>>>>> Java_java_lang_ClassLoader_00024NativeLibrary_findBuiltinLib+0x8b > >>>>>>>> j > >>>>>>>> > >>>>>>>> > >>>>>>>> > java.lang.ClassLoader$NativeLibrary.findBuiltinLib(Ljava/lang/String;)Ljava/lang/String;+0 > >>>>>>>> j > >>>>>>>> > java.lang.ClassLoader.loadLibrary0(Ljava/lang/Class;Ljava/io/File;)Z+4 > >>>>>>>> j > >>>>>>>> > >>>>>>>> > >>>>>>>> > java.lang.ClassLoader.loadLibrary(Ljava/lang/Class;Ljava/lang/String;Z)V+228 > >>>>>>>> j > >>>>>>>> > java.lang.Runtime.loadLibrary0(Ljava/lang/Class;Ljava/lang/String;)V+54 > >>>>>>>> j java.lang.System.loadLibrary(Ljava/lang/String;)V+7 > >>>>>>>> j java.lang.System.initializeSystemClass()V+113 > >>>>>>>> v ~StubRoutines::call_stub > >>>>>>>> V [libjvm.so+0x9d279a] JavaCalls::call_helper(JavaValue*, > >>>>>>>> methodHandle*, > >>>>>>>> JavaCallArguments*, Thread*)+0x6b4 > >>>>>>>> V [libjvm.so+0xcad591] os::os_exception_wrapper(void > (*)(JavaValue*, > >>>>>>>> methodHandle*, JavaCallArguments*, Thread*), JavaValue*, > methodHandle*, > >>>>>>>> JavaCallArguments*, Thread*)+0x45 > >>>>>>>> V [libjvm.so+0x9d20cf] JavaCalls::call(JavaValue*, methodHandle, > >>>>>>>> JavaCallArguments*, Thread*)+0x8b > >>>>>>>> V [libjvm.so+0x9d1d3b] JavaCalls::call_static(JavaValue*, > >>>>>>>> KlassHandle, > >>>>>>>> Symbol*, Symbol*, JavaCallArguments*, Thread*)+0x139 > >>>>>>>> V [libjvm.so+0x9d1e3f] JavaCalls::call_static(JavaValue*, > >>>>>>>> KlassHandle, > >>>>>>>> Symbol*, Symbol*, Thread*)+0x9d > >>>>>>>> V [libjvm.so+0xe3cceb] call_initializeSystemClass(Thread*)+0xb0 > >>>>>>>> V [libjvm.so+0xe44444] > >>>>>>>> Threads::initialize_java_lang_classes(JavaThread*, > >>>>>>>> Thread*)+0x21a > >>>>>>>> V [libjvm.so+0xe44b12] Threads::create_vm(JavaVMInitArgs*, > >>>>>>>> bool*)+0x4a6 > >>>>>>>> V [libjvm.so+0xa19bd7] JNI_CreateJavaVM+0xc7 > >>>>>>>> C [libjli.so+0xa520] InitializeJVM+0x154 > >>>>>>>> C [libjli.so+0x8024] JavaMain+0xcc > >>>>>>>> > >>>>>>>> > >>>> > >> > > From david.holmes at oracle.com Thu Jun 11 04:52:53 2015 From: david.holmes at oracle.com (David Holmes) Date: Thu, 11 Jun 2015 14:52:53 +1000 Subject: RFR: JDK-8085822 JEP 223: New Version-String Scheme (initial integration) In-Reply-To: <557829DC.8000405@oracle.com> References: <5571AD18.7080701@oracle.com> <557625C8.5050200@oracle.com> <5576E633.9050503@oracle.com> <5576E81B.8050703@oracle.com> <5576EF94.3010500@oracle.com> <55780A33.1010302@oracle.com> <557829DC.8000405@oracle.com> Message-ID: <55791425.8070709@oracle.com> Hi Magnus, On 10/06/2015 10:13 PM, Magnus Ihse Bursie wrote: > On 2015-06-10 11:58, David Holmes wrote: >> Hi Magnus, >> >> Generally looks good - a few comments/queries below. > > In general, I believe most issues you found are valid. :-) However, as I > said before in this thread, I'd like to see them resolved in the needed > follow-up patches. The source code changes in Hotspot and JDK are > inadequate to fully implement JEP-223, so these areas will need to be > rewritten anyhow. Are you okay with resolving these issues later? Given this is going to a staging repo I'm okay with deferring things - I just have a concern whether such things may be overlooked given that the integration with the staging repo will not be undergoing a final review. I would prefer to see the Version.java.template doc comments corrected, even if the issue of whether to add and deprecate is deferred, but again as this is to a staging area I can let it slide for now. I saw the fix to hotspot/src/share/vm/runtime/vmStructs.cpp. Thanks, David >> >> On 9/06/2015 11:52 PM, Magnus Ihse Bursie wrote: >>> Here's an updated webrev, which fixes the typos that were pointed out by >>> reviewers: >>> http://cr.openjdk.java.net/~ihse/JDK-8085822-JEP-223-initial-patch/webrev.02/ >>> >> >> common/autoconf/version-numbers >> >> Shouldn't there be a DEFAULT_VERSION_XXX for each of the XXX parts of >> the version info? (Even if all zeroes presently.) > So that's a tricky one. :-& The question here is, I think, does it make > sense to update version-numbers when we do a security (9.0.1) or minor > (9.1.0) release? Looking historically, the version-numbers file have not > been changed for the 8u family. The only change was going from 8 to 9 > when creating the new jdk9 forest. That was what I based my decition to > only have the major number in the file. (The rest of the version string > is set by configure flags when building, in Oracle case by the RE team.) > > If it makes sense to put the minor/security/patch numbers here, I won't > oppose it, but I guess we have until the first such release to figure > out what's best, and that likely includes discussion with RE and > possibly other consumers in the community (RedHat etc). > >> >> --- >> >> Looking at hotspot changes I can't convince myself that the new >> streamlined "version" variables will capture things like "fastdebug". >> Will that filter through via configure variables? > > The "fastdebug" label has been handled as a less valued token in the > JEP-223 process. Right now there's no mention of it at all in the > version string proposal in the JEP. As I understand it, Iris is about to > propose an amendment which will just make fastdebug be a part of the OPT > string. I'm not entirely happy with that myself, but that's the way it's > decided. So wherever you can see the OPT string, you'll see the debug > level tag. > > Currently, however, that's not how it is implemented in this patch. > Since no decision was made on this (and it's still not formally > decided), I had to pick a route to go forward. The current patch will > instead put the "fastdebug" label as part of the PRE string (that's the > reason for the pre-base and pre-debuglevel arguments to configure). If > the planned changes goes into the JEP, this'll change to make the > debuglevel tag a part of the OPT string instead. > >> --- >> >> make/*/makefiles/vm.make >> >> Shouldn't the -DVERSION_XX=$(VERSION_XX) definitions be taken from the >> VERSION_CFLAGS in spec.gmk? (Or are you still allowing for a >> stand-alone hotspot build?) > The hotspot JEP-223 work initially made by Alejandro kept support for > stand-alone hotspot builds. I made additional changes on top of that, > which still tried to cater for stand-alone builds. At this very moment > I'm not sure if stand-alone hotspot builds are supposed to work or not, > but I've tried to not change the situation with this patch. > > There are two future changes coming down the pipe: One is the additional > JEP-223 work needed for Hotspot. I know Alejandro had plans for > redesigning the API between Hotspot and the JDK, so no JDK version > strings should be compiled into the JVM, but all of it extracted during > an API in runtime. That would make most (all?) of the makefile changes > in hotspot irrelevant. However, that implementation is not even started, > so it's needed for the time being. > > The second change is the build-infra hotspot makefile rewrite. When that > happens, stand-alone builds will definitely disappear, and if Hotspot > still needs make support for version strings, then the logical choice is > to use VERSION_CFLAGS. > > Ok? > >> >> --- >> >> hotspot/src/share/vm/prims/jvm.h >> jdk/src/java.base/share/native/include/jvm.h >> >> I think this comment is way out of date: >> >> /* Build number is available only for RE build (i.e. JDK_BUILD_NUMBER >> is set to bNN) >> * It will be zero for internal builds. >> */ >> >> and can be completely removed. Even if still true, mention of an "RE >> build" has no place in OpenJDK sources. > Yep, agree. Follow-up patch, right? > >> >> --- >> >> hotspot/src/share/vm/runtime/java.cpp >> >> I think a lot of the modified code is obsolete post Hotspot Express - >> which makes it hard to determine if the changes make sense. > Yep, agree. Follow-up patch, right? >> >> --- >> >> hotspot/src/share/vm/runtime/vmStructs.cpp >> >> Please fix the alignment (3 extra spaces on modified line): >> >> 1239 static_field(Abstract_VM_Version, _vm_minor_version, >> int) \ >> 1240 static_field(Abstract_VM_Version, >> _vm_security_version, int) \ > > I was about to say "follow-up patch", but ugly indentation really sucks > so I can fix this. Ok if I skip redoing the review for that? > >> >> --- >> >> hotspot/test/runtime/6981737/Test6981737.java >> >> This test is really only valid for the new version scheme now, so it >> should probably be rewritten - and in that case it really isn't >> testing 6981737 but should be replaced by a new test for the new >> version format. > Yep, agree. Follow-up patch, right? >> >> --- >> >> jdk/src/java.base/share/classes/sun/misc/Version.java.template >> >> This comment is nonsensical: >> >> /** >> ! * Returns the security version of the running JVM if it's 1.6 >> or newer >> * or any RE VM build. It will return 0 if it's an internal 1.5 or >> * 1.4.x build. >> * @since 1.6 >> */ >> >> as security version does not exist pre 9. Normally you should be >> adding a new method and deprecating the old one. The new one is @since 9. > Yep, agree. Follow-up patch, right? >> >> /** >> ! * Returns the security version of the running JDK. >> * @since 1.6 >> */ >> >> Ditto: @since 9 (but again old should be deprecated and new method added) >> >> 253 /** >> 254 * Returns the build number of the running JDK if it's a RE >> build >> 255 * It will return 0 if it's an internal build. >> >> As with jvm.h this seems obsolete commentary these days - not only RE >> builds define a build number. > Yep, agree. Follow-up patch, right? > > /Magnus > >> >> Thanks, >> David > From david.holmes at oracle.com Thu Jun 11 04:57:17 2015 From: david.holmes at oracle.com (David Holmes) Date: Thu, 11 Jun 2015 14:57:17 +1000 Subject: [8u60] Backport RFR: JDK-8078666 and JDK-8074312 In-Reply-To: <557817DB.2030806@oracle.com> References: <1433856445.3310.105.camel@redhat.com> <1433929956.3385.48.camel@redhat.com> <557817DB.2030806@oracle.com> Message-ID: <5579152D.2000401@oracle.com> On 10/06/2015 8:56 PM, Se?n Coffey wrote: > Hopefully, someone from the hotspot team can help out here. These fixes > can enter via the hotspot team forest (jdk8u/hs-dev) and don't need > approval since Alejandro looks after that I approve, and will sponsor these two simple backports. David ----- > Regards, > Sean. > > On 10/06/15 10:52, Severin Gehwolf wrote: >> Adding in jdk8u-dev. >> >> On Tue, 2015-06-09 at 15:27 +0200, Severin Gehwolf wrote: >>> Hi, >>> >>> Could I please get JDK-8078666 and JDK-8074312 backported to 8u60? I'd >>> need a sponsor for this. >>> >>> We've been using the JDK-8078666 fix for Fedora 22 on JDK8 for a while >>> now. Similarly, the fix for JDK-8074312 is now also required for Fedora >>> 21 and we've had this patch in use since March. >>> >>> "Enable hotspot builds on 4.x Linux kernels" >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8074312 >>> Webrev: >>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8074312/8-backport/ >>> Original review thread: >>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-March/017463.html >>> >>> JDK 9 fix applies cleanly modulo copyright changes. >>> >>> >>> "JVM fastdebug build compiled with GCC 5 asserts with "widen increases" >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8078666 >>> Original review thread: >>> http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2015-April/017759.html >>> >>> JDK 9 fix applies cleanly to 8u forest. >>> >>> Thanks, >>> Severin >>> >> >> > From david.holmes at oracle.com Thu Jun 11 05:45:53 2015 From: david.holmes at oracle.com (David Holmes) Date: Thu, 11 Jun 2015 15:45:53 +1000 Subject: RFR(XS) 8087120: [GCC5] java.lang.StackOverflowError on Zero JVM initialization on non x86 platforms In-Reply-To: <1433944161.3385.97.camel@redhat.com> References: <1433944161.3385.97.camel@redhat.com> Message-ID: <55792091.6090909@oracle.com> On 10/06/2015 11:49 PM, Severin Gehwolf wrote: > Hi, > > Could somebody please review this Zero only change? I'd also need a > sponsor who can push the change for me once reviewed. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8087120 > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8087120/webrev.01/ > > The issue is that Zero relies on undefined behaviour for getting the > current stack pointer by allocating a variable on the stack and > returning its address. With GCC 5 returning an address of a local > variable will always be 0, thus causing the issue. It worked fine with > older GCC versions, because they returned the actual address of the > variable. > > The fix is to use GCC's built-in function "__builtin_frame_address". > This also works on GCC 5. It's GCC specific, though. On the other hand, > I don't know if anybody builds Zero without GCC. An alternative would be > to use alloca, but that has strange semantics if the stack pointer > cannot be extended. Thoughts? The Zero folk will need to confirm if this gcc dependency is ok or whether it requires an ifdef - and they can also push directly to one of the hotspot repos. Is the built-in available across gcc 4.x releases? David > Thanks, > Severin > From erik.joelsson at oracle.com Thu Jun 11 06:58:41 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 11 Jun 2015 08:58:41 +0200 Subject: RFR: JDK-8085822 JEP 223: New Version-String Scheme (initial integration) In-Reply-To: <55783F49.6030906@oracle.com> References: <5571AD18.7080701@oracle.com> <557625C8.5050200@oracle.com> <55783F49.6030906@oracle.com> Message-ID: <557931A1.6030406@oracle.com> Looks good. /Erik On 2015-06-10 15:44, Magnus Ihse Bursie wrote: > On 2015-06-09 01:31, Daniel D. Daugherty wrote: >> > >> http://cr.openjdk.java.net/~ihse/JDK-8085822-JEP-223-initial-patch/webrev.01 >> >> >> General comment: Not all copyright years were updated. > > I realize I missed that part of the review. :-( > > I have now updated the copyright years. Here's a delta review: > > http://cr.openjdk.java.net/~ihse/JDK-8085822-JEP-223-initial-patch-delta-02/webrev.01/ > > > Here's the complete review once again: > > http://cr.openjdk.java.net/~ihse/JDK-8085822-JEP-223-initial-patch/webrev.03 > > > Hopefully this is now the final version to be pushed to verona, and > that any additional problems can be resolved with follow-up patches. > > /Magnus From Alan.Bateman at oracle.com Thu Jun 11 07:42:18 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 11 Jun 2015 08:42:18 +0100 Subject: RFR(M): 8081674: EmptyStackException at startup if running with extended or unsupported charset In-Reply-To: <7B3C08CF-028E-4AD2-B7F8-C803F2BA3C7D@oracle.com> References: <557626AA.6010008@oracle.com> <55772A56.2030308@oracle.com> <7B3C08CF-028E-4AD2-B7F8-C803F2BA3C7D@oracle.com> Message-ID: <55793BDA.8000204@oracle.com> On 10/06/2015 20:02, Mandy Chung wrote: > : > ClassLoader.java > It should have done that. Nit: > Can you move line 1693 to 1868 closer to loadLibrary0 (the caller of findBuiltinLib)? > Also make it private. > > Same applies to jdk9. > > Otherwise looks good. No need to generate a webrev as long as you make the change before the push. Looks good to me too (assuming these changes). > : > >> On jdk9 we are now running in another problem which is caused by the >> fact that the extended charsets are now being loaded by ServiceLoader >> (I've detailed that already in the bug report). But I think we can >> leave the fix of that problem to another change as this seems to >> require some more reasoning (see Alan's comments in the bug report). > Yes this is a harder problem that have to investigate further. > Right, the main issue here is that java.base must contain all charsets that are needed during start up / VM initialization. There is also no guarantee the jdk.charsets module will be linked into the run-time image. There are two scenarios that come from this. One is the LANG setting as we have here, the other is attempting to run with file.encoding set. The choice as to whether to fail gracefully or switch to UTF-8 might be different for these two scenarios, it just investigation and a proposal. -Alan From sgehwolf at redhat.com Thu Jun 11 07:49:42 2015 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 11 Jun 2015 09:49:42 +0200 Subject: [8u60] Backport RFR: JDK-8078666 and JDK-8074312 In-Reply-To: <5579152D.2000401@oracle.com> References: <1433856445.3310.105.camel@redhat.com> <1433929956.3385.48.camel@redhat.com> <557817DB.2030806@oracle.com> <5579152D.2000401@oracle.com> Message-ID: <1434008982.3325.8.camel@redhat.com> On Thu, 2015-06-11 at 14:57 +1000, David Holmes wrote: > On 10/06/2015 8:56 PM, Se?n Coffey wrote: > > Hopefully, someone from the hotspot team can help out here. These fixes > > can enter via the hotspot team forest (jdk8u/hs-dev) and don't need > > approval since Alejandro looks after that > > I approve, and will sponsor these two simple backports. Thanks, David! Cheers, Severin > David > ----- > > > Regards, > > Sean. > > > > On 10/06/15 10:52, Severin Gehwolf wrote: > >> Adding in jdk8u-dev. > >> > >> On Tue, 2015-06-09 at 15:27 +0200, Severin Gehwolf wrote: > >>> Hi, > >>> > >>> Could I please get JDK-8078666 and JDK-8074312 backported to 8u60? I'd > >>> need a sponsor for this. > >>> > >>> We've been using the JDK-8078666 fix for Fedora 22 on JDK8 for a while > >>> now. Similarly, the fix for JDK-8074312 is now also required for Fedora > >>> 21 and we've had this patch in use since March. > >>> > >>> "Enable hotspot builds on 4.x Linux kernels" > >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8074312 > >>> Webrev: > >>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8074312/8-backport/ > >>> Original review thread: > >>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-March/017463.html > >>> > >>> JDK 9 fix applies cleanly modulo copyright changes. > >>> > >>> > >>> "JVM fastdebug build compiled with GCC 5 asserts with "widen increases" > >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8078666 > >>> Original review thread: > >>> http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2015-April/017759.html > >>> > >>> JDK 9 fix applies cleanly to 8u forest. > >>> > >>> Thanks, > >>> Severin > >>> > >> > >> > > From sgehwolf at redhat.com Thu Jun 11 08:05:47 2015 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 11 Jun 2015 10:05:47 +0200 Subject: RFR(XS) 8087120: [GCC5] java.lang.StackOverflowError on Zero JVM initialization on non x86 platforms In-Reply-To: <55792091.6090909@oracle.com> References: <1433944161.3385.97.camel@redhat.com> <55792091.6090909@oracle.com> Message-ID: <1434009947.3325.18.camel@redhat.com> Hi David, On Thu, 2015-06-11 at 15:45 +1000, David Holmes wrote: > On 10/06/2015 11:49 PM, Severin Gehwolf wrote: > > Hi, > > > > Could somebody please review this Zero only change? I'd also need a > > sponsor who can push the change for me once reviewed. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8087120 > > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8087120/webrev.01/ > > > > The issue is that Zero relies on undefined behaviour for getting the > > current stack pointer by allocating a variable on the stack and > > returning its address. With GCC 5 returning an address of a local > > variable will always be 0, thus causing the issue. It worked fine with > > older GCC versions, because they returned the actual address of the > > variable. > > > > The fix is to use GCC's built-in function "__builtin_frame_address". > > This also works on GCC 5. It's GCC specific, though. On the other hand, > > I don't know if anybody builds Zero without GCC. An alternative would be > > to use alloca, but that has strange semantics if the stack pointer > > cannot be extended. Thoughts? > > The Zero folk will need to confirm if this gcc dependency is ok or > whether it requires an ifdef - and they can also push directly to one of > the hotspot repos. Speaking as the Zero maintainer, the GCC dependency is OK. I'd rather avoid the ifdef. Unfortunately, I am not a committer so cannot push it myself. I can ask Andrew Haley to push the fix for me once you're OK with it. > Is the built-in available across gcc 4.x releases? Looking at the oldest GCC manual I've found for the 4.x series it appears it's available since 4.0.4. A couple of examples: https://gcc.gnu.org/onlinedocs/gcc-4.0.4/gcc/Return-Address.html#Return-Address https://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Return-Address.html#Return-Address https://gcc.gnu.org/onlinedocs/gcc-4.5.4/gcc/Return-Address.html#Return-Address https://gcc.gnu.org/onlinedocs/gcc-4.9.2/gcc/Return-Address.html#Return-Address https://gcc.gnu.org/onlinedocs/gcc-5.1.0/gcc/Return-Address.html#Return-Address Thanks, Severin From goetz.lindenmaier at sap.com Thu Jun 11 09:02:59 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 11 Jun 2015 09:02:59 +0000 Subject: RFR(S): 8087183: Fix call to inline function is_oop in header debugInfo.hpp. Message-ID: <4295855A5C1DE049A61835A1887419CC2CFF2D12@DEWDFEMB12A.global.corp.sap> Hi, in debugInfo.hpp is_oop() is called. This is an inline function defined in oop.inline.hpp. As oop.inline.hpp is not included in debugInfo.hpp, and it should not be included there, this leads to compilation failures in the fastdebug build on aix. To fix this, I just move the function calling is_oop to debugInfo.cpp. In that file also the only call to that function is located, so that it still can be inlined. Please review this change. I please need a sponsor. http://cr.openjdk.java.net/~goetz/webrevs/8087183-is_oop/webrev-01/ Best regards, Goetz. From jesper.wilhelmsson at oracle.com Thu Jun 11 10:37:10 2015 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Thu, 11 Jun 2015 12:37:10 +0200 Subject: No push of hs-rt to jdk9/hs this week Message-ID: <557964D6.4070509@oracle.com> Hi, There is a regression, JDK-8087153 [1], in hs-rt that was found when analyzing the Tuesday nightlies yesterday. The causing change is most likely JDK-8054386. Investigation is ongoing and for now we hope to fix the bug rather than backing out the change. The current plan is to not push anything to main until this issue has been resolved. There are a few changes that came in before JDK-8054386: 8081219: hs_err improvement: Add event logging for class redefinition to the hs_err file 8080947: Add uint as a valid VM flag type 8081382: Make flags ParallelGCThreads and ConcGCThreads of type uint 7097567: G1: abstract and encapsulate collector phases and transitions between them We could push just these without messing with the mercurial history etc. Let me know asap if any of these are critical to get in this week. Thanks, /Jesper [1] https://bugs.openjdk.java.net/browse/JDK-8087153 From david.holmes at oracle.com Thu Jun 11 10:51:34 2015 From: david.holmes at oracle.com (David Holmes) Date: Thu, 11 Jun 2015 20:51:34 +1000 Subject: RFR(XS) 8087120: [GCC5] java.lang.StackOverflowError on Zero JVM initialization on non x86 platforms In-Reply-To: <1434009947.3325.18.camel@redhat.com> References: <1433944161.3385.97.camel@redhat.com> <55792091.6090909@oracle.com> <1434009947.3325.18.camel@redhat.com> Message-ID: <55796836.6010902@oracle.com> Hi Severin, On 11/06/2015 6:05 PM, Severin Gehwolf wrote: > Hi David, > > On Thu, 2015-06-11 at 15:45 +1000, David Holmes wrote: >> On 10/06/2015 11:49 PM, Severin Gehwolf wrote: >>> Hi, >>> >>> Could somebody please review this Zero only change? I'd also need a >>> sponsor who can push the change for me once reviewed. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8087120 >>> webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8087120/webrev.01/ >>> >>> The issue is that Zero relies on undefined behaviour for getting the >>> current stack pointer by allocating a variable on the stack and >>> returning its address. With GCC 5 returning an address of a local >>> variable will always be 0, thus causing the issue. It worked fine with >>> older GCC versions, because they returned the actual address of the >>> variable. >>> >>> The fix is to use GCC's built-in function "__builtin_frame_address". >>> This also works on GCC 5. It's GCC specific, though. On the other hand, >>> I don't know if anybody builds Zero without GCC. An alternative would be >>> to use alloca, but that has strange semantics if the stack pointer >>> cannot be extended. Thoughts? >> >> The Zero folk will need to confirm if this gcc dependency is ok or >> whether it requires an ifdef - and they can also push directly to one of >> the hotspot repos. > > Speaking as the Zero maintainer, the GCC dependency is OK. I'd rather > avoid the ifdef. Unfortunately, I am not a committer so cannot push it > myself. I can ask Andrew Haley to push the fix for me once you're OK > with it. It is zero specific so I am fine with it if you are. Thanks, David >> Is the built-in available across gcc 4.x releases? > > Looking at the oldest GCC manual I've found for the 4.x series it > appears it's available since 4.0.4. A couple of examples: > https://gcc.gnu.org/onlinedocs/gcc-4.0.4/gcc/Return-Address.html#Return-Address > https://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Return-Address.html#Return-Address > https://gcc.gnu.org/onlinedocs/gcc-4.5.4/gcc/Return-Address.html#Return-Address > https://gcc.gnu.org/onlinedocs/gcc-4.9.2/gcc/Return-Address.html#Return-Address > https://gcc.gnu.org/onlinedocs/gcc-5.1.0/gcc/Return-Address.html#Return-Address > > Thanks, > Severin > From erik.joelsson at oracle.com Thu Jun 11 10:53:33 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 11 Jun 2015 12:53:33 +0200 Subject: RFR: JDK-8087195: Support building hotspot with devkits on Macosx Message-ID: <557968AD.2040705@oracle.com> Hello, Please review this small makefile tweak. When using a devkit to build hotspot on Macosx, the dtrace command gets confused and tries to use the wrong preprocessor. I've fixed this by splitting out the running of the preprocessor to a separate call. I've verified by comparing the generated header files with and without the patch. Bug: https://bugs.openjdk.java.net/browse/JDK-8087195 Patch inline: diff -r 11af3990d56c make/bsd/makefiles/dtrace.make --- a/make/bsd/makefiles/dtrace.make +++ b/make/bsd/makefiles/dtrace.make @@ -263,14 +263,19 @@ $(DtraceOutDir): mkdir $(DtraceOutDir) +# When building using a devkit, dtrace cannot find the correct preprocessor so +# we run it explicitly before runing dtrace. $(DtraceOutDir)/hotspot.h: $(DTRACE_COMMON_SRCDIR)/hotspot.d | $(DtraceOutDir) - $(QUIETLY) $(DTRACE_PROG) $(DTRACE_OPTS) -C -I. -h -o $@ -s $(DTRACE_COMMON_SRCDIR)/hotspot.d + $(QUIETLY) $(CC) -E $(DTRACE_OPTS) -I. -x c $(DTRACE_COMMON_SRCDIR)/hotspot.d > $(DtraceOutDir)/hotspot.d + $(QUIETLY) $(DTRACE_PROG) -h -o $@ -s $(DtraceOutDir)/hotspot.d $(DtraceOutDir)/hotspot_jni.h: $(DTRACE_COMMON_SRCDIR)/hotspot_jni.d | $(DtraceOutDir) - $(QUIETLY) $(DTRACE_PROG) $(DTRACE_OPTS) -C -I. -h -o $@ -s $(DTRACE_COMMON_SRCDIR)/hotspot_jni.d + $(QUIETLY) $(CC) -E $(DTRACE_OPTS) -I. -x c $(DTRACE_COMMON_SRCDIR)/hotspot_jni.d > $(DtraceOutDir)/hotspot_jni.d + $(QUIETLY) $(DTRACE_PROG) -h -o $@ -s $(DtraceOutDir)/hotspot_jni.d $(DtraceOutDir)/hs_private.h: $(DTRACE_COMMON_SRCDIR)/hs_private.d | $(DtraceOutDir) - $(QUIETLY) $(DTRACE_PROG) $(DTRACE_OPTS) -C -I. -h -o $@ -s $(DTRACE_COMMON_SRCDIR)/hs_private.d + $(QUIETLY) $(CC) -E $(DTRACE_OPTS) -I. -x c $(DTRACE_COMMON_SRCDIR)/hs_private.d > $(DtraceOutDir)/hs_private.d + $(QUIETLY) $(DTRACE_PROG) -h -o $@ -s $(DtraceOutDir)/hs_private.d dtrace_gen_headers: $(DtraceOutDir)/hotspot.h $(DtraceOutDir)/hotspot_jni.h $(DtraceOutDir)/hs_private.h /Erik From magnus.ihse.bursie at oracle.com Thu Jun 11 12:14:59 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 11 Jun 2015 14:14:59 +0200 Subject: RFR: JDK-8085822 JEP 223: New Version-String Scheme (initial integration) In-Reply-To: <55791425.8070709@oracle.com> References: <5571AD18.7080701@oracle.com> <557625C8.5050200@oracle.com> <5576E633.9050503@oracle.com> <5576E81B.8050703@oracle.com> <5576EF94.3010500@oracle.com> <55780A33.1010302@oracle.com> <557829DC.8000405@oracle.com> <55791425.8070709@oracle.com> Message-ID: <55797BC3.9080202@oracle.com> On 2015-06-11 06:52, David Holmes wrote: > Hi Magnus, > > On 10/06/2015 10:13 PM, Magnus Ihse Bursie wrote: >> On 2015-06-10 11:58, David Holmes wrote: >>> Hi Magnus, >>> >>> Generally looks good - a few comments/queries below. >> >> In general, I believe most issues you found are valid. :-) However, as I >> said before in this thread, I'd like to see them resolved in the needed >> follow-up patches. The source code changes in Hotspot and JDK are >> inadequate to fully implement JEP-223, so these areas will need to be >> rewritten anyhow. Are you okay with resolving these issues later? > > Given this is going to a staging repo I'm okay with deferring things - > I just have a concern whether such things may be overlooked given that > the integration with the staging repo will not be undergoing a final > review. I agree completely with your concern. I have summarized the issues that were raised but not addressed during this review, and created JBS bugs, one per component. I will do my best to make sure that fixing them does not get lost from the Verona project agenda. The three bugs are: https://bugs.openjdk.java.net/browse/JDK-8087202 https://bugs.openjdk.java.net/browse/JDK-8087203 https://bugs.openjdk.java.net/browse/JDK-8087205 Here's the core content of them. If I have missed something, please add it to the bug reports: HOTSPOT: Alan Bateman: Will the update_version and special_update_version fields eventually be dropped from the jvm_version_info structure? The webrev shows a change to this comment in jvm.h: "Third, this file contains various I/O and network operations needed by the standard Java I/O and network APIs." I think this comment can be removed because those JVM_* functions were removed some time ago. Daniel D. Daugherty: General comment: It looks like support for the 'patch' value is not completely implemented through all the Makefiles. I didn't audit for this, but it's just my impression. hotspot/src/share/vm/runtime/java.cpp L661: void JDK_Version::fully_initialize( L662: uint8_t major, uint8_t minor, uint8_t security, uint8_t update) { L663: // This is only called when current is less than 1.6 and we've gotten Since you're ripping out vestigial version support, I think this function can go away since this is version 9 and newer. Don't really know for sure, but based on that comment... hotspot/src/share/vm/runtime/vm_version.cpp L84: void Abstract_VM_Version::initialize() { L85: // FIXME: Initialization can probably be removed now. I agree, but that would entail also removing the _initialized and the uses of it... Follow on bug fix? David Holmes: make/*/makefiles/vm.make Shouldn't the -DVERSION_XX=$(VERSION_XX) definitions be taken from the VERSION_CFLAGS in spec.gmk? (Or are you still allowing for a stand-alone hotspot build?) hotspot/src/share/vm/prims/jvm.h I think this comment is way out of date: /* Build number is available only for RE build (i.e. JDK_BUILD_NUMBER is set to bNN) * It will be zero for internal builds. */ and can be completely removed. Even if still true, mention of an "RE build" has no place in OpenJDK sources. hotspot/src/share/vm/runtime/java.cpp I think a lot of the modified code is obsolete post Hotspot Express - which makes it hard to determine if the changes make sense. hotspot/test/runtime/6981737/Test6981737.java This test is really only valid for the new version scheme now, so it should probably be rewritten - and in that case it really isn't testing 6981737 but should be replaced by a new test for the new version format. JDK: Alan Bateman: Version.java.template - the comment in jvmSecurityVersion() still talks about 1.6 and newer. Can this be replaced to just say that it returns the security version? Daniel D. Daugherty: jdk/src/java.base/share/classes/sun/misc/Version.java.template L149: * Returns the security version of the running JVM if it's 1.6 or newer This JavaDoc update is wrong, but it might not be important if sun.misc.Version class is going away. David Holmes: jdk/src/java.base/share/classes/sun/misc/Version.java.template This comment is nonsensical: /** ! * Returns the security version of the running JVM if it's 1.6 or newer * or any RE VM build. It will return 0 if it's an internal 1.5 or * 1.4.x build. * @since 1.6 */ as security version does not exist pre 9. Normally you should be adding a new method and deprecating the old one. The new one is @since 9. /** ! * Returns the security version of the running JDK. * @since 1.6 */ Ditto: @since 9 (but again old should be deprecated and new method added) 253 /** 254 * Returns the build number of the running JDK if it's a RE build 255 * It will return 0 if it's an internal build. As with jvm.h this seems obsolete commentary these days - not only RE builds define a build number. LANGTOOLS: Daniel D. Daugherty: langtools/src/java.compiler/share/classes/javax/lang/model/SourceVersion.java old L171: case "1.9": new L171: case "9": Should this logic support both versions? Will dropping "1.9" here prevent a pre-version changeset JVM from being dropped into a JDK for triage purposes? Granted we don't often triage 'javac' with different JVMs, but... Jan Lahoda: +1 on keeping both "1.9" and "9" here. javac can be used independently on the rest of JDK to some extent, so support for running it on older builds of JDK 9 seems reasonable to me. (I wonder if current JDK 9 javac should be prepared for the new version scheme in advance.) /Magnus > > I would prefer to see the Version.java.template doc comments > corrected, even if the issue of whether to add and deprecate is > deferred, but again as this is to a staging area I can let it slide > for now. > > I saw the fix to hotspot/src/share/vm/runtime/vmStructs.cpp. > > Thanks, > David > >>> >>> On 9/06/2015 11:52 PM, Magnus Ihse Bursie wrote: >>>> Here's an updated webrev, which fixes the typos that were pointed >>>> out by >>>> reviewers: >>>> http://cr.openjdk.java.net/~ihse/JDK-8085822-JEP-223-initial-patch/webrev.02/ >>>> >>>> >>> >>> common/autoconf/version-numbers >>> >>> Shouldn't there be a DEFAULT_VERSION_XXX for each of the XXX parts of >>> the version info? (Even if all zeroes presently.) >> So that's a tricky one. :-& The question here is, I think, does it make >> sense to update version-numbers when we do a security (9.0.1) or minor >> (9.1.0) release? Looking historically, the version-numbers file have not >> been changed for the 8u family. The only change was going from 8 to 9 >> when creating the new jdk9 forest. That was what I based my decition to >> only have the major number in the file. (The rest of the version string >> is set by configure flags when building, in Oracle case by the RE team.) >> >> If it makes sense to put the minor/security/patch numbers here, I won't >> oppose it, but I guess we have until the first such release to figure >> out what's best, and that likely includes discussion with RE and >> possibly other consumers in the community (RedHat etc). >> >>> >>> --- >>> >>> Looking at hotspot changes I can't convince myself that the new >>> streamlined "version" variables will capture things like "fastdebug". >>> Will that filter through via configure variables? >> >> The "fastdebug" label has been handled as a less valued token in the >> JEP-223 process. Right now there's no mention of it at all in the >> version string proposal in the JEP. As I understand it, Iris is about to >> propose an amendment which will just make fastdebug be a part of the OPT >> string. I'm not entirely happy with that myself, but that's the way it's >> decided. So wherever you can see the OPT string, you'll see the debug >> level tag. >> >> Currently, however, that's not how it is implemented in this patch. >> Since no decision was made on this (and it's still not formally >> decided), I had to pick a route to go forward. The current patch will >> instead put the "fastdebug" label as part of the PRE string (that's the >> reason for the pre-base and pre-debuglevel arguments to configure). If >> the planned changes goes into the JEP, this'll change to make the >> debuglevel tag a part of the OPT string instead. >> >>> --- >>> >>> make/*/makefiles/vm.make >>> >>> Shouldn't the -DVERSION_XX=$(VERSION_XX) definitions be taken from the >>> VERSION_CFLAGS in spec.gmk? (Or are you still allowing for a >>> stand-alone hotspot build?) >> The hotspot JEP-223 work initially made by Alejandro kept support for >> stand-alone hotspot builds. I made additional changes on top of that, >> which still tried to cater for stand-alone builds. At this very moment >> I'm not sure if stand-alone hotspot builds are supposed to work or not, >> but I've tried to not change the situation with this patch. >> >> There are two future changes coming down the pipe: One is the additional >> JEP-223 work needed for Hotspot. I know Alejandro had plans for >> redesigning the API between Hotspot and the JDK, so no JDK version >> strings should be compiled into the JVM, but all of it extracted during >> an API in runtime. That would make most (all?) of the makefile changes >> in hotspot irrelevant. However, that implementation is not even started, >> so it's needed for the time being. >> >> The second change is the build-infra hotspot makefile rewrite. When that >> happens, stand-alone builds will definitely disappear, and if Hotspot >> still needs make support for version strings, then the logical choice is >> to use VERSION_CFLAGS. >> >> Ok? >> >>> >>> --- >>> >>> hotspot/src/share/vm/prims/jvm.h >>> jdk/src/java.base/share/native/include/jvm.h >>> >>> I think this comment is way out of date: >>> >>> /* Build number is available only for RE build (i.e. JDK_BUILD_NUMBER >>> is set to bNN) >>> * It will be zero for internal builds. >>> */ >>> >>> and can be completely removed. Even if still true, mention of an "RE >>> build" has no place in OpenJDK sources. >> Yep, agree. Follow-up patch, right? >> >>> >>> --- >>> >>> hotspot/src/share/vm/runtime/java.cpp >>> >>> I think a lot of the modified code is obsolete post Hotspot Express - >>> which makes it hard to determine if the changes make sense. >> Yep, agree. Follow-up patch, right? >>> >>> --- >>> >>> hotspot/src/share/vm/runtime/vmStructs.cpp >>> >>> Please fix the alignment (3 extra spaces on modified line): >>> >>> 1239 static_field(Abstract_VM_Version, _vm_minor_version, >>> int) \ >>> 1240 static_field(Abstract_VM_Version, >>> _vm_security_version, int) \ >> >> I was about to say "follow-up patch", but ugly indentation really sucks >> so I can fix this. Ok if I skip redoing the review for that? >> >>> >>> --- >>> >>> hotspot/test/runtime/6981737/Test6981737.java >>> >>> This test is really only valid for the new version scheme now, so it >>> should probably be rewritten - and in that case it really isn't >>> testing 6981737 but should be replaced by a new test for the new >>> version format. >> Yep, agree. Follow-up patch, right? >>> >>> --- >>> >>> jdk/src/java.base/share/classes/sun/misc/Version.java.template >>> >>> This comment is nonsensical: >>> >>> /** >>> ! * Returns the security version of the running JVM if it's 1.6 >>> or newer >>> * or any RE VM build. It will return 0 if it's an internal >>> 1.5 or >>> * 1.4.x build. >>> * @since 1.6 >>> */ >>> >>> as security version does not exist pre 9. Normally you should be >>> adding a new method and deprecating the old one. The new one is >>> @since 9. >> Yep, agree. Follow-up patch, right? >>> >>> /** >>> ! * Returns the security version of the running JDK. >>> * @since 1.6 >>> */ >>> >>> Ditto: @since 9 (but again old should be deprecated and new method >>> added) >>> >>> 253 /** >>> 254 * Returns the build number of the running JDK if it's a RE >>> build >>> 255 * It will return 0 if it's an internal build. >>> >>> As with jvm.h this seems obsolete commentary these days - not only RE >>> builds define a build number. >> Yep, agree. Follow-up patch, right? >> >> /Magnus >> >>> >>> Thanks, >>> David >> From erik.joelsson at oracle.com Thu Jun 11 13:11:06 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 11 Jun 2015 15:11:06 +0200 Subject: RFR: JDK-8087195: Support building hotspot with devkits on Macosx In-Reply-To: <557968AD.2040705@oracle.com> References: <557968AD.2040705@oracle.com> Message-ID: <557988EA.1030705@oracle.com> Hello again, I missed cleaning the path correctly when testing this so missed another needed change. When calling "lipo", the hotspot makefiles should use the variable supplied by configure. Here is an updated patch. Webrev: http://cr.openjdk.java.net/~erikj/8087195/webrev.hotspot.01/ /Erik On 2015-06-11 12:53, Erik Joelsson wrote: > Hello, > > Please review this small makefile tweak. When using a devkit to build > hotspot on Macosx, the dtrace command gets confused and tries to use > the wrong preprocessor. I've fixed this by splitting out the running > of the preprocessor to a separate call. I've verified by comparing the > generated header files with and without the patch. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8087195 > Patch inline: > diff -r 11af3990d56c make/bsd/makefiles/dtrace.make > --- a/make/bsd/makefiles/dtrace.make > +++ b/make/bsd/makefiles/dtrace.make > @@ -263,14 +263,19 @@ > $(DtraceOutDir): > mkdir $(DtraceOutDir) > > +# When building using a devkit, dtrace cannot find the correct > preprocessor so > +# we run it explicitly before runing dtrace. > $(DtraceOutDir)/hotspot.h: $(DTRACE_COMMON_SRCDIR)/hotspot.d | > $(DtraceOutDir) > - $(QUIETLY) $(DTRACE_PROG) $(DTRACE_OPTS) -C -I. -h -o $@ -s > $(DTRACE_COMMON_SRCDIR)/hotspot.d > + $(QUIETLY) $(CC) -E $(DTRACE_OPTS) -I. -x c > $(DTRACE_COMMON_SRCDIR)/hotspot.d > $(DtraceOutDir)/hotspot.d > + $(QUIETLY) $(DTRACE_PROG) -h -o $@ -s $(DtraceOutDir)/hotspot.d > > $(DtraceOutDir)/hotspot_jni.h: $(DTRACE_COMMON_SRCDIR)/hotspot_jni.d > | $(DtraceOutDir) > - $(QUIETLY) $(DTRACE_PROG) $(DTRACE_OPTS) -C -I. -h -o $@ -s > $(DTRACE_COMMON_SRCDIR)/hotspot_jni.d > + $(QUIETLY) $(CC) -E $(DTRACE_OPTS) -I. -x c > $(DTRACE_COMMON_SRCDIR)/hotspot_jni.d > $(DtraceOutDir)/hotspot_jni.d > + $(QUIETLY) $(DTRACE_PROG) -h -o $@ -s $(DtraceOutDir)/hotspot_jni.d > > $(DtraceOutDir)/hs_private.h: $(DTRACE_COMMON_SRCDIR)/hs_private.d | > $(DtraceOutDir) > - $(QUIETLY) $(DTRACE_PROG) $(DTRACE_OPTS) -C -I. -h -o $@ -s > $(DTRACE_COMMON_SRCDIR)/hs_private.d > + $(QUIETLY) $(CC) -E $(DTRACE_OPTS) -I. -x c > $(DTRACE_COMMON_SRCDIR)/hs_private.d > $(DtraceOutDir)/hs_private.d > + $(QUIETLY) $(DTRACE_PROG) -h -o $@ -s $(DtraceOutDir)/hs_private.d > > dtrace_gen_headers: $(DtraceOutDir)/hotspot.h > $(DtraceOutDir)/hotspot_jni.h $(DtraceOutDir)/hs_private.h > > > /Erik From vitalyd at gmail.com Thu Jun 11 13:26:01 2015 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Thu, 11 Jun 2015 09:26:01 -0400 Subject: Dynamic G1 barrier elision for C2 in young In-Reply-To: References: Message-ID: Hi Erik, I think this is a neat idea. There's a class of java programs that don't trigger any GC while up (or very few GCs at specific points in time). Typically these are the same types of apps that pool objects on free lists, and thus incur write barrier overhead for no actual gain. FWIW, I'd welcome such elision but would also like to see it for the parallel collector :). Thanks sent from my phone On Jun 8, 2015 6:00 AM, "Erik ?sterlund" wrote: > Hi, > > Since this concerns compiler too, I decided to CC hotspot-dev. > > Thanks, > /Erik > > Den 06/06/15 02:44 skrev Erik ?sterlund : > > >Hi guys, > > > >Making G1 run faster on GC-tuned applications that are designed to only > >rarely spill objects into old, seems like an interesting and important > >optimization goal at the moment. > > > >Today I tried an interesting experiment. I sample garbage during the > >sweeping phase (phase 2) of System.gc() (G1MarkSweep) that stumbles > >through garbage anyway, hoping to find classes with instances that are > >used all the time, but /never/ make it into old. Then I deoptimize these > >classes and recompile the relevant nmethods depending on the class to > >elide the G1 write barriers (in C2). If the GC eventually needs to promote > >any of these objects to old, I just deoptimize again and recompile with G1 > >barriers turned back on. > > > >On some DaCapo benchmarks, it payed off very well for a few benchmarks > >that supposedly use many temporary objects: > >fop: -9.2% time <- this one was brutal!! > >xalan: -6.9% time > >jython: -5.9% time > > > >Results were measured with 40 warmup iterations, and then computed the > >average of the following 10 iterations, so 50 iterations in total. Class > >unloading was turned off (using my own patch to make -Xnoclassgc work, > >because it seems to be broken currently) and 512M heaps. > > > > > >The G1 barriers are already optimized to be faster for young objects, but > >if the GC finds out that certain types of objects /never/ get old, telling > >the compiler so allows complete elision of both the pre and post barriers > >from the code which is nice. > > > >Are we conceptually interested in such a solution, potentially accompanied > >with a flag like -XX:+G1DynamicallyOptimizeYoung? Thought I?d check if I > >can get some feedback before going too far with this. > > > >Here is the code I used. > > > >Patch 1: -Xnoclassgc > > > http://cr.openjdk.java.net/~eosterlund/g1_experiments/noclassgc/webrev.00/ > > > >This just fixes an issue that -Xnoclassgc doesn?t work properly using G1 > >(unfortunately I have yet to get the bug system work to report it...). > >With this JVM flag, it should not do class unloading. I had to run my > >experiments without class unloading because it killed the optimized > >nmethods of the almost always dead objects I want to optimize in DaCapo, > >because DaCapo does not retain their class loaders or something. > > > >Patch 2: Dynamic G1 barrier elision > > > http://cr.openjdk.java.net/~eosterlund/g1_experiments/dynamic_barrier_elis > >i > >on/webrev.00/ > > > >This is where the interesting stuff went if anyone is interested. This is > >just a very basic prototype/concept to check if the approach seems > >interesting to you guys. You probably want to add stuff like deoptimizing > >less (only if there are fields to actually optimize/deoptimize - keep > >track of that more accurately), and to sample garbage outside of > >System.gc() - this was just a convenience for now, and being more accurate > >with which class declared a field, not the canonical class, etc. > > > >Any comments are welcome. > > > >Thanks, > >/Erik > > > > > > From sgehwolf at redhat.com Thu Jun 11 13:31:27 2015 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 11 Jun 2015 15:31:27 +0200 Subject: RFR(XS) 8087120: [GCC5] java.lang.StackOverflowError on Zero JVM initialization on non x86 platforms In-Reply-To: <55796836.6010902@oracle.com> References: <1433944161.3385.97.camel@redhat.com> <55792091.6090909@oracle.com> <1434009947.3325.18.camel@redhat.com> <55796836.6010902@oracle.com> Message-ID: <1434029487.3325.71.camel@redhat.com> On Thu, 2015-06-11 at 20:51 +1000, David Holmes wrote: > Hi Severin, > > On 11/06/2015 6:05 PM, Severin Gehwolf wrote: > > Hi David, > > > > On Thu, 2015-06-11 at 15:45 +1000, David Holmes wrote: > >> On 10/06/2015 11:49 PM, Severin Gehwolf wrote: > >>> Hi, > >>> > >>> Could somebody please review this Zero only change? I'd also need a > >>> sponsor who can push the change for me once reviewed. > >>> > >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8087120 > >>> webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8087120/webrev.01/ > >>> > >>> The issue is that Zero relies on undefined behaviour for getting the > >>> current stack pointer by allocating a variable on the stack and > >>> returning its address. With GCC 5 returning an address of a local > >>> variable will always be 0, thus causing the issue. It worked fine with > >>> older GCC versions, because they returned the actual address of the > >>> variable. > >>> > >>> The fix is to use GCC's built-in function "__builtin_frame_address". > >>> This also works on GCC 5. It's GCC specific, though. On the other hand, > >>> I don't know if anybody builds Zero without GCC. An alternative would be > >>> to use alloca, but that has strange semantics if the stack pointer > >>> cannot be extended. Thoughts? > >> > >> The Zero folk will need to confirm if this gcc dependency is ok or > >> whether it requires an ifdef - and they can also push directly to one of > >> the hotspot repos. > > > > Speaking as the Zero maintainer, the GCC dependency is OK. I'd rather > > avoid the ifdef. Unfortunately, I am not a committer so cannot push it > > myself. I can ask Andrew Haley to push the fix for me once you're OK > > with it. > > It is zero specific so I am fine with it if you are. Thanks, David! Cheers, Severin > Thanks, > David > > >> Is the built-in available across gcc 4.x releases? > > > > Looking at the oldest GCC manual I've found for the 4.x series it > > appears it's available since 4.0.4. A couple of examples: > > https://gcc.gnu.org/onlinedocs/gcc-4.0.4/gcc/Return-Address.html#Return-Address > > https://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Return-Address.html#Return-Address > > https://gcc.gnu.org/onlinedocs/gcc-4.5.4/gcc/Return-Address.html#Return-Address > > https://gcc.gnu.org/onlinedocs/gcc-4.9.2/gcc/Return-Address.html#Return-Address > > https://gcc.gnu.org/onlinedocs/gcc-5.1.0/gcc/Return-Address.html#Return-Address > > > > Thanks, > > Severin > > From vladimir.kozlov at oracle.com Thu Jun 11 15:29:45 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 11 Jun 2015 08:29:45 -0700 Subject: RFR(S): 8087183: Fix call to inline function is_oop in header debugInfo.hpp. In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CFF2D12@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CFF2D12@DEWDFEMB12A.global.corp.sap> Message-ID: <5579A969.9000101@oracle.com> Looks good. Thanks, Vladimir On 6/11/15 2:02 AM, Lindenmaier, Goetz wrote: > Hi, > > in debugInfo.hpp is_oop() is called. This is an inline function defined in oop.inline.hpp. > As oop.inline.hpp is not included in debugInfo.hpp, and it should not be included there, > this leads to compilation failures in the fastdebug build on aix. > > To fix this, I just move the function calling is_oop to debugInfo.cpp. In that file also the > only call to that function is located, so that it still can be inlined. > > Please review this change. I please need a sponsor. > http://cr.openjdk.java.net/~goetz/webrevs/8087183-is_oop/webrev-01/ > > Best regards, > Goetz. > From volker.simonis at gmail.com Thu Jun 11 16:11:44 2015 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 11 Jun 2015 18:11:44 +0200 Subject: RFR(M): 8081674: EmptyStackException at startup if running with extended or unsupported charset In-Reply-To: <55793BDA.8000204@oracle.com> References: <557626AA.6010008@oracle.com> <55772A56.2030308@oracle.com> <7B3C08CF-028E-4AD2-B7F8-C803F2BA3C7D@oracle.com> <55793BDA.8000204@oracle.com> Message-ID: On Thu, Jun 11, 2015 at 9:42 AM, Alan Bateman wrote: > > On 10/06/2015 20:02, Mandy Chung wrote: >> >> : >> ClassLoader.java >> It should have done that. Nit: >> Can you move line 1693 to 1868 closer to loadLibrary0 (the caller of >> findBuiltinLib)? >> Also make it private. >> >> Same applies to jdk9. >> >> Otherwise looks good. No need to generate a webrev as long as you make >> the change before the push. > > Looks good to me too (assuming these changes). > Thanks! >> : >> >>> On jdk9 we are now running in another problem which is caused by the >>> fact that the extended charsets are now being loaded by ServiceLoader >>> (I've detailed that already in the bug report). But I think we can >>> leave the fix of that problem to another change as this seems to >>> require some more reasoning (see Alan's comments in the bug report). >> >> Yes this is a harder problem that have to investigate further. >> > Right, the main issue here is that java.base must contain all charsets that > are needed during start up / VM initialization. There is also no guarantee > the jdk.charsets module will be linked into the run-time image. > > There are two scenarios that come from this. One is the LANG setting as we > have here, the other is attempting to run with file.encoding set. The choice > as to whether to fail gracefully or switch to UTF-8 might be different for > these two scenarios, it just investigation and a proposal. > I'd vote for falling back to either UTF-8 or ISO-8859-1 and issuing a warning. Failing gracefully maybe difficult as we're in the middle of the initialization so throwing an exception is probably the best we can do (which I wouldn't consider "gracefully"). Regards, Volker > -Alan From aph at redhat.com Thu Jun 11 16:17:53 2015 From: aph at redhat.com (Andrew Haley) Date: Thu, 11 Jun 2015 17:17:53 +0100 Subject: hs-comp: VM is not exiting Message-ID: <5579B4B1.70805@redhat.com> I'm building a clean hs-comp, and I find that the VM does not exit when a Timer is scheduled. The VM seems to be deadlocked. import java.util.Timer; import java.util.TimerTask; public class TimerTest { static volatile boolean finished = true; static Timer timer = new Timer(); public static void main(String[] args) { TimerTask t = new TimerTask() { public void run() { finished = true; } }; timer.schedule(t, 1000); throw new RuntimeException(); } } Is this a known bug? Thanks, Andrew. From vladimir.kozlov at oracle.com Thu Jun 11 16:49:39 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 11 Jun 2015 09:49:39 -0700 Subject: hs-comp: VM is not exiting In-Reply-To: <5579B4B1.70805@redhat.com> References: <5579B4B1.70805@redhat.com> Message-ID: <5579BC23.1060405@oracle.com> Interesting. I tested jdk7,8,9 - all behave the same (ran with -Xint). It hangs on some kind of synchronization: ----------------- lwp# 42 / thread# 42 -------------------- fffffd7fff0abbca lwp_cond_wait (681248, 681230, 0, 0) fffffd7c166d288f __1cCosNPlatformEventEpark6M_v_ () + 7b fffffd7c166a4080 __1cNObjectMonitorEwait6MlbpnGThread__v_ () + 36c fffffd7c1686a540 __1cSObjectSynchronizerEwait6FnGHandle_lpnGThread__v_ () + f8 fffffd7c1633f098 JVM_MonitorWait () + 214 fffffd7fe1214ceb * java/lang/Object.wait(J)V+0 fffffd7fe12072e0 * java/lang/Object.wait()V+2 (line 1004) fffffd7fe12072e0 * java/util/TimerThread.mainLoop()V+28 (line 1049) fffffd7fe12072e0 * java/util/TimerThread.run()V+1 (line 1010) fffffd7fe120050b * java/util/TimerThread.run()V+19912 (line 1029) Vladimir On 6/11/15 9:17 AM, Andrew Haley wrote: > I'm building a clean hs-comp, and I find that the VM does not exit > when a Timer is scheduled. The VM seems to be deadlocked. > > import java.util.Timer; > import java.util.TimerTask; > > public class TimerTest { > > static volatile boolean finished = true; > static Timer timer = new Timer(); > > public static void main(String[] args) { > TimerTask t = new TimerTask() { > public void run() { > finished = true; > } > }; > timer.schedule(t, 1000); > throw new RuntimeException(); > } > } > > Is this a known bug? > > Thanks, > Andrew. > From vladimir.kozlov at oracle.com Thu Jun 11 17:04:20 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 11 Jun 2015 10:04:20 -0700 Subject: Change submitted with wrong bugId. In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CFF2D2A@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CFF2D2A@DEWDFEMB12A.global.corp.sap> Message-ID: <5579BF94.9060706@oracle.com> First, we should let people know about this. (I don't know client-lib mailing list). Fortunately 8075505 is AWT backport bug which was fixed already. 8075505 will not appear in changeset since we use main bug id in backport changesets. So we don't need to blacklist it for jcheck. I updated 8075506 to resolved state with linked changeset. Please, add comment there about bug id. Regards, Vladimir On 6/11/15 2:11 AM, Lindenmaier, Goetz wrote: > Hi Vladimir, > > I just figured I have an open bug where I already have submitted the > corresponding > > webrev: https://bugs.openjdk.java.net/browse/JDK-8075506 > > This is because the bugID in the change is wrong, and thus the wrong bug > was closed. > > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/1c471be03faf > > I can?t figure what went wrong, as the webrev is fine: > > http://cr.openjdk.java.net/~goetz/webrevs/8075506-aixMem/webrev.00/ > > Probably I messed up the change when editing the reviewers. > > Unfortunately, https://bugs.openjdk.java.net/browse/JDK-8075505 > > is a closed bug, so I can?t tell whether an important issue was lost. > > What can I do about this? Could you open 8075505 under a new bugID? > > Should I make 8075506 a duplicate of 8075505 and close it? > > Sorry for the trouble and best regards, > > Goetz. > From aph at redhat.com Thu Jun 11 17:07:07 2015 From: aph at redhat.com (Andrew Haley) Date: Thu, 11 Jun 2015 18:07:07 +0100 Subject: hs-comp: VM is not exiting In-Reply-To: <5579BC23.1060405@oracle.com> References: <5579B4B1.70805@redhat.com> <5579BC23.1060405@oracle.com> Message-ID: <5579C03B.4070804@redhat.com> On 06/11/2015 05:49 PM, Vladimir Kozlov wrote: > Interesting. I tested jdk7,8,9 - all behave the same (ran with -Xint). > It hangs on some kind of synchronization: I think the VM is waiting for the number of non-daemon threads to drop to 1, but it never does. Andrew. From vitalyd at gmail.com Thu Jun 11 17:11:15 2015 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Thu, 11 Jun 2015 13:11:15 -0400 Subject: hs-comp: VM is not exiting In-Reply-To: <5579C03B.4070804@redhat.com> References: <5579B4B1.70805@redhat.com> <5579BC23.1060405@oracle.com> <5579C03B.4070804@redhat.com> Message-ID: The OS is waiting. This class is fairly bad, and should be avoided because the internal thread is (a) non-daemon and (b) cannot be interrupted (it swallows IE and continues). Javadoc calls this out: After the last live reference to a Timer object goes away and all outstanding tasks have completed execution, the timer's task execution thread terminates gracefully (and becomes subject to garbage collection). However, this can take arbitrarily long to occur. By default, the task execution thread does not run as a daemon thread, so it is capable of keeping an application from terminating. If a caller wants to terminate a timer's task execution thread rapidly, the caller should invoke the timer's cancel method. On Thu, Jun 11, 2015 at 1:07 PM, Andrew Haley wrote: > On 06/11/2015 05:49 PM, Vladimir Kozlov wrote: > > Interesting. I tested jdk7,8,9 - all behave the same (ran with -Xint). > > It hangs on some kind of synchronization: > > I think the VM is waiting for the number of non-daemon threads to drop to > 1, > but it never does. > > Andrew. > > From aph at redhat.com Thu Jun 11 17:12:51 2015 From: aph at redhat.com (Andrew Haley) Date: Thu, 11 Jun 2015 18:12:51 +0100 Subject: hs-comp: VM is not exiting In-Reply-To: References: <5579B4B1.70805@redhat.com> <5579BC23.1060405@oracle.com> <5579C03B.4070804@redhat.com> Message-ID: <5579C193.207@redhat.com> On 06/11/2015 06:11 PM, Vitaly Davidovich wrote: > The OS is waiting. > > This class is fairly bad, and should be avoided because the internal thread > is (a) non-daemon and (b) cannot be interrupted (it swallows IE and > continues). Javadoc calls this out: > > After the last live reference to a Timer object goes away and all > outstanding tasks have completed execution, the timer's task execution > thread terminates gracefully (and becomes subject to garbage collection). > However, this can take arbitrarily long to occur. By default, the task > execution thread does not run as a daemon thread, so it is capable of > keeping an application from terminating. If a caller wants to terminate a > timer's task execution thread rapidly, the caller should invoke the timer's > cancel method. But the Timer should time out after 1 second... Andrew. From kim.barrett at oracle.com Thu Jun 11 17:17:25 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 11 Jun 2015 13:17:25 -0400 Subject: RFR(S): 8087183: Fix call to inline function is_oop in header debugInfo.hpp. In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CFF2D12@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CFF2D12@DEWDFEMB12A.global.corp.sap> Message-ID: <7F5177CC-2BC8-4D24-8E12-EE44DC40F445@oracle.com> On Jun 11, 2015, at 5:02 AM, Lindenmaier, Goetz wrote: > > Hi, > > in debugInfo.hpp is_oop() is called. This is an inline function defined in oop.inline.hpp. > As oop.inline.hpp is not included in debugInfo.hpp, and it should not be included there, > this leads to compilation failures in the fastdebug build on aix. > > To fix this, I just move the function calling is_oop to debugInfo.cpp. In that file also the > only call to that function is located, so that it still can be inlined. > > Please review this change. I please need a sponsor. > http://cr.openjdk.java.net/~goetz/webrevs/8087183-is_oop/webrev-01/ > > Best regards, > Goetz. Looks good. I?m mildly surprised this doesn?t run into problems on other platforms. The assert could use oop->is_oop_or_null(), though it makes no difference for this problem. From vitalyd at gmail.com Thu Jun 11 17:22:23 2015 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Thu, 11 Jun 2015 13:22:23 -0400 Subject: hs-comp: VM is not exiting In-Reply-To: <5579C193.207@redhat.com> References: <5579B4B1.70805@redhat.com> <5579BC23.1060405@oracle.com> <5579C03B.4070804@redhat.com> <5579C193.207@redhat.com> Message-ID: Yes, that's true. There's an object with a finalizer that sets a flag indicating no more submissions are allowed, and wakes up the timer thread. This Timer is static, so what's the implication of GC+finalization here? On Thu, Jun 11, 2015 at 1:12 PM, Andrew Haley wrote: > On 06/11/2015 06:11 PM, Vitaly Davidovich wrote: > > The OS is waiting. > > > > This class is fairly bad, and should be avoided because the internal > thread > > is (a) non-daemon and (b) cannot be interrupted (it swallows IE and > > continues). Javadoc calls this out: > > > > After the last live reference to a Timer object goes away and all > > outstanding tasks have completed execution, the timer's task execution > > thread terminates gracefully (and becomes subject to garbage collection). > > However, this can take arbitrarily long to occur. By default, the task > > execution thread does not run as a daemon thread, so it is capable of > > keeping an application from terminating. If a caller wants to terminate a > > timer's task execution thread rapidly, the caller should invoke the > timer's > > cancel method. > > But the Timer should time out after 1 second... > > Andrew. > > From anthony.scarpino at oracle.com Thu Jun 11 18:01:50 2015 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Thu, 11 Jun 2015 11:01:50 -0700 Subject: RFR: 8073108: GHASH Intrinsics In-Reply-To: <54E25D03.7090705@oracle.com> References: <54E25D03.7090705@oracle.com> Message-ID: <5579CD0E.2070801@oracle.com> Now that JEP 246 is targeted, I can proceed a with the GHASH changes I had reviewed back in February. There are two changes from the previous review. One is the separate method for the range checking in jdk:GHASH.java in update(). The other is disabing UseGHASHIntrinsics for arch64 in hotspot. http://cr.openjdk.java.net/~ascarpino/8073108/hotspot/webrev.03/ http://cr.openjdk.java.net/~ascarpino/8073108/jdk/webrev.03/ thanks Tony From david.holmes at oracle.com Fri Jun 12 01:26:18 2015 From: david.holmes at oracle.com (David Holmes) Date: Fri, 12 Jun 2015 11:26:18 +1000 Subject: Change submitted with wrong bugId. In-Reply-To: <5579BF94.9060706@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CFF2D2A@DEWDFEMB12A.global.corp.sap> <5579BF94.9060706@oracle.com> Message-ID: <557A353A.9010200@oracle.com> Including awt-dev. David On 12/06/2015 3:04 AM, Vladimir Kozlov wrote: > First, we should let people know about this. (I don't know client-lib > mailing list). > > Fortunately 8075505 is AWT backport bug which was fixed already. 8075505 > will not appear in changeset since we use main bug id in backport > changesets. So we don't need to blacklist it for jcheck. > > I updated 8075506 to resolved state with linked changeset. > Please, add comment there about bug id. > > Regards, > Vladimir > > On 6/11/15 2:11 AM, Lindenmaier, Goetz wrote: >> Hi Vladimir, >> >> I just figured I have an open bug where I already have submitted the >> corresponding >> >> webrev: https://bugs.openjdk.java.net/browse/JDK-8075506 >> >> This is because the bugID in the change is wrong, and thus the wrong bug >> was closed. >> >> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/1c471be03faf >> >> I can?t figure what went wrong, as the webrev is fine: >> >> http://cr.openjdk.java.net/~goetz/webrevs/8075506-aixMem/webrev.00/ >> >> Probably I messed up the change when editing the reviewers. >> >> Unfortunately, https://bugs.openjdk.java.net/browse/JDK-8075505 >> >> is a closed bug, so I can?t tell whether an important issue was lost. >> >> What can I do about this? Could you open 8075505 under a new bugID? >> >> Should I make 8075506 a duplicate of 8075505 and close it? >> >> Sorry for the trouble and best regards, >> >> Goetz. >> From david.holmes at oracle.com Fri Jun 12 01:37:18 2015 From: david.holmes at oracle.com (David Holmes) Date: Fri, 12 Jun 2015 11:37:18 +1000 Subject: hs-comp: VM is not exiting In-Reply-To: <5579C193.207@redhat.com> References: <5579B4B1.70805@redhat.com> <5579BC23.1060405@oracle.com> <5579C03B.4070804@redhat.com> <5579C193.207@redhat.com> Message-ID: <557A37CE.1020007@oracle.com> On 12/06/2015 3:12 AM, Andrew Haley wrote: > On 06/11/2015 06:11 PM, Vitaly Davidovich wrote: >> The OS is waiting. >> >> This class is fairly bad, and should be avoided because the internal thread >> is (a) non-daemon and (b) cannot be interrupted (it swallows IE and >> continues). Javadoc calls this out: >> >> After the last live reference to a Timer object goes away and all >> outstanding tasks have completed execution, the timer's task execution >> thread terminates gracefully (and becomes subject to garbage collection). >> However, this can take arbitrarily long to occur. By default, the task >> execution thread does not run as a daemon thread, so it is capable of >> keeping an application from terminating. If a caller wants to terminate a >> timer's task execution thread rapidly, the caller should invoke the timer's >> cancel method. > > But the Timer should time out after 1 second... The timer fires as expected, but the VM won't terminate unless the timer is cancelled: import java.util.Timer; import java.util.TimerTask; public class TimerTest { static volatile boolean finished = true; static Timer timer = new Timer(); static boolean cancel = false; public static void main(String[] args) { if (args.length >0) cancel = true; TimerTask t = new TimerTask() { public void run() { finished = true; System.out.println("Timer fired"); if (cancel) timer.cancel(); } }; timer.schedule(t, 1000); } } > java TimerTest Timer fired ^C > java TimerTest cancel Timer fired > David ----- > Andrew. > From david.holmes at oracle.com Fri Jun 12 02:06:58 2015 From: david.holmes at oracle.com (David Holmes) Date: Fri, 12 Jun 2015 12:06:58 +1000 Subject: RFR(S): 8087183: Fix call to inline function is_oop in header debugInfo.hpp. In-Reply-To: <7F5177CC-2BC8-4D24-8E12-EE44DC40F445@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CFF2D12@DEWDFEMB12A.global.corp.sap> <7F5177CC-2BC8-4D24-8E12-EE44DC40F445@oracle.com> Message-ID: <557A3EC2.1080300@oracle.com> On 12/06/2015 3:17 AM, Kim Barrett wrote: > On Jun 11, 2015, at 5:02 AM, Lindenmaier, Goetz wrote: >> >> Hi, >> >> in debugInfo.hpp is_oop() is called. This is an inline function defined in oop.inline.hpp. >> As oop.inline.hpp is not included in debugInfo.hpp, and it should not be included there, >> this leads to compilation failures in the fastdebug build on aix. >> >> To fix this, I just move the function calling is_oop to debugInfo.cpp. In that file also the >> only call to that function is located, so that it still can be inlined. >> >> Please review this change. I please need a sponsor. >> http://cr.openjdk.java.net/~goetz/webrevs/8087183-is_oop/webrev-01/ >> >> Best regards, >> Goetz. > > Looks good. > > I?m mildly surprised this doesn?t run into problems on other platforms. Me too. My first thought was precompiled headers, but this code has been in place for a couple of years - so why is it now a problem ?? David > The assert could use oop->is_oop_or_null(), though it makes no difference for this problem. > From david.holmes at oracle.com Fri Jun 12 02:20:04 2015 From: david.holmes at oracle.com (David Holmes) Date: Fri, 12 Jun 2015 12:20:04 +1000 Subject: RFR: JDK-8087195: Support building hotspot with devkits on Macosx In-Reply-To: <557988EA.1030705@oracle.com> References: <557968AD.2040705@oracle.com> <557988EA.1030705@oracle.com> Message-ID: <557A41D4.8040300@oracle.com> Hi Erik, On 11/06/2015 11:11 PM, Erik Joelsson wrote: > Hello again, > > I missed cleaning the path correctly when testing this so missed another > needed change. When calling "lipo", the hotspot makefiles should use the > variable supplied by configure. Here is an updated patch. > > Webrev: http://cr.openjdk.java.net/~erikj/8087195/webrev.hotspot.01/ Typo: + # we run it explicitly before runing dtrace. runing -> running Looks okay, only question I have is whether the preprocessed .d files should be placed into DtraceOutDir or some tmp location? I'm not sure where the contents of DtraceOutDir end up. Thanks, David > /Erik > > On 2015-06-11 12:53, Erik Joelsson wrote: >> Hello, >> >> Please review this small makefile tweak. When using a devkit to build >> hotspot on Macosx, the dtrace command gets confused and tries to use >> the wrong preprocessor. I've fixed this by splitting out the running >> of the preprocessor to a separate call. I've verified by comparing the >> generated header files with and without the patch. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8087195 >> Patch inline: >> diff -r 11af3990d56c make/bsd/makefiles/dtrace.make >> --- a/make/bsd/makefiles/dtrace.make >> +++ b/make/bsd/makefiles/dtrace.make >> @@ -263,14 +263,19 @@ >> $(DtraceOutDir): >> mkdir $(DtraceOutDir) >> >> +# When building using a devkit, dtrace cannot find the correct >> preprocessor so >> +# we run it explicitly before runing dtrace. >> $(DtraceOutDir)/hotspot.h: $(DTRACE_COMMON_SRCDIR)/hotspot.d | >> $(DtraceOutDir) >> - $(QUIETLY) $(DTRACE_PROG) $(DTRACE_OPTS) -C -I. -h -o $@ -s >> $(DTRACE_COMMON_SRCDIR)/hotspot.d >> + $(QUIETLY) $(CC) -E $(DTRACE_OPTS) -I. -x c >> $(DTRACE_COMMON_SRCDIR)/hotspot.d > $(DtraceOutDir)/hotspot.d >> + $(QUIETLY) $(DTRACE_PROG) -h -o $@ -s $(DtraceOutDir)/hotspot.d >> >> $(DtraceOutDir)/hotspot_jni.h: $(DTRACE_COMMON_SRCDIR)/hotspot_jni.d >> | $(DtraceOutDir) >> - $(QUIETLY) $(DTRACE_PROG) $(DTRACE_OPTS) -C -I. -h -o $@ -s >> $(DTRACE_COMMON_SRCDIR)/hotspot_jni.d >> + $(QUIETLY) $(CC) -E $(DTRACE_OPTS) -I. -x c >> $(DTRACE_COMMON_SRCDIR)/hotspot_jni.d > $(DtraceOutDir)/hotspot_jni.d >> + $(QUIETLY) $(DTRACE_PROG) -h -o $@ -s $(DtraceOutDir)/hotspot_jni.d >> >> $(DtraceOutDir)/hs_private.h: $(DTRACE_COMMON_SRCDIR)/hs_private.d | >> $(DtraceOutDir) >> - $(QUIETLY) $(DTRACE_PROG) $(DTRACE_OPTS) -C -I. -h -o $@ -s >> $(DTRACE_COMMON_SRCDIR)/hs_private.d >> + $(QUIETLY) $(CC) -E $(DTRACE_OPTS) -I. -x c >> $(DTRACE_COMMON_SRCDIR)/hs_private.d > $(DtraceOutDir)/hs_private.d >> + $(QUIETLY) $(DTRACE_PROG) -h -o $@ -s $(DtraceOutDir)/hs_private.d >> >> dtrace_gen_headers: $(DtraceOutDir)/hotspot.h >> $(DtraceOutDir)/hotspot_jni.h $(DtraceOutDir)/hs_private.h >> >> >> /Erik > From erik.joelsson at oracle.com Fri Jun 12 06:35:25 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 12 Jun 2015 08:35:25 +0200 Subject: RFR: JDK-8087195: Support building hotspot with devkits on Macosx In-Reply-To: <557A41D4.8040300@oracle.com> References: <557968AD.2040705@oracle.com> <557988EA.1030705@oracle.com> <557A41D4.8040300@oracle.com> Message-ID: <557A7DAD.3020304@oracle.com> Hello David, On 2015-06-12 04:20, David Holmes wrote: > Hi Erik, > > On 11/06/2015 11:11 PM, Erik Joelsson wrote: >> Hello again, >> >> I missed cleaning the path correctly when testing this so missed another >> needed change. When calling "lipo", the hotspot makefiles should use the >> variable supplied by configure. Here is an updated patch. >> >> Webrev: http://cr.openjdk.java.net/~erikj/8087195/webrev.hotspot.01/ > > Typo: + # we run it explicitly before runing dtrace. > > runing -> running > Fixing that. > Looks okay, only question I have is whether the preprocessed .d files > should be placed into DtraceOutDir or some tmp location? I'm not sure > where the contents of DtraceOutDir end up. > It's defined as DtraceOutDir = $(GENERATED)/dtracefiles which I assume is added to -I for the compiler later. I would say that it's safe to have a couple of other files end up in the same directory. Thanks /Erik > Thanks, > David > >> /Erik >> >> On 2015-06-11 12:53, Erik Joelsson wrote: >>> Hello, >>> >>> Please review this small makefile tweak. When using a devkit to build >>> hotspot on Macosx, the dtrace command gets confused and tries to use >>> the wrong preprocessor. I've fixed this by splitting out the running >>> of the preprocessor to a separate call. I've verified by comparing the >>> generated header files with and without the patch. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8087195 >>> Patch inline: >>> diff -r 11af3990d56c make/bsd/makefiles/dtrace.make >>> --- a/make/bsd/makefiles/dtrace.make >>> +++ b/make/bsd/makefiles/dtrace.make >>> @@ -263,14 +263,19 @@ >>> $(DtraceOutDir): >>> mkdir $(DtraceOutDir) >>> >>> +# When building using a devkit, dtrace cannot find the correct >>> preprocessor so >>> +# we run it explicitly before runing dtrace. >>> $(DtraceOutDir)/hotspot.h: $(DTRACE_COMMON_SRCDIR)/hotspot.d | >>> $(DtraceOutDir) >>> - $(QUIETLY) $(DTRACE_PROG) $(DTRACE_OPTS) -C -I. -h -o $@ -s >>> $(DTRACE_COMMON_SRCDIR)/hotspot.d >>> + $(QUIETLY) $(CC) -E $(DTRACE_OPTS) -I. -x c >>> $(DTRACE_COMMON_SRCDIR)/hotspot.d > $(DtraceOutDir)/hotspot.d >>> + $(QUIETLY) $(DTRACE_PROG) -h -o $@ -s $(DtraceOutDir)/hotspot.d >>> >>> $(DtraceOutDir)/hotspot_jni.h: $(DTRACE_COMMON_SRCDIR)/hotspot_jni.d >>> | $(DtraceOutDir) >>> - $(QUIETLY) $(DTRACE_PROG) $(DTRACE_OPTS) -C -I. -h -o $@ -s >>> $(DTRACE_COMMON_SRCDIR)/hotspot_jni.d >>> + $(QUIETLY) $(CC) -E $(DTRACE_OPTS) -I. -x c >>> $(DTRACE_COMMON_SRCDIR)/hotspot_jni.d > $(DtraceOutDir)/hotspot_jni.d >>> + $(QUIETLY) $(DTRACE_PROG) -h -o $@ -s >>> $(DtraceOutDir)/hotspot_jni.d >>> >>> $(DtraceOutDir)/hs_private.h: $(DTRACE_COMMON_SRCDIR)/hs_private.d | >>> $(DtraceOutDir) >>> - $(QUIETLY) $(DTRACE_PROG) $(DTRACE_OPTS) -C -I. -h -o $@ -s >>> $(DTRACE_COMMON_SRCDIR)/hs_private.d >>> + $(QUIETLY) $(CC) -E $(DTRACE_OPTS) -I. -x c >>> $(DTRACE_COMMON_SRCDIR)/hs_private.d > $(DtraceOutDir)/hs_private.d >>> + $(QUIETLY) $(DTRACE_PROG) -h -o $@ -s $(DtraceOutDir)/hs_private.d >>> >>> dtrace_gen_headers: $(DtraceOutDir)/hotspot.h >>> $(DtraceOutDir)/hotspot_jni.h $(DtraceOutDir)/hs_private.h >>> >>> >>> /Erik >> From goetz.lindenmaier at sap.com Fri Jun 12 06:53:34 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 12 Jun 2015 06:53:34 +0000 Subject: RFR(S): 8087183: Fix call to inline function is_oop in header debugInfo.hpp. In-Reply-To: <557A3EC2.1080300@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CFF2D12@DEWDFEMB12A.global.corp.sap> <7F5177CC-2BC8-4D24-8E12-EE44DC40F445@oracle.com> <557A3EC2.1080300@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2CFF30C7@DEWDFEMB12A.global.corp.sap> Hi, Thanks for the reviews! Could someone please sponsor this? We started to track down the cause by searching and building the repo, but then we narrowed in down to two merges ... and aix builds rather slow. I quit this task then. But the file drags in a lot of os/aix and os_cpu/aix_ppc files. The includes in these files differ from those in other platform directories. And with one of the include cleanup changes in a shared file the indirect include that must have been there at some point vanished I guess. But no matter, is_oop should not be called in a header file ... Best regards, Goetz. -----Original Message----- From: David Holmes [mailto:david.holmes at oracle.com] Sent: Freitag, 12. Juni 2015 04:07 To: Kim Barrett; Lindenmaier, Goetz Cc: HotSpot Developers Subject: Re: RFR(S): 8087183: Fix call to inline function is_oop in header debugInfo.hpp. On 12/06/2015 3:17 AM, Kim Barrett wrote: > On Jun 11, 2015, at 5:02 AM, Lindenmaier, Goetz wrote: >> >> Hi, >> >> in debugInfo.hpp is_oop() is called. This is an inline function defined in oop.inline.hpp. >> As oop.inline.hpp is not included in debugInfo.hpp, and it should not be included there, >> this leads to compilation failures in the fastdebug build on aix. >> >> To fix this, I just move the function calling is_oop to debugInfo.cpp. In that file also the >> only call to that function is located, so that it still can be inlined. >> >> Please review this change. I please need a sponsor. >> http://cr.openjdk.java.net/~goetz/webrevs/8087183-is_oop/webrev-01/ >> >> Best regards, >> Goetz. > > Looks good. > > I'm mildly surprised this doesn't run into problems on other platforms. Me too. My first thought was precompiled headers, but this code has been in place for a couple of years - so why is it now a problem ?? David > The assert could use oop->is_oop_or_null(), though it makes no difference for this problem. > From david.holmes at oracle.com Fri Jun 12 07:11:45 2015 From: david.holmes at oracle.com (David Holmes) Date: Fri, 12 Jun 2015 17:11:45 +1000 Subject: RFR: JDK-8087195: Support building hotspot with devkits on Macosx In-Reply-To: <557A7DAD.3020304@oracle.com> References: <557968AD.2040705@oracle.com> <557988EA.1030705@oracle.com> <557A41D4.8040300@oracle.com> <557A7DAD.3020304@oracle.com> Message-ID: <557A8631.6000706@oracle.com> On 12/06/2015 4:35 PM, Erik Joelsson wrote: > Hello David, > > On 2015-06-12 04:20, David Holmes wrote: >> Hi Erik, >> >> On 11/06/2015 11:11 PM, Erik Joelsson wrote: >>> Hello again, >>> >>> I missed cleaning the path correctly when testing this so missed another >>> needed change. When calling "lipo", the hotspot makefiles should use the >>> variable supplied by configure. Here is an updated patch. >>> >>> Webrev: http://cr.openjdk.java.net/~erikj/8087195/webrev.hotspot.01/ >> >> Typo: + # we run it explicitly before runing dtrace. >> >> runing -> running >> > Fixing that. >> Looks okay, only question I have is whether the preprocessed .d files >> should be placed into DtraceOutDir or some tmp location? I'm not sure >> where the contents of DtraceOutDir end up. >> > It's defined as > DtraceOutDir = $(GENERATED)/dtracefiles > > which I assume is added to -I for the compiler later. I would say that > it's safe to have a couple of other files end up in the same directory. Yep now I see it: Src_Dirs_I += $(GENERATED) and then: ./share/vm/utilities/dtrace.hpp:#include "dtracefiles/hotspot.h" ./share/vm/utilities/dtrace.hpp:#include "dtracefiles/hotspot_jni.h" ./share/vm/utilities/dtrace.hpp:#include "dtracefiles/hs_private.h" No problem. Thanks, David > Thanks > /Erik >> Thanks, >> David >> >>> /Erik >>> >>> On 2015-06-11 12:53, Erik Joelsson wrote: >>>> Hello, >>>> >>>> Please review this small makefile tweak. When using a devkit to build >>>> hotspot on Macosx, the dtrace command gets confused and tries to use >>>> the wrong preprocessor. I've fixed this by splitting out the running >>>> of the preprocessor to a separate call. I've verified by comparing the >>>> generated header files with and without the patch. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8087195 >>>> Patch inline: >>>> diff -r 11af3990d56c make/bsd/makefiles/dtrace.make >>>> --- a/make/bsd/makefiles/dtrace.make >>>> +++ b/make/bsd/makefiles/dtrace.make >>>> @@ -263,14 +263,19 @@ >>>> $(DtraceOutDir): >>>> mkdir $(DtraceOutDir) >>>> >>>> +# When building using a devkit, dtrace cannot find the correct >>>> preprocessor so >>>> +# we run it explicitly before runing dtrace. >>>> $(DtraceOutDir)/hotspot.h: $(DTRACE_COMMON_SRCDIR)/hotspot.d | >>>> $(DtraceOutDir) >>>> - $(QUIETLY) $(DTRACE_PROG) $(DTRACE_OPTS) -C -I. -h -o $@ -s >>>> $(DTRACE_COMMON_SRCDIR)/hotspot.d >>>> + $(QUIETLY) $(CC) -E $(DTRACE_OPTS) -I. -x c >>>> $(DTRACE_COMMON_SRCDIR)/hotspot.d > $(DtraceOutDir)/hotspot.d >>>> + $(QUIETLY) $(DTRACE_PROG) -h -o $@ -s $(DtraceOutDir)/hotspot.d >>>> >>>> $(DtraceOutDir)/hotspot_jni.h: $(DTRACE_COMMON_SRCDIR)/hotspot_jni.d >>>> | $(DtraceOutDir) >>>> - $(QUIETLY) $(DTRACE_PROG) $(DTRACE_OPTS) -C -I. -h -o $@ -s >>>> $(DTRACE_COMMON_SRCDIR)/hotspot_jni.d >>>> + $(QUIETLY) $(CC) -E $(DTRACE_OPTS) -I. -x c >>>> $(DTRACE_COMMON_SRCDIR)/hotspot_jni.d > $(DtraceOutDir)/hotspot_jni.d >>>> + $(QUIETLY) $(DTRACE_PROG) -h -o $@ -s >>>> $(DtraceOutDir)/hotspot_jni.d >>>> >>>> $(DtraceOutDir)/hs_private.h: $(DTRACE_COMMON_SRCDIR)/hs_private.d | >>>> $(DtraceOutDir) >>>> - $(QUIETLY) $(DTRACE_PROG) $(DTRACE_OPTS) -C -I. -h -o $@ -s >>>> $(DTRACE_COMMON_SRCDIR)/hs_private.d >>>> + $(QUIETLY) $(CC) -E $(DTRACE_OPTS) -I. -x c >>>> $(DTRACE_COMMON_SRCDIR)/hs_private.d > $(DtraceOutDir)/hs_private.d >>>> + $(QUIETLY) $(DTRACE_PROG) -h -o $@ -s $(DtraceOutDir)/hs_private.d >>>> >>>> dtrace_gen_headers: $(DtraceOutDir)/hotspot.h >>>> $(DtraceOutDir)/hotspot_jni.h $(DtraceOutDir)/hs_private.h >>>> >>>> >>>> /Erik >>> > From edward.nevill at linaro.org Fri Jun 12 08:49:03 2015 From: edward.nevill at linaro.org (Edward Nevill) Date: Fri, 12 Jun 2015 09:49:03 +0100 Subject: RFR: 8081790: SHA tests fail In-Reply-To: <1433321507.32688.13.camel@mylittlepony.linaroharston> References: <1433321507.32688.13.camel@mylittlepony.linaroharston> Message-ID: Hi, Sorry to bother. The following was posted for review 9 days ago but there has been no response. This is an aarch64 only change to resolve 7 jtreg/hotspot failures. Could a JDK9 reviewer please take a look at this, Thanks, Ed. On 3 June 2015 at 09:51, Edward Nevill wrote: > Hi, > > The following webrev > > http://cr.openjdk.java.net/~enevill/8081790/webrev.00/ > > fixes a number of SHA test failures on aarch64. > > This patch was contributed by alexander.alexeev at caviumnetworks.com > > Currently the following JTReg/hotspot SHA tests fail on aarch64 > > FAILED: > compiler/intrinsics/sha/cli/TestUseSHA1IntrinsicsOptionOnUnsupportedCPU.java > FAILED: > compiler/intrinsics/sha/cli/TestUseSHA256IntrinsicsOptionOnUnsupportedCPU.java > FAILED: compiler/intrinsics/sha/cli/TestUseSHAOptionOnUnsupportedCPU.java > (ie > FAILED: compiler/intrinsics/sha/sanity/TestSHA1Intrinsics.java > FAILED: compiler/intrinsics/sha/sanity/TestSHA1MultiBlockIntrinsics.java > FAILED: compiler/intrinsics/sha/sanity/TestSHA256MultiBlockIntrinsics.java > FAILED: compiler/intrinsics/sha/sanity/TestSHA256Intrinsics.java > > The reason for the test failures is that the test suite is configured on > the assumption that Sparc is the only arch which support SHA in hw (and > therefore supports the -XX:+UseSHA options). > > The webrev adds tests for aarch64. > > The following files have also been renamed as they were inappropriately > named. > > R > test/compiler/intrinsics/sha/cli/testcases/GenericTestCaseForSupportedSparcCPU.java > R > test/compiler/intrinsics/sha/cli/testcases/UseSHAIntrinsicsSpecificTestCaseForUnsupportedSparcCPU.java > R > test/compiler/intrinsics/sha/cli/testcases/UseSHASpecificTestCaseForSupportedSparcCPU.java > R > test/compiler/intrinsics/sha/cli/testcases/UseSHASpecificTestCaseForUnsupportedSparcCPU.java > > These now become > > A > test/compiler/intrinsics/sha/cli/testcases/GenericTestCaseForSupportedCPU.java > A > test/compiler/intrinsics/sha/cli/testcases/UseSHAIntrinsicsSpecificTestCaseForUnsupportedCPU.java > A > test/compiler/intrinsics/sha/cli/testcases/UseSHASpecificTestCaseForSupportedCPU.java > A > test/compiler/intrinsics/sha/cli/testcases/UseSHASpecificTestCaseForUnsupportedCPU.java > > (ie. the 'Sparc' has been dropped from the filename as Sparc is no longer > the only arch which supports SHA). > > Tested with JTReg/hotspot > > Before: Test results: passed: 840; failed: 10; error: 5 > After: Test results: passed: 847; failed: 3; error: 5 > > Please review, > > Thanks, > Ed. > > > From david.holmes at oracle.com Fri Jun 12 08:59:51 2015 From: david.holmes at oracle.com (David Holmes) Date: Fri, 12 Jun 2015 18:59:51 +1000 Subject: RFR: 8081790: SHA tests fail In-Reply-To: References: <1433321507.32688.13.camel@mylittlepony.linaroharston> Message-ID: <557A9F87.3010902@oracle.com> Hi Ed, On 12/06/2015 6:49 PM, Edward Nevill wrote: > Hi, > > Sorry to bother. The following was posted for review 9 days ago but there > has been no response. > > This is an aarch64 only change to resolve 7 jtreg/hotspot failures. > > Could a JDK9 reviewer please take a look at this, The test changes are shared code so this needs someone from the compiler team to review and sponsor. Thanks, David > Thanks, > Ed. > > On 3 June 2015 at 09:51, Edward Nevill wrote: > >> Hi, >> >> The following webrev >> >> http://cr.openjdk.java.net/~enevill/8081790/webrev.00/ >> >> fixes a number of SHA test failures on aarch64. >> >> This patch was contributed by alexander.alexeev at caviumnetworks.com >> >> Currently the following JTReg/hotspot SHA tests fail on aarch64 >> >> FAILED: >> compiler/intrinsics/sha/cli/TestUseSHA1IntrinsicsOptionOnUnsupportedCPU.java >> FAILED: >> compiler/intrinsics/sha/cli/TestUseSHA256IntrinsicsOptionOnUnsupportedCPU.java >> FAILED: compiler/intrinsics/sha/cli/TestUseSHAOptionOnUnsupportedCPU.java >> (ie >> FAILED: compiler/intrinsics/sha/sanity/TestSHA1Intrinsics.java >> FAILED: compiler/intrinsics/sha/sanity/TestSHA1MultiBlockIntrinsics.java >> FAILED: compiler/intrinsics/sha/sanity/TestSHA256MultiBlockIntrinsics.java >> FAILED: compiler/intrinsics/sha/sanity/TestSHA256Intrinsics.java >> >> The reason for the test failures is that the test suite is configured on >> the assumption that Sparc is the only arch which support SHA in hw (and >> therefore supports the -XX:+UseSHA options). >> >> The webrev adds tests for aarch64. >> >> The following files have also been renamed as they were inappropriately >> named. >> >> R >> test/compiler/intrinsics/sha/cli/testcases/GenericTestCaseForSupportedSparcCPU.java >> R >> test/compiler/intrinsics/sha/cli/testcases/UseSHAIntrinsicsSpecificTestCaseForUnsupportedSparcCPU.java >> R >> test/compiler/intrinsics/sha/cli/testcases/UseSHASpecificTestCaseForSupportedSparcCPU.java >> R >> test/compiler/intrinsics/sha/cli/testcases/UseSHASpecificTestCaseForUnsupportedSparcCPU.java >> >> These now become >> >> A >> test/compiler/intrinsics/sha/cli/testcases/GenericTestCaseForSupportedCPU.java >> A >> test/compiler/intrinsics/sha/cli/testcases/UseSHAIntrinsicsSpecificTestCaseForUnsupportedCPU.java >> A >> test/compiler/intrinsics/sha/cli/testcases/UseSHASpecificTestCaseForSupportedCPU.java >> A >> test/compiler/intrinsics/sha/cli/testcases/UseSHASpecificTestCaseForUnsupportedCPU.java >> >> (ie. the 'Sparc' has been dropped from the filename as Sparc is no longer >> the only arch which supports SHA). >> >> Tested with JTReg/hotspot >> >> Before: Test results: passed: 840; failed: 10; error: 5 >> After: Test results: passed: 847; failed: 3; error: 5 >> >> Please review, >> >> Thanks, >> Ed. >> >> >> From magnus.ihse.bursie at oracle.com Fri Jun 12 13:12:11 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 12 Jun 2015 15:12:11 +0200 Subject: RFR: JDK-8087195: Support building hotspot with devkits on Macosx In-Reply-To: <557A7DAD.3020304@oracle.com> References: <557968AD.2040705@oracle.com> <557988EA.1030705@oracle.com> <557A41D4.8040300@oracle.com> <557A7DAD.3020304@oracle.com> Message-ID: <557ADAAB.6040309@oracle.com> On 2015-06-12 08:35, Erik Joelsson wrote: > Hello David, > > On 2015-06-12 04:20, David Holmes wrote: >> Hi Erik, >> >> On 11/06/2015 11:11 PM, Erik Joelsson wrote: >>> Hello again, >>> >>> I missed cleaning the path correctly when testing this so missed >>> another >>> needed change. When calling "lipo", the hotspot makefiles should use >>> the >>> variable supplied by configure. Here is an updated patch. >>> >>> Webrev: http://cr.openjdk.java.net/~erikj/8087195/webrev.hotspot.01/ >> >> Typo: + # we run it explicitly before runing dtrace. >> >> runing -> running >> > Fixing that. Looks good to me then. /Magnus >> Looks okay, only question I have is whether the preprocessed .d files >> should be placed into DtraceOutDir or some tmp location? I'm not sure >> where the contents of DtraceOutDir end up. >> > It's defined as > DtraceOutDir = $(GENERATED)/dtracefiles > > which I assume is added to -I for the compiler later. I would say that > it's safe to have a couple of other files end up in the same directory. > > Thanks > /Erik >> Thanks, >> David >> >>> /Erik >>> >>> On 2015-06-11 12:53, Erik Joelsson wrote: >>>> Hello, >>>> >>>> Please review this small makefile tweak. When using a devkit to build >>>> hotspot on Macosx, the dtrace command gets confused and tries to use >>>> the wrong preprocessor. I've fixed this by splitting out the running >>>> of the preprocessor to a separate call. I've verified by comparing the >>>> generated header files with and without the patch. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8087195 >>>> Patch inline: >>>> diff -r 11af3990d56c make/bsd/makefiles/dtrace.make >>>> --- a/make/bsd/makefiles/dtrace.make >>>> +++ b/make/bsd/makefiles/dtrace.make >>>> @@ -263,14 +263,19 @@ >>>> $(DtraceOutDir): >>>> mkdir $(DtraceOutDir) >>>> >>>> +# When building using a devkit, dtrace cannot find the correct >>>> preprocessor so >>>> +# we run it explicitly before runing dtrace. >>>> $(DtraceOutDir)/hotspot.h: $(DTRACE_COMMON_SRCDIR)/hotspot.d | >>>> $(DtraceOutDir) >>>> - $(QUIETLY) $(DTRACE_PROG) $(DTRACE_OPTS) -C -I. -h -o $@ -s >>>> $(DTRACE_COMMON_SRCDIR)/hotspot.d >>>> + $(QUIETLY) $(CC) -E $(DTRACE_OPTS) -I. -x c >>>> $(DTRACE_COMMON_SRCDIR)/hotspot.d > $(DtraceOutDir)/hotspot.d >>>> + $(QUIETLY) $(DTRACE_PROG) -h -o $@ -s $(DtraceOutDir)/hotspot.d >>>> >>>> $(DtraceOutDir)/hotspot_jni.h: $(DTRACE_COMMON_SRCDIR)/hotspot_jni.d >>>> | $(DtraceOutDir) >>>> - $(QUIETLY) $(DTRACE_PROG) $(DTRACE_OPTS) -C -I. -h -o $@ -s >>>> $(DTRACE_COMMON_SRCDIR)/hotspot_jni.d >>>> + $(QUIETLY) $(CC) -E $(DTRACE_OPTS) -I. -x c >>>> $(DTRACE_COMMON_SRCDIR)/hotspot_jni.d > $(DtraceOutDir)/hotspot_jni.d >>>> + $(QUIETLY) $(DTRACE_PROG) -h -o $@ -s >>>> $(DtraceOutDir)/hotspot_jni.d >>>> >>>> $(DtraceOutDir)/hs_private.h: $(DTRACE_COMMON_SRCDIR)/hs_private.d | >>>> $(DtraceOutDir) >>>> - $(QUIETLY) $(DTRACE_PROG) $(DTRACE_OPTS) -C -I. -h -o $@ -s >>>> $(DTRACE_COMMON_SRCDIR)/hs_private.d >>>> + $(QUIETLY) $(CC) -E $(DTRACE_OPTS) -I. -x c >>>> $(DTRACE_COMMON_SRCDIR)/hs_private.d > $(DtraceOutDir)/hs_private.d >>>> + $(QUIETLY) $(DTRACE_PROG) -h -o $@ -s >>>> $(DtraceOutDir)/hs_private.d >>>> >>>> dtrace_gen_headers: $(DtraceOutDir)/hotspot.h >>>> $(DtraceOutDir)/hotspot_jni.h $(DtraceOutDir)/hs_private.h >>>> >>>> >>>> /Erik >>> > From erik.helin at oracle.com Fri Jun 12 15:15:52 2015 From: erik.helin at oracle.com (Erik Helin) Date: Fri, 12 Jun 2015 17:15:52 +0200 Subject: RFR: 8087200: Code heap does not use large pages Message-ID: <20150612151552.GD29290@ehelin.jrpg.bea.com> Hi all, this patch fixes an issue with the page sizing in in the code heap in 8u60 that was introduced in the backport for JDK-8049864. The issue does not exist in JDK 9 because the code heap in JDK 9 has been rewritten and uses the VirtualSpace to decide the page size for the reserved size (there is still an issue with the alignment of the comittted size in JDK 9, see JDK-8087339 [0]). The fix for 8u60 consists of using the reserved size to determine the page size (and not require that the page size divides the reserved size, because the reserved size will be aligned to the page size later anyway). Webrev: http://cr.openjdk.java.net/~ehelin/8087200/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8087200 Testing: - JPRT - Ad-hoc: - Bigapps: - Kitchensink - runThese - Weblogic - JTReg: - JDK - SVC - NSK - Confirmed that the perf regression introduced with the backport of [0] went away. Thanks, Erik [0]: https://bugs.openjdk.java.net/browse/JDK-8087339 From stefan.karlsson at oracle.com Fri Jun 12 15:21:08 2015 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Fri, 12 Jun 2015 17:21:08 +0200 Subject: RFR: 8087322: Implement a Semaphore utility class Message-ID: <557AF8E4.9040804@oracle.com> Hi all, Please review this patch to create a Semaphore utility class. I need this class to implementing faster GC thread synchronization [1]. http://cr.openjdk.java.net/~stefank/8087322/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8087322 Some of our platforms already implement a Semaphore class, but those classes are hidden inside os_.cpp. I've moved the class declaration to semaphore.hpp, but the implementation is left in the os_.hpp. I considered creating semaphore_.cpp files, but I ended up having to restructure too much code and I wanted to focus on the feature in [1] instead. Should I create a RFE to move the semaphore implementations? There seems to be another opportunity to cleanup the code. If we take os_linux.cpp, as an example, the code uses both the existing Semaphore class and the global ::sem_wait and ::sem_post functions. We might want to consider unifying that code. Since HotSpot is built on platforms that I don't have access to and can't test, I've added the IMPLEMENTS_SEMAPHORE_CLASS define. So, that I can detect if the the current platform implements the Semaphore class, and choose what synchronization primitive to use by the GC. The os_bsd.cpp file has support for "non-apple BSD", but I've only tested this patch with OS X. This patch has been tested in JPRT and our nightly testing together with the patches in [1]. The patch also contains a few unit tests in semaphore.cpp. Thanks, StefanK [1] http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2015-June/013829.html From vladimir.kozlov at oracle.com Fri Jun 12 17:12:47 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 12 Jun 2015 10:12:47 -0700 Subject: RFR: 8081790: SHA tests fail In-Reply-To: <557A9F87.3010902@oracle.com> References: <1433321507.32688.13.camel@mylittlepony.linaroharston> <557A9F87.3010902@oracle.com> Message-ID: <557B130F.1030209@oracle.com> Changes looks fine to me I will sponsor it. Thanks, Vladimir On 6/12/15 1:59 AM, David Holmes wrote: > Hi Ed, > > On 12/06/2015 6:49 PM, Edward Nevill wrote: >> Hi, >> >> Sorry to bother. The following was posted for review 9 days ago but there >> has been no response. >> >> This is an aarch64 only change to resolve 7 jtreg/hotspot failures. >> >> Could a JDK9 reviewer please take a look at this, > > The test changes are shared code so this needs someone from the compiler > team to review and sponsor. > > Thanks, > David > >> Thanks, >> Ed. >> >> On 3 June 2015 at 09:51, Edward Nevill wrote: >> >>> Hi, >>> >>> The following webrev >>> >>> http://cr.openjdk.java.net/~enevill/8081790/webrev.00/ >>> >>> fixes a number of SHA test failures on aarch64. >>> >>> This patch was contributed by alexander.alexeev at caviumnetworks.com >>> >>> Currently the following JTReg/hotspot SHA tests fail on aarch64 >>> >>> FAILED: >>> compiler/intrinsics/sha/cli/TestUseSHA1IntrinsicsOptionOnUnsupportedCPU.java >>> >>> FAILED: >>> compiler/intrinsics/sha/cli/TestUseSHA256IntrinsicsOptionOnUnsupportedCPU.java >>> >>> FAILED: >>> compiler/intrinsics/sha/cli/TestUseSHAOptionOnUnsupportedCPU.java >>> (ie >>> FAILED: compiler/intrinsics/sha/sanity/TestSHA1Intrinsics.java >>> FAILED: compiler/intrinsics/sha/sanity/TestSHA1MultiBlockIntrinsics.java >>> FAILED: >>> compiler/intrinsics/sha/sanity/TestSHA256MultiBlockIntrinsics.java >>> FAILED: compiler/intrinsics/sha/sanity/TestSHA256Intrinsics.java >>> >>> The reason for the test failures is that the test suite is configured on >>> the assumption that Sparc is the only arch which support SHA in hw (and >>> therefore supports the -XX:+UseSHA options). >>> >>> The webrev adds tests for aarch64. >>> >>> The following files have also been renamed as they were inappropriately >>> named. >>> >>> R >>> test/compiler/intrinsics/sha/cli/testcases/GenericTestCaseForSupportedSparcCPU.java >>> >>> R >>> test/compiler/intrinsics/sha/cli/testcases/UseSHAIntrinsicsSpecificTestCaseForUnsupportedSparcCPU.java >>> >>> R >>> test/compiler/intrinsics/sha/cli/testcases/UseSHASpecificTestCaseForSupportedSparcCPU.java >>> >>> R >>> test/compiler/intrinsics/sha/cli/testcases/UseSHASpecificTestCaseForUnsupportedSparcCPU.java >>> >>> >>> These now become >>> >>> A >>> test/compiler/intrinsics/sha/cli/testcases/GenericTestCaseForSupportedCPU.java >>> >>> A >>> test/compiler/intrinsics/sha/cli/testcases/UseSHAIntrinsicsSpecificTestCaseForUnsupportedCPU.java >>> >>> A >>> test/compiler/intrinsics/sha/cli/testcases/UseSHASpecificTestCaseForSupportedCPU.java >>> >>> A >>> test/compiler/intrinsics/sha/cli/testcases/UseSHASpecificTestCaseForUnsupportedCPU.java >>> >>> >>> (ie. the 'Sparc' has been dropped from the filename as Sparc is no >>> longer >>> the only arch which supports SHA). >>> >>> Tested with JTReg/hotspot >>> >>> Before: Test results: passed: 840; failed: 10; error: 5 >>> After: Test results: passed: 847; failed: 3; error: 5 >>> >>> Please review, >>> >>> Thanks, >>> Ed. >>> >>> >>> From john at johncoomes.org Fri Jun 12 18:05:40 2015 From: john at johncoomes.org (John Coomes) Date: Fri, 12 Jun 2015 11:05:40 -0700 (PDT) Subject: resigning as HotSpot Group Lead Message-ID: <1135826162.163050.1434132340098.JavaMail.open-xchange@app2.ox.privateemail.com> Since I have changed jobs and HotSpot is no longer the focus of my day-to-day work, I feel it's best to give up the role of HotSpot Group Lead. Please consider this my resignation. Regards, John From kim.barrett at oracle.com Fri Jun 12 18:08:35 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Fri, 12 Jun 2015 14:08:35 -0400 Subject: RFR: 8087322: Implement a Semaphore utility class In-Reply-To: <557AF8E4.9040804@oracle.com> References: <557AF8E4.9040804@oracle.com> Message-ID: On Jun 12, 2015, at 11:21 AM, Stefan Karlsson wrote: > > Hi all, > > Please review this patch to create a Semaphore utility class. I need this class to implementing faster GC thread synchronization [1]. > > http://cr.openjdk.java.net/~stefank/8087322/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8087322 > > Some of our platforms already implement a Semaphore class, but those classes are hidden inside os_.cpp. I've moved the class declaration to semaphore.hpp, but the implementation is left in the os_.hpp. I considered creating semaphore_.cpp files, but I ended up having to restructure too much code and I wanted to focus on the feature in [1] instead. Should I create a RFE to move the semaphore implementations? Please file an RFE for that. Also, see my later comment about Solaris and perhaps having a shared POSIX implementation of this facility. > There seems to be another opportunity to cleanup the code. If we take os_linux.cpp, as an example, the code uses both the existing Semaphore class and the global ::sem_wait and ::sem_post functions. We might want to consider unifying that code. Please file an RFE for that. > Since HotSpot is built on platforms that I don't have access to and can't test, I've added the IMPLEMENTS_SEMAPHORE_CLASS define. So, that I can detect if the the current platform implements the Semaphore class, and choose what synchronization primitive to use by the GC. Ugh! Another reason to provide a POSIX-based implementation, as many other platforms could probably trivially provide support via that. Looking ahead, I see that another reason to keep the old synchronization code would be to provide a diagnostic fallback, but I would hope that eventually this would all get cleaned up and the non-semaphore-based approach would go away. On to the more detailed comments. Where I've noted a pre-existing defect, I'd generally be fine with an RFE to fix later if you really don't want to spend the time on it right now. ------------------------------------------------------------------------------ src/os/windows/vm/os_windows.cpp I didn't do a careful review of the Windows implementation - I'm not sufficiently well versed in low-level Windows development to feel like I can do an adequate job here. I didn't see anything obviously concerning in what's implemented though. Is the present lack of implementations for trywait and timedwait due to lack of need and so not bothering right now? Or is there some fundamental difficulty? I'm wondering if it might be better to leave the unimplemented functions truely unimplemented, e.g. don't define them at all. That way, if there is ever an attempt to access them, we should presumably get link-time errors, which would be better than runtime errors. ------------------------------------------------------------------------------ src/os/solaris/vm/os_solaris.cpp Probably not something to address in this change set, but I wonder why Solaris is using sema_xxx rather than using a shared POSIX sem_xxx implementation. Such a POSIX implementation could probably be shared by Linux, (non-Apple) BSD, and Solaris, and perhaps others not maintained by Oracle. ------------------------------------------------------------------------------ src/os/solaris/vm/os_solaris.cpp 2270 static int sem_max_value = -1; ... 2272 Semaphore::Semaphore(uint value, uint max) { 2273 guarantee(value <= max, "value lower than max"); 2274 2275 static long sem_value_max = sysconf(_SC_SEM_VALUE_MAX); 2276 guarantee(max == Semaphore::NoMaxCount || value <= sem_max_value, 2277 err_msg("Max value: %u set higher than SEM_VALUE_MAX: %l", sem_value_max)); There's a bit of a mess around sem_max_value and sem_value_max. sem_max_value is used in the comparison. Since it's initialized to -1 and never set anywhere, its int -1 is converted to uint max when comparing with the uint "value" argument. sem_value_max is obtained from sysconf and used in the error message, but not compared against the "value" argument. ------------------------------------------------------------------------------ src/os/solaris/vm/os_solaris.cpp 2288 void Semaphore::signal() { 2289 int ret = sema_post(&_semaphore); 2290 2291 assert(ret == 0, err_msg("Semaphore signal failed: %d", errno)); 2292 } sema_post is documented as returning the error code directly, rather than "returning" it in errno. Fixing that would also fix the presently assigned but never used state of ret in non-debug builds. ------------------------------------------------------------------------------ src/os/solaris/vm/os_solaris.cpp 2300 void Semaphore::wait() { 2301 int ret; 2302 2303 do { 2304 ret = sema_wait(&_semaphore); 2305 // Retry if the wait was interrupted by a signal. 2306 } while (errno == EINTR); 2307 2308 assert(ret == 0, err_msg("Semaphore wait failed: %d", errno)); 2309 } sema_wait is documented as returning the error code directly, rather than "returning" it in errno. Fixing that would also fix the presently assigned but never used state of ret in non-debug builds. ------------------------------------------------------------------------------ src/os/solaris/vm/os_solaris.cpp 2311 bool Semaphore::trywait() { ... 2315 bool Semaphore::timedwait(unsigned int sec, int nsec) { Pre-existing defect: These functions silently swallow various errors, such as EINVAL. It seems like they should be checking for those in at least debug builds. ------------------------------------------------------------------------------ src/os/solaris/vm/os_solaris.cpp 2284 Semaphore::~Semaphore() { 2285 sema_destroy(&_semaphore); 2286 } Pre-existing defect: sema_destroy result not checked. ------------------------------------------------------------------------------ src/os/bsd/vm/os_bsd.cpp Pre-existing defect: The semaphore implementation provided here is very weak on error checking. ------------------------------------------------------------------------------ src/os/bsd/vm/os_bsd.cpp 1984 static jlong semaphore_currenttime() { Now that this function is file-scoped, it is clearly only used by the __APPLE__ implementation, so should be moved inside the nearby #ifdef. ------------------------------------------------------------------------------ src/share/vm/utilities/semaphore.hpp The Semaphore class should not be copyable or copy-assignable. ------------------------------------------------------------------------------ From stefan.karlsson at oracle.com Fri Jun 12 18:45:08 2015 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Fri, 12 Jun 2015 20:45:08 +0200 Subject: RFR: 8087322: Implement a Semaphore utility class In-Reply-To: References: <557AF8E4.9040804@oracle.com> Message-ID: <557B28B4.4020303@oracle.com> Hi Kim, On 2015-06-12 20:08, Kim Barrett wrote: > On Jun 12, 2015, at 11:21 AM, Stefan Karlsson wrote: >> Hi all, >> >> Please review this patch to create a Semaphore utility class. I need this class to implementing faster GC thread synchronization [1]. >> >> http://cr.openjdk.java.net/~stefank/8087322/webrev.00/ >> https://bugs.openjdk.java.net/browse/JDK-8087322 >> >> Some of our platforms already implement a Semaphore class, but those classes are hidden inside os_.cpp. I've moved the class declaration to semaphore.hpp, but the implementation is left in the os_.hpp. I considered creating semaphore_.cpp files, but I ended up having to restructure too much code and I wanted to focus on the feature in [1] instead. Should I create a RFE to move the semaphore implementations? > Please file an RFE for that. Will do. > > Also, see my later comment about Solaris and perhaps having a shared POSIX implementation of this facility. > >> There seems to be another opportunity to cleanup the code. If we take os_linux.cpp, as an example, the code uses both the existing Semaphore class and the global ::sem_wait and ::sem_post functions. We might want to consider unifying that code. > Please file an RFE for that. Will do. > >> Since HotSpot is built on platforms that I don't have access to and can't test, I've added the IMPLEMENTS_SEMAPHORE_CLASS define. So, that I can detect if the the current platform implements the Semaphore class, and choose what synchronization primitive to use by the GC. > Ugh! Another reason to provide a POSIX-based implementation, as many other platforms could probably trivially provide support via that. Sounds good to me, but I'll defer this to someone else. > > Looking ahead, I see that another reason to keep the old synchronization code would be to provide a diagnostic fallback, but I would hope that eventually this would all get cleaned up and the non-semaphore-based approach would go away. I agree. > > On to the more detailed comments. Where I've noted a pre-existing > defect, I'd generally be fine with an RFE to fix later if you really > don't want to spend the time on it right now. > > ------------------------------------------------------------------------------ > src/os/windows/vm/os_windows.cpp > > I didn't do a careful review of the Windows implementation - I'm not > sufficiently well versed in low-level Windows development to feel like > I can do an adequate job here. I didn't see anything obviously > concerning in what's implemented though. Hopefully, someone else can review that code. > > Is the present lack of implementations for trywait and timedwait due > to lack of need and so not bothering right now? Or is there some > fundamental difficulty? The former. > > I'm wondering if it might be better to leave the unimplemented > functions truely unimplemented, e.g. don't define them at all. That > way, if there is ever an attempt to access them, we should presumably > get link-time errors, which would be better than runtime errors. Sounds good to me. I'll change that. > > ------------------------------------------------------------------------------ > src/os/solaris/vm/os_solaris.cpp > > Probably not something to address in this change set, but I wonder why > Solaris is using sema_xxx rather than using a shared POSIX sem_xxx > implementation. Such a POSIX implementation could probably be shared > by Linux, (non-Apple) BSD, and Solaris, and perhaps others not > maintained by Oracle. > > ------------------------------------------------------------------------------ > src/os/solaris/vm/os_solaris.cpp > 2270 static int sem_max_value = -1; > ... > 2272 Semaphore::Semaphore(uint value, uint max) { > 2273 guarantee(value <= max, "value lower than max"); > 2274 > 2275 static long sem_value_max = sysconf(_SC_SEM_VALUE_MAX); > 2276 guarantee(max == Semaphore::NoMaxCount || value <= sem_max_value, > 2277 err_msg("Max value: %u set higher than SEM_VALUE_MAX: %l", sem_value_max)); > > There's a bit of a mess around sem_max_value and sem_value_max. > > sem_max_value is used in the comparison. Since it's initialized to -1 > and never set anywhere, its int -1 is converted to uint max when > comparing with the uint "value" argument. > > sem_value_max is obtained from sysconf and used in the error message, > but not compared against the "value" argument. My intention was to only use the sem_value_max, but I messed it up. I'll fix this. > > ------------------------------------------------------------------------------ > src/os/solaris/vm/os_solaris.cpp > 2288 void Semaphore::signal() { > 2289 int ret = sema_post(&_semaphore); > 2290 > 2291 assert(ret == 0, err_msg("Semaphore signal failed: %d", errno)); > 2292 } > > sema_post is documented as returning the error code directly, rather > than "returning" it in errno. Fixing that would also fix the > presently assigned but never used state of ret in non-debug builds. You might be right, and I'll probably need to write a test that overflows the semaphore, but the man page says: --- RETURN VALUES Upon successful completion, 0 is returned; otherwise, a non-zero value indicates an error. ... The *sema_trywait()* function will fail if:: EBUSY The semaphore pointed to by sp has a zero count. The *sema_post()* function will fail if: EOVERFLOW The semaphore value pointed to by sp exceeds SEM_VALUE_MAX . ... if (sema_trywait(&tellers) != 0) if (errno == EAGAIN){ /* no teller available */ --- So, according to the example the error number is returned in errno, AFAICT. > > ------------------------------------------------------------------------------ > src/os/solaris/vm/os_solaris.cpp > 2300 void Semaphore::wait() { > 2301 int ret; > 2302 > 2303 do { > 2304 ret = sema_wait(&_semaphore); > 2305 // Retry if the wait was interrupted by a signal. > 2306 } while (errno == EINTR); > 2307 > 2308 assert(ret == 0, err_msg("Semaphore wait failed: %d", errno)); > 2309 } > > sema_wait is documented as returning the error code directly, rather > than "returning" it in errno. Fixing that would also fix the > presently assigned but never used state of ret in non-debug builds. > > ------------------------------------------------------------------------------ > src/os/solaris/vm/os_solaris.cpp > 2311 bool Semaphore::trywait() { > ... > 2315 bool Semaphore::timedwait(unsigned int sec, int nsec) { > > Pre-existing defect: These functions silently swallow various errors, > such as EINVAL. It seems like they should be checking for those in at > least debug builds. > > ------------------------------------------------------------------------------ > src/os/solaris/vm/os_solaris.cpp > 2284 Semaphore::~Semaphore() { > 2285 sema_destroy(&_semaphore); > 2286 } > > Pre-existing defect: sema_destroy result not checked. > > ------------------------------------------------------------------------------ > src/os/bsd/vm/os_bsd.cpp > > Pre-existing defect: The semaphore implementation provided here is > very weak on error checking. I'll open an new RFE regarding the pre-existing defects. > > ------------------------------------------------------------------------------ > src/os/bsd/vm/os_bsd.cpp > 1984 static jlong semaphore_currenttime() { > > Now that this function is file-scoped, it is clearly only used by the > __APPLE__ implementation, so should be moved inside the nearby #ifdef. I'll move the code. > > ------------------------------------------------------------------------------ > src/share/vm/utilities/semaphore.hpp > > The Semaphore class should not be copyable or copy-assignable. The same goes for Monitor and Mutex, right? I'll fix this for Semaphore. > > ------------------------------------------------------------------------------ > Thanks for reviewing! StefanK From kim.barrett at oracle.com Fri Jun 12 19:36:46 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Fri, 12 Jun 2015 15:36:46 -0400 Subject: RFR: 8087322: Implement a Semaphore utility class In-Reply-To: <557B28B4.4020303@oracle.com> References: <557AF8E4.9040804@oracle.com> <557B28B4.4020303@oracle.com> Message-ID: <2C0F8888-32E3-4F25-9922-CEB3DF6E0944@oracle.com> On Jun 12, 2015, at 2:45 PM, Stefan Karlsson wrote: > > On 2015-06-12 20:08, Kim Barrett wrote: >> src/os/solaris/vm/os_solaris.cpp >> 2288 void Semaphore::signal() { >> 2289 int ret = sema_post(&_semaphore); >> 2290 >> 2291 assert(ret == 0, err_msg("Semaphore signal failed: %d", errno)); >> 2292 } >> >> sema_post is documented as returning the error code directly, rather >> than "returning" it in errno. Fixing that would also fix the >> presently assigned but never used state of ret in non-debug builds. >> > > You might be right, and I'll probably need to write a test that overflows the semaphore, but the man page says: > --- > RETURN VALUES > > Upon successful completion, 0 is returned; otherwise, a non-zero value indicates an error. > > > ... > The sema_trywait() function will fail if:: > > EBUSY > The semaphore pointed to by sp has a zero count. > > The sema_post() function will fail if: > > EOVERFLOW > The semaphore value pointed to by sp exceeds SEM_VALUE_MAX . > > ... > > if (sema_trywait(&tellers) != 0) > if (errno == EAGAIN){ /* no teller available */ > > --- > > So, according to the example the error number is returned in errno, AFAICT. OK, the description in the documentation I?m looking at is unclear. Maybe there is more recent documentation? (What I?m looking at says last revised in 1998, but this kind of stuff tends to be quite stable.) You are probably correct, but having the semantics hidden away in examples is . >> src/share/vm/utilities/semaphore.hpp >> >> The Semaphore class should not be copyable or copy-assignable. >> > > The same goes for Monitor and Mutex, right? I'll fix this for Semaphore. And probably a whole lot of other classes. This is one of those hygiene things whose lack irritates me about this code base. I don?t know if I should be trying to change it or just get used to the way it is. From stefan.karlsson at oracle.com Fri Jun 12 21:08:54 2015 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Fri, 12 Jun 2015 23:08:54 +0200 Subject: RFR: 8087322: Implement a Semaphore utility class In-Reply-To: <2C0F8888-32E3-4F25-9922-CEB3DF6E0944@oracle.com> References: <557AF8E4.9040804@oracle.com> <557B28B4.4020303@oracle.com> <2C0F8888-32E3-4F25-9922-CEB3DF6E0944@oracle.com> Message-ID: <557B4A66.90500@oracle.com> On 2015-06-12 21:36, Kim Barrett wrote: > On Jun 12, 2015, at 2:45 PM, Stefan Karlsson wrote: >> On 2015-06-12 20:08, Kim Barrett wrote: >>> src/os/solaris/vm/os_solaris.cpp >>> 2288 void Semaphore::signal() { >>> 2289 int ret = sema_post(&_semaphore); >>> 2290 >>> 2291 assert(ret == 0, err_msg("Semaphore signal failed: %d", errno)); >>> 2292 } >>> >>> sema_post is documented as returning the error code directly, rather >>> than "returning" it in errno. Fixing that would also fix the >>> presently assigned but never used state of ret in non-debug builds. >>> >> You might be right, and I'll probably need to write a test that overflows the semaphore, but the man page says: >> --- >> RETURN VALUES >> >> Upon successful completion, 0 is returned; otherwise, a non-zero value indicates an error. >> >> >> ... >> The sema_trywait() function will fail if:: >> >> EBUSY >> The semaphore pointed to by sp has a zero count. >> >> The sema_post() function will fail if: >> >> EOVERFLOW >> The semaphore value pointed to by sp exceeds SEM_VALUE_MAX . >> >> ... >> >> if (sema_trywait(&tellers) != 0) >> if (errno == EAGAIN){ /* no teller available */ >> >> --- >> >> So, according to the example the error number is returned in errno, AFAICT. > OK, the description in the documentation I?m looking at is unclear. Maybe there is more > recent documentation? (What I?m looking at says last revised in 1998, but this kind of stuff > tends to be quite stable.) > > You are probably correct, but having the semantics hidden away in examples is . And now that I read the example above I see that it checks against EAGAIN, but the sema_post documentation mentions EBUSY. So I'm confused. > >>> src/share/vm/utilities/semaphore.hpp >>> >>> The Semaphore class should not be copyable or copy-assignable. >>> >> The same goes for Monitor and Mutex, right? I'll fix this for Semaphore. > And probably a whole lot of other classes. This is one of those hygiene things whose > lack irritates me about this code base. I don?t know if I should be trying to change it > or just get used to the way it is. > Maybe we should create a couple of RFEs and clean up some of the classes, just to get things moving in the right direction? Thanks, StefanK From tobias.hartmann at oracle.com Fri Jun 12 21:38:58 2015 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Fri, 12 Jun 2015 23:38:58 +0200 Subject: RFR: 8087200: Code heap does not use large pages In-Reply-To: <20150612151552.GD29290@ehelin.jrpg.bea.com> References: <20150612151552.GD29290@ehelin.jrpg.bea.com> Message-ID: <557B5172.6010709@oracle.com> Hi Erik, looks good to me (not a reviewer). Best, Tobias On 12.06.2015 17:15, Erik Helin wrote: > Hi all, > > this patch fixes an issue with the page sizing in in the code heap > in 8u60 that was introduced in the backport for JDK-8049864. The issue does > not exist in JDK 9 because the code heap in JDK 9 has been rewritten and > uses the VirtualSpace to decide the page size for the reserved size > (there is still an issue with the alignment of the comittted size in JDK > 9, see JDK-8087339 [0]). > > The fix for 8u60 consists of using the reserved size to determine the > page size (and not require that the page size divides the reserved > size, because the reserved size will be aligned to the page size later > anyway). > > Webrev: > http://cr.openjdk.java.net/~ehelin/8087200/webrev.00/ > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8087200 > > Testing: > - JPRT > - Ad-hoc: > - Bigapps: > - Kitchensink > - runThese > - Weblogic > - JTReg: > - JDK > - SVC > - NSK > - Confirmed that the perf regression introduced with the backport of [0] > went away. > > Thanks, > Erik > > [0]: https://bugs.openjdk.java.net/browse/JDK-8087339 > From vladimir.kozlov at oracle.com Fri Jun 12 22:16:39 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 12 Jun 2015 15:16:39 -0700 Subject: RFR: 8073108: GHASH Intrinsics In-Reply-To: <5579CD0E.2070801@oracle.com> References: <54E25D03.7090705@oracle.com> <5579CD0E.2070801@oracle.com> Message-ID: <557B5A47.5090008@oracle.com> This implementation looks good to me. You need second review since changes are big. Thanks, Vladimir On 6/11/15 11:01 AM, Anthony Scarpino wrote: > Now that JEP 246 is targeted, I can proceed a with the GHASH changes I > had reviewed back in February. > > There are two changes from the previous review. One is the separate > method for the range checking in jdk:GHASH.java in update(). The other > is disabing UseGHASHIntrinsics for arch64 in hotspot. > > http://cr.openjdk.java.net/~ascarpino/8073108/hotspot/webrev.03/ > http://cr.openjdk.java.net/~ascarpino/8073108/jdk/webrev.03/ > > thanks > > Tony > From kim.barrett at oracle.com Sat Jun 13 00:23:02 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Fri, 12 Jun 2015 20:23:02 -0400 Subject: RFR: 8087322: Implement a Semaphore utility class In-Reply-To: <557B4A66.90500@oracle.com> References: <557AF8E4.9040804@oracle.com> <557B28B4.4020303@oracle.com> <2C0F8888-32E3-4F25-9922-CEB3DF6E0944@oracle.com> <557B4A66.90500@oracle.com> Message-ID: <3D2BFAB9-84CA-4F73-B333-70395F655B07@oracle.com> On Jun 12, 2015, at 5:08 PM, Stefan Karlsson wrote: > > On 2015-06-12 21:36, Kim Barrett wrote: >>> So, according to the example the error number is returned in errno, AFAICT. >> OK, the description in the documentation I?m looking at is unclear. Maybe there is more >> recent documentation? (What I?m looking at says last revised in 1998, but this kind of stuff >> tends to be quite stable.) >> >> You are probably correct, but having the semantics hidden away in examples is . > > And now that I read the example above I see that it checks against EAGAIN, but the sema_post documentation mentions EBUSY. So I'm confused. It?s EBUSY in both places in the Solaris 11.2 documentation; the EAGAIN in the example appears to be a doc bug that has been fixed. >>>> src/share/vm/utilities/semaphore.hpp >>>> >>>> The Semaphore class should not be copyable or copy-assignable. >>>> >>> The same goes for Monitor and Mutex, right? I'll fix this for Semaphore. >> And probably a whole lot of other classes. This is one of those hygiene things whose >> lack irritates me about this code base. I don?t know if I should be trying to change it >> or just get used to the way it is. >> > Maybe we should create a couple of RFEs and clean up some of the classes, just to get things moving in the right direction? Sure, but we should take this discussion elsewhere. I?m ok with leaving the Semaphore class as is for now, pending that discussion. From gerard.ziemski at oracle.com Sat Jun 13 14:32:16 2015 From: gerard.ziemski at oracle.com (Gerard Ziemski) Date: Sat, 13 Jun 2015 09:32:16 -0500 Subject: Revision3: Corrected: RFR 8059557 (XL): Validate JVM Command-Line Flag Arguments Message-ID: <557C3EF0.3030107@oracle.com> hi all, Thank you for the reviews so far! Here is a revision 3 of the feature taking into account feedback from Kim Barrett, David Holmes, Derek White and Bengt Rutisson. I have also merged the changes to the latest jdk9. We introduce a new mechanism that allows specification of a valid range per flag that is then used to automatically validate given flag's value every time it changes. Ranges values must be constant and can not change. Optionally, a constraint can also be specified and applied every time a flag value changes for those flags whose valid value can not be trivially checked by a simple min and max (ex. whether it's power of 2, or bigger or smaller than some other flag that can also change) I have chosen to modify the table macros (ex. RUNTIME_FLAGS in globals.hpp) instead of using a more sophisticated solution, such as C++ templates, because even though macros were unfriendly when initially developing, once a solution was arrived at, subsequent additions to the tables of new ranges, or constraint are trivial from developer's point of view. (The intial development unfriendliness of macros was mitigated by using a pre-processor, which for those using a modern IDE like Xcode, is easily available from a menu). Using macros also allowed for more minimal code changes. The presented solution is based on expansion of macros using variadic functions and can be readily seen in runtime/commandLineFlagConstraintList.cpp and runtime/commandLineFlagRangeList.cpp In commandLineFlagConstraintList.cpp or commandLineFlagRangesList.cpp, there is bunch of classes and methods that seems to beg for C++ template to be used. I have tried, but when the compiler tries to generate code for both uintx and size_t, which happen to have the same underlying type (on BSD), it fails to compile overridden methods with same type, but different name. If someone has a way of simplifying the new code via C++ templates, however, we can file a new enhancement request to address that. This webrev represents only the initial range checking framework and only 100 or so flags that were ported from an existing ad hoc range checking code to this new mechanism. There are about 250 remaining flags that still need their ranges determined and ported over to this new mechanism and they are tracked by individual subtasks. I had to modify several existing tests to change the error message that they expected when VM refuses to run, which was changed to provide uniform error messages. To help with testing and subtask efforts I have introduced a new runtime flag: PrintFlagsRanges: "Print VM flags and their ranges and exit VM" which in addition to the already existing flags: "PrintFlagsInitial" and "PrintFlagsFinal" allow for thorough examination of the flags values and their ranges. The code change builds and passes JPRT (-testset hotspot) and UTE (vm.quick.testlist) References: Webrev:http://cr.openjdk.java.net/~gziemski/8059557_rev3 JEP:https://bugs.openjdk.java.net/browse/JDK-8059557 Compiler subtask:https://bugs.openjdk.java.net/browse/JDK-8078554 GC subtask:https://bugs.openjdk.java.net/browse/JDK-8078555 Runtime subtask:https://bugs.openjdk.java.net/browse/JDK-8078556 Note: due to "awk" limit of 50 pats the Frames diff is not available for "src/share/vm/runtime/arguments.cpp? and "src/share/vm/runtime/globals.cpp? Followup issues: JDK-8085866: There are 99 uses of FLAG_SET_ERGO, should they check the return value? JDK-8085864: FLAG_SET_CMDLINE in TestGenCollectorPolicy() currently ignore the return values JDK-8081842: Find a better place for EMIT_{CONSTRAINTS,RANGES}_FOR_GLOBALS_EXT JDK-8081833: There is a large amount of code near-duplication among the various CommandLineFlagRange_ classes JDK-8081519: Split globals.hpp to factor out the Flag values needed by JDK-8059557 hgstat: src/cpu/ppc/vm/globals_ppc.hpp | 2 +- src/cpu/sparc/vm/globals_sparc.hpp | 2 +- src/cpu/x86/vm/globals_x86.hpp | 2 +- src/cpu/zero/vm/globals_zero.hpp | 3 +- src/os/aix/vm/globals_aix.hpp | 2 +- src/os/bsd/vm/globals_bsd.hpp | 29 +- src/os/linux/vm/globals_linux.hpp | 9 +- src/os/solaris/vm/globals_solaris.hpp | 4 +- src/os/windows/vm/globals_windows.hpp | 5 +- src/share/vm/c1/c1_globals.cpp | 4 +- src/share/vm/c1/c1_globals.hpp | 17 +- src/share/vm/gc/g1/g1_globals.cpp | 14 +- src/share/vm/gc/g1/g1_globals.hpp | 38 +- src/share/vm/opto/c2_globals.cpp | 12 +- src/share/vm/opto/c2_globals.hpp | 40 +- src/share/vm/prims/whitebox.cpp | 12 +- src/share/vm/runtime/arguments.cpp | 765 ++++++---------- src/share/vm/runtime/arguments.hpp | 24 +- src/share/vm/runtime/commandLineFlagConstraintList.cpp | 286 ++++++ src/share/vm/runtime/commandLineFlagConstraintList.hpp | 80 + src/share/vm/runtime/commandLineFlagConstraintsCompiler.cpp | 44 + src/share/vm/runtime/commandLineFlagConstraintsCompiler.hpp | 39 + src/share/vm/runtime/commandLineFlagConstraintsGC.cpp | 235 +++++ src/share/vm/runtime/commandLineFlagConstraintsGC.hpp | 58 + src/share/vm/runtime/commandLineFlagConstraintsRuntime.cpp | 65 + src/share/vm/runtime/commandLineFlagConstraintsRuntime.hpp | 41 + src/share/vm/runtime/commandLineFlagRangeList.cpp | 367 ++++++++ src/share/vm/runtime/commandLineFlagRangeList.hpp | 71 + src/share/vm/runtime/globals.cpp | 721 ++++++++++++--- src/share/vm/runtime/globals.hpp | 343 ++++++- src/share/vm/runtime/globals_extension.hpp | 105 +- src/share/vm/runtime/init.cpp | 5 +- src/share/vm/runtime/os_ext.hpp | 7 +- src/share/vm/runtime/thread.cpp | 6 + src/share/vm/services/attachListener.cpp | 4 +- src/share/vm/services/classLoadingService.cpp | 12 +- src/share/vm/services/diagnosticCommand.cpp | 3 +- src/share/vm/services/management.cpp | 6 +- src/share/vm/services/memoryService.cpp | 4 +- src/share/vm/services/writeableFlags.cpp | 183 ++- src/share/vm/services/writeableFlags.hpp | 60 +- test/compiler/c2/7200264/Test7200264.sh | 5 +- test/compiler/startup/NumCompilerThreadsCheck.java | 2 +- test/gc/arguments/TestHeapFreeRatio.java | 23 +- test/gc/arguments/TestSurvivorAlignmentInBytesOption.java | 6 +- test/gc/g1/TestStringDeduplicationTools.java | 6 +- test/runtime/CompressedOops/CompressedClassSpaceSize.java | 4 +- test/runtime/CompressedOops/ObjectAlignment.java | 9 +- test/runtime/contended/Options.java | 10 +- 49 files changed, 2851 insertions(+), 943 deletions(-) From kim.barrett at oracle.com Sat Jun 13 20:54:39 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Sat, 13 Jun 2015 16:54:39 -0400 Subject: Revision3: Corrected: RFR 8059557 (XL): Validate JVM Command-Line Flag Arguments In-Reply-To: <557C3EF0.3030107@oracle.com> References: <557C3EF0.3030107@oracle.com> Message-ID: <0967AA32-430D-430F-98E2-BF70F77287B8@oracle.com> On Jun 13, 2015, at 10:32 AM, Gerard Ziemski wrote: > > Here is a revision 3 of the feature taking into account feedback from Kim Barrett, David Holmes, Derek White and Bengt Rutisson. I have also merged the changes to the latest jdk9. > > [?] > > The code change builds and passes JPRT (-testset hotspot) and UTE (vm.quick.testlist) > > > References: > > Webrev: > http://cr.openjdk.java.net/~gziemski/8059557_rev3 > > JEP: > https://bugs.openjdk.java.net/browse/JDK-8059557 > > Compiler subtask: > https://bugs.openjdk.java.net/browse/JDK-8078554 > > GC subtask: > https://bugs.openjdk.java.net/browse/JDK-8078555 > > Runtime subtask: > https://bugs.openjdk.java.net/browse/JDK-8078556 > > > Note: due to "awk" limit of 50 pats the Frames diff is not available for "src/share/vm/runtime/arguments.cpp? and "src/share/vm/runtime/globals.cpp? > > > Followup issues: > > JDK-8085866: There are 99 uses of FLAG_SET_ERGO, should they check the return value? > JDK-8085864: FLAG_SET_CMDLINE in TestGenCollectorPolicy() currently ignore the return values > JDK-8081842: Find a better place for EMIT_{CONSTRAINTS,RANGES}_FOR_GLOBALS_EXT > JDK-8081833: There is a large amount of code near-duplication among the various CommandLineFlagRange_ classes > JDK-8081519: Split globals.hpp to factor out the Flag values needed by JDK-8059557 Here are a few comments on Revision3. I think all of these can (and should) be handled via followup CRs, and that none of these should prevent Revision3 from being pushed as is. If another round of review for this change does prove to be needed (I hope not), please provide an incremental webrev in the review package. ------------------------------------------------------------------------------ src/share/vm/gc/g1/g1_globals.hpp 71 product(double, G1ConcMarkStepDurationMillis, 10.0, \ 72 "Target duration of individual concurrent marking steps " \ 73 "in milliseconds.") \ 74 range(1.0, (double)max_uintx) \ The new upper bound here seems like a completely random number to me. ------------------------------------------------------------------------------ src/share/vm/opto/c2_globals.hpp 110 notproduct(intx, IndexSetWatch, 0, \ 111 "Trace all operations on this IndexSet (-1 means all, 0 none)") \ 112 range(-1, 0) \ I suspect the upper bound here should be uint_max. ------------------------------------------------------------------------------ src/share/vm/runtime/globals.hpp 375 static const char* flag_error_str(Flag::Error error) { All other functions for the Flag are declared in the .hpp and defined in the .cpp file. I don't see any reason for this function to be different. ------------------------------------------------------------------------------ src/share/vm/runtime/globals.hpp 1563 product(size_t, HeapSizePerGCThread, ScaleForWordSize(64*M), \ 1564 "Size of heap (bytes) per GC thread used in calculating the " \ 1565 "number of GC threads") \ 1566 range((uintx)os::vm_page_size(), max_uintx) \ Type is size_t, but range values are using uintx. ------------------------------------------------------------------------------ src/share/vm/runtime/globals.hpp 1846 product(size_t, MarkStackSizeMax, NOT_LP64(4*M) LP64_ONLY(512*M), \ 1847 "Maximum size of marking stack") \ 1848 range(1, (max_jint - 1)) \ That's a very odd looking maximum. ------------------------------------------------------------------------------ src/share/vm/services/classLoadingService.cpp 35 #include "utilities/defaultStream.hpp" I think utilities/ostream.hpp might be sufficient here. ------------------------------------------------------------------------------ src/share/vm/runtime/commandLineFlagConstraintsGC.cpp 100 #define UseConcMarkSweepGCWorkaroundIfNeeded(initial, max) { \ 101 if ((initial == 7) && (max == 6)) { \ 102 return Flag::SUCCESS; \ 103 } \ 104 } The do/while(0) macro idiom is the usual way to encapsulate statements. It took me a couple of tries to parse this, where it would have been immediately obvious with the do/while(0) idiom. ------------------------------------------------------------------------------ src/share/vm/runtime/globals.cpp In the various apply_constraint_and_check_range_TYPE functions, the present pattern seems to be to find and check the range (if it exists), then find and apply the constraint (if it exists), and then combine the results. I think it might be better to not apply the constraint if there is a range check failure. That way, constraint functions can be written to assume that the values have been range checked, and only need to worry about whatever additional constraints might exist, without the need to potentially deal with out of range values. Whichever behavior is used should be documented as part of the interface to this facility, since it affects how one writes constraint functions. It might also, in some cases, affect whether it is useful to provide a range spec in conjunction with a constraint function. Such a change might also eliminate the need for the get_status_error helper. [Obviously this is pretty high priority if handled as a followup change, since it has a somewhat significant impact on how one writes constraint functions.] ------------------------------------------------------------------------------ From erik.osterlund at lnu.se Sun Jun 14 00:25:23 2015 From: erik.osterlund at lnu.se (=?windows-1254?Q?Erik_=D6sterlund?=) Date: Sun, 14 Jun 2015 00:25:23 +0000 Subject: RFR: 8079315: UseCondCardMark broken in conjunction with CMS precleaning In-Reply-To: References: <5548D913.1030507@redhat.com> <5548F59D.6090008@oracle.com> <5549D681.3000806@redhat.com> <554A1CA0.6070801@oracle.com> <473C887F-8CC5-4E67-BD9A-1882660CFD3C@lnu.se> <554B3B5E.8000705@oracle.com> <8EE73C49-83CD-4162-A3EF-19DDA2C2CDFA@lnu.se> <554FC66F.20307@oracle.com> <55507BE4.3050605@redhat.com> <03C141D8-952E-4E7A-BDAD-024CE2239010@lnu.se> <55508B60.1000200@redhat.com> <8868A273-7C97-45F0-BF10-85DDE5859E85@lnu.se> <5550B182.7090009@redhat.com> <5551FA97.9090502@oracle.com> <5551FD72.1020504@oracle.com> <38CAAA0B-6F32-4508-818F-AD9D248E8B35@lnu.se> <55524C58.4030904@oracle.com> <55524E8C.6080709@redhat.com> <55526041.1030709@redhat.com> <7C4CBC57-D7B2-4779-9353-DEACCB626370@lnu.se> <5552838B.3020305@oracle.com> <556D5EF9.6030702@redhat.com> <556D7692.3070707@oracle.com> Message-ID: Hi guys, Short story: I talked to Dave Dice about my ADS implementation(s). He agrees my ADS is ?probably safe?, but explained that just fencing is probably preferred over ADS for the future anyway due to current hardware trends of optimizing fences. Long story: The motivation why fences are more attractive is that they are getting faster and faster by letting CPUs speculate more about the execution over fencing points, instead of waiting for the entire store buffer to serialize. Instead it speculates and only restarts if speculative load are invalidated before the stores that should have flushed at the fencing checkpoint have been flushed. This way fences are getting significantly cheaper as speculative windows continue to increase, whereas the TLB-shootdown hardware doesn?t have as many good solutions for becoming more scalable right now and can become expensive on multi-socket systems. Therefore, it makes sense to use fences instead, because they seem to have a brighter future with current hardware trends, and scale better. Therefore, let?s go for fences! :) Thanks, /Erik Den 02/06/15 12:22 skrev Erik ?sterlund : >Hi Aleksey, > >Den 02/06/15 11:25 skrev Aleksey Shipilev : > >>On 06/02/2015 10:44 AM, Andrew Haley wrote: >>> Have we come to a complete standstill? >> >>Appears to be so. >> >>I am still uneasy about global_store_fence/mprotect trick, since I don't >>quite believe it works without a hitch everywhere, even given Erik's >>extensive explanation it "appears" to work fine. Erik, can you follow up >>with Dave Dice on whether that is actually safe? > >Sure, will do. > >>The original StoreLoad patch by Andrew looks moderately okay to me, >>given it is conditionalized for CMS (I wonder if it should be >>conditionalized on CMSPrecleaningEnabled?). Google folks may chime in >>saying it breaks the performance for them... > >I think the patch looks okay for now, and it?s important to get a >correctness fix although potentially suboptimal in terms of performance >ASAP. I have a feeling the global_fence discussion could take a while >before reaching a conclusion, don?t know how long. It would be good to >have the correctness fix while exploring better performant synchronization >solutions to elide the fences. > >Yes, Google folks might say there are performance regressions then, but >others might complain the JVM unexpectedly crashes now as it is now. I >think this is worse. > >Thanks, >/Erik > >>Actually, GC guys should make this call. >> >>Thanks, >>-Aleksey >> >> > From erik.osterlund at lnu.se Sun Jun 14 00:53:59 2015 From: erik.osterlund at lnu.se (=?utf-8?B?RXJpayDDlnN0ZXJsdW5k?=) Date: Sun, 14 Jun 2015 00:53:59 +0000 Subject: Dynamic G1 barrier elision for C2 in young In-Reply-To: References: Message-ID: <2F2AB31D-E6E4-4E8F-BF58-C8DEE0325264@lnu.se> Hi Vitaly, Thank you for liking the idea! What I had in mind was optimizing young objects because it?s easy to reason about consistency, but I suppose in such cases even old objects could be optimized. But that would require more care and I don?t know how common such applications are as Java is widely marketed as having cheap allocations. Anyway, the approach could be refined much more if plugged into an engine for points-to analysis. It gives a set of possible allocation points for object references, which could in our case be exploited when emitting reference store code. If objects are then given different Klass pointers (soft handles) for different allocation points at runtime, then the approach could find more opportunities for barrier elision. In cases where the same class is used in different parts of code, sometimes as temporary objects and sometimes as old objects, the difference would be identified and barriers would be elided for the code dealing with the always temporary variants of the class, but not for code dealing with the potentially old objects of the same class. Not sure how low hanging that fruit is though? but C2 does some of that stuff already for lock elision using escape analysis I think, although not intra-procedural (yet) if I get it right. Could have a look when I have time if anyone is interested in this kind of stuff. Thanks, /Erik > On 11 Jun 2015, at 06:26, Vitaly Davidovich wrote: > > Hi Erik, > > I think this is a neat idea. There's a class of java programs that don't trigger any GC while up (or very few GCs at specific points in time). Typically these are the same types of apps that pool objects on free lists, and thus incur write barrier overhead for no actual gain. FWIW, I'd welcome such elision but would also like to see it for the parallel collector :). > > Thanks > > sent from my phone > > On Jun 8, 2015 6:00 AM, "Erik ?sterlund" > wrote: > Hi, > > Since this concerns compiler too, I decided to CC hotspot-dev. > > Thanks, > /Erik > > Den 06/06/15 02:44 skrev Erik ?sterlund >: > > >Hi guys, > > > >Making G1 run faster on GC-tuned applications that are designed to only > >rarely spill objects into old, seems like an interesting and important > >optimization goal at the moment. > > > >Today I tried an interesting experiment. I sample garbage during the > >sweeping phase (phase 2) of System.gc() (G1MarkSweep) that stumbles > >through garbage anyway, hoping to find classes with instances that are > >used all the time, but /never/ make it into old. Then I deoptimize these > >classes and recompile the relevant nmethods depending on the class to > >elide the G1 write barriers (in C2). If the GC eventually needs to promote > >any of these objects to old, I just deoptimize again and recompile with G1 > >barriers turned back on. > > > >On some DaCapo benchmarks, it payed off very well for a few benchmarks > >that supposedly use many temporary objects: > >fop: -9.2% time <- this one was brutal!! > >xalan: -6.9% time > >jython: -5.9% time > > > >Results were measured with 40 warmup iterations, and then computed the > >average of the following 10 iterations, so 50 iterations in total. Class > >unloading was turned off (using my own patch to make -Xnoclassgc work, > >because it seems to be broken currently) and 512M heaps. > > > > > >The G1 barriers are already optimized to be faster for young objects, but > >if the GC finds out that certain types of objects /never/ get old, telling > >the compiler so allows complete elision of both the pre and post barriers > >from the code which is nice. > > > >Are we conceptually interested in such a solution, potentially accompanied > >with a flag like -XX:+G1DynamicallyOptimizeYoung? Thought I?d check if I > >can get some feedback before going too far with this. > > > >Here is the code I used. > > > >Patch 1: -Xnoclassgc > >http://cr.openjdk.java.net/~eosterlund/g1_experiments/noclassgc/webrev.00/ > > > >This just fixes an issue that -Xnoclassgc doesn?t work properly using G1 > >(unfortunately I have yet to get the bug system work to report it...). > >With this JVM flag, it should not do class unloading. I had to run my > >experiments without class unloading because it killed the optimized > >nmethods of the almost always dead objects I want to optimize in DaCapo, > >because DaCapo does not retain their class loaders or something. > > > >Patch 2: Dynamic G1 barrier elision > >http://cr.openjdk.java.net/~eosterlund/g1_experiments/dynamic_barrier_elis > >i > >on/webrev.00/ > > > >This is where the interesting stuff went if anyone is interested. This is > >just a very basic prototype/concept to check if the approach seems > >interesting to you guys. You probably want to add stuff like deoptimizing > >less (only if there are fields to actually optimize/deoptimize - keep > >track of that more accurately), and to sample garbage outside of > >System.gc() - this was just a convenience for now, and being more accurate > >with which class declared a field, not the canonical class, etc. > > > >Any comments are welcome. > > > >Thanks, > >/Erik > > > > > From aph at redhat.com Sun Jun 14 08:37:45 2015 From: aph at redhat.com (Andrew Haley) Date: Sun, 14 Jun 2015 09:37:45 +0100 Subject: RFR: 8079315: UseCondCardMark broken in conjunction with CMS precleaning In-Reply-To: References: <5548D913.1030507@redhat.com> <5549D681.3000806@redhat.com> <554A1CA0.6070801@oracle.com> <473C887F-8CC5-4E67-BD9A-1882660CFD3C@lnu.se> <554B3B5E.8000705@oracle.com> <8EE73C49-83CD-4162-A3EF-19DDA2C2CDFA@lnu.se> <554FC66F.20307@oracle.com> <55507BE4.3050605@redhat.com> <03C141D8-952E-4E7A-BDAD-024CE2239010@lnu.se> <55508B60.1000200@redhat.com> <8868A273-7C97-45F0-BF10-85DDE5859E85@lnu.se> <5550B182.7090009@redhat.com> <5551FA97.9090502@oracle.com> <5551FD72.1020504@oracle.com> <38CAAA0B-6F32-4508-818F-AD9D248E8B35@lnu.se> <55524C58.4030904@oracle.com> <55524E8C.6080709@redhat.com> <55526041.1030709@redhat.com> <7C4CBC57-D7B2-4779-9353-DEACCB626370@lnu.se> <5552838B.3020305@oracle.com> <556D5EF9.6030702@redhat.com> <556D7692.3070707@oracle.com> Message-ID: <557D3D59.4000806@redhat.com> On 14/06/15 01:25, Erik ?sterlund wrote: > Short story: > I talked to Dave Dice about my ADS implementation(s). He agrees my ADS is > ?probably safe?, but explained that just fencing is probably preferred > over ADS for the future anyway due to current hardware trends of > optimizing fences. ... > Therefore, let?s go for fences! :) Great, thanks very much for your work one this. Andrew. From david.holmes at oracle.com Sun Jun 14 23:47:52 2015 From: david.holmes at oracle.com (David Holmes) Date: Mon, 15 Jun 2015 09:47:52 +1000 Subject: RFR: 8087322: Implement a Semaphore utility class In-Reply-To: <557AF8E4.9040804@oracle.com> References: <557AF8E4.9040804@oracle.com> Message-ID: <557E12A8.9080006@oracle.com> Hi Stefan, Quick response - sorry will try to get back to this later. I second the comment to define an os_posix implementation and to do it now rather than defer it for future work. Solaris supports POSIX semaphore API (as well as the SUS/UI semaphore API). This may boil down to only two implementations: posix and win32. I don't see the point of the "max" value in the API given it can't used on all platforms. The posix semaphore functions return -1 and set errno on error, so any guarantees (asserts are normally used here) should do the appropriate errno string conversion. Defining operations as Unimplemented on Windows is bad form. I see no reason these should be unimplemented as WaitForSingleObject handles the required semantics. I'm not a fan of the creeping use of "unit tests" inside the main sources - have I missed some memo on that? Single-threaded unit tests for something like Semaphore seems to only be paying lip-service to the testing aspect anyway. Thanks, David On 13/06/2015 1:21 AM, Stefan Karlsson wrote: > Hi all, > > Please review this patch to create a Semaphore utility class. I need > this class to implementing faster GC thread synchronization [1]. > > http://cr.openjdk.java.net/~stefank/8087322/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8087322 > > Some of our platforms already implement a Semaphore class, but those > classes are hidden inside os_.cpp. I've moved the class declaration > to semaphore.hpp, but the implementation is left in the os_.hpp. I > considered creating semaphore_.cpp files, but I ended up having to > restructure too much code and I wanted to focus on the feature in [1] > instead. Should I create a RFE to move the semaphore implementations? > > There seems to be another opportunity to cleanup the code. If we take > os_linux.cpp, as an example, the code uses both the existing Semaphore > class and the global ::sem_wait and ::sem_post functions. We might want > to consider unifying that code. > > Since HotSpot is built on platforms that I don't have access to and > can't test, I've added the IMPLEMENTS_SEMAPHORE_CLASS define. So, that I > can detect if the the current platform implements the Semaphore class, > and choose what synchronization primitive to use by the GC. > > The os_bsd.cpp file has support for "non-apple BSD", but I've only > tested this patch with OS X. > > This patch has been tested in JPRT and our nightly testing together with > the patches in [1]. The patch also contains a few unit tests in > semaphore.cpp. > > Thanks, > StefanK > > [1] > http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2015-June/013829.html From david.holmes at oracle.com Mon Jun 15 02:31:21 2015 From: david.holmes at oracle.com (David Holmes) Date: Mon, 15 Jun 2015 12:31:21 +1000 Subject: Revision3: Corrected: RFR 8059557 (XL): Validate JVM Command-Line Flag Arguments In-Reply-To: <557C3EF0.3030107@oracle.com> References: <557C3EF0.3030107@oracle.com> Message-ID: <557E38F9.9010105@oracle.com> Hi Gerard, Any chance you could produce and incremental webrev please? Thanks, David On 14/06/2015 12:32 AM, Gerard Ziemski wrote: > hi all, > > Thank you for the reviews so far! > > Here is a revision 3 of the feature taking into account feedback from Kim Barrett, David Holmes, Derek White and Bengt Rutisson. I have also merged the changes to the latest jdk9. > > We introduce a new mechanism that allows specification of a valid range per flag that is then used to automatically validate given flag's value every time it changes. Ranges values must be constant and can not change. Optionally, a constraint can also be specified and applied every time a flag value changes for those flags whose valid value can not be trivially checked by a simple min and max (ex. whether it's power of 2, or bigger or smaller than some other flag that can also change) > > I have chosen to modify the table macros (ex. RUNTIME_FLAGS in globals.hpp) instead of using a more sophisticated solution, such as C++ templates, because even though macros were unfriendly when initially developing, once a solution was arrived at, subsequent additions to the tables of new ranges, or constraint are trivial from developer's point of view. (The intial development unfriendliness of macros was mitigated by using a pre-processor, which for those using a modern IDE like Xcode, is easily available from a menu). Using macros also allowed for more minimal code changes. > > The presented solution is based on expansion of macros using variadic functions and can be readily seen in runtime/commandLineFlagConstraintList.cpp and runtime/commandLineFlagRangeList.cpp > > In commandLineFlagConstraintList.cpp or commandLineFlagRangesList.cpp, there is bunch of classes and methods that seems to beg for C++ template to be used. I have tried, but when the compiler tries to generate code for both uintx and size_t, which happen to have the same underlying type (on BSD), it fails to compile overridden methods with same type, but different name. If someone has a way of simplifying the new code via C++ templates, however, we can file a new enhancement request to address that. > > This webrev represents only the initial range checking framework and only 100 or so flags that were ported from an existing ad hoc range checking code to this new mechanism. There are about 250 remaining flags that still need their ranges determined and ported over to this new mechanism and they are tracked by individual subtasks. > > I had to modify several existing tests to change the error message that they expected when VM refuses to run, which was changed to provide uniform error messages. > > To help with testing and subtask efforts I have introduced a new runtime flag: > > PrintFlagsRanges: "Print VM flags and their ranges and exit VM" > > which in addition to the already existing flags: "PrintFlagsInitial" and "PrintFlagsFinal" allow for thorough examination of the flags values and their ranges. > > The code change builds and passes JPRT (-testset hotspot) and UTE (vm.quick.testlist) > > > References: > > Webrev:http://cr.openjdk.java.net/~gziemski/8059557_rev3 > JEP:https://bugs.openjdk.java.net/browse/JDK-8059557 > Compiler subtask:https://bugs.openjdk.java.net/browse/JDK-8078554 > GC subtask:https://bugs.openjdk.java.net/browse/JDK-8078555 > Runtime subtask:https://bugs.openjdk.java.net/browse/JDK-8078556 > > Note: due to "awk" limit of 50 pats the Frames diff is not available for "src/share/vm/runtime/arguments.cpp? and "src/share/vm/runtime/globals.cpp? > > > Followup issues: > > JDK-8085866: There are 99 uses of FLAG_SET_ERGO, should they check the return value? > JDK-8085864: FLAG_SET_CMDLINE in TestGenCollectorPolicy() currently ignore the return values > JDK-8081842: Find a better place for EMIT_{CONSTRAINTS,RANGES}_FOR_GLOBALS_EXT > JDK-8081833: There is a large amount of code near-duplication among the various CommandLineFlagRange_ classes > JDK-8081519: Split globals.hpp to factor out the Flag values needed by JDK-8059557 > > > hgstat: > > src/cpu/ppc/vm/globals_ppc.hpp | 2 +- > src/cpu/sparc/vm/globals_sparc.hpp | 2 +- > src/cpu/x86/vm/globals_x86.hpp | 2 +- > src/cpu/zero/vm/globals_zero.hpp | 3 +- > src/os/aix/vm/globals_aix.hpp | 2 +- > src/os/bsd/vm/globals_bsd.hpp | 29 +- > src/os/linux/vm/globals_linux.hpp | 9 +- > src/os/solaris/vm/globals_solaris.hpp | 4 +- > src/os/windows/vm/globals_windows.hpp | 5 +- > src/share/vm/c1/c1_globals.cpp | 4 +- > src/share/vm/c1/c1_globals.hpp | 17 +- > src/share/vm/gc/g1/g1_globals.cpp | 14 +- > src/share/vm/gc/g1/g1_globals.hpp | 38 +- > src/share/vm/opto/c2_globals.cpp | 12 +- > src/share/vm/opto/c2_globals.hpp | 40 +- > src/share/vm/prims/whitebox.cpp | 12 +- > src/share/vm/runtime/arguments.cpp | 765 ++++++---------- > src/share/vm/runtime/arguments.hpp | 24 +- > src/share/vm/runtime/commandLineFlagConstraintList.cpp | 286 ++++++ > src/share/vm/runtime/commandLineFlagConstraintList.hpp | 80 + > src/share/vm/runtime/commandLineFlagConstraintsCompiler.cpp | 44 + > src/share/vm/runtime/commandLineFlagConstraintsCompiler.hpp | 39 + > src/share/vm/runtime/commandLineFlagConstraintsGC.cpp | 235 +++++ > src/share/vm/runtime/commandLineFlagConstraintsGC.hpp | 58 + > src/share/vm/runtime/commandLineFlagConstraintsRuntime.cpp | 65 + > src/share/vm/runtime/commandLineFlagConstraintsRuntime.hpp | 41 + > src/share/vm/runtime/commandLineFlagRangeList.cpp | 367 ++++++++ > src/share/vm/runtime/commandLineFlagRangeList.hpp | 71 + > src/share/vm/runtime/globals.cpp | 721 ++++++++++++--- > src/share/vm/runtime/globals.hpp | 343 ++++++- > src/share/vm/runtime/globals_extension.hpp | 105 +- > src/share/vm/runtime/init.cpp | 5 +- > src/share/vm/runtime/os_ext.hpp | 7 +- > src/share/vm/runtime/thread.cpp | 6 + > src/share/vm/services/attachListener.cpp | 4 +- > src/share/vm/services/classLoadingService.cpp | 12 +- > src/share/vm/services/diagnosticCommand.cpp | 3 +- > src/share/vm/services/management.cpp | 6 +- > src/share/vm/services/memoryService.cpp | 4 +- > src/share/vm/services/writeableFlags.cpp | 183 ++- > src/share/vm/services/writeableFlags.hpp | 60 +- > test/compiler/c2/7200264/Test7200264.sh | 5 +- > test/compiler/startup/NumCompilerThreadsCheck.java | 2 +- > test/gc/arguments/TestHeapFreeRatio.java | 23 +- > test/gc/arguments/TestSurvivorAlignmentInBytesOption.java | 6 +- > test/gc/g1/TestStringDeduplicationTools.java | 6 +- > test/runtime/CompressedOops/CompressedClassSpaceSize.java | 4 +- > test/runtime/CompressedOops/ObjectAlignment.java | 9 +- > test/runtime/contended/Options.java | 10 +- > 49 files changed, 2851 insertions(+), 943 deletions(-) > From stefan.karlsson at oracle.com Mon Jun 15 06:40:04 2015 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Mon, 15 Jun 2015 08:40:04 +0200 Subject: RFR: 8087322: Implement a Semaphore utility class In-Reply-To: <557E12A8.9080006@oracle.com> References: <557AF8E4.9040804@oracle.com> <557E12A8.9080006@oracle.com> Message-ID: <557E7344.9060104@oracle.com> Hi David, On 2015-06-15 01:47, David Holmes wrote: > Hi Stefan, > > Quick response - sorry will try to get back to this later. > > I second the comment to define an os_posix implementation and to do it > now rather than defer it for future work. Solaris supports POSIX > semaphore API (as well as the SUS/UI semaphore API). This may boil > down to only two implementations: posix and win32. This adds risk to this patch. Are we sure that the Solaris OS code doesn't rely on some implementation detail of sema_post/sema_wait that is different from how the POSIX semaphores work? For example, how it interacts with signal handlers, etc? > > I don't see the point of the "max" value in the API given it can't > used on all platforms. I don't want it either, but it's needed by the windows implementation. I could get rid of it if we have a sensible max value. Any suggestion on what value to use? > > The posix semaphore functions return -1 and set errno on error, so any > guarantees (asserts are normally used here) I can change to asserts. > should do the appropriate errno string conversion. I followed the surrounding code. For example: 3411 jio_snprintf(msg, sizeof(msg), "Failed to reserve shared memory (errno = %d).", errno); but I see that we print a string at other places. I can change it. BTW, while looking at the return values of sema_wait, I found the following: 2433 while ((ret = ::sema_wait(&sig_sem)) == EINTR) 2434 ; I wonder if this code is broken. Since it checks the return value against EINTR and not errno. > > Defining operations as Unimplemented on Windows is bad form. I see no > reason these should be unimplemented as WaitForSingleObject handles > the required semantics. But that means adding dead/untested code. That's another kind of bad form. > > I'm not a fan of the creeping use of "unit tests" inside the main > sources - have I missed some memo on that? We have been doing that for many years now. > Single-threaded unit tests for something like Semaphore seems to only > be paying lip-service to the testing aspect anyway. It tests boundary conditions. What do other Reviewers think. Should I remove the tests? Thanks, StefanK > > Thanks, > David > > On 13/06/2015 1:21 AM, Stefan Karlsson wrote: >> Hi all, >> >> Please review this patch to create a Semaphore utility class. I need >> this class to implementing faster GC thread synchronization [1]. >> >> http://cr.openjdk.java.net/~stefank/8087322/webrev.00/ >> https://bugs.openjdk.java.net/browse/JDK-8087322 >> >> Some of our platforms already implement a Semaphore class, but those >> classes are hidden inside os_.cpp. I've moved the class declaration >> to semaphore.hpp, but the implementation is left in the os_.hpp. I >> considered creating semaphore_.cpp files, but I ended up having to >> restructure too much code and I wanted to focus on the feature in [1] >> instead. Should I create a RFE to move the semaphore implementations? >> >> There seems to be another opportunity to cleanup the code. If we take >> os_linux.cpp, as an example, the code uses both the existing Semaphore >> class and the global ::sem_wait and ::sem_post functions. We might want >> to consider unifying that code. >> >> Since HotSpot is built on platforms that I don't have access to and >> can't test, I've added the IMPLEMENTS_SEMAPHORE_CLASS define. So, that I >> can detect if the the current platform implements the Semaphore class, >> and choose what synchronization primitive to use by the GC. >> >> The os_bsd.cpp file has support for "non-apple BSD", but I've only >> tested this patch with OS X. >> >> This patch has been tested in JPRT and our nightly testing together with >> the patches in [1]. The patch also contains a few unit tests in >> semaphore.cpp. >> >> Thanks, >> StefanK >> >> [1] >> http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2015-June/013829.html >> From david.holmes at oracle.com Mon Jun 15 07:17:46 2015 From: david.holmes at oracle.com (David Holmes) Date: Mon, 15 Jun 2015 17:17:46 +1000 Subject: RFR: 8087322: Implement a Semaphore utility class In-Reply-To: <557E7344.9060104@oracle.com> References: <557AF8E4.9040804@oracle.com> <557E12A8.9080006@oracle.com> <557E7344.9060104@oracle.com> Message-ID: <557E7C1A.8060902@oracle.com> Hi Stefan, On 15/06/2015 4:40 PM, Stefan Karlsson wrote: > Hi David, > > On 2015-06-15 01:47, David Holmes wrote: >> Hi Stefan, >> >> Quick response - sorry will try to get back to this later. >> >> I second the comment to define an os_posix implementation and to do it >> now rather than defer it for future work. Solaris supports POSIX >> semaphore API (as well as the SUS/UI semaphore API). This may boil >> down to only two implementations: posix and win32. > > This adds risk to this patch. Are we sure that the Solaris OS code > doesn't rely on some implementation detail of sema_post/sema_wait that > is different from how the POSIX semaphores work? For example, how it > interacts with signal handlers, etc? Solaris supports two different semaphore API's. The POSIX API has sem_wait, sem_post etc and operates on sem_t. The other (SUS or UI or Solaris-only ?) API has sema_* and operates on sema_t - it is a very subtle difference: sem vs sema. Under the covers they are the same thing, but the API's themselves have some differences. You can use the POSIX API on Solaris, just as on Linux and hopefully BSD (and maybe AIX?) >> >> I don't see the point of the "max" value in the API given it can't >> used on all platforms. > > I don't want it either, but it's needed by the windows implementation. I > could get rid of it if we have a sensible max value. Any suggestion on > what value to use? On Windows pass in whatever MAX windows defines. >> >> The posix semaphore functions return -1 and set errno on error, so any >> guarantees (asserts are normally used here) > > I can change to asserts. > >> should do the appropriate errno string conversion. > > I followed the surrounding code. For example: > > 3411 jio_snprintf(msg, sizeof(msg), "Failed to reserve shared memory (errno = %d).", errno); > > but I see that we print a string at other places. I can change it. Thanks. > > BTW, while looking at the return values of sema_wait, I found the following: > > 2433 while ((ret = ::sema_wait(&sig_sem)) == EINTR) > 2434 ; > > I wonder if this code is broken. Since it checks the return value against EINTR and not errno. sema_wait returns zero or an error code. POSIX sem_wait returns 0/-1 and sets errno. > >> >> Defining operations as Unimplemented on Windows is bad form. I see no >> reason these should be unimplemented as WaitForSingleObject handles >> the required semantics. > > But that means adding dead/untested code. That's another kind of bad form. Can you elaborate on why only part of the API is being used on Windows? I would have hoped the client code was cross-platform. >> >> I'm not a fan of the creeping use of "unit tests" inside the main >> sources - have I missed some memo on that? > > We have been doing that for many years now. "we" have? I've only noticed a few occurrences :) Thanks, David ----- >> Single-threaded unit tests for something like Semaphore seems to only >> be paying lip-service to the testing aspect anyway. > > It tests boundary conditions. What do other Reviewers think. Should I > remove the tests? > > Thanks, > StefanK >> >> Thanks, >> David >> >> On 13/06/2015 1:21 AM, Stefan Karlsson wrote: >>> Hi all, >>> >>> Please review this patch to create a Semaphore utility class. I need >>> this class to implementing faster GC thread synchronization [1]. >>> >>> http://cr.openjdk.java.net/~stefank/8087322/webrev.00/ >>> https://bugs.openjdk.java.net/browse/JDK-8087322 >>> >>> Some of our platforms already implement a Semaphore class, but those >>> classes are hidden inside os_.cpp. I've moved the class declaration >>> to semaphore.hpp, but the implementation is left in the os_.hpp. I >>> considered creating semaphore_.cpp files, but I ended up having to >>> restructure too much code and I wanted to focus on the feature in [1] >>> instead. Should I create a RFE to move the semaphore implementations? >>> >>> There seems to be another opportunity to cleanup the code. If we take >>> os_linux.cpp, as an example, the code uses both the existing Semaphore >>> class and the global ::sem_wait and ::sem_post functions. We might want >>> to consider unifying that code. >>> >>> Since HotSpot is built on platforms that I don't have access to and >>> can't test, I've added the IMPLEMENTS_SEMAPHORE_CLASS define. So, that I >>> can detect if the the current platform implements the Semaphore class, >>> and choose what synchronization primitive to use by the GC. >>> >>> The os_bsd.cpp file has support for "non-apple BSD", but I've only >>> tested this patch with OS X. >>> >>> This patch has been tested in JPRT and our nightly testing together with >>> the patches in [1]. The patch also contains a few unit tests in >>> semaphore.cpp. >>> >>> Thanks, >>> StefanK >>> >>> [1] >>> http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2015-June/013829.html >>> > From erik.helin at oracle.com Mon Jun 15 08:41:52 2015 From: erik.helin at oracle.com (Erik Helin) Date: Mon, 15 Jun 2015 10:41:52 +0200 Subject: RFR: 8087322: Implement a Semaphore utility class In-Reply-To: <557E7344.9060104@oracle.com> References: <557AF8E4.9040804@oracle.com> <557E12A8.9080006@oracle.com> <557E7344.9060104@oracle.com> Message-ID: <20150615084152.GE29290@ehelin.jrpg.bea.com> On 2015-06-15, Stefan Karlsson wrote: > Hi David, > > On 2015-06-15 01:47, David Holmes wrote: > >Hi Stefan, > > > >Quick response - sorry will try to get back to this later. > > > >I second the comment to define an os_posix implementation and to do it now > >rather than defer it for future work. Solaris supports POSIX semaphore API > >(as well as the SUS/UI semaphore API). This may boil down to only two > >implementations: posix and win32. > > This adds risk to this patch. Are we sure that the Solaris OS code doesn't > rely on some implementation detail of sema_post/sema_wait that is different > from how the POSIX semaphores work? For example, how it interacts with > signal handlers, etc? > > > > >I don't see the point of the "max" value in the API given it can't used on > >all platforms. > > I don't want it either, but it's needed by the windows implementation. I > could get rid of it if we have a sensible max value. Any suggestion on what > value to use? > > > > >The posix semaphore functions return -1 and set errno on error, so any > >guarantees (asserts are normally used here) > > I can change to asserts. > > >should do the appropriate errno string conversion. > > I followed the surrounding code. For example: > > 3411 jio_snprintf(msg, sizeof(msg), "Failed to reserve shared memory (errno = %d).", errno); > > but I see that we print a string at other places. I can change it. > > > BTW, while looking at the return values of sema_wait, I found the following: > > 2433 while ((ret = ::sema_wait(&sig_sem)) == EINTR) > 2434 ; > > I wonder if this code is broken. Since it checks the return value against EINTR and not errno. > > > > > >Defining operations as Unimplemented on Windows is bad form. I see no > >reason these should be unimplemented as WaitForSingleObject handles the > >required semantics. > > But that means adding dead/untested code. That's another kind of bad form. > > > > >I'm not a fan of the creeping use of "unit tests" inside the main sources > >- have I missed some memo on that? > > We have been doing that for many years now. > > >Single-threaded unit tests for something like Semaphore seems to only be > >paying lip-service to the testing aspect anyway. Well, if the tests are easy to implement and verify, why not implement them? There is of course a need for more testing, especially those parts that are not covered by the unit tests, but at least those test won't have to care about verifying what is covered by these unit tests. > It tests boundary conditions. What do other Reviewers think. Should I remove > the tests? No, keep them. Even though you can only test the single-threaded case, it helps me understand and review the change. I also appreciate that you took the time to write the tests! Thanks, Erik > Thanks, > StefanK > > > >Thanks, > >David > > > >On 13/06/2015 1:21 AM, Stefan Karlsson wrote: > >>Hi all, > >> > >>Please review this patch to create a Semaphore utility class. I need > >>this class to implementing faster GC thread synchronization [1]. > >> > >>http://cr.openjdk.java.net/~stefank/8087322/webrev.00/ > >>https://bugs.openjdk.java.net/browse/JDK-8087322 > >> > >>Some of our platforms already implement a Semaphore class, but those > >>classes are hidden inside os_.cpp. I've moved the class declaration > >>to semaphore.hpp, but the implementation is left in the os_.hpp. I > >>considered creating semaphore_.cpp files, but I ended up having to > >>restructure too much code and I wanted to focus on the feature in [1] > >>instead. Should I create a RFE to move the semaphore implementations? > >> > >>There seems to be another opportunity to cleanup the code. If we take > >>os_linux.cpp, as an example, the code uses both the existing Semaphore > >>class and the global ::sem_wait and ::sem_post functions. We might want > >>to consider unifying that code. > >> > >>Since HotSpot is built on platforms that I don't have access to and > >>can't test, I've added the IMPLEMENTS_SEMAPHORE_CLASS define. So, that I > >>can detect if the the current platform implements the Semaphore class, > >>and choose what synchronization primitive to use by the GC. > >> > >>The os_bsd.cpp file has support for "non-apple BSD", but I've only > >>tested this patch with OS X. > >> > >>This patch has been tested in JPRT and our nightly testing together with > >>the patches in [1]. The patch also contains a few unit tests in > >>semaphore.cpp. > >> > >>Thanks, > >>StefanK > >> > >>[1] > >>http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2015-June/013829.html > >> > From thomas.schatzl at oracle.com Mon Jun 15 08:53:25 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Mon, 15 Jun 2015 10:53:25 +0200 Subject: RFR: 8087200: Code heap does not use large pages In-Reply-To: <20150612151552.GD29290@ehelin.jrpg.bea.com> References: <20150612151552.GD29290@ehelin.jrpg.bea.com> Message-ID: <1434358405.2573.2.camel@oracle.com> Hi Erik, On Fri, 2015-06-12 at 17:15 +0200, Erik Helin wrote: > Hi all, > > this patch fixes an issue with the page sizing in in the code heap > in 8u60 that was introduced in the backport for JDK-8049864. The issue does > not exist in JDK 9 because the code heap in JDK 9 has been rewritten and > uses the VirtualSpace to decide the page size for the reserved size > (there is still an issue with the alignment of the comittted size in JDK > 9, see JDK-8087339 [0]). > > The fix for 8u60 consists of using the reserved size to determine the > page size (and not require that the page size divides the reserved > size, because the reserved size will be aligned to the page size later > anyway). > > Webrev: > http://cr.openjdk.java.net/~ehelin/8087200/webrev.00/ > looks good. Thanks for fixing this. Thomas From goetz.lindenmaier at sap.com Mon Jun 15 09:21:29 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 15 Jun 2015 09:21:29 +0000 Subject: RFR(S): 8087183: Fix call to inline function is_oop in header debugInfo.hpp. References: <4295855A5C1DE049A61835A1887419CC2CFF2D12@DEWDFEMB12A.global.corp.sap> <7F5177CC-2BC8-4D24-8E12-EE44DC40F445@oracle.com> <557A3EC2.1080300@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2CFF9B0A@DEWDFEMB12A.global.corp.sap> Hi, I updated the call to is_oop to do "or_null", and fixed the Copyrights. I also added the reviewers to the change comment. http://cr.openjdk.java.net/~goetz/webrevs/8087183-is_oop/webrev-02/ Could someone please sponsor this tiny change? Thanks and best regards, Goetz. -----Original Message----- From: Lindenmaier, Goetz Sent: Freitag, 12. Juni 2015 08:54 To: 'David Holmes'; Kim Barrett Cc: HotSpot Developers Subject: RE: RFR(S): 8087183: Fix call to inline function is_oop in header debugInfo.hpp. Hi, Thanks for the reviews! Could someone please sponsor this? We started to track down the cause by searching and building the repo, but then we narrowed in down to two merges ... and aix builds rather slow. I quit this task then. But the file drags in a lot of os/aix and os_cpu/aix_ppc files. The includes in these files differ from those in other platform directories. And with one of the include cleanup changes in a shared file the indirect include that must have been there at some point vanished I guess. But no matter, is_oop should not be called in a header file ... Best regards, Goetz. -----Original Message----- From: David Holmes [mailto:david.holmes at oracle.com] Sent: Freitag, 12. Juni 2015 04:07 To: Kim Barrett; Lindenmaier, Goetz Cc: HotSpot Developers Subject: Re: RFR(S): 8087183: Fix call to inline function is_oop in header debugInfo.hpp. On 12/06/2015 3:17 AM, Kim Barrett wrote: > On Jun 11, 2015, at 5:02 AM, Lindenmaier, Goetz wrote: >> >> Hi, >> >> in debugInfo.hpp is_oop() is called. This is an inline function defined in oop.inline.hpp. >> As oop.inline.hpp is not included in debugInfo.hpp, and it should not be included there, >> this leads to compilation failures in the fastdebug build on aix. >> >> To fix this, I just move the function calling is_oop to debugInfo.cpp. In that file also the >> only call to that function is located, so that it still can be inlined. >> >> Please review this change. I please need a sponsor. >> http://cr.openjdk.java.net/~goetz/webrevs/8087183-is_oop/webrev-01/ >> >> Best regards, >> Goetz. > > Looks good. > > I'm mildly surprised this doesn't run into problems on other platforms. Me too. My first thought was precompiled headers, but this code has been in place for a couple of years - so why is it now a problem ?? David > The assert could use oop->is_oop_or_null(), though it makes no difference for this problem. > From kim.barrett at oracle.com Mon Jun 15 09:23:13 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 15 Jun 2015 05:23:13 -0400 Subject: RFR: 8087322: Implement a Semaphore utility class In-Reply-To: <557E7C1A.8060902@oracle.com> References: <557AF8E4.9040804@oracle.com> <557E12A8.9080006@oracle.com> <557E7344.9060104@oracle.com> <557E7C1A.8060902@oracle.com> Message-ID: <4FA2ADF9-A2EE-42D6-9B89-07F9E9508B28@oracle.com> On Jun 15, 2015, at 3:17 AM, David Holmes wrote: > > Hi Stefan, > > On 15/06/2015 4:40 PM, Stefan Karlsson wrote: >> Hi David, >> >> On 2015-06-15 01:47, David Holmes wrote: >>> Hi Stefan, >>> >>> Quick response - sorry will try to get back to this later. >>> >>> I second the comment to define an os_posix implementation and to do it >>> now rather than defer it for future work. Solaris supports POSIX >>> semaphore API (as well as the SUS/UI semaphore API). This may boil >>> down to only two implementations: posix and win32. >> >> This adds risk to this patch. Are we sure that the Solaris OS code >> doesn't rely on some implementation detail of sema_post/sema_wait that >> is different from how the POSIX semaphores work? For example, how it >> interacts with signal handlers, etc? > > Solaris supports two different semaphore API's. The POSIX API has sem_wait, sem_post etc and operates on sem_t. The other (SUS or UI or Solaris-only ?) API has sema_* and operates on sema_t - it is a very subtle difference: sem vs sema. Under the covers they are the same thing, but the API's themselves have some differences. You can use the POSIX API on Solaris, just as on Linux and hopefully BSD (and maybe AIX?) > >>> >>> I don't see the point of the "max" value in the API given it can't >>> used on all platforms. >> >> I don't want it either, but it's needed by the windows implementation. I >> could get rid of it if we have a sensible max value. Any suggestion on >> what value to use? > > On Windows pass in whatever MAX windows defines. > >>> >>> The posix semaphore functions return -1 and set errno on error, so any >>> guarantees (asserts are normally used here) >> >> I can change to asserts. >> >>> should do the appropriate errno string conversion. >> >> I followed the surrounding code. For example: >> >> 3411 jio_snprintf(msg, sizeof(msg), "Failed to reserve shared memory (errno = %d).", errno); >> >> but I see that we print a string at other places. I can change it. > > Thanks. > >> >> BTW, while looking at the return values of sema_wait, I found the following: >> >> 2433 while ((ret = ::sema_wait(&sig_sem)) == EINTR) >> 2434 ; >> >> I wonder if this code is broken. Since it checks the return value against EINTR and not errno. > > sema_wait returns zero or an error code. POSIX sem_wait returns 0/-1 and sets errno. This is exactly the question / confusion that Stefan and I discussed earlier in this review thread. The documentation is unclear. The Solaris 11.2 documentation for the sema_xxx functions, describes the return values as: Upon successful completion, 0 is returned; otherwise, a non-zero value indicates an error. That doesn't specify that a non-zero return value can be interpreted as an error code. It might empirically (or as a matter of lore) be that it can, but it doesn't state that. (It's entirely possible I'm not aware of some overarching documentation somewhere that makes such a statement; I'm not that familiar with Solaris.) The documentation further contains examples, and those examples show the error code associated with a failure (a non-zero return value) being obtained from errno, not from the non-zero return value. This also argues against the return value being an error code; why report it in multiple places? Of course, one of the benefits of using the POSIX API would be that it eliminates such questions, as that API?s documentation is quite clear on this matter. >>> Defining operations as Unimplemented on Windows is bad form. I see no >>> reason these should be unimplemented as WaitForSingleObject handles >>> the required semantics. >> >> But that means adding dead/untested code. That's another kind of bad form. > > Can you elaborate on why only part of the API is being used on Windows? I would have hoped the client code was cross-platform. Only part of the API is being used on *any* platform at present. The parts of the API that haven?t been implemented for Windows currently have no uses in our code base. The simplest solution would be to eliminate (for all ports) the unused part of the API, and add it back if someone actually needs it in the future. >>> I'm not a fan of the creeping use of "unit tests" inside the main >>> sources - have I missed some memo on that? >> >> We have been doing that for many years now. > > "we" have? I've only noticed a few occurrences :) I?m not a fan of the approach we have, but at present it is what we have. I?d rather have them than not; they get exercised as part of our normal testing processes, and that?s a good thing. From sgehwolf at redhat.com Mon Jun 15 09:58:36 2015 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 15 Jun 2015 11:58:36 +0200 Subject: RFR(XS) 8098552: 8079792 breaks Zero builds without precompiled headers. Message-ID: <1434362316.4806.17.camel@redhat.com> Hi, Could somebody please review and sponsor this trivial fix? The issue is that the Zero build fails with precompiled headers turned off (other builds probably too, but I haven't checked). The fix is to include memRegion.hpp in g1/g1BiasedArray.hpp since it uses MemRegion. Bug: https://bugs.openjdk.java.net/browse/JDK-8098552 webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8098552/webrev.01/ Thanks, Severin From david.holmes at oracle.com Mon Jun 15 11:32:33 2015 From: david.holmes at oracle.com (David Holmes) Date: Mon, 15 Jun 2015 21:32:33 +1000 Subject: RFR: 8087322: Implement a Semaphore utility class In-Reply-To: <4FA2ADF9-A2EE-42D6-9B89-07F9E9508B28@oracle.com> References: <557AF8E4.9040804@oracle.com> <557E12A8.9080006@oracle.com> <557E7344.9060104@oracle.com> <557E7C1A.8060902@oracle.com> <4FA2ADF9-A2EE-42D6-9B89-07F9E9508B28@oracle.com> Message-ID: <557EB7D1.4060203@oracle.com> On 15/06/2015 7:23 PM, Kim Barrett wrote: > On Jun 15, 2015, at 3:17 AM, David Holmes wrote: >> >> Hi Stefan, >> >> On 15/06/2015 4:40 PM, Stefan Karlsson wrote: >>> Hi David, >>> >>> On 2015-06-15 01:47, David Holmes wrote: >>>> Hi Stefan, >>>> >>>> Quick response - sorry will try to get back to this later. >>>> >>>> I second the comment to define an os_posix implementation and to do it >>>> now rather than defer it for future work. Solaris supports POSIX >>>> semaphore API (as well as the SUS/UI semaphore API). This may boil >>>> down to only two implementations: posix and win32. >>> >>> This adds risk to this patch. Are we sure that the Solaris OS code >>> doesn't rely on some implementation detail of sema_post/sema_wait that >>> is different from how the POSIX semaphores work? For example, how it >>> interacts with signal handlers, etc? >> >> Solaris supports two different semaphore API's. The POSIX API has sem_wait, sem_post etc and operates on sem_t. The other (SUS or UI or Solaris-only ?) API has sema_* and operates on sema_t - it is a very subtle difference: sem vs sema. Under the covers they are the same thing, but the API's themselves have some differences. You can use the POSIX API on Solaris, just as on Linux and hopefully BSD (and maybe AIX?) >> >>>> >>>> I don't see the point of the "max" value in the API given it can't >>>> used on all platforms. >>> >>> I don't want it either, but it's needed by the windows implementation. I >>> could get rid of it if we have a sensible max value. Any suggestion on >>> what value to use? >> >> On Windows pass in whatever MAX windows defines. >> >>>> >>>> The posix semaphore functions return -1 and set errno on error, so any >>>> guarantees (asserts are normally used here) >>> >>> I can change to asserts. >>> >>>> should do the appropriate errno string conversion. >>> >>> I followed the surrounding code. For example: >>> >>> 3411 jio_snprintf(msg, sizeof(msg), "Failed to reserve shared memory (errno = %d).", errno); >>> >>> but I see that we print a string at other places. I can change it. >> >> Thanks. >> >>> >>> BTW, while looking at the return values of sema_wait, I found the following: >>> >>> 2433 while ((ret = ::sema_wait(&sig_sem)) == EINTR) >>> 2434 ; >>> >>> I wonder if this code is broken. Since it checks the return value against EINTR and not errno. >> >> sema_wait returns zero or an error code. POSIX sem_wait returns 0/-1 and sets errno. > > This is exactly the question / confusion that Stefan and I discussed > earlier in this review thread. The documentation is unclear. > > The Solaris 11.2 documentation for the sema_xxx functions, describes > the return values as: > > Upon successful completion, 0 is returned; otherwise, a non-zero > value indicates an error. > > That doesn't specify that a non-zero return value can be interpreted > as an error code. It might empirically (or as a matter of lore) be > that it can, but it doesn't state that. (It's entirely possible I'm > not aware of some overarching documentation somewhere that makes such > a statement; I'm not that familiar with Solaris.) But is immediately followed by: ERRORS These functions will fail if: EINVAL The sp argument does not refer to a valid sema- phore. but I agree it is less than clear these are the returned values > The documentation further contains examples, and those examples show > the error code associated with a failure (a non-zero return value) > being obtained from errno, not from the non-zero return value. This > also argues against the return value being an error code; why report > it in multiple places? I think you will find that this is a simple copy'n'paste error between the sem_ and sema_ manpages. > Of course, one of the benefits of using the POSIX API would be that it > eliminates such questions, as that API?s documentation is quite clear > on this matter. > >>>> Defining operations as Unimplemented on Windows is bad form. I see no >>>> reason these should be unimplemented as WaitForSingleObject handles >>>> the required semantics. >>> >>> But that means adding dead/untested code. That's another kind of bad form. >> >> Can you elaborate on why only part of the API is being used on Windows? I would have hoped the client code was cross-platform. > > Only part of the API is being used on *any* platform at present. The > parts of the API that haven?t been implemented for Windows currently > have no uses in our code base. The simplest solution would be to > eliminate (for all ports) the unused part of the API, and add it back > if someone actually needs it in the future. Okay in that case it's either all in or none in. But certainly there should not be a partially implemented API on some platforms. >>>> I'm not a fan of the creeping use of "unit tests" inside the main >>>> sources - have I missed some memo on that? >>> >>> We have been doing that for many years now. >> >> "we" have? I've only noticed a few occurrences :) > > I?m not a fan of the approach we have, but at present it is what we have. > I?d rather have them than not; they get exercised as part of our normal > testing processes, and that?s a good thing. The "internaltests" ? Not a fan, but more on that in response to Erik. :) Cheers, David From david.holmes at oracle.com Mon Jun 15 11:36:14 2015 From: david.holmes at oracle.com (David Holmes) Date: Mon, 15 Jun 2015 21:36:14 +1000 Subject: RFR: 8087322: Implement a Semaphore utility class In-Reply-To: <20150615084152.GE29290@ehelin.jrpg.bea.com> References: <557AF8E4.9040804@oracle.com> <557E12A8.9080006@oracle.com> <557E7344.9060104@oracle.com> <20150615084152.GE29290@ehelin.jrpg.bea.com> Message-ID: <557EB8AE.5010601@oracle.com> On 15/06/2015 6:41 PM, Erik Helin wrote: > On 2015-06-15, Stefan Karlsson wrote: >> Hi David, >> >> On 2015-06-15 01:47, David Holmes wrote: >>> Hi Stefan, >>> >>> Quick response - sorry will try to get back to this later. >>> >>> I second the comment to define an os_posix implementation and to do it now >>> rather than defer it for future work. Solaris supports POSIX semaphore API >>> (as well as the SUS/UI semaphore API). This may boil down to only two >>> implementations: posix and win32. >> >> This adds risk to this patch. Are we sure that the Solaris OS code doesn't >> rely on some implementation detail of sema_post/sema_wait that is different >> from how the POSIX semaphores work? For example, how it interacts with >> signal handlers, etc? >> >>> >>> I don't see the point of the "max" value in the API given it can't used on >>> all platforms. >> >> I don't want it either, but it's needed by the windows implementation. I >> could get rid of it if we have a sensible max value. Any suggestion on what >> value to use? >> >>> >>> The posix semaphore functions return -1 and set errno on error, so any >>> guarantees (asserts are normally used here) >> >> I can change to asserts. >> >>> should do the appropriate errno string conversion. >> >> I followed the surrounding code. For example: >> >> 3411 jio_snprintf(msg, sizeof(msg), "Failed to reserve shared memory (errno = %d).", errno); >> >> but I see that we print a string at other places. I can change it. >> >> >> BTW, while looking at the return values of sema_wait, I found the following: >> >> 2433 while ((ret = ::sema_wait(&sig_sem)) == EINTR) >> 2434 ; >> >> I wonder if this code is broken. Since it checks the return value against EINTR and not errno. >> >> >>> >>> Defining operations as Unimplemented on Windows is bad form. I see no >>> reason these should be unimplemented as WaitForSingleObject handles the >>> required semantics. >> >> But that means adding dead/untested code. That's another kind of bad form. >> >>> >>> I'm not a fan of the creeping use of "unit tests" inside the main sources >>> - have I missed some memo on that? >> >> We have been doing that for many years now. >> >>> Single-threaded unit tests for something like Semaphore seems to only be >>> paying lip-service to the testing aspect anyway. > > Well, if the tests are easy to implement and verify, why not implement > them? There is of course a need for more testing, especially those parts > that are not covered by the unit tests, but at least those test won't > have to care about verifying what is covered by these unit tests. I don't like seeing tests split up either. Full blown functional unit tests don't belong in the primary source code in my opinion. So I'd rather see a more complete separate test, than a simple "sanity checking" internal unit test that will still need to be complemented by further external testing. Cheers, David >> It tests boundary conditions. What do other Reviewers think. Should I remove >> the tests? > > No, keep them. Even though you can only test the single-threaded case, > it helps me understand and review the change. I also appreciate that you > took the time to write the tests! > > Thanks, > Erik > >> Thanks, >> StefanK >>> >>> Thanks, >>> David >>> >>> On 13/06/2015 1:21 AM, Stefan Karlsson wrote: >>>> Hi all, >>>> >>>> Please review this patch to create a Semaphore utility class. I need >>>> this class to implementing faster GC thread synchronization [1]. >>>> >>>> http://cr.openjdk.java.net/~stefank/8087322/webrev.00/ >>>> https://bugs.openjdk.java.net/browse/JDK-8087322 >>>> >>>> Some of our platforms already implement a Semaphore class, but those >>>> classes are hidden inside os_.cpp. I've moved the class declaration >>>> to semaphore.hpp, but the implementation is left in the os_.hpp. I >>>> considered creating semaphore_.cpp files, but I ended up having to >>>> restructure too much code and I wanted to focus on the feature in [1] >>>> instead. Should I create a RFE to move the semaphore implementations? >>>> >>>> There seems to be another opportunity to cleanup the code. If we take >>>> os_linux.cpp, as an example, the code uses both the existing Semaphore >>>> class and the global ::sem_wait and ::sem_post functions. We might want >>>> to consider unifying that code. >>>> >>>> Since HotSpot is built on platforms that I don't have access to and >>>> can't test, I've added the IMPLEMENTS_SEMAPHORE_CLASS define. So, that I >>>> can detect if the the current platform implements the Semaphore class, >>>> and choose what synchronization primitive to use by the GC. >>>> >>>> The os_bsd.cpp file has support for "non-apple BSD", but I've only >>>> tested this patch with OS X. >>>> >>>> This patch has been tested in JPRT and our nightly testing together with >>>> the patches in [1]. The patch also contains a few unit tests in >>>> semaphore.cpp. >>>> >>>> Thanks, >>>> StefanK >>>> >>>> [1] >>>> http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2015-June/013829.html >>>> >> From erik.helin at oracle.com Mon Jun 15 12:03:31 2015 From: erik.helin at oracle.com (Erik Helin) Date: Mon, 15 Jun 2015 14:03:31 +0200 Subject: RFR: 8087322: Implement a Semaphore utility class In-Reply-To: <557EB8AE.5010601@oracle.com> References: <557AF8E4.9040804@oracle.com> <557E12A8.9080006@oracle.com> <557E7344.9060104@oracle.com> <20150615084152.GE29290@ehelin.jrpg.bea.com> <557EB8AE.5010601@oracle.com> Message-ID: <20150615120331.GF29290@ehelin.jrpg.bea.com> On 2015-06-15, David Holmes wrote: > On 15/06/2015 6:41 PM, Erik Helin wrote: > >On 2015-06-15, Stefan Karlsson wrote: > >>Hi David, > >> > >>On 2015-06-15 01:47, David Holmes wrote: > >>>Hi Stefan, > >>> > >>>Quick response - sorry will try to get back to this later. > >>> > >>>I second the comment to define an os_posix implementation and to do it now > >>>rather than defer it for future work. Solaris supports POSIX semaphore API > >>>(as well as the SUS/UI semaphore API). This may boil down to only two > >>>implementations: posix and win32. > >> > >>This adds risk to this patch. Are we sure that the Solaris OS code doesn't > >>rely on some implementation detail of sema_post/sema_wait that is different > >>from how the POSIX semaphores work? For example, how it interacts with > >>signal handlers, etc? > >> > >>> > >>>I don't see the point of the "max" value in the API given it can't used on > >>>all platforms. > >> > >>I don't want it either, but it's needed by the windows implementation. I > >>could get rid of it if we have a sensible max value. Any suggestion on what > >>value to use? > >> > >>> > >>>The posix semaphore functions return -1 and set errno on error, so any > >>>guarantees (asserts are normally used here) > >> > >>I can change to asserts. > >> > >>>should do the appropriate errno string conversion. > >> > >>I followed the surrounding code. For example: > >> > >>3411 jio_snprintf(msg, sizeof(msg), "Failed to reserve shared memory (errno = %d).", errno); > >> > >>but I see that we print a string at other places. I can change it. > >> > >> > >>BTW, while looking at the return values of sema_wait, I found the following: > >> > >>2433 while ((ret = ::sema_wait(&sig_sem)) == EINTR) > >>2434 ; > >> > >>I wonder if this code is broken. Since it checks the return value against EINTR and not errno. > >> > >> > >>> > >>>Defining operations as Unimplemented on Windows is bad form. I see no > >>>reason these should be unimplemented as WaitForSingleObject handles the > >>>required semantics. > >> > >>But that means adding dead/untested code. That's another kind of bad form. > >> > >>> > >>>I'm not a fan of the creeping use of "unit tests" inside the main sources > >>>- have I missed some memo on that? > >> > >>We have been doing that for many years now. > >> > >>>Single-threaded unit tests for something like Semaphore seems to only be > >>>paying lip-service to the testing aspect anyway. > > > >Well, if the tests are easy to implement and verify, why not implement > >them? There is of course a need for more testing, especially those parts > >that are not covered by the unit tests, but at least those test won't > >have to care about verifying what is covered by these unit tests. > > I don't like seeing tests split up either. Full blown functional unit tests > don't belong in the primary source code in my opinion. So I'd rather see a > more complete separate test, than a simple "sanity checking" internal unit > test that will still need to be complemented by further external testing. I would also like to see a better testing framework with tests being in a separate file and/or folder, but giving that the choice right now is a unit test or no test at all, I'd rather have the unit test. Anyhow, if we want better unit testing support, then that belongs in a separate patch. I also don't see how you would test this without writing the test as a unit test? An "external" test won't be able to assert anything about the VM's own Semaphore class. Thanks, Erik > Cheers, > David > > >>It tests boundary conditions. What do other Reviewers think. Should I remove > >>the tests? > > > >No, keep them. Even though you can only test the single-threaded case, > >it helps me understand and review the change. I also appreciate that you > >took the time to write the tests! > > > >Thanks, > >Erik > > > >>Thanks, > >>StefanK > >>> > >>>Thanks, > >>>David > >>> > >>>On 13/06/2015 1:21 AM, Stefan Karlsson wrote: > >>>>Hi all, > >>>> > >>>>Please review this patch to create a Semaphore utility class. I need > >>>>this class to implementing faster GC thread synchronization [1]. > >>>> > >>>>http://cr.openjdk.java.net/~stefank/8087322/webrev.00/ > >>>>https://bugs.openjdk.java.net/browse/JDK-8087322 > >>>> > >>>>Some of our platforms already implement a Semaphore class, but those > >>>>classes are hidden inside os_.cpp. I've moved the class declaration > >>>>to semaphore.hpp, but the implementation is left in the os_.hpp. I > >>>>considered creating semaphore_.cpp files, but I ended up having to > >>>>restructure too much code and I wanted to focus on the feature in [1] > >>>>instead. Should I create a RFE to move the semaphore implementations? > >>>> > >>>>There seems to be another opportunity to cleanup the code. If we take > >>>>os_linux.cpp, as an example, the code uses both the existing Semaphore > >>>>class and the global ::sem_wait and ::sem_post functions. We might want > >>>>to consider unifying that code. > >>>> > >>>>Since HotSpot is built on platforms that I don't have access to and > >>>>can't test, I've added the IMPLEMENTS_SEMAPHORE_CLASS define. So, that I > >>>>can detect if the the current platform implements the Semaphore class, > >>>>and choose what synchronization primitive to use by the GC. > >>>> > >>>>The os_bsd.cpp file has support for "non-apple BSD", but I've only > >>>>tested this patch with OS X. > >>>> > >>>>This patch has been tested in JPRT and our nightly testing together with > >>>>the patches in [1]. The patch also contains a few unit tests in > >>>>semaphore.cpp. > >>>> > >>>>Thanks, > >>>>StefanK > >>>> > >>>>[1] > >>>>http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2015-June/013829.html > >>>> > >> From stefan.johansson at oracle.com Mon Jun 15 12:05:42 2015 From: stefan.johansson at oracle.com (Stefan Johansson) Date: Mon, 15 Jun 2015 14:05:42 +0200 Subject: RFR(XS) 8098552: 8079792 breaks Zero builds without precompiled headers. In-Reply-To: <1434362316.4806.17.camel@redhat.com> References: <1434362316.4806.17.camel@redhat.com> Message-ID: <557EBF96.8020109@oracle.com> Hi Severin, Fix is correct, but we try to keep the includes sorted so please change it to be: #include "memory/allocation.hpp" +#include "memory/memRegion.hpp" #include "utilities/debug.hpp" I'm not a reviewer, but can sponsor this change and push it as soon as we get a Reviewer to look at it. Thanks, Stefan On 2015-06-15 11:58, Severin Gehwolf wrote: > Hi, > > Could somebody please review and sponsor this trivial fix? The issue is > that the Zero build fails with precompiled headers turned off (other > builds probably too, but I haven't checked). The fix is to include > memRegion.hpp in g1/g1BiasedArray.hpp since it uses MemRegion. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8098552 > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8098552/webrev.01/ > > Thanks, > Severin > From erik.helin at oracle.com Mon Jun 15 12:16:43 2015 From: erik.helin at oracle.com (Erik Helin) Date: Mon, 15 Jun 2015 14:16:43 +0200 Subject: RFR(XS) 8098552: 8079792 breaks Zero builds without precompiled headers. In-Reply-To: <557EBF96.8020109@oracle.com> References: <1434362316.4806.17.camel@redhat.com> <557EBF96.8020109@oracle.com> Message-ID: <20150615121643.GG29290@ehelin.jrpg.bea.com> On 2015-06-15, Stefan Johansson wrote: > Hi Severin, > > Fix is correct, but we try to keep the includes sorted so please change it > to be: > #include "memory/allocation.hpp" > +#include "memory/memRegion.hpp" > #include "utilities/debug.hpp" > > I'm not a reviewer, but can sponsor this change and push it as soon as we > get a Reviewer to look at it. Pending the comment above by Stefan, the patch looks good. Reviewed. Thanks, Erik > Thanks, > Stefan > > On 2015-06-15 11:58, Severin Gehwolf wrote: > >Hi, > > > >Could somebody please review and sponsor this trivial fix? The issue is > >that the Zero build fails with precompiled headers turned off (other > >builds probably too, but I haven't checked). The fix is to include > >memRegion.hpp in g1/g1BiasedArray.hpp since it uses MemRegion. > > > >Bug: https://bugs.openjdk.java.net/browse/JDK-8098552 > >webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8098552/webrev.01/ > > > >Thanks, > >Severin > > > From stefan.johansson at oracle.com Mon Jun 15 12:18:58 2015 From: stefan.johansson at oracle.com (Stefan Johansson) Date: Mon, 15 Jun 2015 14:18:58 +0200 Subject: RFR(XS) 8098552: 8079792 breaks Zero builds without precompiled headers. In-Reply-To: <20150615121643.GG29290@ehelin.jrpg.bea.com> References: <1434362316.4806.17.camel@redhat.com> <557EBF96.8020109@oracle.com> <20150615121643.GG29290@ehelin.jrpg.bea.com> Message-ID: <557EC2B2.3080205@oracle.com> Thanks Erik, Severin, can you provide an updated patch generated by 'hg export'. Once I get that, I'll push it right away. No need to wait 24h for such a trivial fix. Thanks, Stefan On 2015-06-15 14:16, Erik Helin wrote: > On 2015-06-15, Stefan Johansson wrote: >> Hi Severin, >> >> Fix is correct, but we try to keep the includes sorted so please change it >> to be: >> #include "memory/allocation.hpp" >> +#include "memory/memRegion.hpp" >> #include "utilities/debug.hpp" >> >> I'm not a reviewer, but can sponsor this change and push it as soon as we >> get a Reviewer to look at it. > Pending the comment above by Stefan, the patch looks good. Reviewed. > > Thanks, > Erik > >> Thanks, >> Stefan >> >> On 2015-06-15 11:58, Severin Gehwolf wrote: >>> Hi, >>> >>> Could somebody please review and sponsor this trivial fix? The issue is >>> that the Zero build fails with precompiled headers turned off (other >>> builds probably too, but I haven't checked). The fix is to include >>> memRegion.hpp in g1/g1BiasedArray.hpp since it uses MemRegion. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8098552 >>> webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8098552/webrev.01/ >>> >>> Thanks, >>> Severin >>> From Alexander.Alexeev at caviumnetworks.com Mon Jun 15 12:34:16 2015 From: Alexander.Alexeev at caviumnetworks.com (Alexeev, Alexander) Date: Mon, 15 Jun 2015 12:34:16 +0000 Subject: RFR: aarch64: Bit count intrinsic implementation for aarch64 Message-ID: Hello Could somebody review the patch [1] and sponsor if approved? The patch implements _bitCount_i and _bitCount_l intrinsics with ARMv8 SIMD instructions cnt and addv cnt - Population count per byte addv - Add across vector Hotspot tests suite: Before: Test results: passed: 826; failed: 29; error: 8 After: Test results: passed: 826; failed: 29; error: 8 [1] www.googledrive.com/host/0B5VQvD5uJjDQfjRBTHdsaXlBSGN1cUxnRlNncXFwdWpoRUhnRnIxV3Y1OGlqa2lPTjNuUWs From stefan.karlsson at oracle.com Mon Jun 15 12:52:42 2015 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Mon, 15 Jun 2015 14:52:42 +0200 Subject: RFR: 8087322: Implement a Semaphore utility class In-Reply-To: <557E7C1A.8060902@oracle.com> References: <557AF8E4.9040804@oracle.com> <557E12A8.9080006@oracle.com> <557E7344.9060104@oracle.com> <557E7C1A.8060902@oracle.com> Message-ID: <557ECA9A.1080203@oracle.com> On 2015-06-15 09:17, David Holmes wrote: > Hi Stefan, > > On 15/06/2015 4:40 PM, Stefan Karlsson wrote: >> Hi David, >> >> On 2015-06-15 01:47, David Holmes wrote: >>> Hi Stefan, >>> >>> Quick response - sorry will try to get back to this later. >>> >>> I second the comment to define an os_posix implementation and to do it >>> now rather than defer it for future work. Solaris supports POSIX >>> semaphore API (as well as the SUS/UI semaphore API). This may boil >>> down to only two implementations: posix and win32. >> >> This adds risk to this patch. Are we sure that the Solaris OS code >> doesn't rely on some implementation detail of sema_post/sema_wait that >> is different from how the POSIX semaphores work? For example, how it >> interacts with signal handlers, etc? > > Solaris supports two different semaphore API's. The POSIX API has > sem_wait, sem_post etc and operates on sem_t. The other (SUS or UI or > Solaris-only ?) API has sema_* and operates on sema_t - it is a very > subtle difference: sem vs sema. Under the covers they are the same > thing, but the API's themselves have some differences. You can use the > POSIX API on Solaris, just as on Linux and hopefully BSD (and maybe AIX?) I'm going to send out a new patch using the posix API for the Semaphore class. > >>> >>> I don't see the point of the "max" value in the API given it can't >>> used on all platforms. >> >> I don't want it either, but it's needed by the windows implementation. I >> could get rid of it if we have a sensible max value. Any suggestion on >> what value to use? > > On Windows pass in whatever MAX windows defines. Do you know where to find that MAX value? The document doesn't mention the maximum value. Only the type of it: _In_ LONG lMaximumCount, and: /lMaximumCount/ [in] The maximum count for the semaphore object. This value must be greater than zero. Should I assume that LONG_MAX is the right value to use? > >>> >>> The posix semaphore functions return -1 and set errno on error, so any >>> guarantees (asserts are normally used here) >> >> I can change to asserts. >> >>> should do the appropriate errno string conversion. >> >> I followed the surrounding code. For example: >> >> 3411 jio_snprintf(msg, sizeof(msg), "Failed to reserve shared >> memory (errno = %d).", errno); >> >> but I see that we print a string at other places. I can change it. > > Thanks. > >> >> BTW, while looking at the return values of sema_wait, I found the >> following: >> >> 2433 while ((ret = ::sema_wait(&sig_sem)) == EINTR) >> 2434 ; >> >> I wonder if this code is broken. Since it checks the return value >> against EINTR and not errno. > > sema_wait returns zero or an error code. POSIX sem_wait returns 0/-1 > and sets errno. OK. I haven't read the Solaris source code, so what you're saying might be correct. >> >>> >>> Defining operations as Unimplemented on Windows is bad form. I see no >>> reason these should be unimplemented as WaitForSingleObject handles >>> the required semantics. >> >> But that means adding dead/untested code. That's another kind of bad >> form. > > Can you elaborate on why only part of the API is being used on > Windows? I would have hoped the client code was cross-platform. The client code that I'm adding doesn't use the timedwait() and trywait() functions, but the os_.cpp code did. I'll address this in the coming patch where I minimize the API for Semaphore and instead have more complexity in the os_ files. > >>> >>> I'm not a fan of the creeping use of "unit tests" inside the main >>> sources - have I missed some memo on that? >> >> We have been doing that for many years now. > > "we" have? I've only noticed a few occurrences :) I remember this discussion from 2011: http://mail.openjdk.java.net/pipermail/hotspot-dev/2011-October/004640.html :) I don't feel we need to use this thread to discuss the suitability of having the unit tests in the .cpp files. Thanks, StefanK > > Thanks, > David > ----- > >>> Single-threaded unit tests for something like Semaphore seems to only >>> be paying lip-service to the testing aspect anyway. >> >> It tests boundary conditions. What do other Reviewers think. Should I >> remove the tests? >> >> Thanks, >> StefanK >>> >>> Thanks, >>> David >>> >>> On 13/06/2015 1:21 AM, Stefan Karlsson wrote: >>>> Hi all, >>>> >>>> Please review this patch to create a Semaphore utility class. I need >>>> this class to implementing faster GC thread synchronization [1]. >>>> >>>> http://cr.openjdk.java.net/~stefank/8087322/webrev.00/ >>>> https://bugs.openjdk.java.net/browse/JDK-8087322 >>>> >>>> Some of our platforms already implement a Semaphore class, but those >>>> classes are hidden inside os_.cpp. I've moved the class >>>> declaration >>>> to semaphore.hpp, but the implementation is left in the os_.hpp. I >>>> considered creating semaphore_.cpp files, but I ended up having to >>>> restructure too much code and I wanted to focus on the feature in [1] >>>> instead. Should I create a RFE to move the semaphore implementations? >>>> >>>> There seems to be another opportunity to cleanup the code. If we take >>>> os_linux.cpp, as an example, the code uses both the existing Semaphore >>>> class and the global ::sem_wait and ::sem_post functions. We might >>>> want >>>> to consider unifying that code. >>>> >>>> Since HotSpot is built on platforms that I don't have access to and >>>> can't test, I've added the IMPLEMENTS_SEMAPHORE_CLASS define. So, >>>> that I >>>> can detect if the the current platform implements the Semaphore class, >>>> and choose what synchronization primitive to use by the GC. >>>> >>>> The os_bsd.cpp file has support for "non-apple BSD", but I've only >>>> tested this patch with OS X. >>>> >>>> This patch has been tested in JPRT and our nightly testing together >>>> with >>>> the patches in [1]. The patch also contains a few unit tests in >>>> semaphore.cpp. >>>> >>>> Thanks, >>>> StefanK >>>> >>>> [1] >>>> http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2015-June/013829.html >>>> >>>> >> From aph at redhat.com Mon Jun 15 12:52:57 2015 From: aph at redhat.com (Andrew Haley) Date: Mon, 15 Jun 2015 13:52:57 +0100 Subject: RFR: aarch64: Bit count intrinsic implementation for aarch64 In-Reply-To: References: Message-ID: <557ECAA9.1030706@redhat.com> Hi, On 06/15/2015 01:34 PM, Alexeev, Alexander wrote: > Could somebody review the patch [1] and sponsor if approved? Looks good to me, but I am not a jdk9 reviewer. Do any of those tests actually test popcount? Thanks, Andrew. From thomas.stuefe at gmail.com Mon Jun 15 12:57:04 2015 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Mon, 15 Jun 2015 14:57:04 +0200 Subject: RFR(s): 8078513: [linux] Clean up code relevant to LinuxThreads implementation In-Reply-To: References: <554FF886.7030502@oracle.com> <55540B22.70807@oracle.com> <555C48F0.8090205@oracle.com> <557A3DB3.5040002@oracle.com> Message-ID: Hi Volker, David, Volker, thanks for the review! new version: http://cr.openjdk.java.net/~stuefe/webrevs/8078513/webrev.04/webrev/ I added all changes Volker wanted. Oh, and I forgot to add Volker as a Reviewer, please add him when pushing. Kind Regards, Thomas On Mon, Jun 15, 2015 at 11:23 AM, Thomas St?fe wrote: > Hi, > > sorry, dropped the ball on this one. Will post an updated version soon. > > Thomas > > On Fri, Jun 12, 2015 at 4:02 AM, David Holmes > wrote: > >> Hi Thomas, >> >> If you can address Volker's comments we can move forward with this. I'll >> be primary Reviewer and Volker a second reviewer. >> >> Thanks, >> David >> >> On 3/06/2015 3:52 PM, Thomas St?fe wrote: >> >>> Ping... >>> >>> Still need a second reviewer. >>> >>> Thanks! >>> >>> On Wednesday, May 20, 2015, Thomas St?fe >> > wrote: >>> >>> David, thanks! >>> >>> to all: could I have a second reviewer, please? >>> >>> Thanks & Kind Regards, Thomas >>> >>> On Wed, May 20, 2015 at 10:42 AM, David Holmes >>> >> > wrote: >>> >>> Hi Thomas, >>> >>> Summary: ok - need second reviewer ( I think Coleen is away) >>> >>> More inline ... >>> >>> On 19/05/2015 10:26 PM, Thomas St?fe wrote: >>> >>> Hi David, >>> >>> new webrev: >>> >>> http://cr.openjdk.java.net/~stuefe/webrevs/8078513/webrev.02/webrev/ >>> >>> Only two things changed. I reverted my comment change in the >>> SA and in >>> os_linux.cpp I massaged the "expand-thread-stack" comment >>> text a bit. >>> >>> More details inline. >>> >>> On Thu, May 14, 2015 at 4:40 AM, David Holmes >>> >> >>> >> >> >>> wrote: >>> >>> Hi Thomas, >>> >>> On 14/05/2015 2:32 AM, Thomas St?fe wrote: >>> >>> Hi David, >>> >>> here the new version: >>> >>> http://cr.openjdk.java.net/~stuefe/webrevs/8078513/webrev.01/webrev/ >>> >>> Differences to the old version are just comment >>> changes, and I also >>> modified some comments in the SA as Staffan >>> requested. >>> >>> >>> agent/src/os/linux/libproc.h >>> >>> Modified comments still refer to "both thread >>> libraries" but now the >>> two libraries have not been mentioned, so there is no >>> context to >>> know what the two libraries are. >>> >>> >>> I reverted my comment change to the original version. I >>> think I do not >>> know enough about the SA internals to make the comment clear >>> and >>> concise. Someone with more SA knowledge may be better suited >>> to change >>> that comment. >>> >>> >>> Ok. I think you were pretty close anyway, just need to get rid >>> of the "both thread libraries" references. >>> >>> >>> >>> More commentary inline below (with trimming)... >>> >>> >>> See remarks inline: >>> >>> os_linux.cpp: >>> >>> The whole MAP_GROWSDOWN discussion and code >>> also seems to be no >>> longer relevant. >>> >>> >>> I spent a lot of time digging around in the history >>> of this >>> thing. I am >>> unsure whether that stack expansion coding can be >>> removed. There are >>> some rare case where they may still be needed: >>> >>> That whole coding revolves around the question >>> whether thread stacks >>> need to be expanded manually. >>> >>> Nowadays, normal threads allocated with a modern >>> pthread library >>> (NPTL) >>> just allocate the whole stack with mmap(without >>> MAP_NORESERVE), so the >>> memory is committed right away. See glibc sources, >>> nptl/allocate_stack.c. >>> >>> In former times (LinuxThreads) thread stacks were >>> allocated using >>> mmap(MAP_GROWSDOWN), which needed cooperation from >>> the linux kernel: >>> kernel caught faults caused by expanding the stack >>> and transparently >>> mapped the next page. It needed to distinguish real >>> page faults from >>> stack expansion page faults, and seems the logic >>> did not always >>> work, so >>> manual expansion was needed - see os_linux.cpp, >>> "os::Linux::manually_expand_stack". >>> >>> I think there may still be cases where we run on >>> threads whose >>> stacks >>> are allocated with mmap(MAP_GROWSDOWN), even though >>> LinuxThreads >>> is gone: >>> >>> - with primordial threads (not sure, did not test). >>> We do not run on >>> primordial thread but someone may write a launcher >>> and start a >>> VM from >>> the primordial thread or attach the primordial >>> thread to the VM. >>> >>> >>> This is already a very grey area in the VM. See: >>> >>> https://bugs.openjdk.java.net/browse/JDK-6516512 >>> >>> "HotSpot:thread terminology should be clearer or >>> cleaned up." >>> >>> So until that is investigated and cleaned up this code >>> can't really >>> be touched. >>> >>> >>> Interesting and well written bug report. Unfortunately, the >>> issue seems >>> to be in deep sleep. >>> >>> >>> Sadly often true :( >>> >>> At SAP, we explicitly forbid all our internal users to >>> invoke the VM on >>> the primordial thread, and have done so since a long time. >>> We tell all >>> our users to spawn off an own pthread for VM creation. I >>> think the AIX >>> port will not even come up, we just assert. >>> >>> But this is more of a political question. If we pull support >>> for running >>> on the primordial thread in the OpenJDK, there may be >>> applications which >>> break. On the other hand, does this scenario - running on >>> the primordial >>> thread - get tested? Would we even notice if it were not to >>> work anymore? >>> >>> >>> There may be some JNI tests that use the primordial thread but I >>> can't say for sure. >>> >>> - someone may write its own thread implementation >>> using clone and >>> mmap(MAP_GROWSDOWN) allocated stacks. >>> >>> These cases are probably extremely rare, and I >>> would have no qualms >>> removing support for them, but I do not want to >>> decide that. >>> >>> >>> Fair enough. As I said I think this expands into a >>> cleanup up of the >>> whole "initial thread" business anyway. >>> >>> Sidenote: These cases are inherently unsafe because >>> mmap(MAP_GROWSDOWN) >>> is too. Ulrich Drepper tried without success to >>> remove support >>> for these >>> flags from the linux kernel: >>> https://lwn.net/Articles/294001/ >>> >>> I added some comment to os_linux.cpp to explain >>> this a bit better. >>> >>> >>> The two comments don't rely flow together due to the >>> "Force Linux >>> kernel to expand current thread stack." lead-in of the >>> second >>> comment (which isn't actually a grammatically correct >>> sentence). But >>> I can't really think of anything to do that doesn't >>> start making >>> numerous changes to what is already a confusing and >>> disjointed >>> comment block. >>> >>> >>> I tried to improve the comment a bit, to clearly distinguish >>> it from the >>> older comment and to provide enough information for whenever >>> we decide >>> to clean up this expand-thread-stack coding. >>> >>> >>> Revised comment is much clearer - thanks! >>> >>> David >>> ----- >>> >>> >>> Kind Regards, Thomas >>> >>> >>> >>> >>> The gcc 2.x workarounds can also be removed I >>> think. >>> >>> I wonder if we can also eradicate >>> WorkAroundNPTLTimedWaitHang :) >>> >>> >>> I do not dare to do that - I do not know enough >>> about this issue. >>> >>> >>> Separate RFE. I doubt we care about the old systems >>> that had this >>> problem. >>> >>> >>> Aside: The createThread_lock (now unused) >>> seems to have >>> been copied >>> into src/os/aix/vm/os_aix.hpp as part of the >>> AIX port and >>> should be >>> removed at some point. >>> >>> >>> Yes I know :-) It is not the only Linux-specific >>> code which >>> crept into >>> our AIX port. We actually have a bug open to deal >>> with that: >>> https://bugs.openjdk.java.net/browse/JDK-8079125 >>> >>> >>> Good to know :) >>> >>> Thanks, >>> David >>> ----- >>> >>> >>> --- >>> >>> src/os/linux/vm/os_linux.hpp >>> >>> Copyright needs updating. >>> >>> >>> done >>> >>> --- >>> >>> src/os_cpu/linux_x86/vm/os_linux_x86.cpp >>> >>> Copyright needs updating. >>> >>> done >>> >>> os::Linux::supports_variable_stack_size() is >>> now dead >>> code (value >>> is true for all arch's AFAICS) so can be >>> removed from all >>> src/os_cpu/linux_XXX/os_linux_XXX.cpp. >>> >>> I think supports_variable_stack_size() is >>> also always true >>> on other >>> platforms (AIX, BSD) and so could be cleaned >>> up in that >>> code too >>> (separate clean-up CR okay for that). >>> >>> >>> I agree, lets do this in a different RFR because >>> this would touch >>> non-linux sources and I want to keep this linux >>> specific. I opened >>> https://bugs.openjdk.java.net/browse/JDK-8080298 for this. >>> >>> >>> Thanks for filing. >>> >>> >>> >>> --- >>> >>> >>> src/os_cpu/linux_x86/vm/threadLS_linux_x86.cpp >>> >>> Copyright needs updating. >>> >>> done >>> >>> --- >>> >>> I'm happy to sponsor this for you. >>> >>> Thanks, >>> David >>> ----- >>> >>> >>> >>> This change removes (I hope all) remnants >>> of code >>> dealing with >>> LinuxThreads >>> from the hotspot. >>> >>> Discussion of the changes: >>> >>> 1) on LinuxThreads, each thread had an own >>> pid, so getpid() >>> would return a >>> unique pid for every thread it was invoked >>> in. On NPTL, >>> this is >>> not an >>> issue anymore; getpid() works as expected >>> returning a >>> global pid. >>> For LinuxThreads, there was a workaround >>> where at VM >>> startup the >>> pid was >>> captured (on the thread invoking >>> CreateJavaVM) and this >>> pid was >>> stored in >>> static variable _initial_pid and returned >>> in >>> os::current_process_id(). >>> Later another workaround was added because >>> CreateJavaVM >>> was not >>> invoked on >>> the primordial thread anymore, so the pid >>> was handed in >>> via a >>> define (see >>> Arguments::sun_java_launcher_pid()). >>> >>> Both workaround were removed and >>> os::current_process_id() was >>> changed to >>> just return getpid(). >>> >>> >>> We should remove the code on the JDK side as >>> well - >>> possibly as a >>> follow up clean up (but via the same forest as >>> this will be >>> pushed): >>> >>> >>> ./java.base/unix/native/libjli/java_md_solinux.c >>> >>> void SetJavaLauncherPlatformProps() { >>> /* Linux only */ >>> #ifdef __linux__ >>> const char *substr = >>> "-Dsun.java.launcher.pid="; >>> char *pid_prop_str = (char >>> *)JLI_MemAlloc(JLI_StrLen(substr) + >>> MAX_PID_STR_SZ + 1); >>> sprintf(pid_prop_str, "%s%d", substr, >>> getpid()); >>> AddOption(pid_prop_str, NULL); >>> #endif /* __linux__ */ >>> >>> } >>> >>> >>> Unfortunately, sun.launcher.pid gets used in the >>> wild, e.g.: >>> >>> >>> http://stackoverflow.com/questions/35842/how-can-a-java-program-get-its-own-process-id >>> >>> Kind Regards, Thomas >>> >>> >>> >>> >>> 2) os::Linux::gettid(): Linux uses the >>> kernel thread id for >>> OSThread thread >>> id - I did not change that. But by now the >>> system call >>> gettid >>> should be >>> available in every Linux kernel, so I >>> removed the >>> fallback handling. >>> >>> 3) A number of changes dealt with the way >>> LinuxThreads >>> allocated >>> thread >>> stacks (with mmap and the MAP_GROWSDOWN >>> flag). On >>> LinuxThreads, >>> it was not >>> possible to change the size of thread >>> stacks (to start >>> a new >>> thread with a >>> different stack size). NPTL can do this >>> and all the >>> places where >>> we dealt >>> with fixed stacks I changed. >>> >>> 4) On LinuxThreads, there is the problem >>> that the >>> thread stacks >>> - which >>> grow down and are allocated with MAP_FIXED >>> - may at >>> some point >>> trash the >>> java heap. To prevent this, every >>> allocation done with >>> os::reserve_memory() >>> and friends recorded a >>> "_highest_vm_reserved_address". >>> There was >>> a function >>> called "_thread_safety_check" which >>> prevented start of new >>> threads if >>> thread stacks came dangerously close to >>> the highest >>> reserved >>> address + a >>> gap; latter gap could be set via parameter >>> ThreadSafetyMargin. >>> >>> All this coding was removed. Note that >>> this coding >>> probably was >>> already >>> broken since a long time, because there >>> are many >>> allocations >>> which were not >>> tracked. >>> >>> 5) Recognition of glibc version and >>> pthread library >>> version were >>> very >>> elaborate to deal with recognition of >>> LinuxThreads >>> implementation. Those >>> were dumbed down and now just assert in >>> the highly >>> unlikely case >>> that we >>> encounter a LinuxThreads implementation. >>> >>> The rest of the stuff is more >>> straight-forward. >>> >>> --- >>> >>> I built the changes on Linux x64, x86 and >>> ppc64 and ran >>> jtreg tests >>> (hotspot/test) on these platforms too. I >>> did not see >>> any issues, >>> but I'd >>> like to get a couple of reviews for this. >>> >>> Kind Regards, >>> Thomas >>> >>> >>> >>> >>> > From sgehwolf at redhat.com Mon Jun 15 13:00:24 2015 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 15 Jun 2015 15:00:24 +0200 Subject: RFR(XS) 8098552: 8079792 breaks Zero builds without precompiled headers. In-Reply-To: <557EC2B2.3080205@oracle.com> References: <1434362316.4806.17.camel@redhat.com> <557EBF96.8020109@oracle.com> <20150615121643.GG29290@ehelin.jrpg.bea.com> <557EC2B2.3080205@oracle.com> Message-ID: <1434373224.4806.22.camel@redhat.com> Hi, On Mon, 2015-06-15 at 14:18 +0200, Stefan Johansson wrote: > Thanks Erik, > > Severin, can you provide an updated patch generated by 'hg export'. Once > I get that, I'll push it right away. No need to wait 24h for such a > trivial fix. Thanks, Stefan and Erik. I've sent the updated hg exported patch to Stefan for pushing. Cheers, Severin > Thanks, > Stefan > > On 2015-06-15 14:16, Erik Helin wrote: > > On 2015-06-15, Stefan Johansson wrote: > >> Hi Severin, > >> > >> Fix is correct, but we try to keep the includes sorted so please change it > >> to be: > >> #include "memory/allocation.hpp" > >> +#include "memory/memRegion.hpp" > >> #include "utilities/debug.hpp" > >> > >> I'm not a reviewer, but can sponsor this change and push it as soon as we > >> get a Reviewer to look at it. > > Pending the comment above by Stefan, the patch looks good. Reviewed. > > > > Thanks, > > Erik > > > >> Thanks, > >> Stefan > >> > >> On 2015-06-15 11:58, Severin Gehwolf wrote: > >>> Hi, > >>> > >>> Could somebody please review and sponsor this trivial fix? The issue is > >>> that the Zero build fails with precompiled headers turned off (other > >>> builds probably too, but I haven't checked). The fix is to include > >>> memRegion.hpp in g1/g1BiasedArray.hpp since it uses MemRegion. > >>> > >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8098552 > >>> webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8098552/webrev.01/ > >>> > >>> Thanks, > >>> Severin > >>> > From igor.ignatyev at oracle.com Mon Jun 15 13:34:24 2015 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Mon, 15 Jun 2015 16:34:24 +0300 Subject: RFR: JDK-8075327: Merge jdk and hotspot test libraries In-Reply-To: <1365a232-5a2d-4365-ad99-3638fdfac841@default> References: <1365a232-5a2d-4365-ad99-3638fdfac841@default> Message-ID: <557ED460.4050900@oracle.com> Alexander, > Therefore, I would suggest reviewing the current patch as it is , since the changes are trivial and postpone refactoring to the new packages until some time later, since such refactoring is not trivial and the current patch does provide for the merge. I agree that we should separate merge of test-libraries and refactoring them. however I do have a comment regarding the current patch. besides classes in jdk.test.lib package, hotspot test-library contains other common libraries: * jdk.test.lib.cli -- a test framework for command line option tests * jdk.test.lib.dcmd -- aux classes to simplify work w/ jcmd * jdk.test.lib.dtrace -- a test framework for dtrace tests From my point of view, all these packages can be used in jdk tests as well. so I think these packages should be moved to top-level repository. Another reason why these packages should be neither moved nor renamed (to smth like hotspot.test.lib) is ambiguity. If one see classes from jdk.test.lib package (or its subpackages), he/she will expect to find their source in /test, but in your current version, they are placed in hotspot/test. Even if we ok, we such ambiguity there is a risk that at some point, one will introduce another 'jdk.test.lib.cli' in top-level test directory. It will be really really hard to understand which libraries should be used. That means that all other classes from both jdk/test/lib/testlibrary/jdk/testlibrary/ and /hotspot/test/testlibrary/jdk/test/lib should be moved to /test. PS I also noticed that RandomFactory[1] class kinda duplicates Utils::getRandomInstance[2], could you please merge them or file an RFE to do it? Stuart, could you please review jdk part of this patch? [1] http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/c1947d42537b/test/lib/testlibrary/jdk/testlibrary/RandomFactory.java [2] http://hg.openjdk.java.net/jdk9/jdk9/hotspot/file/c25bfaaed7f2/test/testlibrary/jdk/test/lib/Utils.java#l367 -- Thanks, Igor On 06/04/2015 05:23 PM, Alexander Kulyakhtin wrote: > Stefan, > > There are some issues which may make it difficult to implement the grouping of the common test library files into the new packages as JDK-8075327 proposes. > > The changes in the current patch are trivial and made by a script (although they spread over many files). > They are trivial because the names of the packages are left intact (except fo renaming of jdk.testlibrary to jdk.test.lib in the jdk repo). > > However, if we introduce the new packages per the CR description we will end up with > > import jdk.test.lib.*; > import jdk.test.lib.vm.*; > import jdk.test.lib.processtools.*; > import jdk.test.lib.misc.*; > > where previously was just a single line > > import jdk.test.lib.*; > > The same goes for @build and @run directives where we end up with > > @build jdk.test.lib.* jdk.test.lib.vm.* jdk.test.lib.processtools.* jdk.test.lib.misc.* > > instead of > > @build jdk.test.lib.* > > There are many tests having import jdk.test.lib.* and @build jdk.test.lib.* and similar constructions. > > If we then want to deduce the minimal required dependencies for each and every jdk and hotspot test, then it will not be as trivial task as what we have currently done. It will, probably, require a significant review effort from both jdk and hotspot teams. > The benefits of that effort are not quite evident for me though I, probably, might be missing something here. > > The current patch does already provide for the merge of the common part of the jdk and hotspot libraries and do eliminate the duplicated files. > > Therefore, I would suggest reviewing the current patch as it is , since the changes are trivial and postpone refactoring to the new packages until some time later, since such refactoring is not trivial and the current patch does provide for the merge. > > Best regards, > Alexander > > ----- Original Message ----- > From: alexander.kulyakhtin at oracle.com > To: stefan.sarne at oracle.com > Cc: jdk9-dev at openjdk.java.net, yekaterina.kantserova at oracle.com, hotspot-dev at openjdk.java.net > Sent: Wednesday, June 3, 2015 3:33:22 PM GMT +03:00 Iraq > Subject: Re: RFR: JDK-8075327: Merge jdk and hotspot test libraries > > > > Hi Stefan, > > Thank you very much for the review. I'll update the patch accordingly, shortly. > > Best regards, > Alexander > > ----- Original Message ----- > From: stefan.sarne at oracle.com > To: alexander.kulyakhtin at oracle.com, jdk9-dev at openjdk.java.net, hotspot-dev at openjdk.java.net > Cc: yekaterina.kantserova at oracle.com > Sent: Wednesday, June 3, 2015 12:08:33 PM GMT +03:00 Iraq > Subject: Re: RFR: JDK-8075327: Merge jdk and hotspot test libraries > > > > Hi Alexander, > > I think we want to group the utilities into packages directly. > > One reason for grouping is to support discovery, to clarify what belongs together. For example both the OutputAnalyzer and the StreamPumper belong together in a processtools package, while Asserts doesn't. > > Another reason is to simplify imports and reduce the impact of wild card includes, since for example an import of process tools should not have to bother with declaring usage of sun.misc.Unsafe in the modules world, just because Utils happen to be in the same package. > > Here are some examples - also available in the jira case: > > Package jdk.test.lib.processtools is the package for utilities for launching processes and analyzing the output. > /test/lib/share/classes/jdk/test/lib/processtools/OutputAnalyzer.java > /test/lib/share/classes/jdk/test/lib/processtools/OutputBuffer.java > /test/lib/share/classes/jdk/test/lib/processtools/ProcessTools.java > /test/lib/share/classes/jdk/test/lib/processtools/StreamPumper.java > /test/lib/share/classes/jdk/test/lib/processtools/JDKToolFinder.java > /test/lib/share/classes/jdk/test/lib/processtools/JDKToolLauncher.java > > /test/lib-test/jdk/test/lib/processtools/OutputAnalyzerTest.java > > > Asserts can stay at top level. > /test/lib/share/classes/jdk/test/lib/Asserts.java > /test/lib-test/jdk/test/lib/AssertsTest.java > > > For VM specific info, it would have vm package. Note that the whitebox API moves here. > /test/lib/share/classes/jdk/test/lib/vm/InputArguments.java > /test/lib/share/classes/jdk/test/lib/vm/Platform.java > > > Ok, so then there are the stuff which just is a bucket of stuff and fluff. > A later exercise could be to break this class into better named and placed classes, but this is a start: > /test/lib/share/classes/jdk/test/lib/misc/Utils.java > > Thanks, > Stefan > > > Alexander Kulyakhtin skrev den 2015-06-02 13:18: > > > Hi, > > Could you, please, review the following test-only changes to the 'jdk', 'hotspot' and the common 'test' repository http://cr.openjdk.java.net/~akulyakh/8075327/wr_hs/webrev.01/index.html http://cr.openjdk.java.net/~akulyakh/8075327/wr_jdk/webrev.01/index.html http://cr.openjdk.java.net/~akulyakh/8075327/wr_test/webrev.01/ The changes are to move test library files common to both jdk and hotspot to the upper-level test repository. > > The following has been done: > 1) Common files (Asserts.java, OutputAnalyzer.java etc) from the jdk and hotspot repositories, have been merged and moved to the upper-level common test repository, to test/lib/share/classes. > 2) Package jdk.testlibrary in the jdk repository have been renamed to jdk.test.lib to have the same name as in the hotspot repository > 2) Upper level test/lib/share/classes library references have been added to the @library statements > 3) Some packages previously located at upper level test repo at /test/lib have been moved to /test/lib/share/classes for consistency > > Best regards, > Alexander > From Alexander.Alexeev at caviumnetworks.com Mon Jun 15 13:51:40 2015 From: Alexander.Alexeev at caviumnetworks.com (Alexeev, Alexander) Date: Mon, 15 Jun 2015 13:51:40 +0000 Subject: RFR: aarch64: Bit count intrinsic implementation for aarch64 In-Reply-To: <557ECAA9.1030706@redhat.com> References: <557ECAA9.1030706@redhat.com> Message-ID: > Do any of those tests actually test popcount? Relevant JDK tests also all pass jdk/test/java/lang/Long/* jdk/test/java/lang/Integer/* Regards, Alexander From stefan.sarne at oracle.com Mon Jun 15 14:23:16 2015 From: stefan.sarne at oracle.com (=?UTF-8?B?U3RlZmFuIFPDpHJuZQ==?=) Date: Mon, 15 Jun 2015 16:23:16 +0200 Subject: RFR: JDK-8075327: Merge jdk and hotspot test libraries In-Reply-To: <1365a232-5a2d-4365-ad99-3638fdfac841@default> References: <1365a232-5a2d-4365-ad99-3638fdfac841@default> Message-ID: <557EDFD4.8090303@oracle.com> Hi Alexander, If you prefer to make this change in two steps, I am ok with this. I think further cleanup into packages is important. But as you highlight, it will not be good if we just "add imports to all new locations". There should not be unused imports. Thanks, Stefan Alexander Kulyakhtin skrev den 2015-06-04 16:23: > Stefan, > > There are some issues which may make it difficult to implement the > grouping of the common test library files into the new packages as > JDK-8075327 proposes. > > The changes in the current patch are trivial and made by a script > (although they spread over many files). > They are trivial because the names of the packages are left intact > (except fo renaming of jdk.testlibrary to jdk.test.lib in the jdk repo). > > However, if we introduce the new packages per the CR description we > will end up with > > import jdk.test.lib.*; > import jdk.test.lib.vm.*; > import jdk.test.lib.processtools.*; > import jdk.test.lib.misc.*; > > where previously was just a single line > > import jdk.test.lib.*; > > The same goes for @build and @run directives where we end up with > > @build jdk.test.lib.* jdk.test.lib.vm.* jdk.test.lib.processtools.* > jdk.test.lib.misc.* > > instead of > > @build jdk.test.lib.* > > There are many tests having import jdk.test.lib.* and @build > jdk.test.lib.* and similar constructions. > > If we then want to deduce the minimal required dependencies for each > and every jdk and hotspot test, then it will not be as trivial task > as what we have currently done. It will, probably, require a > significant review effort from both jdk and hotspot teams. > The benefits of that effort are not quite evident for me though I, > probably, might be missing something here. > > The current patch does already provide for the merge of the common > part of the jdk and hotspot libraries and do eliminate the duplicated > files. > > Therefore, I would suggest reviewing the current patch as it is , > since the changes are trivial and postpone refactoring to the new > packages until some time later, since such refactoring is not trivial > and the current patch does provide for the merge. > > Best regards, > Alexander > > ----- Original Message ----- > From: alexander.kulyakhtin at oracle.com > To: stefan.sarne at oracle.com > Cc: jdk9-dev at openjdk.java.net, yekaterina.kantserova at oracle.com, > hotspot-dev at openjdk.java.net > Sent: Wednesday, June 3, 2015 3:33:22 PM GMT +03:00 Iraq > Subject: Re: RFR: JDK-8075327: Merge jdk and hotspot test libraries > > Hi Stefan, > > Thank you very much for the review. I'll update the patch accordingly, > shortly. > > Best regards, > Alexander > > ----- Original Message ----- > From: stefan.sarne at oracle.com > To: alexander.kulyakhtin at oracle.com, jdk9-dev at openjdk.java.net, > hotspot-dev at openjdk.java.net > Cc: yekaterina.kantserova at oracle.com > Sent: Wednesday, June 3, 2015 12:08:33 PM GMT +03:00 Iraq > Subject: Re: RFR: JDK-8075327: Merge jdk and hotspot test libraries > > > Hi Alexander, > > I think we want to group the utilities into packages directly. > > One reason for grouping is to support discovery, to clarify what > belongs together. For example both the OutputAnalyzer and the > StreamPumper belong together in a processtools package, while Asserts > doesn't. > > Another reason is to simplify imports and reduce the impact of wild > card includes, since for example an import of process tools should not > have to bother with declaring usage of sun.misc.Unsafe in the modules > world, just because Utils happen to be in the same package. > > Here are some examples - also available in the jira case: > > Package jdk.test.lib.processtools is the package for utilities for > launching processes and analyzing the output. > root>/test/lib/share/classes/jdk/test/lib/processtools/OutputAnalyzer.java > root>/test/lib/share/classes/jdk/test/lib/processtools/OutputBuffer.java > root>/test/lib/share/classes/jdk/test/lib/processtools/ProcessTools.java > root>/test/lib/share/classes/jdk/test/lib/processtools/StreamPumper.java > root>/test/lib/share/classes/jdk/test/lib/processtools/JDKToolFinder.java > root>/test/lib/share/classes/jdk/test/lib/processtools/JDKToolLauncher.java > > root>/test/lib-test/jdk/test/lib/processtools/OutputAnalyzerTest.java > > > Asserts can stay at top level. > /test/lib/share/classes/jdk/test/lib/Asserts.java > /test/lib-test/jdk/test/lib/AssertsTest.java > > > For VM specific info, it would have vm package. Note that the whitebox > API moves here. > /test/lib/share/classes/jdk/test/lib/vm/InputArguments.java > /test/lib/share/classes/jdk/test/lib/vm/Platform.java > > > Ok, so then there are the stuff which just is a bucket of stuff and fluff. > A later exercise could be to break this class into better named and > placed classes, but this is a start: > /test/lib/share/classes/jdk/test/lib/misc/Utils.java > > Thanks, > Stefan > > Alexander Kulyakhtin skrev den 2015-06-02 13:18: > > Hi, > > Could you, please, review the following test-only changes to the 'jdk', 'hotspot' and the common 'test' repository > > http://cr.openjdk.java.net/~akulyakh/8075327/wr_hs/webrev.01/index.html > http://cr.openjdk.java.net/~akulyakh/8075327/wr_jdk/webrev.01/index.html > http://cr.openjdk.java.net/~akulyakh/8075327/wr_test/webrev.01/ > > The changes are to move test library files common to both jdk and hotspot to the upper-level test repository. > > The following has been done: > 1) Common files (Asserts.java, OutputAnalyzer.java etc) from the jdk and hotspot repositories, have been merged and moved to the upper-level common test repository, to test/lib/share/classes. > 2) Package jdk.testlibrary in the jdk repository have been renamed to jdk.test.lib to have the same name as in the hotspot repository > 2) Upper level test/lib/share/classes library references have been added to the @library statements > 3) Some packages previously located at upper level test repo at /test/lib have been moved to /test/lib/share/classes for consistency > > Best regards, > Alexander > > From goetz.lindenmaier at sap.com Mon Jun 15 15:30:16 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 15 Jun 2015 15:30:16 +0000 Subject: Ping: RFR(M): 8086069: Adapt runtime calls to recent intrinsics to pass ints as long Message-ID: <4295855A5C1DE049A61835A1887419CC2CFF9D17@DEWDFEMB12A.global.corp.sap> Hi, Could someone please have a look at this change? I had a look whether I can push the functionality down to make_runtime_call(). This would simplify matters a lot. But as the TypeFunc is hashed, I can not change it any more in make_runtime_call(). @aarch-people: I saw you have CCallingConventionRequiresIntsAsLongs set. Could you please check whether this breaks your intinsics, e.g., multiplyToLen? (We assure in sharedRuntime_ppc.cpp, c_calling_convention() that no INT types end up there.) Thanks, Goetz -----Original Message----- From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Lindenmaier, Goetz Sent: Dienstag, 9. Juni 2015 17:18 To: HotSpot Developers Subject: RFR(M): 8086069: Adapt runtime calls to recent intrinsics to pass ints as long Hi, we are working on porting the recently* added intrinsics to PPC. As these use runtime calls, the calls must obey to the platform ABI, which requires that ints are passed as longs. We made a similar change in "8024342: PPC64 (part 111): Support for C calling conventions that require 64-bit ints." It adapts the calls if CCallingConventionRequiresIntsAsLongs is set. This change adapts the calls to multiplyToLen, CRC32, AES, SHA accordingly. Please review this change. I please need a sponsor. http://cr.openjdk.java.net/~goetz/webrevs/8086069-call_conv/webrev.01/ Best regards, Goetz * i.e., added after making our initial port From stefan.karlsson at oracle.com Mon Jun 15 15:38:14 2015 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Mon, 15 Jun 2015 17:38:14 +0200 Subject: RFR: 8087200: Code heap does not use large pages In-Reply-To: <20150612151552.GD29290@ehelin.jrpg.bea.com> References: <20150612151552.GD29290@ehelin.jrpg.bea.com> Message-ID: <557EF166.7080006@oracle.com> Hi Erik, On 2015-06-12 17:15, Erik Helin wrote: > Hi all, > > this patch fixes an issue with the page sizing in in the code heap > in 8u60 that was introduced in the backport for JDK-8049864. The issue does > not exist in JDK 9 because the code heap in JDK 9 has been rewritten and > uses the VirtualSpace to decide the page size for the reserved size > (there is still an issue with the alignment of the comittted size in JDK > 9, see JDK-8087339 [0]). > > The fix for 8u60 consists of using the reserved size to determine the > page size (and not require that the page size divides the reserved > size, because the reserved size will be aligned to the page size later > anyway). > > Webrev: > http://cr.openjdk.java.net/~ehelin/8087200/webrev.00/ Looks good. StefanK > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8087200 > > Testing: > - JPRT > - Ad-hoc: > - Bigapps: > - Kitchensink > - runThese > - Weblogic > - JTReg: > - JDK > - SVC > - NSK > - Confirmed that the perf regression introduced with the backport of [0] > went away. > > Thanks, > Erik > > [0]: https://bugs.openjdk.java.net/browse/JDK-8087339 From vladimir.kozlov at oracle.com Mon Jun 15 16:16:35 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 15 Jun 2015 09:16:35 -0700 Subject: RFR: aarch64: Bit count intrinsic implementation for aarch64 In-Reply-To: References: <557ECAA9.1030706@redhat.com> Message-ID: <557EFA63.50203@oracle.com> Andrew, please, help Alexeev to file JBS bug and publish webrev on cr.openjdk. We can't review or accept patches which are not on cr. server. There are several hotspot tests which check bitCount intrinsics (for example, compiler//codegen/6378821/Test6378821.java) but not full range of values. Note, jdk tests should be run with -Xcomp to make sure methods are compiled and intrinsics are used. Thanks, Vladimir On 6/15/15 6:51 AM, Alexeev, Alexander wrote: > >> Do any of those tests actually test popcount? > > Relevant JDK tests also all pass > jdk/test/java/lang/Long/* > jdk/test/java/lang/Integer/* > > Regards, > Alexander > From aph at redhat.com Mon Jun 15 16:22:50 2015 From: aph at redhat.com (Andrew Haley) Date: Mon, 15 Jun 2015 17:22:50 +0100 Subject: RFR: aarch64: Bit count intrinsic implementation for aarch64 In-Reply-To: <557EFA63.50203@oracle.com> References: <557ECAA9.1030706@redhat.com> <557EFA63.50203@oracle.com> Message-ID: <557EFBDA.5050404@redhat.com> On 06/15/2015 05:16 PM, Vladimir Kozlov wrote: > Andrew, please, help Alexeev to file JBS bug and publish webrev on cr.openjdk. We can't review or accept patches which > are not on cr. server. Sure, I'll do that. Given that he now has done the paperwork, is there anything to prevent him from having an account on cr.openjdk? Andrew. From christian.thalinger at oracle.com Mon Jun 15 16:56:49 2015 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 15 Jun 2015 09:56:49 -0700 Subject: CFV: New HotSpot Group Lead: Vladimir Kozlov Message-ID: I hereby nominate Vladimir Kozlov to HotSpot Group Lead [1]. Vladimir is a member of the HotSpot Group since OpenJDK was established, is working on the HotSpot JVM for more than 12 years and is well known in the HotSpot OpenJDK community. Votes are due by June 26, 2015 12:00 PST. Only current Members of the HotSpot Group [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Simple Majority voting instructions, see [3]. Thanks, Christian Thalinger [1]: http://openjdk.java.net/bylaws#group-lead [2]: http://openjdk.java.net/census#hotspot [3]: http://openjdk.java.net/groups#lead-vote From dawid.weiss at gmail.com Mon Jun 15 17:01:46 2015 From: dawid.weiss at gmail.com (Dawid Weiss) Date: Mon, 15 Jun 2015 19:01:46 +0200 Subject: CFV: New HotSpot Group Lead: Vladimir Kozlov In-Reply-To: References: Message-ID: [non-eligible] but sincere +1. Dawid On Mon, Jun 15, 2015 at 6:56 PM, Christian Thalinger wrote: > I hereby nominate Vladimir Kozlov to HotSpot Group Lead [1]. > > Vladimir is a member of the HotSpot Group since OpenJDK was > established, is working on the HotSpot JVM for more than 12 years > and is well known in the HotSpot OpenJDK community. > > Votes are due by June 26, 2015 12:00 PST. > > Only current Members of the HotSpot Group [2] are eligible to > vote on this nomination. Votes must be cast in the open by > replying to this mailing list. > > For Simple Majority voting instructions, see [3]. > > Thanks, > Christian Thalinger > > [1]: http://openjdk.java.net/bylaws#group-lead > [2]: http://openjdk.java.net/census#hotspot > [3]: http://openjdk.java.net/groups#lead-vote From bertrand.delsart at oracle.com Mon Jun 15 17:10:14 2015 From: bertrand.delsart at oracle.com (Bertrand Delsart) Date: Mon, 15 Jun 2015 19:10:14 +0200 Subject: RFR [S] 8081406: cleanup and minor extensions of the debugging facilities in CodeStrings In-Reply-To: <55674A24.4050501@oracle.com> References: <55674A24.4050501@oracle.com> Message-ID: <557F06F6.203@oracle.com> Friendly reminder. Bertrand. On 28/05/2015 19:02, Bertrand Delsart wrote: > Hi all, > > Small RFR to address minor issues in debug mode with CodeStrings > > https://bugs.openjdk.java.net/browse/JDK-8081406 > http://cr.openjdk.java.net/~bdelsart/8081406/webrev.00/ > > The change does not impact the product mode. > > In non product mode, CodeStrings allows to associate a linked list of > strings to a CodeBuffer, CodeBlob or Stub. In addition, with ASSERTS, it > defines a boolean asserting whether the list of strings are valid. > > Here are the issues addressed by this CR: > > - The old code mentioned the fact that CodeStrings was not always > correctly initialized. This is addressed by the fix, allowing > check_valid to be added at a few locations where it could currently > failed due to uninitialized values (like at the beginning of > CodeStrings::free). This also makes the code more robust against future > versions of CodeStrings. > > - As a minor extension, it is now possible for platform dependent code > to modify the comment separator used by print_block_comment, which was > hard coded to " ;; ". > > - As another minor extension, related to the validity assertions, > freeing a code string no longer necessarily marks it (and hence its > Stub/CodeBlob/CodeBuffer) as invalid. If CodeStrings contains only > comment, removing them does not change the validity of the CodeStrings. > For similar reason, assignment over a non null CodeStrings is now valid > when we can safely free the old string. > > The modified code passes JPRT. It was also validated in fastdebug mode > with the vm.compiler.testlist to check that the validity assertion were > not triggered. One of our closed extensions also validated advanced use > of CodeStrings::assign (included cases where the target of the > assignment was not free). > > Best regards, > > Bertrand. > -- Bertrand Delsart, Grenoble Engineering Center Oracle, 180 av. de l'Europe, ZIRST de Montbonnot 38330 Montbonnot Saint Martin, FRANCE bertrand.delsart at oracle.com Phone : +33 4 76 18 81 23 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From volker.simonis at gmail.com Mon Jun 15 17:19:03 2015 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 15 Jun 2015 19:19:03 +0200 Subject: CFV: New HotSpot Group Lead: Vladimir Kozlov In-Reply-To: References: Message-ID: Vote: yes On Mon, Jun 15, 2015 at 6:56 PM, Christian Thalinger wrote: > I hereby nominate Vladimir Kozlov to HotSpot Group Lead [1]. > > Vladimir is a member of the HotSpot Group since OpenJDK was > established, is working on the HotSpot JVM for more than 12 years > and is well known in the HotSpot OpenJDK community. > > Votes are due by June 26, 2015 12:00 PST. > > Only current Members of the HotSpot Group [2] are eligible to > vote on this nomination. Votes must be cast in the open by > replying to this mailing list. > > For Simple Majority voting instructions, see [3]. > > Thanks, > Christian Thalinger > > [1]: http://openjdk.java.net/bylaws#group-lead > [2]: http://openjdk.java.net/census#hotspot > [3]: http://openjdk.java.net/groups#lead-vote From stefan.karlsson at oracle.com Mon Jun 15 17:21:58 2015 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Mon, 15 Jun 2015 19:21:58 +0200 Subject: CFV: New HotSpot Group Lead: Vladimir Kozlov In-Reply-To: References: Message-ID: <557F09B6.101@oracle.com> Vote: yes StefanK On 2015-06-15 18:56, Christian Thalinger wrote: > I hereby nominate Vladimir Kozlov to HotSpot Group Lead [1]. > > Vladimir is a member of the HotSpot Group since OpenJDK was > established, is working on the HotSpot JVM for more than 12 years > and is well known in the HotSpot OpenJDK community. > > Votes are due by June 26, 2015 12:00 PST. > > Only current Members of the HotSpot Group [2] are eligible to > vote on this nomination. Votes must be cast in the open by > replying to this mailing list. > > For Simple Majority voting instructions, see [3]. > > Thanks, > Christian Thalinger > > [1]: http://openjdk.java.net/bylaws#group-lead > [2]: http://openjdk.java.net/census#hotspot > [3]: http://openjdk.java.net/groups#lead-vote From christian.thalinger at oracle.com Mon Jun 15 17:23:00 2015 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 15 Jun 2015 10:23:00 -0700 Subject: CFV: New HotSpot Group Lead: Vladimir Kozlov In-Reply-To: References: Message-ID: <8B79D4DF-DC3A-4381-AEBA-87DAD3DE2C26@oracle.com> Vote: yes > On Jun 15, 2015, at 9:56 AM, Christian Thalinger wrote: > > I hereby nominate Vladimir Kozlov to HotSpot Group Lead [1]. > > Vladimir is a member of the HotSpot Group since OpenJDK was > established, is working on the HotSpot JVM for more than 12 years > and is well known in the HotSpot OpenJDK community. > > Votes are due by June 26, 2015 12:00 PST. > > Only current Members of the HotSpot Group [2] are eligible to > vote on this nomination. Votes must be cast in the open by > replying to this mailing list. > > For Simple Majority voting instructions, see [3]. > > Thanks, > Christian Thalinger > > [1]: http://openjdk.java.net/bylaws#group-lead > [2]: http://openjdk.java.net/census#hotspot > [3]: http://openjdk.java.net/groups#lead-vote From daniel.daugherty at oracle.com Mon Jun 15 17:25:03 2015 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Mon, 15 Jun 2015 11:25:03 -0600 Subject: CFV: New HotSpot Group Lead: Vladimir Kozlov In-Reply-To: References: Message-ID: <557F0A6F.3030200@oracle.com> Vote: yes Dan On 6/15/15 10:56 AM, Christian Thalinger wrote: > I hereby nominate Vladimir Kozlov to HotSpot Group Lead [1]. > > Vladimir is a member of the HotSpot Group since OpenJDK was > established, is working on the HotSpot JVM for more than 12 years > and is well known in the HotSpot OpenJDK community. > > Votes are due by June 26, 2015 12:00 PST. > > Only current Members of the HotSpot Group [2] are eligible to > vote on this nomination. Votes must be cast in the open by > replying to this mailing list. > > For Simple Majority voting instructions, see [3]. > > Thanks, > Christian Thalinger > > [1]: http://openjdk.java.net/bylaws#group-lead > [2]: http://openjdk.java.net/census#hotspot > [3]: http://openjdk.java.net/groups#lead-vote From gerard.ziemski at oracle.com Mon Jun 15 17:26:04 2015 From: gerard.ziemski at oracle.com (Gerard Ziemski) Date: Mon, 15 Jun 2015 12:26:04 -0500 Subject: Revision3: Corrected: RFR 8059557 (XL): Validate JVM Command-Line Flag Arguments In-Reply-To: <0967AA32-430D-430F-98E2-BF70F77287B8@oracle.com> References: <557C3EF0.3030107@oracle.com> <0967AA32-430D-430F-98E2-BF70F77287B8@oracle.com> Message-ID: <557F0AAC.4080406@oracle.com> hi Kim, David, I am responding to Kim?s comments in-line, but David please see the last comment, which addresses an issue that you have brought up earlier in rev 2: > On Jun 15, 2015, at 10:41 AM, Gerard Ziemski wrote: > > > > > -------- Forwarded Message -------- > Subject: Re: Revision3: Corrected: RFR 8059557 (XL): Validate JVM Command-Line Flag Arguments > Date: Sat, 13 Jun 2015 16:54:39 -0400 > From: Kim Barrett > To: Gerard Ziemski > CC: hotspot-dev > > On Jun 13, 2015, at 10:32 AM, Gerard Ziemski > wrote: >> Here is a revision 3 of the feature taking into account feedback from Kim Barrett, David Holmes, Derek White and Bengt Rutisson. I have also merged the changes to the latest jdk9. [...] > Here are a few comments on Revision3. I think all of these can (and > should) be handled via followup CRs, and that none of these should > prevent Revision3 from being pushed as is. I think I should spin up rev 4 - please see the last issue here, which you have raised. > > If another round of review for this change does prove to be needed (I > hope not), please provide an incremental webrev in the review package. > > ------------------------------------------------------------------------------ > src/share/vm/gc/g1/g1_globals.hpp > 71 product(double, G1ConcMarkStepDurationMillis, 10.0, \ > 72 "Target duration of individual concurrent marking steps " \ > 73 "in milliseconds.") \ > 74 range(1.0, (double)max_uintx) \ > > The new upper bound here seems like a completely random number to me. > The existing ad-hoc code just checked the min, and left the upper bound unchecked. Since we need an upper bound for range check, I had to provide some reasonable value and (double)max_uintx seemed a better choice than the mathematically correct DBL_MAX, which would require me to add #import > ------------------------------------------------------------------------------ > src/share/vm/opto/c2_globals.hpp > 110 notproduct(intx, IndexSetWatch, 0, \ > 111 "Trace all operations on this IndexSet (-1 means all, 0 none)") \ > 112 range(-1, 0) \ > > I suspect the upper bound here should be uint_max. > Fixed, though I believe that the value should be actually max_intx. > ------------------------------------------------------------------------------ > src/share/vm/runtime/globals.hpp > 375 static const char* flag_error_str(Flag::Error error) { > > All other functions for the Flag are declared in the .hpp and defined > in the .cpp file. I don't see any reason for this function to be > different. > > ?flag_error_str? is a static method and I simply followed the pattern set by the other static methods (ie. ?find_flag?, ?fuzzy_match?). > ------------------------------------------------------------------------------ > src/share/vm/runtime/globals.hpp > 1563 product(size_t, HeapSizePerGCThread, ScaleForWordSize(64*M), \ > 1564 "Size of heap (bytes) per GC thread used in calculating the " \ > 1565 "number of GC threads") \ > 1566 range((uintx)os::vm_page_size(), max_uintx) \ > > Type is size_t, but range values are using uintx. > The original ad-hoc code used "(uintx)os::vm_page_size()? for the min, but did not check the upper bound, so I provided max_uintx for the max. Also, HeapSizePerGCThread is assigned to a local variable of type ?uintx? and there is no such thing as max_size_t (?) > ------------------------------------------------------------------------------ > src/share/vm/runtime/globals.hpp > 1846 product(size_t, MarkStackSizeMax, NOT_LP64(4*M) LP64_ONLY(512*M), \ > 1847 "Maximum size of marking stack") \ > 1848 range(1, (max_jint - 1)) \ > > That's a very odd looking maximum. > > It comes from the original ad-hoc code. > ------------------------------------------------------------------------------ > src/share/vm/services/classLoadingService.cpp > 35 #include "utilities/defaultStream.hpp" > > I think utilities/ostream.hpp might be sufficient here. > OK. > ------------------------------------------------------------------------------ > src/share/vm/runtime/commandLineFlagConstraintsGC.cpp > 100 #define UseConcMarkSweepGCWorkaroundIfNeeded(initial, max) { \ > 101 if ((initial == 7) && (max == 6)) { \ > 102 return Flag::SUCCESS; \ > 103 } \ > 104 } > > The do/while(0) macro idiom is the usual way to encapsulate > statements. It took me a couple of tries to parse this, where it > would have been immediately obvious with the do/while(0) idiom. > > Can you please provide a concrete example of how I should use "do/while(0)? here? I don't understand how that would help with the readability - we?re talking here about a simple macro that short-circuits a method if the ?if? statement passes. > ------------------------------------------------------------------------------ > src/share/vm/runtime/globals.cpp > > In the various apply_constraint_and_check_range_TYPE functions, the > present pattern seems to be to find and check the range (if it > exists), then find and apply the constraint (if it exists), and then > combine the results. > > I think it might be better to not apply the constraint if there is a > range check failure. That way, constraint functions can be written to > assume that the values have been range checked, and only need to worry > about whatever additional constraints might exist, without the need to > potentially deal with out of range values. > > Whichever behavior is used should be documented as part of the > interface to this facility, since it affects how one writes constraint > functions. It might also, in some cases, affect whether it is useful > to provide a range spec in conjunction with a constraint function. > > Such a change might also eliminate the need for the get_status_error > helper. > > [Obviously this is pretty high priority if handled as a followup > change, since it has a somewhat significant impact on how one writes > constraint functions.] > I added this behavior to address David?s concern from webrev 2, but to be honest I had doubts about it. Originally, I had the code checking the ranges first, and only checking the constraints if the range check passed. However, that required me to change "test/runtime/CompressedOops/ObjectAlignment.java? and "/test/runtime/contended/Options.java?, by removing the cases that checked both ranges and constraints, which David pointed out as loosing functionality. The previous ad-hoc code was free to do whatever it wanted and in those 2 cases (ObjectAlignmentInBytes and ContendedPaddingWidth) the test was free to check both the range and constraint at the same time. So I tried to do the same in my framework, but that made the code a bit more complex (ie. need for ?get_status_error? helper). Most importantly, however, I much prefer the design where the constraint check is only attempted if the range passes (ie. constraint is guaranteed that the value is within the range) I will revert the code back to what it was like in webrev 2, and these 2 tests will technically loose some functionality, however, there are specific test cases in each of the tests that do exercise both the constraint and the range, though one at the time. I will rev up to #4 and will come up with rev2 -> rev4 diffs shortly. Thank you for your patience! cheers From roland.westrelin at oracle.com Mon Jun 15 17:30:26 2015 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Mon, 15 Jun 2015 19:30:26 +0200 Subject: CFV: New HotSpot Group Lead: Vladimir Kozlov In-Reply-To: References: Message-ID: <058461C7-499A-4209-AA5B-2EE18C7E7EB8@oracle.com> Vote: yes Roland. > On Jun 15, 2015, at 6:56 PM, Christian Thalinger wrote: > > I hereby nominate Vladimir Kozlov to HotSpot Group Lead [1]. > > Vladimir is a member of the HotSpot Group since OpenJDK was > established, is working on the HotSpot JVM for more than 12 years > and is well known in the HotSpot OpenJDK community. > > Votes are due by June 26, 2015 12:00 PST. > > Only current Members of the HotSpot Group [2] are eligible to > vote on this nomination. Votes must be cast in the open by > replying to this mailing list. > > For Simple Majority voting instructions, see [3]. > > Thanks, > Christian Thalinger > > [1]: http://openjdk.java.net/bylaws#group-lead > [2]: http://openjdk.java.net/census#hotspot > [3]: http://openjdk.java.net/groups#lead-vote From kmcguigan at twitter.com Mon Jun 15 17:53:44 2015 From: kmcguigan at twitter.com (Keith McGuigan) Date: Mon, 15 Jun 2015 13:53:44 -0400 Subject: CFV: New HotSpot Group Lead: Vladimir Kozlov In-Reply-To: References: Message-ID: Vote: yes On Mon, Jun 15, 2015 at 12:56 PM, Christian Thalinger < christian.thalinger at oracle.com> wrote: > I hereby nominate Vladimir Kozlov to HotSpot Group Lead [1]. > > Vladimir is a member of the HotSpot Group since OpenJDK was > established, is working on the HotSpot JVM for more than 12 years > and is well known in the HotSpot OpenJDK community. > > Votes are due by June 26, 2015 12:00 PST. > > Only current Members of the HotSpot Group [2] are eligible to > vote on this nomination. Votes must be cast in the open by > replying to this mailing list. > > For Simple Majority voting instructions, see [3]. > > Thanks, > Christian Thalinger > > [1]: http://openjdk.java.net/bylaws#group-lead < > http://openjdk.java.net/bylaws#group-lead> > [2]: http://openjdk.java.net/census#hotspot < > http://openjdk.java.net/census#hotspot> > [3]: http://openjdk.java.net/groups#lead-vote < > http://openjdk.java.net/groups#lead-vote> -- [image: twitter-icon-large.png] Keith McGuigan @kamggg kmcguigan at twitter.com From coleen.phillimore at oracle.com Mon Jun 15 17:55:19 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Mon, 15 Jun 2015 13:55:19 -0400 Subject: CFV: New HotSpot Group Lead: Vladimir Kozlov In-Reply-To: References: Message-ID: <557F1187.1060806@oracle.com> Vote: yes On 6/15/15 12:56 PM, Christian Thalinger wrote: > I hereby nominate Vladimir Kozlov to HotSpot Group Lead [1]. > > Vladimir is a member of the HotSpot Group since OpenJDK was > established, is working on the HotSpot JVM for more than 12 years > and is well known in the HotSpot OpenJDK community. > > Votes are due by June 26, 2015 12:00 PST. > > Only current Members of the HotSpot Group [2] are eligible to > vote on this nomination. Votes must be cast in the open by > replying to this mailing list. > > For Simple Majority voting instructions, see [3]. > > Thanks, > Christian Thalinger > > [1]: http://openjdk.java.net/bylaws#group-lead > [2]: http://openjdk.java.net/census#hotspot > [3]: http://openjdk.java.net/groups#lead-vote From igor.veresov at oracle.com Mon Jun 15 17:57:50 2015 From: igor.veresov at oracle.com (Igor Veresov) Date: Mon, 15 Jun 2015 10:57:50 -0700 Subject: CFV: New HotSpot Group Lead: Vladimir Kozlov In-Reply-To: References: Message-ID: <1F4BEC15-7980-48D0-80B6-837E03621092@oracle.com> Vote: yes igor > On Jun 15, 2015, at 9:56 AM, Christian Thalinger wrote: > > I hereby nominate Vladimir Kozlov to HotSpot Group Lead [1]. > > Vladimir is a member of the HotSpot Group since OpenJDK was > established, is working on the HotSpot JVM for more than 12 years > and is well known in the HotSpot OpenJDK community. > > Votes are due by June 26, 2015 12:00 PST. > > Only current Members of the HotSpot Group [2] are eligible to > vote on this nomination. Votes must be cast in the open by > replying to this mailing list. > > For Simple Majority voting instructions, see [3]. > > Thanks, > Christian Thalinger > > [1]: http://openjdk.java.net/bylaws#group-lead > [2]: http://openjdk.java.net/census#hotspot > [3]: http://openjdk.java.net/groups#lead-vote From igor.ignatyev at oracle.com Mon Jun 15 18:01:35 2015 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Mon, 15 Jun 2015 21:01:35 +0300 Subject: CFV: New HotSpot Group Lead: Vladimir Kozlov In-Reply-To: References: Message-ID: <557F12FF.4030304@oracle.com> Vote: yes Igor On 06/15/2015 07:56 PM, Christian Thalinger wrote: > I hereby nominate Vladimir Kozlov to HotSpot Group Lead [1]. > > Vladimir is a member of the HotSpot Group since OpenJDK was > established, is working on the HotSpot JVM for more than 12 years > and is well known in the HotSpot OpenJDK community. > > Votes are due by June 26, 2015 12:00 PST. > > Only current Members of the HotSpot Group [2] are eligible to > vote on this nomination. Votes must be cast in the open by > replying to this mailing list. > > For Simple Majority voting instructions, see [3]. > > Thanks, > Christian Thalinger > > [1]: http://openjdk.java.net/bylaws#group-lead > [2]: http://openjdk.java.net/census#hotspot > [3]: http://openjdk.java.net/groups#lead-vote > From bengt.rutisson at oracle.com Mon Jun 15 19:33:16 2015 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Mon, 15 Jun 2015 21:33:16 +0200 Subject: CFV: New HotSpot Group Lead: Vladimir Kozlov In-Reply-To: References: Message-ID: <557F287C.5000705@oracle.com> Vote: yes Bengt On 15/06/15 18:56, Christian Thalinger wrote: > I hereby nominate Vladimir Kozlov to HotSpot Group Lead [1]. > > Vladimir is a member of the HotSpot Group since OpenJDK was > established, is working on the HotSpot JVM for more than 12 years > and is well known in the HotSpot OpenJDK community. > > Votes are due by June 26, 2015 12:00 PST. > > Only current Members of the HotSpot Group [2] are eligible to > vote on this nomination. Votes must be cast in the open by > replying to this mailing list. > > For Simple Majority voting instructions, see [3]. > > Thanks, > Christian Thalinger > > [1]: http://openjdk.java.net/bylaws#group-lead > [2]: http://openjdk.java.net/census#hotspot > [3]: http://openjdk.java.net/groups#lead-vote From john.r.rose at oracle.com Mon Jun 15 19:54:14 2015 From: john.r.rose at oracle.com (John Rose) Date: Mon, 15 Jun 2015 12:54:14 -0700 Subject: CFV: New HotSpot Group Lead: Vladimir Kozlov In-Reply-To: References: Message-ID: Vote: yes (with pleasure!) On Jun 15, 2015, at 9:56 AM, Christian Thalinger wrote: > > I hereby nominate Vladimir Kozlov to HotSpot Group Lead [1]. From stefan.karlsson at oracle.com Mon Jun 15 20:28:50 2015 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Mon, 15 Jun 2015 22:28:50 +0200 Subject: RFR: 8087322: Implement a Semaphore utility class In-Reply-To: <557AF8E4.9040804@oracle.com> References: <557AF8E4.9040804@oracle.com> Message-ID: <557F3582.6060401@oracle.com> Hi again, I've hopefully addressed some of Kim's and David's concerns with the following version: http://cr.openjdk.java.net/~stefank/8087322/webrev.01.delta/ http://cr.openjdk.java.net/~stefank/8087322/webrev.01/ Changes in the current version of the patch: - Created a POSIX version that is used by Linux and Solaris (and maybe AIX?). - Use asserts instead of guarantees. (I've got offline feedback that others preferred at least some of the guarantees.) - Print the errno value and the errno string in the posix version - Removed trywait and timedwait from the Semaphore class and added that functionality in platform-specific semaphore classes. This gets rid of the Unimplemented() functions in os_windows.cpp. - I removed the IMPLEMENTS_SEMAPHORE_CLASS define. Some comments about the current patch: - I have not removed the 'max' parameter, since I haven't yet figured out what the max value should be used for windows. - OS X doesn't implement unamed POSIX semaphores, so I have to go through hoops to compile out the POXIS version when building on OS X. - I had to add -lrt to get the patch to link on Solaris. Tested with JPRT, Thanks, StefanK On 2015-06-12 17:21, Stefan Karlsson wrote: > Hi all, > > Please review this patch to create a Semaphore utility class. I need > this class to implementing faster GC thread synchronization [1]. > > http://cr.openjdk.java.net/~stefank/8087322/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8087322 > > Some of our platforms already implement a Semaphore class, but those > classes are hidden inside os_.cpp. I've moved the class > declaration to semaphore.hpp, but the implementation is left in the > os_.hpp. I considered creating semaphore_.cpp files, but I > ended up having to restructure too much code and I wanted to focus on > the feature in [1] instead. Should I create a RFE to move the > semaphore implementations? > > There seems to be another opportunity to cleanup the code. If we take > os_linux.cpp, as an example, the code uses both the existing Semaphore > class and the global ::sem_wait and ::sem_post functions. We might > want to consider unifying that code. > > Since HotSpot is built on platforms that I don't have access to and > can't test, I've added the IMPLEMENTS_SEMAPHORE_CLASS define. So, that > I can detect if the the current platform implements the Semaphore > class, and choose what synchronization primitive to use by the GC. > > The os_bsd.cpp file has support for "non-apple BSD", but I've only > tested this patch with OS X. > > This patch has been tested in JPRT and our nightly testing together > with the patches in [1]. The patch also contains a few unit tests in > semaphore.cpp. > > Thanks, > StefanK > > [1] > http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2015-June/013829.html From kim.barrett at oracle.com Mon Jun 15 20:30:34 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 15 Jun 2015 16:30:34 -0400 Subject: Revision3: Corrected: RFR 8059557 (XL): Validate JVM Command-Line Flag Arguments In-Reply-To: <557F0AAC.4080406@oracle.com> References: <557C3EF0.3030107@oracle.com> <0967AA32-430D-430F-98E2-BF70F77287B8@oracle.com> <557F0AAC.4080406@oracle.com> Message-ID: <6349F4EB-A9E2-41F5-85ED-D836FD88F853@oracle.com> On Jun 15, 2015, at 1:26 PM, Gerard Ziemski wrote: > >> Here are a few comments on Revision3. I think all of these can (and >> should) be handled via followup CRs, and that none of these should >> prevent Revision3 from being pushed as is. >> > > I think I should spin up rev 4 - please see the last issue here, which you have raised. Even after reading your discussion below, my preference would be to separate that issue out and deal with it as a followup. The size of this change set is causing me to glaze over and not feel like I?m doing an effective review any more. >> src/share/vm/gc/g1/g1_globals.hpp >> 71 product(double, G1ConcMarkStepDurationMillis, 10.0, \ >> 72 "Target duration of individual concurrent marking steps " \ >> 73 "in milliseconds.") \ >> 74 range(1.0, (double)max_uintx) \ >> >> The new upper bound here seems like a completely random number to me. >> >> > The existing ad-hoc code just checked the min, and left the upper bound unchecked. Since we need an upper bound for range check, I had to provide some reasonable value and (double)max_uintx seemed a better choice than the mathematically correct DBL_MAX, which would require me to add #import My opinion: is just not big enough to be seriously concerned about. Using something that has some meaning and is not a very nearly randomly chosen value is more important. If we really want to avoid , pick a stupidly large but ?meaningful? upper bound like an hour (or 24 hours, or? ) or 10000 seconds or some such. Note that any change from DBL_MAX is at least theoretically a user-impacting change, so ought to go through the process for that. (Maybe that will push you to :-) >> src/share/vm/opto/c2_globals.hpp >> 110 notproduct(intx, IndexSetWatch, 0, \ >> 111 "Trace all operations on this IndexSet (-1 means all, 0 none)") \ >> 112 range(-1, 0) \ >> >> I suspect the upper bound here should be uint_max. >> >> > Fixed, though I believe that the value should be actually max_intx. Right, sorry about the type mismatch. >> src/share/vm/runtime/globals.hpp >> 375 static const char* flag_error_str(Flag::Error error) { >> >> All other functions for the Flag are declared in the .hpp and defined >> in the .cpp file. I don't see any reason for this function to be >> different. > ?flag_error_str? is a static method and I simply followed the pattern set by the other static methods (ie. ?find_flag?, ?fuzzy_match?). find_flag and fuzzy_match are declared in the .hpp and defined in the .cpp. >> src/share/vm/runtime/globals.hpp >> 1563 product(size_t, HeapSizePerGCThread, ScaleForWordSize(64*M), \ >> 1564 "Size of heap (bytes) per GC thread used in calculating the " \ >> 1565 "number of GC threads") \ >> 1566 range((uintx)os::vm_page_size(), max_uintx) \ >> >> Type is size_t, but range values are using uintx. >> >> > The original ad-hoc code used "(uintx)os::vm_page_size()? for the min, but did not check the upper bound, so I provided max_uintx for the max. > > Also, HeapSizePerGCThread is assigned to a local variable of type ?uintx? and there is no such thing as max_size_t (?) The code I?m looking at (hs-rt tip) uses (size_t)os::vm_page_size() for the min. That change was relatively recent: 8074459: Flags handling memory sizes should be of type size_t Maybe an incorrect ?merge? with that change set in your changes? >> src/share/vm/runtime/globals.hpp >> 1846 product(size_t, MarkStackSizeMax, NOT_LP64(4*M) LP64_ONLY(512*M), \ >> 1847 "Maximum size of marking stack") \ >> 1848 range(1, (max_jint - 1)) \ >> >> That's a very odd looking maximum. >> >> >> > It comes from the original ad-hoc code. That doesn?t make it any less odd looking. I think it is worth an RFE to understand that value and add a comment explaining it (or changing it to something less surprising, if that?s warranted). Or at least a comment questioning the value. Not that I think anyone?s going to look at it anytime soon. >> src/share/vm/runtime/commandLineFlagConstraintsGC.cpp >> 100 #define UseConcMarkSweepGCWorkaroundIfNeeded(initial, max) { \ >> 101 if ((initial == 7) && (max == 6)) { \ >> 102 return Flag::SUCCESS; \ >> 103 } \ >> 104 } >> >> The do/while(0) macro idiom is the usual way to encapsulate >> statements. It took me a couple of tries to parse this, where it >> would have been immediately obvious with the do/while(0) idiom. >> >> >> > Can you please provide a concrete example of how I should use "do/while(0)? here? I don't understand how that would help with the readability - we?re talking here about a simple macro that short-circuits a method if the ?if? statement passes. The expansion presently wraps the ?if? statement in an extra level of braces, to avoid leaving a dangling if. That?s good, but I found it non-obvious, perhaps in part due to the formatting. But the ?usual idiom? for that sort of thing is the do/while(0) idiom, e.g #define UseConcMarkSweepGCWorkaroundIfNeeded(initial, max) \ do { \ if (initial == 7) && (max == 6)) { \ return Flag::SUCCESS; \ } \ } while (0) If written that way, it would have been immediately obvious (to me) what was being done, since do/while(0) is a "well-known? and easily recognized pattern chunk. >> src/share/vm/runtime/globals.cpp >> >> In the various apply_constraint_and_check_range_TYPE functions, the >> present pattern seems to be to find and check the range (if it >> exists), then find and apply the constraint (if it exists), and then >> combine the results. >> >> I think it might be better to not apply the constraint if there is a >> range check failure. That way, constraint functions can be written to >> assume that the values have been range checked, and only need to worry >> about whatever additional constraints might exist, without the need to >> potentially deal with out of range values. >> >> Whichever behavior is used should be documented as part of the >> interface to this facility, since it affects how one writes constraint >> functions. It might also, in some cases, affect whether it is useful >> to provide a range spec in conjunction with a constraint function. >> >> Such a change might also eliminate the need for the get_status_error >> helper. >> >> [Obviously this is pretty high priority if handled as a followup >> change, since it has a somewhat significant impact on how one writes >> constraint functions.] >> >> > I added this behavior to address David?s concern from webrev 2, but to be honest I had doubts about it. > > Originally, I had the code checking the ranges first, and only checking the constraints if the range check passed. However, that required me to change "test/runtime/CompressedOops/ObjectAlignment.java? and "/test/runtime/contended/Options.java?, by removing the cases that checked both ranges and constraints, which David pointed out as loosing functionality. The previous ad-hoc code was free to do whatever it wanted and in those 2 cases (ObjectAlignmentInBytes and ContendedPaddingWidth) the test was free to check both the range and constraint at the same time. Sorry, I overlooked or forgot the earlier discussion in this area. > So I tried to do the same in my framework, but that made the code a bit more complex (ie. need for ?get_status_error? helper). > > Most importantly, however, I much prefer the design where the constraint check is only attempted if the range passes (ie. constraint is guaranteed that the value is within the range) > > I will revert the code back to what it was like in webrev 2, and these 2 tests will technically loose some functionality, however, there are specific test cases in each of the tests that do exercise both the constraint and the range, though one at the time. My opinion: If there is some (possible) contention over this area, I think that?s all the more reason at this point to address it separately, as long as we do so soon. Having the whole change lingering for this important but narrow piece seems less than ideal. From jesper.wilhelmsson at oracle.com Mon Jun 15 20:33:25 2015 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Mon, 15 Jun 2015 22:33:25 +0200 Subject: CFV: New HotSpot Group Lead: Vladimir Kozlov In-Reply-To: References: Message-ID: <557F3695.8060309@oracle.com> Vote: yes /Jesper Christian Thalinger skrev den 15/6/15 18:56: > I hereby nominate Vladimir Kozlov to HotSpot Group Lead [1]. > > Vladimir is a member of the HotSpot Group since OpenJDK was > established, is working on the HotSpot JVM for more than 12 years > and is well known in the HotSpot OpenJDK community. > > Votes are due by June 26, 2015 12:00 PST. > > Only current Members of the HotSpot Group [2] are eligible to > vote on this nomination. Votes must be cast in the open by > replying to this mailing list. > > For Simple Majority voting instructions, see [3]. > > Thanks, > Christian Thalinger > > [1]: http://openjdk.java.net/bylaws#group-lead > [2]: http://openjdk.java.net/census#hotspot > [3]: http://openjdk.java.net/groups#lead-vote > From john.r.rose at oracle.com Mon Jun 15 20:47:17 2015 From: john.r.rose at oracle.com (John Rose) Date: Mon, 15 Jun 2015 13:47:17 -0700 Subject: Ping: RFR(M): 8086069: Adapt runtime calls to recent intrinsics to pass ints as long In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CFF9D17@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CFF9D17@DEWDFEMB12A.global.corp.sap> Message-ID: <57EF8CC4-3CB7-488E-89D4-5AE5EA3C99AA@oracle.com> This change surprises me. Sometimes our machine-independent IR needs #ifdefs, Matcher queries, or flag tests to deal with platform stuff we haven't factorized properly. In this case a flag test is "apologizing" for oddly-sized argument registers at the IR level. But TypeFuncs and the rest of the IR do not talk about such details of calling conventions. A C2 type is only about the information content of arguments and return values, not their register bindings. The lower level function SharedRuntime::c_calling_convention determines exact bindings of values to argument and return value registers, using the type VMRegPair. It is likely that there is some awkwardness in assigning a *pair* of regs (representing a single 64-bit register) to carry a 32-bit value, but surely this is less complex, and more to the point, than hacking conversions from 32- to 64-bit values at the IR level. I would expect that, if your approach is to work, there should be an assert in SharedRuntime::c_calling_convention saying that the 32-bit types T_INT, etc., are *never* presented to the SR::ccc/VMRegPair layer of the code. But, as it seems to me, it would be less disruptive to the overall design if SR::ccc can be presented with T_INT types, and be free to return an indication of which 64-bit register will carry that value. The low-level move instructions which push data into those argument registers can be specialized to those target registers (in the AD file) if there is a need for filling up the 32 extra bits (sign or zero). HTH ? John On Jun 15, 2015, at 8:30 AM, Lindenmaier, Goetz wrote: > > Hi, > > Could someone please have a look at this change? > > I had a look whether I can push the functionality down to make_runtime_call(). > This would simplify matters a lot. But as the TypeFunc is hashed, I can not > change it any more in make_runtime_call(). > > @aarch-people: I saw you have CCallingConventionRequiresIntsAsLongs set. > Could you please check whether this breaks your intinsics, e.g., multiplyToLen? > (We assure in sharedRuntime_ppc.cpp, c_calling_convention() that no INT types > end up there.) > > Thanks, > Goetz > > -----Original Message----- > From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Lindenmaier, Goetz > Sent: Dienstag, 9. Juni 2015 17:18 > To: HotSpot Developers > Subject: RFR(M): 8086069: Adapt runtime calls to recent intrinsics to pass ints as long > > Hi, > > we are working on porting the recently* added intrinsics to PPC. As these use > runtime calls, the calls must obey to the platform ABI, which requires that ints > are passed as longs. > > We made a similar change in "8024342: PPC64 (part 111): Support for C calling > conventions that require 64-bit ints." It adapts the calls if > CCallingConventionRequiresIntsAsLongs is set. > > This change adapts the calls to multiplyToLen, CRC32, AES, SHA accordingly. > > Please review this change. I please need a sponsor. > http://cr.openjdk.java.net/~goetz/webrevs/8086069-call_conv/webrev.01/ > > Best regards, > Goetz > > > * i.e., added after making our initial port From rasbold at google.com Mon Jun 15 20:51:29 2015 From: rasbold at google.com (Chuck Rasbold) Date: Mon, 15 Jun 2015 13:51:29 -0700 Subject: CFV: New HotSpot Group Lead: Vladimir Kozlov In-Reply-To: <557F3695.8060309@oracle.com> References: <557F3695.8060309@oracle.com> Message-ID: Vote: yes On Mon, Jun 15, 2015 at 1:33 PM, Jesper Wilhelmsson < jesper.wilhelmsson at oracle.com> wrote: > Vote: yes > /Jesper > > Christian Thalinger skrev den 15/6/15 18:56: > > I hereby nominate Vladimir Kozlov to HotSpot Group Lead [1]. >> >> Vladimir is a member of the HotSpot Group since OpenJDK was >> established, is working on the HotSpot JVM for more than 12 years >> and is well known in the HotSpot OpenJDK community. >> >> Votes are due by June 26, 2015 12:00 PST. >> >> Only current Members of the HotSpot Group [2] are eligible to >> vote on this nomination. Votes must be cast in the open by >> replying to this mailing list. >> >> For Simple Majority voting instructions, see [3]. >> >> Thanks, >> Christian Thalinger >> >> [1]: http://openjdk.java.net/bylaws#group-lead < >> http://openjdk.java.net/bylaws#group-lead> >> [2]: http://openjdk.java.net/census#hotspot < >> http://openjdk.java.net/census#hotspot> >> [3]: http://openjdk.java.net/groups#lead-vote < >> http://openjdk.java.net/groups#lead-vote> >> >> From Peter.B.Kessler at Oracle.COM Mon Jun 15 21:55:03 2015 From: Peter.B.Kessler at Oracle.COM (Peter B. Kessler) Date: Mon, 15 Jun 2015 14:55:03 -0700 Subject: CFV: New HotSpot Group Lead: Vladimir Kozlov In-Reply-To: References: Message-ID: <557F49B7.4050706@Oracle.COM> Vote: yes ... peter On 06/15/15 09:56 AM, Christian Thalinger wrote: > I hereby nominate Vladimir Kozlov to HotSpot Group Lead [1]. > > Vladimir is a member of the HotSpot Group since OpenJDK was > established, is working on the HotSpot JVM for more than 12 years > and is well known in the HotSpot OpenJDK community. > > Votes are due by June 26, 2015 12:00 PST. > > Only current Members of the HotSpot Group [2] are eligible to > vote on this nomination. Votes must be cast in the open by > replying to this mailing list. > > For Simple Majority voting instructions, see [3]. > > Thanks, > Christian Thalinger > > [1]: http://openjdk.java.net/bylaws#group-lead > [2]: http://openjdk.java.net/census#hotspot > [3]: http://openjdk.java.net/groups#lead-vote > From ivan at azulsystems.com Mon Jun 15 22:30:20 2015 From: ivan at azulsystems.com (Ivan Krylov) Date: Tue, 16 Jun 2015 01:30:20 +0300 Subject: CFV: New HotSpot Group Lead: Vladimir Kozlov In-Reply-To: References: Message-ID: <557F51FC.5010000@azulsystems.com> Vote: yes On 15/06/2015 19:56, Christian Thalinger wrote: > I hereby nominate Vladimir Kozlov to HotSpot Group Lead [1]. > > Vladimir is a member of the HotSpot Group since OpenJDK was > established, is working on the HotSpot JVM for more than 12 years > and is well known in the HotSpot OpenJDK community. > > Votes are due by June 26, 2015 12:00 PST. > > Only current Members of the HotSpot Group [2] are eligible to > vote on this nomination. Votes must be cast in the open by > replying to this mailing list. > > For Simple Majority voting instructions, see [3]. > > Thanks, > Christian Thalinger > > [1]: http://openjdk.java.net/bylaws#group-lead > [2]: http://openjdk.java.net/census#hotspot > [3]: http://openjdk.java.net/groups#lead-vote From uschindler at apache.org Mon Jun 15 22:38:09 2015 From: uschindler at apache.org (Uwe Schindler) Date: Tue, 16 Jun 2015 00:38:09 +0200 Subject: CFV: New HotSpot Group Lead: Vladimir Kozlov In-Reply-To: References: Message-ID: <024a01d0a7bb$f66d8540$e3488fc0$@apache.org> [non-eligible] +1 from the other Apache Lucene guy :-) Thanks for the hard work in making Hotspot what it is now! ----- Uwe Schindler uschindler at apache.org ASF Member, Apache Lucene PMC / Committer Bremen, Germany http://lucene.apache.org/ > -----Original Message----- > From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On > Behalf Of Dawid Weiss > Sent: Monday, June 15, 2015 7:02 PM > Cc: hotspot-dev at openjdk.java.net Developers > Subject: Re: CFV: New HotSpot Group Lead: Vladimir Kozlov > > [non-eligible] but sincere +1. > > Dawid > > On Mon, Jun 15, 2015 at 6:56 PM, Christian Thalinger > wrote: > > I hereby nominate Vladimir Kozlov to HotSpot Group Lead [1]. > > > > Vladimir is a member of the HotSpot Group since OpenJDK was > > established, is working on the HotSpot JVM for more than 12 years and > > is well known in the HotSpot OpenJDK community. > > > > Votes are due by June 26, 2015 12:00 PST. > > > > Only current Members of the HotSpot Group [2] are eligible to vote on > > this nomination. Votes must be cast in the open by replying to this > > mailing list. > > > > For Simple Majority voting instructions, see [3]. > > > > Thanks, > > Christian Thalinger > > > > [1]: http://openjdk.java.net/bylaws#group-lead > > > > [2]: http://openjdk.java.net/census#hotspot > > > > [3]: http://openjdk.java.net/groups#lead-vote > From anthony.scarpino at oracle.com Mon Jun 15 23:26:12 2015 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Mon, 15 Jun 2015 16:26:12 -0700 Subject: RFR: 8073108: GHASH Intrinsics [need second reviewer] In-Reply-To: <557B5A47.5090008@oracle.com> References: <54E25D03.7090705@oracle.com> <5579CD0E.2070801@oracle.com> <557B5A47.5090008@oracle.com> Message-ID: <557F5F14.70709@oracle.com> Hi other reviewers, I'm hoping someone else can review this. Tony On 06/12/2015 03:16 PM, Vladimir Kozlov wrote: > This implementation looks good to me. You need second review since > changes are big. > > Thanks, > Vladimir > > On 6/11/15 11:01 AM, Anthony Scarpino wrote: >> Now that JEP 246 is targeted, I can proceed a with the GHASH changes I >> had reviewed back in February. >> >> There are two changes from the previous review. One is the separate >> method for the range checking in jdk:GHASH.java in update(). The other >> is disabling UseGHASHIntrinsics for arch64 in hotspot. >> >> http://cr.openjdk.java.net/~ascarpino/8073108/hotspot/webrev.03/ >> http://cr.openjdk.java.net/~ascarpino/8073108/jdk/webrev.03/ >> >> thanks >> >> Tony >> From dean.long at oracle.com Tue Jun 16 00:07:34 2015 From: dean.long at oracle.com (Dean Long) Date: Mon, 15 Jun 2015 17:07:34 -0700 Subject: Ping: RFR(M): 8086069: Adapt runtime calls to recent intrinsics to pass ints as long In-Reply-To: <57EF8CC4-3CB7-488E-89D4-5AE5EA3C99AA@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CFF9D17@DEWDFEMB12A.global.corp.sap> <57EF8CC4-3CB7-488E-89D4-5AE5EA3C99AA@oracle.com> Message-ID: <557F68C6.4050805@oracle.com> This may be a dumb (but hopefully related) question, but why do we need to add top() for _LP64: 4364 #ifdef _LP64 4365 #define XTOP ,top() /*additional argument*/ 4366 #else //_LP64 4367 #define XTOP /*no additional argument*/ 4368 #endif //_LP64 4396 make_runtime_call(RC_LEAF|RC_NO_FP, 4397 OptoRuntime::fast_arraycopy_Type(), 4398 StubRoutines::unsafe_arraycopy(), 4399 "unsafe_arraycopy", 4400 TypeRawPtr::BOTTOM, 4401 src, dst, size XTOP); And why only for"size", but not "src" and "dst"? dl On 6/15/2015 1:47 PM, John Rose wrote: > This change surprises me. Sometimes our machine-independent IR needs #ifdefs, Matcher queries, or flag tests to deal with platform stuff we haven't factorized properly. In this case a flag test is "apologizing" for oddly-sized argument registers at the IR level. > > But TypeFuncs and the rest of the IR do not talk about such details of calling conventions. A C2 type is only about the information content of arguments and return values, not their register bindings. The lower level function SharedRuntime::c_calling_convention determines exact bindings of values to argument and return value registers, using the type VMRegPair. It is likely that there is some awkwardness in assigning a *pair* of regs (representing a single 64-bit register) to carry a 32-bit value, but surely this is less complex, and more to the point, than hacking conversions from 32- to 64-bit values at the IR level. > > I would expect that, if your approach is to work, there should be an assert in SharedRuntime::c_calling_convention saying that the 32-bit types T_INT, etc., are *never* presented to the SR::ccc/VMRegPair layer of the code. But, as it seems to me, it would be less disruptive to the overall design if SR::ccc can be presented with T_INT types, and be free to return an indication of which 64-bit register will carry that value. The low-level move instructions which push data into those argument registers can be specialized to those target registers (in the AD file) if there is a need for filling up the 32 extra bits (sign or zero). > > HTH > ? John > > On Jun 15, 2015, at 8:30 AM, Lindenmaier, Goetz wrote: >> Hi, >> >> Could someone please have a look at this change? >> >> I had a look whether I can push the functionality down to make_runtime_call(). >> This would simplify matters a lot. But as the TypeFunc is hashed, I can not >> change it any more in make_runtime_call(). >> >> @aarch-people: I saw you have CCallingConventionRequiresIntsAsLongs set. >> Could you please check whether this breaks your intinsics, e.g., multiplyToLen? >> (We assure in sharedRuntime_ppc.cpp, c_calling_convention() that no INT types >> end up there.) >> >> Thanks, >> Goetz >> >> -----Original Message----- >> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Lindenmaier, Goetz >> Sent: Dienstag, 9. Juni 2015 17:18 >> To: HotSpot Developers >> Subject: RFR(M): 8086069: Adapt runtime calls to recent intrinsics to pass ints as long >> >> Hi, >> >> we are working on porting the recently* added intrinsics to PPC. As these use >> runtime calls, the calls must obey to the platform ABI, which requires that ints >> are passed as longs. >> >> We made a similar change in "8024342: PPC64 (part 111): Support for C calling >> conventions that require 64-bit ints." It adapts the calls if >> CCallingConventionRequiresIntsAsLongs is set. >> >> This change adapts the calls to multiplyToLen, CRC32, AES, SHA accordingly. >> >> Please review this change. I please need a sponsor. >> http://cr.openjdk.java.net/~goetz/webrevs/8086069-call_conv/webrev.01/ >> >> Best regards, >> Goetz >> >> >> * i.e., added after making our initial port From ChrisPhi at LGonQn.Org Tue Jun 16 00:18:28 2015 From: ChrisPhi at LGonQn.Org (Chris Phillips @ T O) Date: Mon, 15 Jun 2015 20:18:28 -0400 Subject: CFV: New HotSpot Group Lead: Vladimir Kozlov In-Reply-To: References: Message-ID: <557F6B54.5000908@LGonQn.Org> Vote: yes Of course! ChrisPhi [resend with correct email] On 15/06/15 12:56 PM, Christian Thalinger wrote: > I hereby nominate Vladimir Kozlov to HotSpot Group Lead [1]. > > Vladimir is a member of the HotSpot Group since OpenJDK was > established, is working on the HotSpot JVM for more than 12 years > and is well known in the HotSpot OpenJDK community. > > Votes are due by June 26, 2015 12:00 PST. > > Only current Members of the HotSpot Group [2] are eligible to > vote on this nomination. Votes must be cast in the open by > replying to this mailing list. > > For Simple Majority voting instructions, see [3]. > > Thanks, > Christian Thalinger > > [1]: http://openjdk.java.net/bylaws#group-lead > [2]: http://openjdk.java.net/census#hotspot > [3]: http://openjdk.java.net/groups#lead-vote > > -- -- -- Woda: "Java: write once, debug anywhere" Hong Zhang http://thehenrys.ca | Chris Phillips - Resident cat slave and dubious character | | mailto:NorthernL00n at LGonQn.Org (416)483-3768 | | http://LGonQn.Org/www/Chris.Phillips cell: (416)505-3610 | "EPIC stands for Expects Perfectly Intuitive Compilers" P. Bannon http://www.hazmatmodine.com NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. "blah blah blah - Ginger!" -- From john.r.rose at oracle.com Tue Jun 16 00:20:09 2015 From: john.r.rose at oracle.com (John Rose) Date: Mon, 15 Jun 2015 17:20:09 -0700 Subject: RFR: 8073108: GHASH Intrinsics [need second reviewer] In-Reply-To: <557F5F14.70709@oracle.com> References: <54E25D03.7090705@oracle.com> <5579CD0E.2070801@oracle.com> <557B5A47.5090008@oracle.com> <557F5F14.70709@oracle.com> Message-ID: Thanks for taking this on. It looks good, except for one thing. The intrinsic does not need to be an instance method, and doing so creates an undesirable coupling between the JVM and JDK. Specifically, the JDK should not need to know about subkeyH and state fields. The Java code should pass those as plain (array long[2]) arguments to the intrinsic method processBlocks, which should be adjusted to be static. The domain check routine should be adjusted to be static also. On my wish list for the future (but not now) is even less coupling with the JVM. The loop code for processBlocks should be written in Java, with various intrinsics (xmulx*) for dealing with single operations on 128-bit values (stored in long[2] boxes and 64-bit registers). The Unsafe misaligned access routines could help simplify this also, if the coding were done in Java. This is not too hard to express in Java and compile to excellent code. There will be a little extra awkwardness working with 64x2-vectors in a way that will compile naturally to a range of ALUs (both 64- and 128-bit). If we get it right we can reduce the amount of assembly code in the JVM and get even more timely access to new data-processing instructions. Would you please file a followup bug (low pri. for now) to track this, at least for GHASH and other crypto loops? ? John On Jun 15, 2015, at 4:26 PM, Anthony Scarpino wrote: > > Hi other reviewers, > > I'm hoping someone else can review this. > > Tony > > On 06/12/2015 03:16 PM, Vladimir Kozlov wrote: >> This implementation looks good to me. You need second review since >> changes are big. >> >> Thanks, >> Vladimir >> >> On 6/11/15 11:01 AM, Anthony Scarpino wrote: >>> Now that JEP 246 is targeted, I can proceed a with the GHASH changes I >>> had reviewed back in February. >>> >>> There are two changes from the previous review. One is the separate >>> method for the range checking in jdk:GHASH.java in update(). The other >>> is disabling UseGHASHIntrinsics for arch64 in hotspot. >>> >>> http://cr.openjdk.java.net/~ascarpino/8073108/hotspot/webrev.03/ >>> http://cr.openjdk.java.net/~ascarpino/8073108/jdk/webrev.03/ >>> >>> thanks >>> >>> Tony >>> > From john.r.rose at oracle.com Tue Jun 16 00:26:36 2015 From: john.r.rose at oracle.com (John Rose) Date: Mon, 15 Jun 2015 17:26:36 -0700 Subject: Ping: RFR(M): 8086069: Adapt runtime calls to recent intrinsics to pass ints as long In-Reply-To: <557F68C6.4050805@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CFF9D17@DEWDFEMB12A.global.corp.sap> <57EF8CC4-3CB7-488E-89D4-5AE5EA3C99AA@oracle.com> <557F68C6.4050805@oracle.com> Message-ID: On Jun 15, 2015, at 5:07 PM, Dean Long wrote: > > This may be a dumb (but hopefully related) question, but why do we need to add top() for _LP64: > > 4364 #ifdef _LP64 > 4365 #define XTOP ,top() /*additional argument*/ > 4366 #else //_LP64 > 4367 #define XTOP /*no additional argument*/ > 4368 #endif //_LP64 > > 4396 make_runtime_call(RC_LEAF|RC_NO_FP, > 4397 OptoRuntime::fast_arraycopy_Type(), > 4398 StubRoutines::unsafe_arraycopy(), > 4399 "unsafe_arraycopy", > 4400 TypeRawPtr::BOTTOM, > 4401 src, dst, size XTOP); > > And why only for"size", but not "src" and "dst"? That is one of the awkward places we jam in LP64-specific code. Java has no size_t type; the closest it gets is "long". But the compiler uses Java types to set up runtime stub call signatures. So if we want the compiler to pass a size_t value to a stub, it has to pass a long on !LP64 and int on ILP32. (There's no need for an int-in-a-long here, since size_t is never 32 bits on an int-in-a-long machine.) To complete the embarrassment, the compiler has an internal convention of always representing the twin word for longs and doubles (see JVMS). Net result is that if you want to ask for a size_t in the JIT on LP64, you have to #ifdef in a jlong, and pass a "top" twin word. ? John From dean.long at oracle.com Tue Jun 16 03:57:05 2015 From: dean.long at oracle.com (Dean Long) Date: Mon, 15 Jun 2015 20:57:05 -0700 Subject: Ping: RFR(M): 8086069: Adapt runtime calls to recent intrinsics to pass ints as long In-Reply-To: References: <4295855A5C1DE049A61835A1887419CC2CFF9D17@DEWDFEMB12A.global.corp.sap> <57EF8CC4-3CB7-488E-89D4-5AE5EA3C99AA@oracle.com> <557F68C6.4050805@oracle.com> Message-ID: <557F9E91.7020603@oracle.com> On 6/15/2015 5:26 PM, John Rose wrote: > On Jun 15, 2015, at 5:07 PM, Dean Long > wrote: >> >> This may be a dumb (but hopefully related) question, but why do we >> need to add top() for _LP64: >> >> 4364 #ifdef _LP64 >> 4365 #define XTOP ,top() /*additional argument*/ >> 4366 #else //_LP64 >> 4367 #define XTOP /*no additional argument*/ >> 4368 #endif //_LP64 >> >> 4396 make_runtime_call(RC_LEAF|RC_NO_FP, >> 4397 OptoRuntime::fast_arraycopy_Type(), >> 4398 StubRoutines::unsafe_arraycopy(), >> 4399 "unsafe_arraycopy", >> 4400 TypeRawPtr::BOTTOM, >> 4401 src, dst, size XTOP); >> >> And why only for"size", but not "src" and "dst"? > > That is one of the awkward places we jam in LP64-specific code. > Java has no size_t type; the closest it gets is "long". > But the compiler uses Java types to set up runtime stub call signatures. > So if we want the compiler to pass a size_t value to a stub, it has to > pass a long on !LP64 and int on ILP32. > (There's no need for an int-in-a-long here, since size_t is never 32 > bits on an int-in-a-long machine.) > To complete the embarrassment, the compiler has an internal convention > of always representing the twin word for longs and doubles (see JVMS). > Net result is that if you want to ask for a size_t in the JIT on LP64, > you have to #ifdef in a jlong, and pass a "top" twin word. > ? John Thanks for the explanation. It sounds like we are modeling the abstract Java stack representation of long and double, and this wouldn't be easy to change, because I see things like "TypeFunc::Parms + 1" and "argument(2)" that would need to change before this could go away. dl From john.r.rose at oracle.com Tue Jun 16 04:13:02 2015 From: john.r.rose at oracle.com (John Rose) Date: Mon, 15 Jun 2015 21:13:02 -0700 Subject: Ping: RFR(M): 8086069: Adapt runtime calls to recent intrinsics to pass ints as long In-Reply-To: <557F9E91.7020603@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CFF9D17@DEWDFEMB12A.global.corp.sap> <57EF8CC4-3CB7-488E-89D4-5AE5EA3C99AA@oracle.com> <557F68C6.4050805@oracle.com> <557F9E91.7020603@oracle.com> Message-ID: On Jun 15, 2015, at 8:57 PM, Dean Long wrote: > > Thanks for the explanation. It sounds like we are modeling the abstract Java stack representation of long and double, and this wouldn't be > easy to change, because I see things like "TypeFunc::Parms + 1" and "argument(2)" that would need to change before this could go away. Indeed. Slot pairs are a mess, an optimization (or concession) for platforms that no longer matter. (Primitives might look like that in a few years.) Some messes in HotSpot stem (IMO) from excessive attention to the bytecode syntax, designing a managed execution engine around the oddities of a code format. In an ideal world, I would like to isolate, deprecate, and eventually remove the "evil twin" slots, since they no longer have any meaning (except maybe on some 32-bit systems). Doing it at all levels will be hard, except in the context of some other breaking change. But it could be done locally in the JVM, removing the notion of twin slots from modules that don't have an absolute need to work with them. JITs shouldn't have to know about them, IMO; maybe not even the interpreter (though that would involve a renumbering prepass). When we get value types, we may be able to make such a change, even to the bytecode syntax itself. Or perhaps we will perpetuate the "evil twin" convention, but apply it to all value types (plus long and double). Or perhaps (happy thought) we can make every value/ref/prim occupy one stack slot, in some bytecode of the future. ? John From erik.helin at oracle.com Tue Jun 16 06:13:26 2015 From: erik.helin at oracle.com (Erik Helin) Date: Tue, 16 Jun 2015 08:13:26 +0200 Subject: CFV: New HotSpot Group Lead: Vladimir Kozlov In-Reply-To: References: Message-ID: <20150616061326.GI29290@ehelin.jrpg.bea.com> Vote: yes Thanks, Erik On 2015-06-15, Christian Thalinger wrote: > I hereby nominate Vladimir Kozlov to HotSpot Group Lead [1]. > > Vladimir is a member of the HotSpot Group since OpenJDK was > established, is working on the HotSpot JVM for more than 12 years > and is well known in the HotSpot OpenJDK community. > > Votes are due by June 26, 2015 12:00 PST. > > Only current Members of the HotSpot Group [2] are eligible to > vote on this nomination. Votes must be cast in the open by > replying to this mailing list. > > For Simple Majority voting instructions, see [3]. > > Thanks, > Christian Thalinger > > [1]: http://openjdk.java.net/bylaws#group-lead > [2]: http://openjdk.java.net/census#hotspot > [3]: http://openjdk.java.net/groups#lead-vote From mikael.gerdin at oracle.com Tue Jun 16 07:00:51 2015 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Tue, 16 Jun 2015 09:00:51 +0200 Subject: CFV: New HotSpot Group Lead: Vladimir Kozlov In-Reply-To: References: Message-ID: <557FC9A3.8020106@oracle.com> Vote: yes On 2015-06-15 18:56, Christian Thalinger wrote: > I hereby nominate Vladimir Kozlov to HotSpot Group Lead [1]. > > Vladimir is a member of the HotSpot Group since OpenJDK was > established, is working on the HotSpot JVM for more than 12 years > and is well known in the HotSpot OpenJDK community. > > Votes are due by June 26, 2015 12:00 PST. > > Only current Members of the HotSpot Group [2] are eligible to > vote on this nomination. Votes must be cast in the open by > replying to this mailing list. > > For Simple Majority voting instructions, see [3]. > > Thanks, > Christian Thalinger > > [1]: http://openjdk.java.net/bylaws#group-lead > [2]: http://openjdk.java.net/census#hotspot > [3]: http://openjdk.java.net/groups#lead-vote > From thomas.schatzl at oracle.com Tue Jun 16 07:17:44 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 16 Jun 2015 09:17:44 +0200 Subject: CFV: New HotSpot Group Lead: Vladimir Kozlov In-Reply-To: References: Message-ID: <1434439064.2684.0.camel@oracle.com> Vote: yes On Mon, 2015-06-15 at 09:56 -0700, Christian Thalinger wrote: > I hereby nominate Vladimir Kozlov to HotSpot Group Lead [1]. > > Vladimir is a member of the HotSpot Group since OpenJDK was > established, is working on the HotSpot JVM for more than 12 years > and is well known in the HotSpot OpenJDK community. > > Votes are due by June 26, 2015 12:00 PST. > > Only current Members of the HotSpot Group [2] are eligible to > vote on this nomination. Votes must be cast in the open by > replying to this mailing list. > > For Simple Majority voting instructions, see [3]. > > Thanks, > Christian Thalinger > > [1]: http://openjdk.java.net/bylaws#group-lead > [2]: http://openjdk.java.net/census#hotspot > [3]: http://openjdk.java.net/groups#lead-vote From goetz.lindenmaier at sap.com Tue Jun 16 07:23:01 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 16 Jun 2015 07:23:01 +0000 Subject: Ping: RFR(M): 8086069: Adapt runtime calls to recent intrinsics to pass ints as long In-Reply-To: <57EF8CC4-3CB7-488E-89D4-5AE5EA3C99AA@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CFF9D17@DEWDFEMB12A.global.corp.sap> <57EF8CC4-3CB7-488E-89D4-5AE5EA3C99AA@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2CFF9F65@DEWDFEMB12A.global.corp.sap> Hi John, thanks for looking at this change! The PPC ABI says that int arguments must properly be extended to 64-bit: http://refspecs.linuxfoundation.org/ELF/ppc64/PPC-elf64abi-1.9.html#PARAM-PASS "Simple integer types (char, short, int, long, enum) are mapped to a single doubleword. Values shorter than a doubleword are sign or zero extended as necessary." We achieve this by adding an I2L node for arguments < 64-bit. To assure proper typing of the IR, we have to adapt the function type and parameter list accordingly. Obviously, we have to deal with the fact that longs occupy 2 slots. That's not nice, but currently necessary. The assertion you mention is in sharedRuntime_ppc.cpp:738. The approach works, it's just not implemented for the new intrinsics. Also, I was looking for a generic solution, where I don't have to adapt each runtime call added to the parser. Sure we could issue sign extending instructions along with the call node during emitting to the code buffer. But if we add this early during parsing, the nodes are subject to optimization. Best regards, Goetz. -----Original Message----- From: John Rose [mailto:john.r.rose at oracle.com] Sent: Montag, 15. Juni 2015 22:47 To: Lindenmaier, Goetz Cc: HotSpot Developers; aarch64-port-dev at openjdk.java.net Subject: Re: Ping: RFR(M): 8086069: Adapt runtime calls to recent intrinsics to pass ints as long This change surprises me. Sometimes our machine-independent IR needs #ifdefs, Matcher queries, or flag tests to deal with platform stuff we haven't factorized properly. In this case a flag test is "apologizing" for oddly-sized argument registers at the IR level. But TypeFuncs and the rest of the IR do not talk about such details of calling conventions. A C2 type is only about the information content of arguments and return values, not their register bindings. The lower level function SharedRuntime::c_calling_convention determines exact bindings of values to argument and return value registers, using the type VMRegPair. It is likely that there is some awkwardness in assigning a *pair* of regs (representing a single 64-bit register) to carry a 32-bit value, but surely this is less complex, and more to the point, than hacking conversions from 32- to 64-bit values at the IR level. I would expect that, if your approach is to work, there should be an assert in SharedRuntime::c_calling_convention saying that the 32-bit types T_INT, etc., are *never* presented to the SR::ccc/VMRegPair layer of the code. But, as it seems to me, it would be less disruptive to the overall design if SR::ccc can be presented with T_INT types, and be free to return an indication of which 64-bit register will carry that value. The low-level move instructions which push data into those argument registers can be specialized to those target registers (in the AD file) if there is a need for filling up the 32 extra bits (sign or zero). HTH ? John On Jun 15, 2015, at 8:30 AM, Lindenmaier, Goetz wrote: > > Hi, > > Could someone please have a look at this change? > > I had a look whether I can push the functionality down to make_runtime_call(). > This would simplify matters a lot. But as the TypeFunc is hashed, I can not > change it any more in make_runtime_call(). > > @aarch-people: I saw you have CCallingConventionRequiresIntsAsLongs set. > Could you please check whether this breaks your intinsics, e.g., multiplyToLen? > (We assure in sharedRuntime_ppc.cpp, c_calling_convention() that no INT types > end up there.) > > Thanks, > Goetz > > -----Original Message----- > From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Lindenmaier, Goetz > Sent: Dienstag, 9. Juni 2015 17:18 > To: HotSpot Developers > Subject: RFR(M): 8086069: Adapt runtime calls to recent intrinsics to pass ints as long > > Hi, > > we are working on porting the recently* added intrinsics to PPC. As these use > runtime calls, the calls must obey to the platform ABI, which requires that ints > are passed as longs. > > We made a similar change in "8024342: PPC64 (part 111): Support for C calling > conventions that require 64-bit ints." It adapts the calls if > CCallingConventionRequiresIntsAsLongs is set. > > This change adapts the calls to multiplyToLen, CRC32, AES, SHA accordingly. > > Please review this change. I please need a sponsor. > http://cr.openjdk.java.net/~goetz/webrevs/8086069-call_conv/webrev.01/ > > Best regards, > Goetz > > > * i.e., added after making our initial port From jesper.wilhelmsson at oracle.com Tue Jun 16 11:23:40 2015 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Tue, 16 Jun 2015 13:23:40 +0200 Subject: New bug blocking push to main this week Message-ID: <5580073C.6000902@oracle.com> Hi, Just a heads up, There is a new bug in jdk9/hs-rt that is blocking a potential push to jdk9/hs this week: https://bugs.openjdk.java.net/browse/JDK-8098815 We also have the bug from last week that is still open: https://bugs.openjdk.java.net/browse/JDK-8087153 These two needs to get fixed or backed out before the Wednesday nightly starts tomorrow. Thanks! /Jesper From alexander.kulyakhtin at oracle.com Tue Jun 16 13:12:39 2015 From: alexander.kulyakhtin at oracle.com (Alexander Kulyakhtin) Date: Tue, 16 Jun 2015 06:12:39 -0700 (PDT) Subject: RFR: JDK-8075327: Merge jdk and hotspot test libraries Message-ID: <1e9b38b0-e19d-49c2-861c-06024a25334a@default> Igor, Stuart As Igor has suggested, we have divided the changes into several subtasks. The changes under review are then for the subtask https://bugs.openjdk.java.net/browse/JDK-8098823 "Merge common classes from jdk and hotspot test libraries" These changes merge the common files from the jdk and hotspot test libraries and move them one level up to the top-level 'test' repository. This eliminates the duplicate files between the jdk and the hotspot test libraries. The changes are as follows: 1) Common files (Asserts.java, OutputAnalyzer.java etc) from the jdk and hotspot repositories, have been merged and moved to the upper-level common test repository, to test/lib/share/classes. 2) Package jdk.testlibrary in the jdk repository have been renamed to jdk.test.lib to have the same name as in the hotspot repository 3) Upper level test/lib/share/classes library references have been added to the @library statements 4) Some packages previously located at upper level test repo at /test/lib have been moved to /test/lib/share/classes for consistency http://cr.openjdk.java.net/~akulyakh/8075327/wr_hs/webrev.01/index.html http://cr.openjdk.java.net/~akulyakh/8075327/wr_jdk/webrev.01/index.html http://cr.openjdk.java.net/~akulyakh/8075327/wr_test/webrev.01/index.html The other proposed changes are addressed by different subtasks and will be reviewed later. Stuart, Could you, please, provide your comments on the proposed changes from the jdk repository perspective? Best regards, Alexander ----- Original Message ----- From: igor.ignatyev at oracle.com To: alexander.kulyakhtin at oracle.com, stuart.marks at oracle.com Cc: jdk9-dev at openjdk.java.net, stefan.sarne at oracle.com, yekaterina.kantserova at oracle.com, hotspot-dev at openjdk.java.net, alexandre.iline at oracle.com, aleksey.voytilov at oracle.com Sent: Monday, June 15, 2015 4:34:38 PM GMT +03:00 Iraq Subject: Re: RFR: JDK-8075327: Merge jdk and hotspot test libraries Alexander, > Therefore, I would suggest reviewing the current patch as it is , since the changes are trivial and postpone refactoring to the new packages until some time later, since such refactoring is not trivial and the current patch does provide for the merge. I agree that we should separate merge of test-libraries and refactoring them. however I do have a comment regarding the current patch. besides classes in jdk.test.lib package, hotspot test-library contains other common libraries: * jdk.test.lib.cli -- a test framework for command line option tests * jdk.test.lib.dcmd -- aux classes to simplify work w/ jcmd * jdk.test.lib.dtrace -- a test framework for dtrace tests From my point of view, all these packages can be used in jdk tests as well. so I think these packages should be moved to top-level repository. Another reason why these packages should be neither moved nor renamed (to smth like hotspot.test.lib) is ambiguity. If one see classes from jdk.test.lib package (or its subpackages), he/she will expect to find their source in /test, but in your current version, they are placed in hotspot/test. Even if we ok, we such ambiguity there is a risk that at some point, one will introduce another 'jdk.test.lib.cli' in top-level test directory. It will be really really hard to understand which libraries should be used. That means that all other classes from both jdk/test/lib/testlibrary/jdk/testlibrary/ and /hotspot/test/testlibrary/jdk/test/lib should be moved to /test. PS I also noticed that RandomFactory[1] class kinda duplicates Utils::getRandomInstance[2], could you please merge them or file an RFE to do it? Stuart, could you please review jdk part of this patch? [1] http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/c1947d42537b/test/lib/testlibrary/jdk/testlibrary/RandomFactory.java [2] http://hg.openjdk.java.net/jdk9/jdk9/hotspot/file/c25bfaaed7f2/test/testlibrary/jdk/test/lib/Utils.java#l367 -- Thanks, Igor On 06/04/2015 05:23 PM, Alexander Kulyakhtin wrote: > Stefan, > > There are some issues which may make it difficult to implement the grouping of the common test library files into the new packages as JDK-8075327 proposes. > > The changes in the current patch are trivial and made by a script (although they spread over many files). > They are trivial because the names of the packages are left intact (except fo renaming of jdk.testlibrary to jdk.test.lib in the jdk repo). > > However, if we introduce the new packages per the CR description we will end up with > > import jdk.test.lib.*; > import jdk.test.lib.vm.*; > import jdk.test.lib.processtools.*; > import jdk.test.lib.misc.*; > > where previously was just a single line > > import jdk.test.lib.*; > > The same goes for @build and @run directives where we end up with > > @build jdk.test.lib.* jdk.test.lib.vm.* jdk.test.lib.processtools.* jdk.test.lib.misc.* > > instead of > > @build jdk.test.lib.* > > There are many tests having import jdk.test.lib.* and @build jdk.test.lib.* and similar constructions. > > If we then want to deduce the minimal required dependencies for each and every jdk and hotspot test, then it will not be as trivial task as what we have currently done. It will, probably, require a significant review effort from both jdk and hotspot teams. > The benefits of that effort are not quite evident for me though I, probably, might be missing something here. > > The current patch does already provide for the merge of the common part of the jdk and hotspot libraries and do eliminate the duplicated files. > > Therefore, I would suggest reviewing the current patch as it is , since the changes are trivial and postpone refactoring to the new packages until some time later, since such refactoring is not trivial and the current patch does provide for the merge. > > Best regards, > Alexander > > ----- Original Message ----- > From: alexander.kulyakhtin at oracle.com > To: stefan.sarne at oracle.com > Cc: jdk9-dev at openjdk.java.net, yekaterina.kantserova at oracle.com, hotspot-dev at openjdk.java.net > Sent: Wednesday, June 3, 2015 3:33:22 PM GMT +03:00 Iraq > Subject: Re: RFR: JDK-8075327: Merge jdk and hotspot test libraries > > > > Hi Stefan, > > Thank you very much for the review. I'll update the patch accordingly, shortly. > > Best regards, > Alexander > > ----- Original Message ----- > From: stefan.sarne at oracle.com > To: alexander.kulyakhtin at oracle.com, jdk9-dev at openjdk.java.net, hotspot-dev at openjdk.java.net > Cc: yekaterina.kantserova at oracle.com > Sent: Wednesday, June 3, 2015 12:08:33 PM GMT +03:00 Iraq > Subject: Re: RFR: JDK-8075327: Merge jdk and hotspot test libraries > > > > Hi Alexander, > > I think we want to group the utilities into packages directly. > > One reason for grouping is to support discovery, to clarify what belongs together. For example both the OutputAnalyzer and the StreamPumper belong together in a processtools package, while Asserts doesn't. > > Another reason is to simplify imports and reduce the impact of wild card includes, since for example an import of process tools should not have to bother with declaring usage of sun.misc.Unsafe in the modules world, just because Utils happen to be in the same package. > > Here are some examples - also available in the jira case: > > Package jdk.test.lib.processtools is the package for utilities for launching processes and analyzing the output. > /test/lib/share/classes/jdk/test/lib/processtools/OutputAnalyzer.java > /test/lib/share/classes/jdk/test/lib/processtools/OutputBuffer.java > /test/lib/share/classes/jdk/test/lib/processtools/ProcessTools.java > /test/lib/share/classes/jdk/test/lib/processtools/StreamPumper.java > /test/lib/share/classes/jdk/test/lib/processtools/JDKToolFinder.java > /test/lib/share/classes/jdk/test/lib/processtools/JDKToolLauncher.java > > /test/lib-test/jdk/test/lib/processtools/OutputAnalyzerTest.java > > > Asserts can stay at top level. > /test/lib/share/classes/jdk/test/lib/Asserts.java > /test/lib-test/jdk/test/lib/AssertsTest.java > > > For VM specific info, it would have vm package. Note that the whitebox API moves here. > /test/lib/share/classes/jdk/test/lib/vm/InputArguments.java > /test/lib/share/classes/jdk/test/lib/vm/Platform.java > > > Ok, so then there are the stuff which just is a bucket of stuff and fluff. > A later exercise could be to break this class into better named and placed classes, but this is a start: > /test/lib/share/classes/jdk/test/lib/misc/Utils.java > > Thanks, > Stefan > > > Alexander Kulyakhtin skrev den 2015-06-02 13:18: > > > Hi, > > Could you, please, review the following test-only changes to the 'jdk', 'hotspot' and the common 'test' repository http://cr.openjdk.java.net/~akulyakh/8075327/wr_hs/webrev.01/index.html http://cr.openjdk.java.net/~akulyakh/8075327/wr_jdk/webrev.01/index.html http://cr.openjdk.java.net/~akulyakh/8075327/wr_test/webrev.01/ The changes are to move test library files common to both jdk and hotspot to the upper-level test repository. > > The following has been done: > 1) Common files (Asserts.java, OutputAnalyzer.java etc) from the jdk and hotspot repositories, have been merged and moved to the upper-level common test repository, to test/lib/share/classes. > 2) Package jdk.testlibrary in the jdk repository have been renamed to jdk.test.lib to have the same name as in the hotspot repository > 2) Upper level test/lib/share/classes library references have been added to the @library statements > 3) Some packages previously located at upper level test repo at /test/lib have been moved to /test/lib/share/classes for consistency > > Best regards, > Alexander > From jiangli.zhou at oracle.com Tue Jun 16 13:27:29 2015 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Tue, 16 Jun 2015 06:27:29 -0700 Subject: CFV: New HotSpot Group Lead: Vladimir Kozlov In-Reply-To: References: Message-ID: Vote: yes Jiangli > On Jun 15, 2015, at 9:56 AM, Christian Thalinger wrote: > > I hereby nominate Vladimir Kozlov to HotSpot Group Lead [1]. > > Vladimir is a member of the HotSpot Group since OpenJDK was > established, is working on the HotSpot JVM for more than 12 years > and is well known in the HotSpot OpenJDK community. > > Votes are due by June 26, 2015 12:00 PST. > > Only current Members of the HotSpot Group [2] are eligible to > vote on this nomination. Votes must be cast in the open by > replying to this mailing list. > > For Simple Majority voting instructions, see [3]. > > Thanks, > Christian Thalinger > > [1]: http://openjdk.java.net/bylaws#group-lead > [2]: http://openjdk.java.net/census#hotspot > [3]: http://openjdk.java.net/groups#lead-vote From edward.nevill at gmail.com Fri Jun 12 09:42:45 2015 From: edward.nevill at gmail.com (Edward Nevill) Date: Fri, 12 Jun 2015 10:42:45 +0100 Subject: [aarch64-port-dev ] RFR: 8081790: SHA tests fail In-Reply-To: <557A9F87.3010902@oracle.com> References: <1433321507.32688.13.camel@mylittlepony.linaroharston> <557A9F87.3010902@oracle.com> Message-ID: <1434102165.7052.61.camel@mint> On Fri, 2015-06-12 at 18:59 +1000, David Holmes wrote: > Hi Ed, > > On 12/06/2015 6:49 PM, Edward Nevill wrote: > > Hi, > > > > Sorry to bother. The following was posted for review 9 days ago but there > > has been no response. > > > > This is an aarch64 only change to resolve 7 jtreg/hotspot failures. > > > > Could a JDK9 reviewer please take a look at this, > > The test changes are shared code so this needs someone from the compiler > team to review and sponsor. Yes, thanks for pointing this out. Could someone from the compiler team please review and sponsor, Ed. > > > > On 3 June 2015 at 09:51, Edward Nevill wrote: > > > >> Hi, > >> > >> The following webrev > >> > >> http://cr.openjdk.java.net/~enevill/8081790/webrev.00/ > >> > >> fixes a number of SHA test failures on aarch64. > >> > >> This patch was contributed by alexander.alexeev at caviumnetworks.com > >> > >> Currently the following JTReg/hotspot SHA tests fail on aarch64 > >> > >> FAILED: > >> compiler/intrinsics/sha/cli/TestUseSHA1IntrinsicsOptionOnUnsupportedCPU.java > >> FAILED: > >> compiler/intrinsics/sha/cli/TestUseSHA256IntrinsicsOptionOnUnsupportedCPU.java > >> FAILED: compiler/intrinsics/sha/cli/TestUseSHAOptionOnUnsupportedCPU.java > >> (ie > >> FAILED: compiler/intrinsics/sha/sanity/TestSHA1Intrinsics.java > >> FAILED: compiler/intrinsics/sha/sanity/TestSHA1MultiBlockIntrinsics.java > >> FAILED: compiler/intrinsics/sha/sanity/TestSHA256MultiBlockIntrinsics.java > >> FAILED: compiler/intrinsics/sha/sanity/TestSHA256Intrinsics.java > >> > >> The reason for the test failures is that the test suite is configured on > >> the assumption that Sparc is the only arch which support SHA in hw (and > >> therefore supports the -XX:+UseSHA options). > >> > >> The webrev adds tests for aarch64. > >> > >> The following files have also been renamed as they were inappropriately > >> named. > >> > >> R > >> test/compiler/intrinsics/sha/cli/testcases/GenericTestCaseForSupportedSparcCPU.java > >> R > >> test/compiler/intrinsics/sha/cli/testcases/UseSHAIntrinsicsSpecificTestCaseForUnsupportedSparcCPU.java > >> R > >> test/compiler/intrinsics/sha/cli/testcases/UseSHASpecificTestCaseForSupportedSparcCPU.java > >> R > >> test/compiler/intrinsics/sha/cli/testcases/UseSHASpecificTestCaseForUnsupportedSparcCPU.java > >> > >> These now become > >> > >> A > >> test/compiler/intrinsics/sha/cli/testcases/GenericTestCaseForSupportedCPU.java > >> A > >> test/compiler/intrinsics/sha/cli/testcases/UseSHAIntrinsicsSpecificTestCaseForUnsupportedCPU.java > >> A > >> test/compiler/intrinsics/sha/cli/testcases/UseSHASpecificTestCaseForSupportedCPU.java > >> A > >> test/compiler/intrinsics/sha/cli/testcases/UseSHASpecificTestCaseForUnsupportedCPU.java > >> > >> (ie. the 'Sparc' has been dropped from the filename as Sparc is no longer > >> the only arch which supports SHA). > >> > >> Tested with JTReg/hotspot > >> > >> Before: Test results: passed: 840; failed: 10; error: 5 > >> After: Test results: passed: 847; failed: 3; error: 5 > >> > >> Please review, > >> > >> Thanks, > >> Ed. > >> > >> > >> From dmitry.dmitriev at oracle.com Tue Jun 16 13:59:39 2015 From: dmitry.dmitriev at oracle.com (Dmitry Dmitriev) Date: Tue, 16 Jun 2015 16:59:39 +0300 Subject: Revision3: Corrected: RFR 8059557 (XL): Validate JVM Command-Line Flag Arguments In-Reply-To: <557C3EF0.3030107@oracle.com> References: <557C3EF0.3030107@oracle.com> Message-ID: <55802BCB.5060502@oracle.com> Hi Gerard, I noticed 2 typos for new int and uint types in src/share/vm/runtime/commandLineFlagRangeList.cpp: 45 Flag::Error check_int(int value, bool verbose = true) { 46 if ((value < _min) || (value > _max)) { 47 if (verbose == true) { 48 jio_fprintf(defaultStream::error_stream(), 49 "int %s=%d is outside the allowed range [ %d ... D ]\n", 50 name(), value, _min, _max); 51 } On line 49 at the end - "%d" must be instead of "D". 101 Flag::Error check_uint(uint value, bool verbose = true) { 102 if ((value < _min) || (value > _max)) { 103 if (verbose == true) { 104 jio_fprintf(defaultStream::error_stream(), 105 "uintx %s=%u is outside the allowed range [ %u ... %u ]\n", 106 name(), value, _min, _max); 107 } On line 105 - "uint" should be instead of "uintx" before "%s=%u". Thanks, Dmitry On 13.06.2015 17:32, Gerard Ziemski wrote: > hi all, > > Thank you for the reviews so far! > > Here is a revision 3 of the feature taking into account feedback from Kim Barrett, David Holmes, Derek White and Bengt Rutisson. I have also merged the changes to the latest jdk9. > > We introduce a new mechanism that allows specification of a valid range per flag that is then used to automatically validate given flag's value every time it changes. Ranges values must be constant and can not change. Optionally, a constraint can also be specified and applied every time a flag value changes for those flags whose valid value can not be trivially checked by a simple min and max (ex. whether it's power of 2, or bigger or smaller than some other flag that can also change) > > I have chosen to modify the table macros (ex. RUNTIME_FLAGS in globals.hpp) instead of using a more sophisticated solution, such as C++ templates, because even though macros were unfriendly when initially developing, once a solution was arrived at, subsequent additions to the tables of new ranges, or constraint are trivial from developer's point of view. (The intial development unfriendliness of macros was mitigated by using a pre-processor, which for those using a modern IDE like Xcode, is easily available from a menu). Using macros also allowed for more minimal code changes. > > The presented solution is based on expansion of macros using variadic functions and can be readily seen in runtime/commandLineFlagConstraintList.cpp and runtime/commandLineFlagRangeList.cpp > > In commandLineFlagConstraintList.cpp or commandLineFlagRangesList.cpp, there is bunch of classes and methods that seems to beg for C++ template to be used. I have tried, but when the compiler tries to generate code for both uintx and size_t, which happen to have the same underlying type (on BSD), it fails to compile overridden methods with same type, but different name. If someone has a way of simplifying the new code via C++ templates, however, we can file a new enhancement request to address that. > > This webrev represents only the initial range checking framework and only 100 or so flags that were ported from an existing ad hoc range checking code to this new mechanism. There are about 250 remaining flags that still need their ranges determined and ported over to this new mechanism and they are tracked by individual subtasks. > > I had to modify several existing tests to change the error message that they expected when VM refuses to run, which was changed to provide uniform error messages. > > To help with testing and subtask efforts I have introduced a new runtime flag: > > PrintFlagsRanges: "Print VM flags and their ranges and exit VM" > > which in addition to the already existing flags: "PrintFlagsInitial" and "PrintFlagsFinal" allow for thorough examination of the flags values and their ranges. > > The code change builds and passes JPRT (-testset hotspot) and UTE (vm.quick.testlist) > > > References: > > Webrev:http://cr.openjdk.java.net/~gziemski/8059557_rev3 > JEP:https://bugs.openjdk.java.net/browse/JDK-8059557 > Compiler subtask:https://bugs.openjdk.java.net/browse/JDK-8078554 > GC subtask:https://bugs.openjdk.java.net/browse/JDK-8078555 > Runtime subtask:https://bugs.openjdk.java.net/browse/JDK-8078556 > > Note: due to "awk" limit of 50 pats the Frames diff is not available for "src/share/vm/runtime/arguments.cpp? and "src/share/vm/runtime/globals.cpp? > > > Followup issues: > > JDK-8085866: There are 99 uses of FLAG_SET_ERGO, should they check the return value? > JDK-8085864: FLAG_SET_CMDLINE in TestGenCollectorPolicy() currently ignore the return values > JDK-8081842: Find a better place for EMIT_{CONSTRAINTS,RANGES}_FOR_GLOBALS_EXT > JDK-8081833: There is a large amount of code near-duplication among the various CommandLineFlagRange_ classes > JDK-8081519: Split globals.hpp to factor out the Flag values needed by JDK-8059557 > > > hgstat: > > src/cpu/ppc/vm/globals_ppc.hpp | 2 +- > src/cpu/sparc/vm/globals_sparc.hpp | 2 +- > src/cpu/x86/vm/globals_x86.hpp | 2 +- > src/cpu/zero/vm/globals_zero.hpp | 3 +- > src/os/aix/vm/globals_aix.hpp | 2 +- > src/os/bsd/vm/globals_bsd.hpp | 29 +- > src/os/linux/vm/globals_linux.hpp | 9 +- > src/os/solaris/vm/globals_solaris.hpp | 4 +- > src/os/windows/vm/globals_windows.hpp | 5 +- > src/share/vm/c1/c1_globals.cpp | 4 +- > src/share/vm/c1/c1_globals.hpp | 17 +- > src/share/vm/gc/g1/g1_globals.cpp | 14 +- > src/share/vm/gc/g1/g1_globals.hpp | 38 +- > src/share/vm/opto/c2_globals.cpp | 12 +- > src/share/vm/opto/c2_globals.hpp | 40 +- > src/share/vm/prims/whitebox.cpp | 12 +- > src/share/vm/runtime/arguments.cpp | 765 ++++++---------- > src/share/vm/runtime/arguments.hpp | 24 +- > src/share/vm/runtime/commandLineFlagConstraintList.cpp | 286 ++++++ > src/share/vm/runtime/commandLineFlagConstraintList.hpp | 80 + > src/share/vm/runtime/commandLineFlagConstraintsCompiler.cpp | 44 + > src/share/vm/runtime/commandLineFlagConstraintsCompiler.hpp | 39 + > src/share/vm/runtime/commandLineFlagConstraintsGC.cpp | 235 +++++ > src/share/vm/runtime/commandLineFlagConstraintsGC.hpp | 58 + > src/share/vm/runtime/commandLineFlagConstraintsRuntime.cpp | 65 + > src/share/vm/runtime/commandLineFlagConstraintsRuntime.hpp | 41 + > src/share/vm/runtime/commandLineFlagRangeList.cpp | 367 ++++++++ > src/share/vm/runtime/commandLineFlagRangeList.hpp | 71 + > src/share/vm/runtime/globals.cpp | 721 ++++++++++++--- > src/share/vm/runtime/globals.hpp | 343 ++++++- > src/share/vm/runtime/globals_extension.hpp | 105 +- > src/share/vm/runtime/init.cpp | 5 +- > src/share/vm/runtime/os_ext.hpp | 7 +- > src/share/vm/runtime/thread.cpp | 6 + > src/share/vm/services/attachListener.cpp | 4 +- > src/share/vm/services/classLoadingService.cpp | 12 +- > src/share/vm/services/diagnosticCommand.cpp | 3 +- > src/share/vm/services/management.cpp | 6 +- > src/share/vm/services/memoryService.cpp | 4 +- > src/share/vm/services/writeableFlags.cpp | 183 ++- > src/share/vm/services/writeableFlags.hpp | 60 +- > test/compiler/c2/7200264/Test7200264.sh | 5 +- > test/compiler/startup/NumCompilerThreadsCheck.java | 2 +- > test/gc/arguments/TestHeapFreeRatio.java | 23 +- > test/gc/arguments/TestSurvivorAlignmentInBytesOption.java | 6 +- > test/gc/g1/TestStringDeduplicationTools.java | 6 +- > test/runtime/CompressedOops/CompressedClassSpaceSize.java | 4 +- > test/runtime/CompressedOops/ObjectAlignment.java | 9 +- > test/runtime/contended/Options.java | 10 +- > 49 files changed, 2851 insertions(+), 943 deletions(-) > From aph at redhat.com Tue Jun 16 14:38:24 2015 From: aph at redhat.com (Andrew Haley) Date: Tue, 16 Jun 2015 15:38:24 +0100 Subject: RFR: 8079315: UseCondCardMark broken in conjunction with CMS precleaning In-Reply-To: <557D3D59.4000806@redhat.com> References: <5548D913.1030507@redhat.com> <554A1CA0.6070801@oracle.com> <473C887F-8CC5-4E67-BD9A-1882660CFD3C@lnu.se> <554B3B5E.8000705@oracle.com> <8EE73C49-83CD-4162-A3EF-19DDA2C2CDFA@lnu.se> <554FC66F.20307@oracle.com> <55507BE4.3050605@redhat.com> <03C141D8-952E-4E7A-BDAD-024CE2239010@lnu.se> <55508B60.1000200@redhat.com> <8868A273-7C97-45F0-BF10-85DDE5859E85@lnu.se> <5550B182.7090009@redhat.com> <5551FA97.9090502@oracle.com> <5551FD72.1020504@oracle.com> <38CAAA0B-6F32-4508-818F-AD9D248E8B35@lnu.se> <55524C58.4030904@oracle.com> <55524E8C.6080709@redhat.com> <55526041.1030709@redhat.com> <7C4CBC57-D7B2-4779-9353-DEACCB626370@lnu.se> <5552838B.3020305@oracle.com> <556D5EF9.6030702@redhat.com> <556D7692.3070707@oracle.com> <557D3D59.4000806@redhat.com> Message-ID: <558034E0.6060600@redhat.com> On 06/14/2015 09:37 AM, Andrew Haley wrote: > On 14/06/15 01:25, Erik ?sterlund wrote: > >> Short story: >> I talked to Dave Dice about my ADS implementation(s). He agrees my ADS is >> ?probably safe?, but explained that just fencing is probably preferred >> over ADS for the future anyway due to current hardware trends of >> optimizing fences. > ... >> Therefore, let?s go for fences! :) > > Great, thanks very much for your work one this. OK, so, will someone please review my patch or suggest an alternative? http://cr.openjdk.java.net/~aph/8079315/ Thanks, Andrew. From erik.osterlund at lnu.se Tue Jun 16 15:24:45 2015 From: erik.osterlund at lnu.se (=?Windows-1252?Q?Erik_=D6sterlund?=) Date: Tue, 16 Jun 2015 15:24:45 +0000 Subject: RFR: 8079315: UseCondCardMark broken in conjunction with CMS precleaning In-Reply-To: <558034E0.6060600@redhat.com> References: <5548D913.1030507@redhat.com> <554A1CA0.6070801@oracle.com> <473C887F-8CC5-4E67-BD9A-1882660CFD3C@lnu.se> <554B3B5E.8000705@oracle.com> <8EE73C49-83CD-4162-A3EF-19DDA2C2CDFA@lnu.se> <554FC66F.20307@oracle.com> <55507BE4.3050605@redhat.com> <03C141D8-952E-4E7A-BDAD-024CE2239010@lnu.se> <55508B60.1000200@redhat.com> <8868A273-7C97-45F0-BF10-85DDE5859E85@lnu.se> <5550B182.7090009@redhat.com> <5551FA97.9090502@oracle.com> <5551FD72.1020504@oracle.com> <38CAAA0B-6F32-4508-818F-AD9D248E8B35@lnu.se> <55524C58.4030904@oracle.com> <55524E8C.6080709@redhat.com> <55526041.1030709@redhat.com> <7C4CBC57-D7B2-4779-9353-DEACCB626370@lnu.se> <5552838B.3020305@oracle.com> <556D5EF9.6030702@redhat.com> <556D7692.3070707@oracle.com> <557D3D59.4000806@redhat.com> <558034E0.6060600@redhat.com> Message-ID: Hi Andrew, I?m just an author, so my opinion probably doesn?t matter. However, it would be nice if you in graphKit.cpp could join the two if statements: L3806: if (UseConcMarkSweepGC && UseCondCardMark) { ?membar stuff? } L3811: if (UseCondCardMark) { ?stuff? } ?so that the code gets more readable and is consistent with how it was done in the other 2 files. Also, I?m curious if you ran any benchmarks to see what happens to performance? Otherwise it looks good to me! Thanks, /Erik Den 16/06/15 07:38 skrev Andrew Haley : >On 06/14/2015 09:37 AM, Andrew Haley wrote: >> On 14/06/15 01:25, Erik ?sterlund wrote: >> >>> Short story: >>> I talked to Dave Dice about my ADS implementation(s). He agrees my ADS >>>is >>> ?probably safe?, but explained that just fencing is probably preferred >>> over ADS for the future anyway due to current hardware trends of >>> optimizing fences. >> ... >>> Therefore, let?s go for fences! :) >> >> Great, thanks very much for your work one this. > >OK, so, will someone please review my patch or suggest an alternative? > >http://cr.openjdk.java.net/~aph/8079315/ > >Thanks, >Andrew. > > From dmitrij.pochepko at oracle.com Tue Jun 16 14:30:12 2015 From: dmitrij.pochepko at oracle.com (Dmitrij Pochepko) Date: Tue, 16 Jun 2015 17:30:12 +0300 Subject: RFR (XXS): 8098834 - Update jprt.properties with property listing tests subtrees Message-ID: <558032F4.4010202@oracle.com> Hi, Please review this small fix. A new property for jprt, listing directories used for regression tests bug: https://bugs.openjdk.java.net/browse/JDK-8098834 webrev: http://cr.openjdk.java.net/~dpochepk/8098834/webrev.01/ Thanks, Dmitrij From dmitry.dmitriev at oracle.com Tue Jun 16 15:58:36 2015 From: dmitry.dmitriev at oracle.com (Dmitry Dmitriev) Date: Tue, 16 Jun 2015 18:58:36 +0300 Subject: RFR 8059557: Test set for "Validate JVM Command-Line Flag Arguments" In-Reply-To: <556F0559.3080601@oracle.com> References: <555A09B8.7010402@oracle.com> <555E46A7.4020402@oracle.com> <55671906.10000@oracle.com> <556D3597.8090508@oracle.com> <556F0559.3080601@oracle.com> Message-ID: <558047AC.6040705@oracle.com> Hello, Here a updated version of test set for Command Line Option Validation. The main changes are: added new options types - int and uint, added @modules, test all options with range in TestOptionsWithRanges.java test. Tested: JPRT Webrev: http://cr.openjdk.java.net/~ddmitriev/8059557/webrev.05/ Webrev incremental(from 04): http://cr.openjdk.java.net/~ddmitriev/8059557/webrev.05.incremental/ JEP: https://bugs.openjdk.java.net/browse/JDK-8059557 Thanks, Dmitry On 03.06.2015 16:47, Dmitry Dmitriev wrote: > Hello David, > > Thank you for pointing on style/grammar mistakes! I corrected all of > them. > Here a link to the updated > webrev:http://cr.openjdk.java.net/~ddmitriev/8059557/webrev.04/ > > > About "options validation" package - I agree that this looks odd, but > if you don't mind I prefer to leave it. It slightly simplify calling > static methods by using static import and also I use package-private > access level. > > Regards, > Dmitry > > On 02.06.2015 7:48, David Holmes wrote: >> Hi Dmitry, >> >> On 28/05/2015 11:32 PM, Dmitry Dmitriev wrote: >>> Hello all, >>> >>> Here is a 3 version of the tests taking into account feedback from >>> Christian, David and Gerard. >>> >>> I limit number of options in TestOptionsWithRanges.java to 15. This >>> include options of different types(intx, uintx etc.) and with different >>> combination of min/max range. TestOptionsWithRangesDynamic.java leaved >>> as is, because amount of manageable numeric options is very small and >>> currently only 3 of them have range. Also, I improve code for double >>> option. >>> >>> Webrev: http://cr.openjdk.java.net/~ddmitriev/8059557/webrev.03/ >>> >> >> Only a few style/grammar nits (the downside of writing so many doc >> comments :) ). >> >> Meta-question: is there a specific reason to use the package "options >> validation"? It looks odd to me to have >> OptionsValidation/common/optionsvalidation/ in the paths. >> >> General doc-comment comments: >> - @param/@return descriptions should start with lower-case (you >> currently mix-n-match) >> - @throws description should start with "if", so: >> @throws IOException if an error occurred reading the data >> >> >> General Java-style comments: >> - access modifiers (public, private, protected) always come first >> >> --- >> >> test/runtime/CommandLine/OptionsValidation/common/optionsvalidation/IntJVMOption.java >> >> >> 265 * passed value is negative then error will be >> catched earlier for >> >> catched -> caught >> >> --- >> >> test/runtime/CommandLine/OptionsValidation/common/optionsvalidation/JVMOption.java >> >> >> 327 * @param param Tested parameter passed to the java >> >> "the java" is not a noun - suggest "the JVM" ? >> >> Maybe change Java to JVM to avoid use of "java" as a noun everywhere. >> >> 350 failedMessage(name, fullOptionString, valid, "JVM >> output reports about fatal error. JVM exit with code " + returnCode + >> "!"); >> >> The message isn't grammatically correct: about -> a; exit -> exited >> >> Similarly "JVM exit" -> "JVM exited" >> >> 377 failedMessage(name, fullOptionString, valid, >> "JVM output not contains " >> >> not contains -> does not contain >> >> 400 * Return list of strings which contain options with valid >> values which used >> >> which used -> which can be used >> >> 416 * Return list of strings which contain options with invalid >> values which >> 417 * used for testing on command line >> >> Ditto >> >> --- >> >> test/runtime/CommandLine/OptionsValidation/common/optionsvalidation/JVMOptionsUtils.java >> >> >> 101 * Add dependency for option depending on it's type. E.g. ran >> java in >> >> ran java -> run the JVM >> >> 119 * @param withRanges true if needed options with defined ranges >> >> I'm not sure what this means. Occurs elswhere too. >> >> 121 * "product", "diagnostic" etc. Accept option only if >> acceptOrigin return >> >> return -> returns (or even return -> evaluates). Occurs elsewhere too. >> >> 260 * methods. Tested only writeable options. >> >> Suggestion: Only tests writeable options. Occurs elsewhere too. >> >> 264 * @throws Exception >> >> When? Why? Occurs elsewhere too. >> >> Thanks, >> David >> ----- >> >>> Thanks, >>> Dmitry >>> >>> >>> On 21.05.2015 23:57, Dmitry Dmitriev wrote: >>>> Hello all, >>>> >>>> Recently I correct several typos, so here a new webrev for tests: >>>> http://cr.openjdk.java.net/~ddmitriev/8059557/webrev.02/ >>>> >>>> >>>> Thanks, >>>> Dmitry >>>> >>>> On 18.05.2015 18:48, Dmitry Dmitriev wrote: >>>>> Hello all, >>>>> >>>>> Please review test set for verifying functionality implemented by JEP >>>>> 245 "Validate JVM Command-Line Flag Arguments"(JDK-8059557). Review >>>>> request for this JEP can be found there: >>>>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-May/018539.html >>>>> >>>>> >>>>> I create 3 tests for verifying options with ranges. The tests mostly >>>>> rely on common/optionsvalidation/JVMOptionsUtils.java. Class in this >>>>> file contains functions to get options with ranges as list(by parsing >>>>> new option "-XX:+PrintFlagsRanges" output), run command line test for >>>>> list of options and other. The actual test code contained in >>>>> common/optionsvalidation/JVMOption.java file - testCommandLine(), >>>>> testDynamic(), testJcmd() and testAttach() methods. >>>>> common/optionsvalidation/IntJVMOption.java and >>>>> common/optionsvalidation/DoubleJVMOption.java source files contain >>>>> classes derived from JVMOption class for integer and double JVM >>>>> options correspondingly. >>>>> >>>>> Here are description of the tests: >>>>> 1) >>>>> hotspot/test/runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java >>>>> >>>>> >>>>> >>>>> This test get all options with ranges by parsing output of new option >>>>> "-XX:+PrintFlagsRanges" and verify these options by starting Java and >>>>> passing options in command line with valid and invalid values. >>>>> Currently it verifies about 106 options which have ranges. >>>>> Invalid values are values which out-of-range. In test used values >>>>> "min-1" and "max+1".In this case Java should always exit with code 1 >>>>> and print error message about out-of-range value(with one exception, >>>>> if option is unsigned and passing negative value, then out-of-range >>>>> error message is not printed because error occurred earlier). >>>>> Valid values are values in range, e.g. min&max and also several >>>>> additional values. In this case Java should successfully exit(exit >>>>> code 0) or exit with error code 1 for other reasons(low memory with >>>>> certain option value etc.). In any case for values in range Java >>>>> should not print messages about out of range value. >>>>> In any case Java should not crash. >>>>> This test excluded from JPRT because it takes long time to execute >>>>> and also fails - some options with value in valid range cause Java to >>>>> crash(bugs are submitted). >>>>> >>>>> 2) >>>>> hotspot/test/runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java >>>>> >>>>> >>>>> >>>>> This test get all writeable options with ranges by parsing output of >>>>> new option "-XX:+PrintFlagsRanges" and verify these options by >>>>> dynamically changing it's values to the valid and invalid values. >>>>> Used 3 methods for that: DynamicVMOption isValidValue and >>>>> isInvalidValue methods, Jcmd and by attach method. Currently 3 >>>>> writeable options with ranges are verified by this test. >>>>> This test pass in JPRT. >>>>> >>>>> 3) >>>>> hotspot/test/runtime/CommandLine/OptionsValidation/TestJcmdOutput.java >>>>> >>>>> >>>>> This test verified output of Jcmd when out-of-range value is set to >>>>> the writeable option or value violates option constraint. Also this >>>>> test verify that jcmd not write error message to the target process. >>>>> This test pass in JPRT. >>>>> >>>>> >>>>> I am not write special tests for constraints for this JEP because >>>>> there are exist test for that(e.g. >>>>> test/runtime/CompressedOops/ObjectAlignment.java for >>>>> ObjectAlignmentInBytes or >>>>> hotspot/test/gc/arguments/TestHeapFreeRatio.java for >>>>> MinHeapFreeRatio/MaxHeapFreeRatio). >>>>> >>>>> Webrev: http://cr.openjdk.java.net/~ddmitriev/8059557/webrev.00/ >>>>> >>>>> >>>>> JEP: https://bugs.openjdk.java.net/browse/JDK-8059557 >>>>> >>>>> Thanks, >>>>> Dmitry >>>>> >>>> >>> > From jon.masamitsu at oracle.com Tue Jun 16 16:28:07 2015 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Tue, 16 Jun 2015 09:28:07 -0700 Subject: CFV: New HotSpot Group Lead: Vladimir Kozlov In-Reply-To: References: Message-ID: <55804E97.5020701@oracle.com> Vote: yes On 06/15/2015 09:56 AM, Christian Thalinger wrote: > I hereby nominate Vladimir Kozlov to HotSpot Group Lead [1]. > > Vladimir is a member of the HotSpot Group since OpenJDK was > established, is working on the HotSpot JVM for more than 12 years > and is well known in the HotSpot OpenJDK community. > > Votes are due by June 26, 2015 12:00 PST. > > Only current Members of the HotSpot Group [2] are eligible to > vote on this nomination. Votes must be cast in the open by > replying to this mailing list. > > For Simple Majority voting instructions, see [3]. > > Thanks, > Christian Thalinger > > [1]: http://openjdk.java.net/bylaws#group-lead > [2]: http://openjdk.java.net/census#hotspot > [3]: http://openjdk.java.net/groups#lead-vote From christian.tornqvist at oracle.com Tue Jun 16 19:29:53 2015 From: christian.tornqvist at oracle.com (Christian Tornqvist) Date: Tue, 16 Jun 2015 15:29:53 -0400 Subject: RFR 8059557: Test set for "Validate JVM Command-Line Flag Arguments" In-Reply-To: <558047AC.6040705@oracle.com> References: <555A09B8.7010402@oracle.com> <555E46A7.4020402@oracle.com> <55671906.10000@oracle.com> <556D3597.8090508@oracle.com> <556F0559.3080601@oracle.com> <558047AC.6040705@oracle.com> Message-ID: <02b201d0a86a$d22898a0$7679c9e0$@oracle.com> Hi Dmitry, As mentioned in our private IM discussion, I?m concerned about the passing in external options (using ProcessTools.createJavaProcessBuilder(true,?)). The potential for test issues when passing in external args to this test is quite high, and the cost of running these command line tests with ?Xcomp is very high and makes little sense. Otherwise I think this looks good J Thanks, Christian From: Dmitry Dmitriev [mailto:dmitry.dmitriev at oracle.com] Sent: Tuesday, June 16, 2015 11:59 AM To: hotspot-dev at openjdk.java.net Cc: David Holmes ; Gerard Ziemski ; Christian Tornqvist Subject: Re: RFR 8059557: Test set for "Validate JVM Command-Line Flag Arguments" Hello, Here a updated version of test set for Command Line Option Validation. The main changes are: added new options types - int and uint, added @modules, test all options with range in TestOptionsWithRanges.java test. Tested: JPRT Webrev: http://cr.openjdk.java.net/~ddmitriev/8059557/webrev.05/ Webrev incremental(from 04): http://cr.openjdk.java.net/~ddmitriev/8059557/webrev.05.incremental/ JEP: https://bugs.openjdk.java.net/browse/JDK-8059557 Thanks, Dmitry On 03.06.2015 16:47, Dmitry Dmitriev wrote: Hello David, Thank you for pointing on style/grammar mistakes! I corrected all of them. Here a link to the updated webrev: http://cr.openjdk.java.net/~ddmitriev/8059557/webrev.04/ About "options validation" package - I agree that this looks odd, but if you don't mind I prefer to leave it. It slightly simplify calling static methods by using static import and also I use package-private access level. Regards, Dmitry On 02.06.2015 7:48, David Holmes wrote: Hi Dmitry, On 28/05/2015 11:32 PM, Dmitry Dmitriev wrote: Hello all, Here is a 3 version of the tests taking into account feedback from Christian, David and Gerard. I limit number of options in TestOptionsWithRanges.java to 15. This include options of different types(intx, uintx etc.) and with different combination of min/max range. TestOptionsWithRangesDynamic.java leaved as is, because amount of manageable numeric options is very small and currently only 3 of them have range. Also, I improve code for double option. Webrev: http://cr.openjdk.java.net/~ddmitriev/8059557/webrev.03/ Only a few style/grammar nits (the downside of writing so many doc comments :) ). Meta-question: is there a specific reason to use the package "options validation"? It looks odd to me to have OptionsValidation/common/optionsvalidation/ in the paths. General doc-comment comments: - @param/@return descriptions should start with lower-case (you currently mix-n-match) - @throws description should start with "if", so: @throws IOException if an error occurred reading the data General Java-style comments: - access modifiers (public, private, protected) always come first --- test/runtime/CommandLine/OptionsValidation/common/optionsvalidation/IntJVMOption.java 265 * passed value is negative then error will be catched earlier for catched -> caught --- test/runtime/CommandLine/OptionsValidation/common/optionsvalidation/JVMOption.java 327 * @param param Tested parameter passed to the java "the java" is not a noun - suggest "the JVM" ? Maybe change Java to JVM to avoid use of "java" as a noun everywhere. 350 failedMessage(name, fullOptionString, valid, "JVM output reports about fatal error. JVM exit with code " + returnCode + "!"); The message isn't grammatically correct: about -> a; exit -> exited Similarly "JVM exit" -> "JVM exited" 377 failedMessage(name, fullOptionString, valid, "JVM output not contains " not contains -> does not contain 400 * Return list of strings which contain options with valid values which used which used -> which can be used 416 * Return list of strings which contain options with invalid values which 417 * used for testing on command line Ditto --- test/runtime/CommandLine/OptionsValidation/common/optionsvalidation/JVMOptionsUtils.java 101 * Add dependency for option depending on it's type. E.g. ran java in ran java -> run the JVM 119 * @param withRanges true if needed options with defined ranges I'm not sure what this means. Occurs elswhere too. 121 * "product", "diagnostic" etc. Accept option only if acceptOrigin return return -> returns (or even return -> evaluates). Occurs elsewhere too. 260 * methods. Tested only writeable options. Suggestion: Only tests writeable options. Occurs elsewhere too. 264 * @throws Exception When? Why? Occurs elsewhere too. Thanks, David ----- Thanks, Dmitry On 21.05.2015 23:57, Dmitry Dmitriev wrote: Hello all, Recently I correct several typos, so here a new webrev for tests: http://cr.openjdk.java.net/~ddmitriev/8059557/webrev.02/ Thanks, Dmitry On 18.05.2015 18:48, Dmitry Dmitriev wrote: Hello all, Please review test set for verifying functionality implemented by JEP 245 "Validate JVM Command-Line Flag Arguments"(JDK-8059557). Review request for this JEP can be found there: http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-May/018539.html I create 3 tests for verifying options with ranges. The tests mostly rely on common/optionsvalidation/JVMOptionsUtils.java. Class in this file contains functions to get options with ranges as list(by parsing new option "-XX:+PrintFlagsRanges" output), run command line test for list of options and other. The actual test code contained in common/optionsvalidation/JVMOption.java file - testCommandLine(), testDynamic(), testJcmd() and testAttach() methods. common/optionsvalidation/IntJVMOption.java and common/optionsvalidation/DoubleJVMOption.java source files contain classes derived from JVMOption class for integer and double JVM options correspondingly. Here are description of the tests: 1) hotspot/test/runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java This test get all options with ranges by parsing output of new option "-XX:+PrintFlagsRanges" and verify these options by starting Java and passing options in command line with valid and invalid values. Currently it verifies about 106 options which have ranges. Invalid values are values which out-of-range. In test used values "min-1" and "max+1".In this case Java should always exit with code 1 and print error message about out-of-range value(with one exception, if option is unsigned and passing negative value, then out-of-range error message is not printed because error occurred earlier). Valid values are values in range, e.g. min&max and also several additional values. In this case Java should successfully exit(exit code 0) or exit with error code 1 for other reasons(low memory with certain option value etc.). In any case for values in range Java should not print messages about out of range value. In any case Java should not crash. This test excluded from JPRT because it takes long time to execute and also fails - some options with value in valid range cause Java to crash(bugs are submitted). 2) hotspot/test/runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java This test get all writeable options with ranges by parsing output of new option "-XX:+PrintFlagsRanges" and verify these options by dynamically changing it's values to the valid and invalid values. Used 3 methods for that: DynamicVMOption isValidValue and isInvalidValue methods, Jcmd and by attach method. Currently 3 writeable options with ranges are verified by this test. This test pass in JPRT. 3) hotspot/test/runtime/CommandLine/OptionsValidation/TestJcmdOutput.java This test verified output of Jcmd when out-of-range value is set to the writeable option or value violates option constraint. Also this test verify that jcmd not write error message to the target process. This test pass in JPRT. I am not write special tests for constraints for this JEP because there are exist test for that(e.g. test/runtime/CompressedOops/ObjectAlignment.java for ObjectAlignmentInBytes or hotspot/test/gc/arguments/TestHeapFreeRatio.java for MinHeapFreeRatio/MaxHeapFreeRatio). Webrev: http://cr.openjdk.java.net/~ddmitriev/8059557/webrev.00/ JEP: https://bugs.openjdk.java.net/browse/JDK-8059557 Thanks, Dmitry From dmitry.dmitriev at oracle.com Tue Jun 16 20:29:48 2015 From: dmitry.dmitriev at oracle.com (Dmitry Dmitriev) Date: Tue, 16 Jun 2015 23:29:48 +0300 Subject: RFR 8059557: Test set for "Validate JVM Command-Line Flag Arguments" In-Reply-To: <02b201d0a86a$d22898a0$7679c9e0$@oracle.com> References: <555A09B8.7010402@oracle.com> <555E46A7.4020402@oracle.com> <55671906.10000@oracle.com> <556D3597.8090508@oracle.com> <556F0559.3080601@oracle.com> <558047AC.6040705@oracle.com> <02b201d0a86a$d22898a0$7679c9e0$@oracle.com> Message-ID: <5580873C.6050302@oracle.com> Hi Christian, Thank you for review. Yes, I agree with your concern. I run tests with "-Xcomp" and it takes a lot of time. I rewrite the logic and remove passing in external options. Also in this case I add special case for client mode, i.e. if test ran in client mode, then also verify options with client mode. Webrev: http://cr.openjdk.java.net/~ddmitriev/8059557/webrev.06/ Webrev incremental(from 04): http://cr.openjdk.java.net/~ddmitriev/8059557/webrev.06.incremental/ Thanks, Dmitry On 16.06.2015 22:29, Christian Tornqvist wrote: > > Hi Dmitry, > > As mentioned in our private IM discussion, I?m concerned about the > passing in external options (using > ProcessTools.createJavaProcessBuilder(true,?)). The potential for test > issues when passing in external args to this test is quite high, and > the cost of running these command line tests with ?Xcomp is very high > and makes little sense. > > Otherwise I think this looks good J > > Thanks, > > Christian > > *From:*Dmitry Dmitriev [mailto:dmitry.dmitriev at oracle.com] > *Sent:* Tuesday, June 16, 2015 11:59 AM > *To:* hotspot-dev at openjdk.java.net > *Cc:* David Holmes ; Gerard Ziemski > ; Christian Tornqvist > > *Subject:* Re: RFR 8059557: Test set for "Validate JVM Command-Line > Flag Arguments" > > Hello, > > Here a updated version of test set for Command Line Option Validation. > The main changes are: added new options types - int and uint, added > @modules, test all options with range in TestOptionsWithRanges.java test. > > Tested: JPRT > > Webrev: http://cr.openjdk.java.net/~ddmitriev/8059557/webrev.05/ > > Webrev incremental(from 04): > http://cr.openjdk.java.net/~ddmitriev/8059557/webrev.05.incremental/ > > JEP: https://bugs.openjdk.java.net/browse/JDK-8059557 > > Thanks, > Dmitry > > On 03.06.2015 16:47, Dmitry Dmitriev wrote: > > Hello David, > > Thank you for pointing on style/grammar mistakes! I corrected all > of them. > Here a link to the updated > webrev:http://cr.openjdk.java.net/~ddmitriev/8059557/webrev.04/ > > > About "options validation" package - I agree that this looks odd, > but if you don't mind I prefer to leave it. It slightly simplify > calling static methods by using static import and also I use > package-private access level. > > Regards, > Dmitry > > On 02.06.2015 7:48, David Holmes wrote: > > Hi Dmitry, > > On 28/05/2015 11:32 PM, Dmitry Dmitriev wrote: > > Hello all, > > Here is a 3 version of the tests taking into account > feedback from > Christian, David and Gerard. > > I limit number of options in TestOptionsWithRanges.java to > 15. This > include options of different types(intx, uintx etc.) and > with different > combination of min/max range. > TestOptionsWithRangesDynamic.java leaved > as is, because amount of manageable numeric options is > very small and > currently only 3 of them have range. Also, I improve code > for double > option. > > Webrev: > http://cr.openjdk.java.net/~ddmitriev/8059557/webrev.03/ > > > > > > Only a few style/grammar nits (the downside of writing so many > doc comments :) ). > > Meta-question: is there a specific reason to use the package > "options validation"? It looks odd to me to have > OptionsValidation/common/optionsvalidation/ in the paths. > > General doc-comment comments: > - @param/@return descriptions should start with lower-case > (you currently mix-n-match) > - @throws description should start with "if", so: > @throws IOException if an error occurred reading the data > > > General Java-style comments: > - access modifiers (public, private, protected) always come first > > --- > > test/runtime/CommandLine/OptionsValidation/common/optionsvalidation/IntJVMOption.java > > > 265 * passed value is negative then error > will be catched earlier for > > catched -> caught > > --- > > test/runtime/CommandLine/OptionsValidation/common/optionsvalidation/JVMOption.java > > > 327 * @param param Tested parameter passed to the java > > "the java" is not a noun - suggest "the JVM" ? > > Maybe change Java to JVM to avoid use of "java" as a noun > everywhere. > > 350 failedMessage(name, fullOptionString, valid, > "JVM output reports about fatal error. JVM exit with code " + > returnCode + "!"); > > The message isn't grammatically correct: about -> a; exit -> > exited > > Similarly "JVM exit" -> "JVM exited" > > 377 failedMessage(name, fullOptionString, > valid, "JVM output not contains " > > not contains -> does not contain > > 400 * Return list of strings which contain options with > valid values which used > > which used -> which can be used > > 416 * Return list of strings which contain options with > invalid values which > 417 * used for testing on command line > > Ditto > > --- > > test/runtime/CommandLine/OptionsValidation/common/optionsvalidation/JVMOptionsUtils.java > > > 101 * Add dependency for option depending on it's type. > E.g. ran java in > > ran java -> run the JVM > > 119 * @param withRanges true if needed options with > defined ranges > > I'm not sure what this means. Occurs elswhere too. > > 121 * "product", "diagnostic" etc. Accept option only if > acceptOrigin return > > return -> returns (or even return -> evaluates). Occurs > elsewhere too. > > 260 * methods. Tested only writeable options. > > Suggestion: Only tests writeable options. Occurs elsewhere too. > > 264 * @throws Exception > > When? Why? Occurs elsewhere too. > > Thanks, > David > ----- > > > Thanks, > Dmitry > > > On 21.05.2015 23:57, Dmitry Dmitriev wrote: > > Hello all, > > Recently I correct several typos, so here a new webrev > for tests: > http://cr.openjdk.java.net/~ddmitriev/8059557/webrev.02/ > > > > > > > Thanks, > Dmitry > > On 18.05.2015 18:48, Dmitry Dmitriev wrote: > > Hello all, > > Please review test set for verifying functionality > implemented by JEP > 245 "Validate JVM Command-Line Flag > Arguments"(JDK-8059557). Review > request for this JEP can be found there: > http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-May/018539.html > > > I create 3 tests for verifying options with > ranges. The tests mostly > rely on > common/optionsvalidation/JVMOptionsUtils.java. > Class in this > file contains functions to get options with ranges > as list(by parsing > new option "-XX:+PrintFlagsRanges" output), run > command line test for > list of options and other. The actual test code > contained in > common/optionsvalidation/JVMOption.java file - > testCommandLine(), > testDynamic(), testJcmd() and testAttach() methods. > common/optionsvalidation/IntJVMOption.java and > common/optionsvalidation/DoubleJVMOption.java > source files contain > classes derived from JVMOption class for integer > and double JVM > options correspondingly. > > Here are description of the tests: > 1) > hotspot/test/runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java > > > > This test get all options with ranges by parsing > output of new option > "-XX:+PrintFlagsRanges" and verify these options > by starting Java and > passing options in command line with valid and > invalid values. > Currently it verifies about 106 options which have > ranges. > Invalid values are values which out-of-range. In > test used values > "min-1" and "max+1".In this case Java should > always exit with code 1 > and print error message about out-of-range > value(with one exception, > if option is unsigned and passing negative value, > then out-of-range > error message is not printed because error > occurred earlier). > Valid values are values in range, e.g. min&max and > also several > additional values. In this case Java should > successfully exit(exit > code 0) or exit with error code 1 for other > reasons(low memory with > certain option value etc.). In any case for values > in range Java > should not print messages about out of range value. > In any case Java should not crash. > This test excluded from JPRT because it takes long > time to execute > and also fails - some options with value in valid > range cause Java to > crash(bugs are submitted). > > 2) > hotspot/test/runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java > > > > This test get all writeable options with ranges by > parsing output of > new option "-XX:+PrintFlagsRanges" and verify > these options by > dynamically changing it's values to the valid and > invalid values. > Used 3 methods for that: DynamicVMOption > isValidValue and > isInvalidValue methods, Jcmd and by attach method. > Currently 3 > writeable options with ranges are verified by this > test. > This test pass in JPRT. > > 3) > hotspot/test/runtime/CommandLine/OptionsValidation/TestJcmdOutput.java > > > This test verified output of Jcmd when > out-of-range value is set to > the writeable option or value violates option > constraint. Also this > test verify that jcmd not write error message to > the target process. > This test pass in JPRT. > > > I am not write special tests for constraints for > this JEP because > there are exist test for that(e.g. > test/runtime/CompressedOops/ObjectAlignment.java for > ObjectAlignmentInBytes or > hotspot/test/gc/arguments/TestHeapFreeRatio.java for > MinHeapFreeRatio/MaxHeapFreeRatio). > > Webrev: > http://cr.openjdk.java.net/~ddmitriev/8059557/webrev.00/ > > > > > > > JEP: https://bugs.openjdk.java.net/browse/JDK-8059557 > > Thanks, > Dmitry > From gerard.ziemski at oracle.com Tue Jun 16 21:11:16 2015 From: gerard.ziemski at oracle.com (Gerard Ziemski) Date: Tue, 16 Jun 2015 16:11:16 -0500 Subject: Revision3: Corrected: RFR 8059557 (XL): Validate JVM Command-Line Flag Arguments In-Reply-To: <557E38F9.9010105@oracle.com> References: <557C3EF0.3030107@oracle.com> <557E38F9.9010105@oracle.com> Message-ID: <558090F4.6000105@oracle.com> Coleen, Dmitry, David, Kim, Derek and Bengt, I have create an incremental webrev as requested: http://cr.openjdk.java.net/~gziemski/8059557_rev2_to_rev3 As per suggestion from Kim and Coleen, I will not be spinning webrev4 unless there is a blocker in the code that we haven't found yet. The plan right now is to check in rev3 and have https://bugs.openjdk.java.net/browse/JDK-8112746 track any follow up issues, which I already populated with comments from Coleen, Dmitry and Kim. Can I have a final sign off on this webrev rev3 from all of you please? cheers On 6/14/2015 9:31 PM, David Holmes wrote: > Hi Gerard, > > Any chance you could produce and incremental webrev please? > > Thanks, > David > > On 14/06/2015 12:32 AM, Gerard Ziemski wrote: >> hi all, >> >> Thank you for the reviews so far! >> >> Here is a revision 3 of the feature taking into account feedback from >> Kim Barrett, David Holmes, Derek White and Bengt Rutisson. I have >> also merged the changes to the latest jdk9. >> >> We introduce a new mechanism that allows specification of a valid >> range per flag that is then used to automatically validate given >> flag's value every time it changes. Ranges values must be constant >> and can not change. Optionally, a constraint can also be specified >> and applied every time a flag value changes for those flags whose >> valid value can not be trivially checked by a simple min and max (ex. >> whether it's power of 2, or bigger or smaller than some other flag >> that can also change) >> >> I have chosen to modify the table macros (ex. RUNTIME_FLAGS in >> globals.hpp) instead of using a more sophisticated solution, such as >> C++ templates, because even though macros were unfriendly when >> initially developing, once a solution was arrived at, subsequent >> additions to the tables of new ranges, or constraint are trivial from >> developer's point of view. (The intial development unfriendliness of >> macros was mitigated by using a pre-processor, which for those using >> a modern IDE like Xcode, is easily available from a menu). Using >> macros also allowed for more minimal code changes. >> >> The presented solution is based on expansion of macros using variadic >> functions and can be readily seen in >> runtime/commandLineFlagConstraintList.cpp and >> runtime/commandLineFlagRangeList.cpp >> >> In commandLineFlagConstraintList.cpp or >> commandLineFlagRangesList.cpp, there is bunch of classes and methods >> that seems to beg for C++ template to be used. I have tried, but when >> the compiler tries to generate code for both uintx and size_t, which >> happen to have the same underlying type (on BSD), it fails to compile >> overridden methods with same type, but different name. If someone has >> a way of simplifying the new code via C++ templates, however, we can >> file a new enhancement request to address that. >> >> This webrev represents only the initial range checking framework and >> only 100 or so flags that were ported from an existing ad hoc range >> checking code to this new mechanism. There are about 250 remaining >> flags that still need their ranges determined and ported over to this >> new mechanism and they are tracked by individual subtasks. >> >> I had to modify several existing tests to change the error message >> that they expected when VM refuses to run, which was changed to >> provide uniform error messages. >> >> To help with testing and subtask efforts I have introduced a new >> runtime flag: >> >> PrintFlagsRanges: "Print VM flags and their ranges and exit VM" >> >> which in addition to the already existing flags: "PrintFlagsInitial" >> and "PrintFlagsFinal" allow for thorough examination of the flags >> values and their ranges. >> >> The code change builds and passes JPRT (-testset hotspot) and UTE >> (vm.quick.testlist) >> >> >> References: >> >> Webrev:http://cr.openjdk.java.net/~gziemski/8059557_rev3 >> JEP:https://bugs.openjdk.java.net/browse/JDK-8059557 >> Compiler subtask:https://bugs.openjdk.java.net/browse/JDK-8078554 >> GC subtask:https://bugs.openjdk.java.net/browse/JDK-8078555 >> Runtime subtask:https://bugs.openjdk.java.net/browse/JDK-8078556 >> >> Note: due to "awk" limit of 50 pats the Frames diff is not available >> for "src/share/vm/runtime/arguments.cpp? and >> "src/share/vm/runtime/globals.cpp? >> >> >> Followup issues: >> >> JDK-8085866: There are 99 uses of FLAG_SET_ERGO, should they check >> the return value? >> JDK-8085864: FLAG_SET_CMDLINE in TestGenCollectorPolicy() currently >> ignore the return values >> JDK-8081842: Find a better place for >> EMIT_{CONSTRAINTS,RANGES}_FOR_GLOBALS_EXT >> JDK-8081833: There is a large amount of code near-duplication among >> the various CommandLineFlagRange_ classes >> JDK-8081519: Split globals.hpp to factor out the Flag values needed >> by JDK-8059557 >> >> >> hgstat: >> >> src/cpu/ppc/vm/globals_ppc.hpp | 2 +- >> src/cpu/sparc/vm/globals_sparc.hpp | 2 +- >> src/cpu/x86/vm/globals_x86.hpp | 2 +- >> src/cpu/zero/vm/globals_zero.hpp | 3 +- >> src/os/aix/vm/globals_aix.hpp | 2 +- >> src/os/bsd/vm/globals_bsd.hpp | 29 +- >> src/os/linux/vm/globals_linux.hpp | 9 +- >> src/os/solaris/vm/globals_solaris.hpp | 4 +- >> src/os/windows/vm/globals_windows.hpp | 5 +- >> src/share/vm/c1/c1_globals.cpp | 4 +- >> src/share/vm/c1/c1_globals.hpp | 17 +- >> src/share/vm/gc/g1/g1_globals.cpp | 14 +- >> src/share/vm/gc/g1/g1_globals.hpp | 38 +- >> src/share/vm/opto/c2_globals.cpp | 12 +- >> src/share/vm/opto/c2_globals.hpp | 40 +- >> src/share/vm/prims/whitebox.cpp | 12 +- >> src/share/vm/runtime/arguments.cpp | 765 >> ++++++---------- >> src/share/vm/runtime/arguments.hpp | 24 +- >> src/share/vm/runtime/commandLineFlagConstraintList.cpp | 286 >> ++++++ >> src/share/vm/runtime/commandLineFlagConstraintList.hpp | 80 + >> src/share/vm/runtime/commandLineFlagConstraintsCompiler.cpp | 44 + >> src/share/vm/runtime/commandLineFlagConstraintsCompiler.hpp | 39 + >> src/share/vm/runtime/commandLineFlagConstraintsGC.cpp | 235 >> +++++ >> src/share/vm/runtime/commandLineFlagConstraintsGC.hpp | 58 + >> src/share/vm/runtime/commandLineFlagConstraintsRuntime.cpp | 65 + >> src/share/vm/runtime/commandLineFlagConstraintsRuntime.hpp | 41 + >> src/share/vm/runtime/commandLineFlagRangeList.cpp | 367 >> ++++++++ >> src/share/vm/runtime/commandLineFlagRangeList.hpp | 71 + >> src/share/vm/runtime/globals.cpp | 721 >> ++++++++++++--- >> src/share/vm/runtime/globals.hpp | 343 >> ++++++- >> src/share/vm/runtime/globals_extension.hpp | 105 +- >> src/share/vm/runtime/init.cpp | 5 +- >> src/share/vm/runtime/os_ext.hpp | 7 +- >> src/share/vm/runtime/thread.cpp | 6 + >> src/share/vm/services/attachListener.cpp | 4 +- >> src/share/vm/services/classLoadingService.cpp | 12 +- >> src/share/vm/services/diagnosticCommand.cpp | 3 +- >> src/share/vm/services/management.cpp | 6 +- >> src/share/vm/services/memoryService.cpp | 4 +- >> src/share/vm/services/writeableFlags.cpp | 183 ++- >> src/share/vm/services/writeableFlags.hpp | 60 +- >> test/compiler/c2/7200264/Test7200264.sh | 5 +- >> test/compiler/startup/NumCompilerThreadsCheck.java | 2 +- >> test/gc/arguments/TestHeapFreeRatio.java | 23 +- >> test/gc/arguments/TestSurvivorAlignmentInBytesOption.java | 6 +- >> test/gc/g1/TestStringDeduplicationTools.java | 6 +- >> test/runtime/CompressedOops/CompressedClassSpaceSize.java | 4 +- >> test/runtime/CompressedOops/ObjectAlignment.java | 9 +- >> test/runtime/contended/Options.java | 10 +- >> 49 files changed, 2851 insertions(+), 943 deletions(-) >> > From ysr1729 at gmail.com Tue Jun 16 21:21:48 2015 From: ysr1729 at gmail.com (Srinivas Ramakrishna) Date: Tue, 16 Jun 2015 14:21:48 -0700 Subject: CFV: New HotSpot Group Lead: Vladimir Kozlov In-Reply-To: References: Message-ID: Vote: yes -- ramki (OpenJDK: ysr) On Mon, Jun 15, 2015 at 9:56 AM, Christian Thalinger < christian.thalinger at oracle.com> wrote: > I hereby nominate Vladimir Kozlov to HotSpot Group Lead [1]. > > Vladimir is a member of the HotSpot Group since OpenJDK was > established, is working on the HotSpot JVM for more than 12 years > and is well known in the HotSpot OpenJDK community. > > Votes are due by June 26, 2015 12:00 PST. > > Only current Members of the HotSpot Group [2] are eligible to > vote on this nomination. Votes must be cast in the open by > replying to this mailing list. > > For Simple Majority voting instructions, see [3]. > > Thanks, > Christian Thalinger > > [1]: http://openjdk.java.net/bylaws#group-lead < > http://openjdk.java.net/bylaws#group-lead> > [2]: http://openjdk.java.net/census#hotspot < > http://openjdk.java.net/census#hotspot> > [3]: http://openjdk.java.net/groups#lead-vote < > http://openjdk.java.net/groups#lead-vote> From kim.barrett at oracle.com Tue Jun 16 22:36:06 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 16 Jun 2015 18:36:06 -0400 Subject: Revision3: Corrected: RFR 8059557 (XL): Validate JVM Command-Line Flag Arguments In-Reply-To: <558090F4.6000105@oracle.com> References: <557C3EF0.3030107@oracle.com> <557E38F9.9010105@oracle.com> <558090F4.6000105@oracle.com> Message-ID: <1E910F21-187D-452E-B021-8ADE2573A4B6@oracle.com> On Jun 16, 2015, at 5:11 PM, Gerard Ziemski wrote: > > Coleen, Dmitry, David, Kim, Derek and Bengt, > > I have create an incremental webrev as requested: http://cr.openjdk.java.net/~gziemski/8059557_rev2_to_rev3 > > As per suggestion from Kim and Coleen, I will not be spinning webrev4 unless there is a blocker in the code that we haven't found yet. > > The plan right now is to check in rev3 and have https://bugs.openjdk.java.net/browse/JDK-8112746 track any follow up issues, which I already populated with comments from Coleen, Dmitry and Kim. > > Can I have a final sign off on this webrev rev3 from all of you please? A few more minor comments to add to the collection of followups, but no showstoppers. Looks good to me. ------------------------------------------------------------------------------ src/share/vm/runtime/commandLineFlagConstraintList.cpp 41 // the "name" argument must be a string literal [and others like it.] That isn't strictly true. The real constraint is that the lifetime of the string must be at least as long as the lifetime of the constraint object, since the string is being captured without copying it. A string literal is in practice the usual way that gets satisfied; we don't have any directly constructed constraint objects that I know of, or function calls for the names of the any options in the macros. ------------------------------------------------------------------------------ src/share/vm/runtime/commandLineFlagRangeList.hpp 47 ~CommandLineFlagRange() {} Destructor should be virtual, to prevent accidental slicing. Similarly for ~CommandLineFlagConstraint. [I think in current practice this doesn't matter, as the objects are constructed, added to the associated list, and never deleted.] ------------------------------------------------------------------------------ From alejandro.murillo at oracle.com Tue Jun 16 22:55:15 2015 From: alejandro.murillo at oracle.com (Alejandro E Murillo) Date: Tue, 16 Jun 2015 16:55:15 -0600 Subject: [verona.stage] RFR 8087203: Add support for PATCH field and remove unused fields of new version string Message-ID: <5580A953.8090905@oracle.com> Please review these changes: Bug: https://bugs.openjdk.java.net/browse/JDK-8087202 Webrev: http://cr.openjdk.java.net/~amurillo/9/8087202 These are intended to: (1) Add support for the patch field of the new version string format (2) Remove unused fields remaining from the old version string format (3) Patch some jaxp initialization code to be able to handle the new version string. this will be pushed under a different bug number, but is required to be able to run and pass all the tests associated with "-testset hotspot" (for JFR tests the VM can't be started without that). These will be pushed under this sub-task: https://bugs.openjdk.java.net/browse/JDK-8098588 (4) Additional notes: (a) Some pieces of code, only necessary for 1.5 or older, were removed (b) update_version and special_update_version were removed (c) The code to parse the version string in jdk/test/sun/misc/Version/Version.java will probably change when the Version.java class is available. (d) As with the changes for 8085822, this is all being pushed to [1] and then later to jdk9/dev (e) These changes should address most, if not all, of the issues raised during the code review for JDK-8085822 (see also https://bugs.openjdk.java.net/browse/JDK-8087203) (f) All builds and tests pass for "-testset hotspot". [1] http://hg.openjdk.java.net/verona/stage Thanks -- Alejandro From david.holmes at oracle.com Tue Jun 16 23:45:04 2015 From: david.holmes at oracle.com (David Holmes) Date: Wed, 17 Jun 2015 09:45:04 +1000 Subject: CFV: New HotSpot Group Lead: Vladimir Kozlov In-Reply-To: References: Message-ID: <5580B500.1050700@oracle.com> Vote: yes David On 16/06/2015 2:56 AM, Christian Thalinger wrote: > I hereby nominate Vladimir Kozlov to HotSpot Group Lead [1]. > > Vladimir is a member of the HotSpot Group since OpenJDK was > established, is working on the HotSpot JVM for more than 12 years > and is well known in the HotSpot OpenJDK community. > > Votes are due by June 26, 2015 12:00 PST. > > Only current Members of the HotSpot Group [2] are eligible to > vote on this nomination. Votes must be cast in the open by > replying to this mailing list. > > For Simple Majority voting instructions, see [3]. > > Thanks, > Christian Thalinger > > [1]: http://openjdk.java.net/bylaws#group-lead > [2]: http://openjdk.java.net/census#hotspot > [3]: http://openjdk.java.net/groups#lead-vote > From david.holmes at oracle.com Wed Jun 17 01:42:44 2015 From: david.holmes at oracle.com (David Holmes) Date: Wed, 17 Jun 2015 11:42:44 +1000 Subject: RFR [S] 8081406: cleanup and minor extensions of the debugging facilities in CodeStrings In-Reply-To: <55674A24.4050501@oracle.com> References: <55674A24.4050501@oracle.com> Message-ID: <5580D094.8060803@oracle.com> Hi Bertrand, On 29/05/2015 3:02 AM, Bertrand Delsart wrote: > Hi all, > > Small RFR to address minor issues in debug mode with CodeStrings Not something I'm familiar with so I may be missing some things here. > https://bugs.openjdk.java.net/browse/JDK-8081406 > http://cr.openjdk.java.net/~bdelsart/8081406/webrev.00/ > > The change does not impact the product mode. So the initialization of CodeBlob::_strings and CodeBuffer::_code_strings does happen in product mode as well, but the resulting CodeStrings object does nothing. Suggests to me that *_strings should be a non-product field only (but that's an aside to this set of changes). src/share/vm/asm/codeBuffer.hpp The ifdef style in this file is quite awful IMO but the changes are consistent with it. 308 // FREE strings; invalidate if contains non comment strings. if -> if it --- src/share/vm/asm/codeBuffer.cpp 1105 *this = other; // copy all fields (including _defunct when it exists) I can see the need to free() the existing CodeStrings if present, but otherwise why does the original logic need to change from: _strings = other._strings; _other.set_null_and_invalidate(); to the somewhat cryptic: *this = other; other.set_null_and_invalidate(); I'm not even certain what that assignment will do. It's also not clear why _defunct needs to be copied over rather than just being set to true (as _other can't have _defunct==false as we already called check_valid() ). The change of semantics of free() does make me concerned whether existing uses of it now have their assumptions invalidated? It isn't clear to me why you would want to free() something but retain validity - more of a clear()/reset() operation. But then I don't understand the significance of comment versus non-comment with regards to validity ?? Thanks, David > In non product mode, CodeStrings allows to associate a linked list of > strings to a CodeBuffer, CodeBlob or Stub. In addition, with ASSERTS, it > defines a boolean asserting whether the list of strings are valid. > Here are the issues addressed by this CR: > > - The old code mentioned the fact that CodeStrings was not always > correctly initialized. This is addressed by the fix, allowing > check_valid to be added at a few locations where it could currently > failed due to uninitialized values (like at the beginning of > CodeStrings::free). This also makes the code more robust against future > versions of CodeStrings. > > - As a minor extension, it is now possible for platform dependent code > to modify the comment separator used by print_block_comment, which was > hard coded to " ;; ". > > - As another minor extension, related to the validity assertions, > freeing a code string no longer necessarily marks it (and hence its > Stub/CodeBlob/CodeBuffer) as invalid. If CodeStrings contains only > comment, removing them does not change the validity of the CodeStrings. > For similar reason, assignment over a non null CodeStrings is now valid > when we can safely free the old string. > > The modified code passes JPRT. It was also validated in fastdebug mode > with the vm.compiler.testlist to check that the validity assertion were > not triggered. One of our closed extensions also validated advanced use > of CodeStrings::assign (included cases where the target of the > assignment was not free). > > Best regards, > > Bertrand. > From david.holmes at oracle.com Wed Jun 17 03:56:40 2015 From: david.holmes at oracle.com (David Holmes) Date: Wed, 17 Jun 2015 13:56:40 +1000 Subject: Revision3: Corrected: RFR 8059557 (XL): Validate JVM Command-Line Flag Arguments In-Reply-To: <558090F4.6000105@oracle.com> References: <557C3EF0.3030107@oracle.com> <557E38F9.9010105@oracle.com> <558090F4.6000105@oracle.com> Message-ID: <5580EFF8.3080900@oracle.com> Hi Gerard, On 17/06/2015 7:11 AM, Gerard Ziemski wrote: > Coleen, Dmitry, David, Kim, Derek and Bengt, > > I have create an incremental webrev as requested: > http://cr.openjdk.java.net/~gziemski/8059557_rev2_to_rev3 > > As per suggestion from Kim and Coleen, I will not be spinning webrev4 > unless there is a blocker in the code that we haven't found yet. > > The plan right now is to check in rev3 and have > https://bugs.openjdk.java.net/browse/JDK-8112746 track any follow up > issues, which I already populated with comments from Coleen, Dmitry and > Kim. > > Can I have a final sign off on this webrev rev3 from all of you please? Other than the D->%d issue Dmitry spotted I have no further comments. Thanks, David > > cheers > > On 6/14/2015 9:31 PM, David Holmes wrote: >> Hi Gerard, >> >> Any chance you could produce and incremental webrev please? >> >> Thanks, >> David >> >> On 14/06/2015 12:32 AM, Gerard Ziemski wrote: >>> hi all, >>> >>> Thank you for the reviews so far! >>> >>> Here is a revision 3 of the feature taking into account feedback from >>> Kim Barrett, David Holmes, Derek White and Bengt Rutisson. I have >>> also merged the changes to the latest jdk9. >>> >>> We introduce a new mechanism that allows specification of a valid >>> range per flag that is then used to automatically validate given >>> flag's value every time it changes. Ranges values must be constant >>> and can not change. Optionally, a constraint can also be specified >>> and applied every time a flag value changes for those flags whose >>> valid value can not be trivially checked by a simple min and max (ex. >>> whether it's power of 2, or bigger or smaller than some other flag >>> that can also change) >>> >>> I have chosen to modify the table macros (ex. RUNTIME_FLAGS in >>> globals.hpp) instead of using a more sophisticated solution, such as >>> C++ templates, because even though macros were unfriendly when >>> initially developing, once a solution was arrived at, subsequent >>> additions to the tables of new ranges, or constraint are trivial from >>> developer's point of view. (The intial development unfriendliness of >>> macros was mitigated by using a pre-processor, which for those using >>> a modern IDE like Xcode, is easily available from a menu). Using >>> macros also allowed for more minimal code changes. >>> >>> The presented solution is based on expansion of macros using variadic >>> functions and can be readily seen in >>> runtime/commandLineFlagConstraintList.cpp and >>> runtime/commandLineFlagRangeList.cpp >>> >>> In commandLineFlagConstraintList.cpp or >>> commandLineFlagRangesList.cpp, there is bunch of classes and methods >>> that seems to beg for C++ template to be used. I have tried, but when >>> the compiler tries to generate code for both uintx and size_t, which >>> happen to have the same underlying type (on BSD), it fails to compile >>> overridden methods with same type, but different name. If someone has >>> a way of simplifying the new code via C++ templates, however, we can >>> file a new enhancement request to address that. >>> >>> This webrev represents only the initial range checking framework and >>> only 100 or so flags that were ported from an existing ad hoc range >>> checking code to this new mechanism. There are about 250 remaining >>> flags that still need their ranges determined and ported over to this >>> new mechanism and they are tracked by individual subtasks. >>> >>> I had to modify several existing tests to change the error message >>> that they expected when VM refuses to run, which was changed to >>> provide uniform error messages. >>> >>> To help with testing and subtask efforts I have introduced a new >>> runtime flag: >>> >>> PrintFlagsRanges: "Print VM flags and their ranges and exit VM" >>> >>> which in addition to the already existing flags: "PrintFlagsInitial" >>> and "PrintFlagsFinal" allow for thorough examination of the flags >>> values and their ranges. >>> >>> The code change builds and passes JPRT (-testset hotspot) and UTE >>> (vm.quick.testlist) >>> >>> >>> References: >>> >>> Webrev:http://cr.openjdk.java.net/~gziemski/8059557_rev3 >>> JEP:https://bugs.openjdk.java.net/browse/JDK-8059557 >>> Compiler subtask:https://bugs.openjdk.java.net/browse/JDK-8078554 >>> GC subtask:https://bugs.openjdk.java.net/browse/JDK-8078555 >>> Runtime subtask:https://bugs.openjdk.java.net/browse/JDK-8078556 >>> >>> Note: due to "awk" limit of 50 pats the Frames diff is not available >>> for "src/share/vm/runtime/arguments.cpp? and >>> "src/share/vm/runtime/globals.cpp? >>> >>> >>> Followup issues: >>> >>> JDK-8085866: There are 99 uses of FLAG_SET_ERGO, should they check >>> the return value? >>> JDK-8085864: FLAG_SET_CMDLINE in TestGenCollectorPolicy() currently >>> ignore the return values >>> JDK-8081842: Find a better place for >>> EMIT_{CONSTRAINTS,RANGES}_FOR_GLOBALS_EXT >>> JDK-8081833: There is a large amount of code near-duplication among >>> the various CommandLineFlagRange_ classes >>> JDK-8081519: Split globals.hpp to factor out the Flag values needed >>> by JDK-8059557 >>> >>> >>> hgstat: >>> >>> src/cpu/ppc/vm/globals_ppc.hpp | 2 +- >>> src/cpu/sparc/vm/globals_sparc.hpp | 2 +- >>> src/cpu/x86/vm/globals_x86.hpp | 2 +- >>> src/cpu/zero/vm/globals_zero.hpp | 3 +- >>> src/os/aix/vm/globals_aix.hpp | 2 +- >>> src/os/bsd/vm/globals_bsd.hpp | 29 +- >>> src/os/linux/vm/globals_linux.hpp | 9 +- >>> src/os/solaris/vm/globals_solaris.hpp | 4 +- >>> src/os/windows/vm/globals_windows.hpp | 5 +- >>> src/share/vm/c1/c1_globals.cpp | 4 +- >>> src/share/vm/c1/c1_globals.hpp | 17 +- >>> src/share/vm/gc/g1/g1_globals.cpp | 14 +- >>> src/share/vm/gc/g1/g1_globals.hpp | 38 +- >>> src/share/vm/opto/c2_globals.cpp | 12 +- >>> src/share/vm/opto/c2_globals.hpp | 40 +- >>> src/share/vm/prims/whitebox.cpp | 12 +- >>> src/share/vm/runtime/arguments.cpp | 765 >>> ++++++---------- >>> src/share/vm/runtime/arguments.hpp | 24 +- >>> src/share/vm/runtime/commandLineFlagConstraintList.cpp | 286 >>> ++++++ >>> src/share/vm/runtime/commandLineFlagConstraintList.hpp | 80 + >>> src/share/vm/runtime/commandLineFlagConstraintsCompiler.cpp | 44 + >>> src/share/vm/runtime/commandLineFlagConstraintsCompiler.hpp | 39 + >>> src/share/vm/runtime/commandLineFlagConstraintsGC.cpp | 235 >>> +++++ >>> src/share/vm/runtime/commandLineFlagConstraintsGC.hpp | 58 + >>> src/share/vm/runtime/commandLineFlagConstraintsRuntime.cpp | 65 + >>> src/share/vm/runtime/commandLineFlagConstraintsRuntime.hpp | 41 + >>> src/share/vm/runtime/commandLineFlagRangeList.cpp | 367 >>> ++++++++ >>> src/share/vm/runtime/commandLineFlagRangeList.hpp | 71 + >>> src/share/vm/runtime/globals.cpp | 721 >>> ++++++++++++--- >>> src/share/vm/runtime/globals.hpp | 343 >>> ++++++- >>> src/share/vm/runtime/globals_extension.hpp | 105 +- >>> src/share/vm/runtime/init.cpp | 5 +- >>> src/share/vm/runtime/os_ext.hpp | 7 +- >>> src/share/vm/runtime/thread.cpp | 6 + >>> src/share/vm/services/attachListener.cpp | 4 +- >>> src/share/vm/services/classLoadingService.cpp | 12 +- >>> src/share/vm/services/diagnosticCommand.cpp | 3 +- >>> src/share/vm/services/management.cpp | 6 +- >>> src/share/vm/services/memoryService.cpp | 4 +- >>> src/share/vm/services/writeableFlags.cpp | 183 ++- >>> src/share/vm/services/writeableFlags.hpp | 60 +- >>> test/compiler/c2/7200264/Test7200264.sh | 5 +- >>> test/compiler/startup/NumCompilerThreadsCheck.java | 2 +- >>> test/gc/arguments/TestHeapFreeRatio.java | 23 +- >>> test/gc/arguments/TestSurvivorAlignmentInBytesOption.java | 6 +- >>> test/gc/g1/TestStringDeduplicationTools.java | 6 +- >>> test/runtime/CompressedOops/CompressedClassSpaceSize.java | 4 +- >>> test/runtime/CompressedOops/ObjectAlignment.java | 9 +- >>> test/runtime/contended/Options.java | 10 +- >>> 49 files changed, 2851 insertions(+), 943 deletions(-) >>> >> > From david.holmes at oracle.com Wed Jun 17 04:10:46 2015 From: david.holmes at oracle.com (David Holmes) Date: Wed, 17 Jun 2015 14:10:46 +1000 Subject: RFR (XXS): 8098834 - Update jprt.properties with property listing tests subtrees In-Reply-To: <558032F4.4010202@oracle.com> References: <558032F4.4010202@oracle.com> Message-ID: <5580F346.3070306@oracle.com> Hi Dmitrij, On 17/06/2015 12:30 AM, Dmitrij Pochepko wrote: > Hi, > > Please review this small fix. > A new property for jprt, listing directories used for regression tests > > bug: https://bugs.openjdk.java.net/browse/JDK-8098834 > webrev: http://cr.openjdk.java.net/~dpochepk/8098834/webrev.01/ Looks okay. Thanks, David > Thanks, > Dmitrij From thomas.schatzl at oracle.com Wed Jun 17 09:41:41 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Wed, 17 Jun 2015 11:41:41 +0200 Subject: RFR: 8079315: UseCondCardMark broken in conjunction with CMS precleaning In-Reply-To: <558034E0.6060600@redhat.com> References: <5548D913.1030507@redhat.com> <554A1CA0.6070801@oracle.com> <473C887F-8CC5-4E67-BD9A-1882660CFD3C@lnu.se> <554B3B5E.8000705@oracle.com> <8EE73C49-83CD-4162-A3EF-19DDA2C2CDFA@lnu.se> <554FC66F.20307@oracle.com> <55507BE4.3050605@redhat.com> <03C141D8-952E-4E7A-BDAD-024CE2239010@lnu.se> <55508B60.1000200@redhat.com> <8868A273-7C97-45F0-BF10-85DDE5859E85@lnu.se> <5550B182.7090009@redhat.com> <5551FA97.9090502@oracle.com> <5551FD72.1020504@oracle.com> <38CAAA0B-6F32-4508-818F-AD9D248E8B35@lnu.se> <55524C58.4030904@oracle.com> <55524E8C.6080709@redhat.com> <55526041.1030709@redhat.com> <7C4CBC57-D7B2-4779-9353-DEACCB626370@lnu.se> <5552838B.3020305@oracle.com> <556D5EF9.6030702@redhat.com> <556D7692.3070707@oracle.com> <557D3D59.4000806@redhat.com> <558034E0.6060600@redhat.com> Message-ID: <1434534101.6640.1.camel@oracle.com> Hi, On Tue, 2015-06-16 at 15:38 +0100, Andrew Haley wrote: > On 06/14/2015 09:37 AM, Andrew Haley wrote: > > On 14/06/15 01:25, Erik ?sterlund wrote: > > > >> Short story: > >> I talked to Dave Dice about my ADS implementation(s). He agrees my ADS is > >> ?probably safe?, but explained that just fencing is probably preferred > >> over ADS for the future anyway due to current hardware trends of > >> optimizing fences. > > ... > >> Therefore, let?s go for fences! :) > > > > Great, thanks very much for your work one this. > > OK, so, will someone please review my patch or suggest an alternative? > > http://cr.openjdk.java.net/~aph/8079315/ looks good. Am I correct to assume that the CR that this issue has been based on (8078438) needs a sponsor too? Thomas From manasthakur17 at gmail.com Wed Jun 17 10:55:59 2015 From: manasthakur17 at gmail.com (Manas Thakur) Date: Wed, 17 Jun 2015 16:25:59 +0530 Subject: How is stack-trace constructed? Message-ID: Hello all Whenever an exception is thrown at runtime, we get the full stack-trace, listing all the call sites of the method. This is possible irrespective of whether the method enclosing exception site is compiled by C1 or C2, or interpreted. Can someone help me out in finding the data structures that store this call-site information? Regards, Manas From manasthakur17 at gmail.com Wed Jun 17 10:58:04 2015 From: manasthakur17 at gmail.com (Manas Thakur) Date: Wed, 17 Jun 2015 16:28:04 +0530 Subject: How is stack-trace constructed? In-Reply-To: References: Message-ID: <25351F75-0FAE-4186-B4E9-DA823BF7EC1C@gmail.com> Typo: By call sites of a method, I meant the whole call stack of the method. - Manas > On 17-Jun-2015, at 4:25 pm, Manas Thakur wrote: > > Hello all > > Whenever an exception is thrown at runtime, we get the full stack-trace, listing all the call sites of the method. This is possible irrespective of whether the method enclosing exception site is compiled by C1 or C2, or interpreted. Can someone help me out in finding the data structures that store this call-site information? > > Regards, > Manas From aph at redhat.com Wed Jun 17 10:57:56 2015 From: aph at redhat.com (Andrew Haley) Date: Wed, 17 Jun 2015 11:57:56 +0100 Subject: How is stack-trace constructed? In-Reply-To: References: Message-ID: <558152B4.2090708@redhat.com> On 06/17/2015 11:55 AM, Manas Thakur wrote: > Whenever an exception is thrown at runtime, we get the full stack-trace, listing all the call sites of the method. This is possible irrespective of whether the method enclosing exception site is compiled by C1 or C2, or interpreted. Can someone help me out in finding the data structures that store this call-site information? This is not a very simple answer. There is a great deal of information stored along with compiled code, and it is used to trace the stack. Have you tried stepping through the code in a debugger? Andrew. From manasthakur17 at gmail.com Wed Jun 17 11:02:11 2015 From: manasthakur17 at gmail.com (Manas Thakur) Date: Wed, 17 Jun 2015 16:32:11 +0530 Subject: How is stack-trace constructed? In-Reply-To: <558152B4.2090708@redhat.com> References: <558152B4.2090708@redhat.com> Message-ID: <8744A10E-F4A7-41E0-980E-55B157CD1DB5@gmail.com> Hi Andrew, I haven?t done that (will do for sure if you suggest). But I thought this information must be available somewhere with a data structure in ?ciMethod?. Can you tell if I am leading to the right direction? Regards, Manas > On 17-Jun-2015, at 4:27 pm, Andrew Haley wrote: > > On 06/17/2015 11:55 AM, Manas Thakur wrote: >> Whenever an exception is thrown at runtime, we get the full stack-trace, listing all the call sites of the method. This is possible irrespective of whether the method enclosing exception site is compiled by C1 or C2, or interpreted. Can someone help me out in finding the data structures that store this call-site information? > > This is not a very simple answer. There is a great deal of information > stored along with compiled code, and it is used to trace the stack. Have > you tried stepping through the code in a debugger? > > Andrew. > From bertrand.delsart at oracle.com Wed Jun 17 11:07:00 2015 From: bertrand.delsart at oracle.com (Bertrand Delsart) Date: Wed, 17 Jun 2015 13:07:00 +0200 Subject: RFR [S] 8081406: cleanup and minor extensions of the debugging facilities in CodeStrings In-Reply-To: <5580D094.8060803@oracle.com> References: <55674A24.4050501@oracle.com> <5580D094.8060803@oracle.com> Message-ID: <558154D4.8090405@oracle.com> Thanks David, Updated webrev. See below my inlined comments for additional explanations on the changes. http://cr.openjdk.java.net/~bdelsart/8081406/webrev.01/ This is a subset of the previous changes: - free was reverted to its initial definition but its behavior is now clearly documented (e.g. the fact that it must invalidate the object since this was David's concern) - assign is nearly reverted too but still ensures _defunct is set Regards, Bertrand. On 17/06/2015 03:42, David Holmes wrote: > Hi Bertrand, > > On 29/05/2015 3:02 AM, Bertrand Delsart wrote: >> Hi all, >> >> Small RFR to address minor issues in debug mode with CodeStrings > > Not something I'm familiar with so I may be missing some things here. > >> https://bugs.openjdk.java.net/browse/JDK-8081406 >> http://cr.openjdk.java.net/~bdelsart/8081406/webrev.00/ >> >> The change does not impact the product mode. > > So the initialization of CodeBlob::_strings and > CodeBuffer::_code_strings does happen in product mode as well, but the > resulting CodeStrings object does nothing. Suggests to me that *_strings > should be a non-product field only (but that's an aside to this set of > changes). > > src/share/vm/asm/codeBuffer.hpp > > The ifdef style in this file is quite awful IMO but the changes are > consistent with it. > > 308 // FREE strings; invalidate if contains non comment strings. > > if -> if it OK. [ Will in fact just be "invalidate this" due to your other feedback ] > > --- > > src/share/vm/asm/codeBuffer.cpp > > 1105 *this = other; // copy all fields (including _defunct when it > exists) > > I can see the need to free() the existing CodeStrings if present, but > otherwise why does the original logic need to change from: > > _strings = other._strings; > _other.set_null_and_invalidate(); > > to the somewhat cryptic: > > *this = other; > other.set_null_and_invalidate(); > > I'm not even certain what that assignment will do. It's also not clear > why _defunct needs to be copied over rather than just being set to true > (as _other can't have _defunct==false as we already called check_valid() ). First, the fields declared in CodeStrings depends on several ifdefs (ASSERT and PRODUCT). "*this=" is a way to avoid the "awful ifdef style" :-) In addition, this is slightly more robust IMHO. For instance, it makes the assignment copy independent of the internals of CodeStrings. In particular, _defunct would have to be set to false, not true :-) Now, I did check that this had not lead to issue in JPRT and with other test in debug mode, including on exotic platforms, but it is impossible to prove that all C++ compilers will handle correctly "*this=" which should just be an assignment copy between two C++ objects (and a NOP in product mode, where the CodeStrings are of size 0). Since this RFR is blocking later pushes, I'll avoid further delays and replace *this = other by : _strings = other._strings #ifdef ASSERT _defunct = false; #endif > The change of semantics of free() does make me concerned whether > existing uses of it now have their assumptions invalidated? It isn't > clear to me why you would want to free() something but retain validity - > more of a clear()/reset() operation. But then I don't understand the > significance of comment versus non-comment with regards to validity ?? I see your concern about free(). To make that clearer, I added explicitly next to the declaration of free the fact that it invalidates the buffer. My change was initially due to closed code in JDK-8087333 (an RFE concurrently being reviewed). Extending the meaning of _valid had allowed the closed code to be cleaner and more robust, catching errors in the handling on non-comment strings (see below) but this may no longer be necessary. I'll look for an alternate solution if needed (for instance adding a new clear() method; thanks for the suggestion). Reverting free() in the current webrev means I'll also remove from CodeStrings::assign the + if (!is_null()) { + // The assignment replaces the old content. + // Delete old CodeStrings, invalidating it if there are non-comment + // strings. + free(); + check_valid(); // else the container may reference freed strings + } and add back the - assert(is_null(), "Cannot assign onto non-empty CodeStrings"); FYI, some information on the comment versus non-comment. Non-comment strings in CodeStrings are (currently) used only in for debug functionalities (verify_oop, unimplemented, untested, ...) but they are necessary to correctly report errors. If deleted, the VM may crash when trying to print a debug message. Since CodeStrings are embedded into a CodeBlob container, marking the CodeStrings invalid when freed allowed to detect that the CodeBlob was no longer valid. On the other hand, a comment string is something which is not necessary for correct execution. It is only used when dumping the code. Removing a comment from a CodeStrings has no impact on the execution of the Java application... and freeing them was the most efficient way to handle them for JDK-8087333. My change allowed to detect as a side effect of the free whether we had safely deleted only comments or whether there was a non-comment string that had not been properly handled. As stated above, I'll look for an alternative to provide the same robustness without impacting the existing methods, avoiding all risks. Regards, Bertrand. > > Thanks, > David > >> In non product mode, CodeStrings allows to associate a linked list of >> strings to a CodeBuffer, CodeBlob or Stub. In addition, with ASSERTS, it >> defines a boolean asserting whether the list of strings are valid. > > > >> Here are the issues addressed by this CR: >> >> - The old code mentioned the fact that CodeStrings was not always >> correctly initialized. This is addressed by the fix, allowing >> check_valid to be added at a few locations where it could currently >> failed due to uninitialized values (like at the beginning of >> CodeStrings::free). This also makes the code more robust against future >> versions of CodeStrings. >> >> - As a minor extension, it is now possible for platform dependent code >> to modify the comment separator used by print_block_comment, which was >> hard coded to " ;; ". >> >> - As another minor extension, related to the validity assertions, >> freeing a code string no longer necessarily marks it (and hence its >> Stub/CodeBlob/CodeBuffer) as invalid. If CodeStrings contains only >> comment, removing them does not change the validity of the CodeStrings. >> For similar reason, assignment over a non null CodeStrings is now valid >> when we can safely free the old string. >> >> The modified code passes JPRT. It was also validated in fastdebug mode >> with the vm.compiler.testlist to check that the validity assertion were >> not triggered. One of our closed extensions also validated advanced use >> of CodeStrings::assign (included cases where the target of the >> assignment was not free). >> >> Best regards, >> >> Bertrand. >> -- Bertrand Delsart, Grenoble Engineering Center Oracle, 180 av. de l'Europe, ZIRST de Montbonnot 38330 Montbonnot Saint Martin, FRANCE bertrand.delsart at oracle.com Phone : +33 4 76 18 81 23 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From dmitry.dmitriev at oracle.com Wed Jun 17 11:14:47 2015 From: dmitry.dmitriev at oracle.com (Dmitry Dmitriev) Date: Wed, 17 Jun 2015 14:14:47 +0300 Subject: Revision3: Corrected: RFR 8059557 (XL): Validate JVM Command-Line Flag Arguments In-Reply-To: <558090F4.6000105@oracle.com> References: <557C3EF0.3030107@oracle.com> <557E38F9.9010105@oracle.com> <558090F4.6000105@oracle.com> Message-ID: <558156A7.8040904@oracle.com> Hi Gerard, Changes looks good! Regards, Dmitry On 17.06.2015 0:11, Gerard Ziemski wrote: > Coleen, Dmitry, David, Kim, Derek and Bengt, > > I have create an incremental webrev as requested: > http://cr.openjdk.java.net/~gziemski/8059557_rev2_to_rev3 > > As per suggestion from Kim and Coleen, I will not be spinning webrev4 > unless there is a blocker in the code that we haven't found yet. > > The plan right now is to check in rev3 and have > https://bugs.openjdk.java.net/browse/JDK-8112746 track any follow up > issues, which I already populated with comments from Coleen, Dmitry > and Kim. > > Can I have a final sign off on this webrev rev3 from all of you please? > > > cheers > > On 6/14/2015 9:31 PM, David Holmes wrote: >> Hi Gerard, >> >> Any chance you could produce and incremental webrev please? >> >> Thanks, >> David >> >> On 14/06/2015 12:32 AM, Gerard Ziemski wrote: >>> hi all, >>> >>> Thank you for the reviews so far! >>> >>> Here is a revision 3 of the feature taking into account feedback >>> from Kim Barrett, David Holmes, Derek White and Bengt Rutisson. I >>> have also merged the changes to the latest jdk9. >>> >>> We introduce a new mechanism that allows specification of a valid >>> range per flag that is then used to automatically validate given >>> flag's value every time it changes. Ranges values must be constant >>> and can not change. Optionally, a constraint can also be specified >>> and applied every time a flag value changes for those flags whose >>> valid value can not be trivially checked by a simple min and max >>> (ex. whether it's power of 2, or bigger or smaller than some other >>> flag that can also change) >>> >>> I have chosen to modify the table macros (ex. RUNTIME_FLAGS in >>> globals.hpp) instead of using a more sophisticated solution, such as >>> C++ templates, because even though macros were unfriendly when >>> initially developing, once a solution was arrived at, subsequent >>> additions to the tables of new ranges, or constraint are trivial >>> from developer's point of view. (The intial development >>> unfriendliness of macros was mitigated by using a pre-processor, >>> which for those using a modern IDE like Xcode, is easily available >>> from a menu). Using macros also allowed for more minimal code changes. >>> >>> The presented solution is based on expansion of macros using >>> variadic functions and can be readily seen in >>> runtime/commandLineFlagConstraintList.cpp and >>> runtime/commandLineFlagRangeList.cpp >>> >>> In commandLineFlagConstraintList.cpp or >>> commandLineFlagRangesList.cpp, there is bunch of classes and methods >>> that seems to beg for C++ template to be used. I have tried, but >>> when the compiler tries to generate code for both uintx and size_t, >>> which happen to have the same underlying type (on BSD), it fails to >>> compile overridden methods with same type, but different name. If >>> someone has a way of simplifying the new code via C++ templates, >>> however, we can file a new enhancement request to address that. >>> >>> This webrev represents only the initial range checking framework and >>> only 100 or so flags that were ported from an existing ad hoc range >>> checking code to this new mechanism. There are about 250 remaining >>> flags that still need their ranges determined and ported over to >>> this new mechanism and they are tracked by individual subtasks. >>> >>> I had to modify several existing tests to change the error message >>> that they expected when VM refuses to run, which was changed to >>> provide uniform error messages. >>> >>> To help with testing and subtask efforts I have introduced a new >>> runtime flag: >>> >>> PrintFlagsRanges: "Print VM flags and their ranges and exit VM" >>> >>> which in addition to the already existing flags: "PrintFlagsInitial" >>> and "PrintFlagsFinal" allow for thorough examination of the flags >>> values and their ranges. >>> >>> The code change builds and passes JPRT (-testset hotspot) and UTE >>> (vm.quick.testlist) >>> >>> >>> References: >>> >>> Webrev:http://cr.openjdk.java.net/~gziemski/8059557_rev3 >>> JEP:https://bugs.openjdk.java.net/browse/JDK-8059557 >>> Compiler subtask:https://bugs.openjdk.java.net/browse/JDK-8078554 >>> GC subtask:https://bugs.openjdk.java.net/browse/JDK-8078555 >>> Runtime subtask:https://bugs.openjdk.java.net/browse/JDK-8078556 >>> >>> Note: due to "awk" limit of 50 pats the Frames diff is not available >>> for "src/share/vm/runtime/arguments.cpp? and >>> "src/share/vm/runtime/globals.cpp? >>> >>> >>> Followup issues: >>> >>> JDK-8085866: There are 99 uses of FLAG_SET_ERGO, should they check >>> the return value? >>> JDK-8085864: FLAG_SET_CMDLINE in TestGenCollectorPolicy() currently >>> ignore the return values >>> JDK-8081842: Find a better place for >>> EMIT_{CONSTRAINTS,RANGES}_FOR_GLOBALS_EXT >>> JDK-8081833: There is a large amount of code near-duplication among >>> the various CommandLineFlagRange_ classes >>> JDK-8081519: Split globals.hpp to factor out the Flag values needed >>> by JDK-8059557 >>> >>> >>> hgstat: >>> >>> src/cpu/ppc/vm/globals_ppc.hpp | 2 +- >>> src/cpu/sparc/vm/globals_sparc.hpp | 2 +- >>> src/cpu/x86/vm/globals_x86.hpp | 2 +- >>> src/cpu/zero/vm/globals_zero.hpp | 3 +- >>> src/os/aix/vm/globals_aix.hpp | 2 +- >>> src/os/bsd/vm/globals_bsd.hpp | 29 +- >>> src/os/linux/vm/globals_linux.hpp | 9 +- >>> src/os/solaris/vm/globals_solaris.hpp | 4 +- >>> src/os/windows/vm/globals_windows.hpp | 5 +- >>> src/share/vm/c1/c1_globals.cpp | 4 +- >>> src/share/vm/c1/c1_globals.hpp | 17 +- >>> src/share/vm/gc/g1/g1_globals.cpp | 14 +- >>> src/share/vm/gc/g1/g1_globals.hpp | 38 +- >>> src/share/vm/opto/c2_globals.cpp | 12 +- >>> src/share/vm/opto/c2_globals.hpp | 40 +- >>> src/share/vm/prims/whitebox.cpp | 12 +- >>> src/share/vm/runtime/arguments.cpp | 765 ++++++---------- >>> src/share/vm/runtime/arguments.hpp | 24 +- >>> src/share/vm/runtime/commandLineFlagConstraintList.cpp | 286 ++++++ >>> src/share/vm/runtime/commandLineFlagConstraintList.hpp | 80 + >>> src/share/vm/runtime/commandLineFlagConstraintsCompiler.cpp | 44 + >>> src/share/vm/runtime/commandLineFlagConstraintsCompiler.hpp | 39 + >>> src/share/vm/runtime/commandLineFlagConstraintsGC.cpp | 235 +++++ >>> src/share/vm/runtime/commandLineFlagConstraintsGC.hpp | 58 + >>> src/share/vm/runtime/commandLineFlagConstraintsRuntime.cpp | 65 + >>> src/share/vm/runtime/commandLineFlagConstraintsRuntime.hpp | 41 + >>> src/share/vm/runtime/commandLineFlagRangeList.cpp | 367 ++++++++ >>> src/share/vm/runtime/commandLineFlagRangeList.hpp | 71 + >>> src/share/vm/runtime/globals.cpp | 721 ++++++++++++--- >>> src/share/vm/runtime/globals.hpp | 343 ++++++- >>> src/share/vm/runtime/globals_extension.hpp | 105 +- >>> src/share/vm/runtime/init.cpp | 5 +- >>> src/share/vm/runtime/os_ext.hpp | 7 +- >>> src/share/vm/runtime/thread.cpp | 6 + >>> src/share/vm/services/attachListener.cpp | 4 +- >>> src/share/vm/services/classLoadingService.cpp | 12 +- >>> src/share/vm/services/diagnosticCommand.cpp | 3 +- >>> src/share/vm/services/management.cpp | 6 +- >>> src/share/vm/services/memoryService.cpp | 4 +- >>> src/share/vm/services/writeableFlags.cpp | 183 ++- >>> src/share/vm/services/writeableFlags.hpp | 60 +- >>> test/compiler/c2/7200264/Test7200264.sh | 5 +- >>> test/compiler/startup/NumCompilerThreadsCheck.java | 2 +- >>> test/gc/arguments/TestHeapFreeRatio.java | 23 +- >>> test/gc/arguments/TestSurvivorAlignmentInBytesOption.java | 6 +- >>> test/gc/g1/TestStringDeduplicationTools.java | 6 +- >>> test/runtime/CompressedOops/CompressedClassSpaceSize.java | 4 +- >>> test/runtime/CompressedOops/ObjectAlignment.java | 9 +- >>> test/runtime/contended/Options.java | 10 +- >>> 49 files changed, 2851 insertions(+), 943 deletions(-) >>> >> > From aph at redhat.com Wed Jun 17 11:15:56 2015 From: aph at redhat.com (Andrew Haley) Date: Wed, 17 Jun 2015 12:15:56 +0100 Subject: How is stack-trace constructed? In-Reply-To: <8744A10E-F4A7-41E0-980E-55B157CD1DB5@gmail.com> References: <558152B4.2090708@redhat.com> <8744A10E-F4A7-41E0-980E-55B157CD1DB5@gmail.com> Message-ID: <558156EC.1090608@redhat.com> Hi, On 06/17/2015 12:02 PM, Manas Thakur wrote: > > I haven?t done that (will do for sure if you suggest). But I thought > this information must be available somewhere with a data structure > in ?ciMethod?. Can you tell if I am leading to the right direction? No, those are compile-time structures. The information you seek is in the nmethod. It has PcDescs which map a physical PC to the corresponding source scope and bytecode index. Once you have that it's relatively easy. Put a breakpoint on java_lang_Throwable::fill_in_stack_trace here: if (nm->method()->is_native()) { method = nm->method(); bci = 0; } else { PcDesc* pd = nm->pc_desc_at(pc); decode_offset = pd->scope_decode_offset(); // if decode_offset is not equal to 0, it will execute the // "compiled java method case" at the beginning of the loop. and you can watch it happen. Andrew. From david.holmes at oracle.com Tue Jun 16 01:46:34 2015 From: david.holmes at oracle.com (David Holmes) Date: Tue, 16 Jun 2015 11:46:34 +1000 Subject: CFV: New HotSpot Group Lead: Vladimir Kozlov In-Reply-To: References: Message-ID: <557F7FFA.9020602@oracle.com> Vote: yes David On 16/06/2015 2:56 AM, Christian Thalinger wrote: > I hereby nominate Vladimir Kozlov to HotSpot Group Lead [1]. > > Vladimir is a member of the HotSpot Group since OpenJDK was > established, is working on the HotSpot JVM for more than 12 years > and is well known in the HotSpot OpenJDK community. > > Votes are due by June 26, 2015 12:00 PST. > > Only current Members of the HotSpot Group [2] are eligible to > vote on this nomination. Votes must be cast in the open by > replying to this mailing list. > > For Simple Majority voting instructions, see [3]. > > Thanks, > Christian Thalinger > > [1]: http://openjdk.java.net/bylaws#group-lead > [2]: http://openjdk.java.net/census#hotspot > [3]: http://openjdk.java.net/groups#lead-vote > From manasthakur17 at gmail.com Wed Jun 17 12:33:23 2015 From: manasthakur17 at gmail.com (Manas Thakur) Date: Wed, 17 Jun 2015 18:03:23 +0530 Subject: How is stack-trace constructed? In-Reply-To: <558156EC.1090608@redhat.com> References: <558152B4.2090708@redhat.com> <8744A10E-F4A7-41E0-980E-55B157CD1DB5@gmail.com> <558156EC.1090608@redhat.com> Message-ID: <69ED7903-1879-4859-901D-327CF0C4BEDD@gmail.com> Thanks a lot Andrew; I understood the flow now. Regards, Manas > On 17-Jun-2015, at 4:45 pm, Andrew Haley wrote: > > Hi, > > On 06/17/2015 12:02 PM, Manas Thakur wrote: >> >> I haven?t done that (will do for sure if you suggest). But I thought >> this information must be available somewhere with a data structure >> in ?ciMethod?. Can you tell if I am leading to the right direction? > > No, those are compile-time structures. The information you seek is in > the nmethod. It has PcDescs which map a physical PC to the > corresponding source scope and bytecode index. Once you have that > it's relatively easy. > > Put a breakpoint on java_lang_Throwable::fill_in_stack_trace here: > > if (nm->method()->is_native()) { > method = nm->method(); > bci = 0; > } else { > PcDesc* pd = nm->pc_desc_at(pc); > decode_offset = pd->scope_decode_offset(); > // if decode_offset is not equal to 0, it will execute the > // "compiled java method case" at the beginning of the loop. > > and you can watch it happen. > > Andrew. From gerard.ziemski at oracle.com Wed Jun 17 15:03:06 2015 From: gerard.ziemski at oracle.com (Gerard Ziemski) Date: Wed, 17 Jun 2015 10:03:06 -0500 Subject: Revision3: Corrected: RFR 8059557 (XL): Validate JVM Command-Line Flag Arguments In-Reply-To: <558156A7.8040904@oracle.com> References: <557C3EF0.3030107@oracle.com> <557E38F9.9010105@oracle.com> <558090F4.6000105@oracle.com> <558156A7.8040904@oracle.com> Message-ID: <55818C2A.90401@oracle.com> Thank you Dmitry! On 6/17/2015 6:14 AM, Dmitry Dmitriev wrote: > Hi Gerard, > > Changes looks good! > > Regards, > Dmitry > > On 17.06.2015 0:11, Gerard Ziemski wrote: >> Coleen, Dmitry, David, Kim, Derek and Bengt, >> >> I have create an incremental webrev as requested: >> http://cr.openjdk.java.net/~gziemski/8059557_rev2_to_rev3 >> >> As per suggestion from Kim and Coleen, I will not be spinning webrev4 >> unless there is a blocker in the code that we haven't found yet. >> >> The plan right now is to check in rev3 and have >> https://bugs.openjdk.java.net/browse/JDK-8112746 track any follow up >> issues, which I already populated with comments from Coleen, Dmitry >> and Kim. >> >> Can I have a final sign off on this webrev rev3 from all of you please? >> >> >> cheers >> >> On 6/14/2015 9:31 PM, David Holmes wrote: >>> Hi Gerard, >>> >>> Any chance you could produce and incremental webrev please? >>> >>> Thanks, >>> David >>> >>> On 14/06/2015 12:32 AM, Gerard Ziemski wrote: >>>> hi all, >>>> >>>> Thank you for the reviews so far! >>>> >>>> Here is a revision 3 of the feature taking into account feedback >>>> from Kim Barrett, David Holmes, Derek White and Bengt Rutisson. I >>>> have also merged the changes to the latest jdk9. >>>> >>>> We introduce a new mechanism that allows specification of a valid >>>> range per flag that is then used to automatically validate given >>>> flag's value every time it changes. Ranges values must be constant >>>> and can not change. Optionally, a constraint can also be specified >>>> and applied every time a flag value changes for those flags whose >>>> valid value can not be trivially checked by a simple min and max >>>> (ex. whether it's power of 2, or bigger or smaller than some other >>>> flag that can also change) >>>> >>>> I have chosen to modify the table macros (ex. RUNTIME_FLAGS in >>>> globals.hpp) instead of using a more sophisticated solution, such >>>> as C++ templates, because even though macros were unfriendly when >>>> initially developing, once a solution was arrived at, subsequent >>>> additions to the tables of new ranges, or constraint are trivial >>>> from developer's point of view. (The intial development >>>> unfriendliness of macros was mitigated by using a pre-processor, >>>> which for those using a modern IDE like Xcode, is easily available >>>> from a menu). Using macros also allowed for more minimal code changes. >>>> >>>> The presented solution is based on expansion of macros using >>>> variadic functions and can be readily seen in >>>> runtime/commandLineFlagConstraintList.cpp and >>>> runtime/commandLineFlagRangeList.cpp >>>> >>>> In commandLineFlagConstraintList.cpp or >>>> commandLineFlagRangesList.cpp, there is bunch of classes and >>>> methods that seems to beg for C++ template to be used. I have >>>> tried, but when the compiler tries to generate code for both uintx >>>> and size_t, which happen to have the same underlying type (on BSD), >>>> it fails to compile overridden methods with same type, but >>>> different name. If someone has a way of simplifying the new code >>>> via C++ templates, however, we can file a new enhancement request >>>> to address that. >>>> >>>> This webrev represents only the initial range checking framework >>>> and only 100 or so flags that were ported from an existing ad hoc >>>> range checking code to this new mechanism. There are about 250 >>>> remaining flags that still need their ranges determined and ported >>>> over to this new mechanism and they are tracked by individual >>>> subtasks. >>>> >>>> I had to modify several existing tests to change the error message >>>> that they expected when VM refuses to run, which was changed to >>>> provide uniform error messages. >>>> >>>> To help with testing and subtask efforts I have introduced a new >>>> runtime flag: >>>> >>>> PrintFlagsRanges: "Print VM flags and their ranges and exit VM" >>>> >>>> which in addition to the already existing flags: >>>> "PrintFlagsInitial" and "PrintFlagsFinal" allow for thorough >>>> examination of the flags values and their ranges. >>>> >>>> The code change builds and passes JPRT (-testset hotspot) and UTE >>>> (vm.quick.testlist) >>>> >>>> >>>> References: >>>> >>>> Webrev:http://cr.openjdk.java.net/~gziemski/8059557_rev3 >>>> JEP:https://bugs.openjdk.java.net/browse/JDK-8059557 >>>> Compiler subtask:https://bugs.openjdk.java.net/browse/JDK-8078554 >>>> GC subtask:https://bugs.openjdk.java.net/browse/JDK-8078555 >>>> Runtime subtask:https://bugs.openjdk.java.net/browse/JDK-8078556 >>>> >>>> Note: due to "awk" limit of 50 pats the Frames diff is not >>>> available for "src/share/vm/runtime/arguments.cpp? and >>>> "src/share/vm/runtime/globals.cpp? >>>> >>>> >>>> Followup issues: >>>> >>>> JDK-8085866: There are 99 uses of FLAG_SET_ERGO, should they check >>>> the return value? >>>> JDK-8085864: FLAG_SET_CMDLINE in TestGenCollectorPolicy() currently >>>> ignore the return values >>>> JDK-8081842: Find a better place for >>>> EMIT_{CONSTRAINTS,RANGES}_FOR_GLOBALS_EXT >>>> JDK-8081833: There is a large amount of code near-duplication among >>>> the various CommandLineFlagRange_ classes >>>> JDK-8081519: Split globals.hpp to factor out the Flag values needed >>>> by JDK-8059557 >>>> >>>> >>>> hgstat: >>>> >>>> src/cpu/ppc/vm/globals_ppc.hpp | 2 +- >>>> src/cpu/sparc/vm/globals_sparc.hpp | 2 +- >>>> src/cpu/x86/vm/globals_x86.hpp | 2 +- >>>> src/cpu/zero/vm/globals_zero.hpp | 3 +- >>>> src/os/aix/vm/globals_aix.hpp | 2 +- >>>> src/os/bsd/vm/globals_bsd.hpp | 29 +- >>>> src/os/linux/vm/globals_linux.hpp | 9 +- >>>> src/os/solaris/vm/globals_solaris.hpp | 4 +- >>>> src/os/windows/vm/globals_windows.hpp | 5 +- >>>> src/share/vm/c1/c1_globals.cpp | 4 +- >>>> src/share/vm/c1/c1_globals.hpp | 17 +- >>>> src/share/vm/gc/g1/g1_globals.cpp | 14 +- >>>> src/share/vm/gc/g1/g1_globals.hpp | 38 +- >>>> src/share/vm/opto/c2_globals.cpp | 12 +- >>>> src/share/vm/opto/c2_globals.hpp | 40 +- >>>> src/share/vm/prims/whitebox.cpp | 12 +- >>>> src/share/vm/runtime/arguments.cpp | 765 ++++++---------- >>>> src/share/vm/runtime/arguments.hpp | 24 +- >>>> src/share/vm/runtime/commandLineFlagConstraintList.cpp | 286 ++++++ >>>> src/share/vm/runtime/commandLineFlagConstraintList.hpp | 80 + >>>> src/share/vm/runtime/commandLineFlagConstraintsCompiler.cpp | 44 + >>>> src/share/vm/runtime/commandLineFlagConstraintsCompiler.hpp | 39 + >>>> src/share/vm/runtime/commandLineFlagConstraintsGC.cpp | 235 +++++ >>>> src/share/vm/runtime/commandLineFlagConstraintsGC.hpp | 58 + >>>> src/share/vm/runtime/commandLineFlagConstraintsRuntime.cpp | 65 + >>>> src/share/vm/runtime/commandLineFlagConstraintsRuntime.hpp | 41 + >>>> src/share/vm/runtime/commandLineFlagRangeList.cpp | 367 ++++++++ >>>> src/share/vm/runtime/commandLineFlagRangeList.hpp | 71 + >>>> src/share/vm/runtime/globals.cpp | 721 ++++++++++++--- >>>> src/share/vm/runtime/globals.hpp | 343 ++++++- >>>> src/share/vm/runtime/globals_extension.hpp | 105 +- >>>> src/share/vm/runtime/init.cpp | 5 +- >>>> src/share/vm/runtime/os_ext.hpp | 7 +- >>>> src/share/vm/runtime/thread.cpp | 6 + >>>> src/share/vm/services/attachListener.cpp | 4 +- >>>> src/share/vm/services/classLoadingService.cpp | 12 +- >>>> src/share/vm/services/diagnosticCommand.cpp | 3 +- >>>> src/share/vm/services/management.cpp | 6 +- >>>> src/share/vm/services/memoryService.cpp | 4 +- >>>> src/share/vm/services/writeableFlags.cpp | 183 ++- >>>> src/share/vm/services/writeableFlags.hpp | 60 +- >>>> test/compiler/c2/7200264/Test7200264.sh | 5 +- >>>> test/compiler/startup/NumCompilerThreadsCheck.java | 2 +- >>>> test/gc/arguments/TestHeapFreeRatio.java | 23 +- >>>> test/gc/arguments/TestSurvivorAlignmentInBytesOption.java | 6 +- >>>> test/gc/g1/TestStringDeduplicationTools.java | 6 +- >>>> test/runtime/CompressedOops/CompressedClassSpaceSize.java | 4 +- >>>> test/runtime/CompressedOops/ObjectAlignment.java | 9 +- >>>> test/runtime/contended/Options.java | 10 +- >>>> 49 files changed, 2851 insertions(+), 943 deletions(-) >>>> >>> >> > > From gerard.ziemski at oracle.com Wed Jun 17 15:03:37 2015 From: gerard.ziemski at oracle.com (Gerard Ziemski) Date: Wed, 17 Jun 2015 10:03:37 -0500 Subject: Revision3: Corrected: RFR 8059557 (XL): Validate JVM Command-Line Flag Arguments In-Reply-To: <5580EFF8.3080900@oracle.com> References: <557C3EF0.3030107@oracle.com> <557E38F9.9010105@oracle.com> <558090F4.6000105@oracle.com> <5580EFF8.3080900@oracle.com> Message-ID: <55818C49.7010100@oracle.com> On 6/16/2015 10:56 PM, David Holmes wrote: > Hi Gerard, > > On 17/06/2015 7:11 AM, Gerard Ziemski wrote: >> Coleen, Dmitry, David, Kim, Derek and Bengt, >> >> I have create an incremental webrev as requested: >> http://cr.openjdk.java.net/~gziemski/8059557_rev2_to_rev3 >> >> As per suggestion from Kim and Coleen, I will not be spinning webrev4 >> unless there is a blocker in the code that we haven't found yet. >> >> The plan right now is to check in rev3 and have >> https://bugs.openjdk.java.net/browse/JDK-8112746 track any follow up >> issues, which I already populated with comments from Coleen, Dmitry and >> Kim. >> >> Can I have a final sign off on this webrev rev3 from all of you please? > > Other than the D->%d issue Dmitry spotted I have no further comments. It's in the followup issue. Thank you David! From gerard.ziemski at oracle.com Wed Jun 17 15:07:34 2015 From: gerard.ziemski at oracle.com (Gerard Ziemski) Date: Wed, 17 Jun 2015 10:07:34 -0500 Subject: RFR 8059557: Test set for "Validate JVM Command-Line Flag Arguments" In-Reply-To: <558047AC.6040705@oracle.com> References: <555A09B8.7010402@oracle.com> <555E46A7.4020402@oracle.com> <55671906.10000@oracle.com> <556D3597.8090508@oracle.com> <556F0559.3080601@oracle.com> <558047AC.6040705@oracle.com> Message-ID: <55818D36.3020908@oracle.com> hi Dmitry, Please consider this reviewed (with small "r"). Just one quick question: is there an issue filed to followup on why the test hangs with CICompiler and to enable it back, once we figure it out? cheers On 6/16/2015 10:58 AM, Dmitry Dmitriev wrote: > Hello, > > Here a updated version of test set for Command Line Option Validation. > The main changes are: added new options types - int and uint, added > @modules, test all options with range in TestOptionsWithRanges.java test. > > Tested: JPRT > > Webrev: http://cr.openjdk.java.net/~ddmitriev/8059557/webrev.05/ > > Webrev incremental(from 04): > http://cr.openjdk.java.net/~ddmitriev/8059557/webrev.05.incremental/ > > JEP: https://bugs.openjdk.java.net/browse/JDK-8059557 > > Thanks, > Dmitry > > On 03.06.2015 16:47, Dmitry Dmitriev wrote: >> Hello David, >> >> Thank you for pointing on style/grammar mistakes! I corrected all of >> them. >> Here a link to the updated >> webrev:http://cr.openjdk.java.net/~ddmitriev/8059557/webrev.04/ >> >> >> About "options validation" package - I agree that this looks odd, but >> if you don't mind I prefer to leave it. It slightly simplify calling >> static methods by using static import and also I use package-private >> access level. >> >> Regards, >> Dmitry >> >> On 02.06.2015 7:48, David Holmes wrote: >>> Hi Dmitry, >>> >>> On 28/05/2015 11:32 PM, Dmitry Dmitriev wrote: >>>> Hello all, >>>> >>>> Here is a 3 version of the tests taking into account feedback from >>>> Christian, David and Gerard. >>>> >>>> I limit number of options in TestOptionsWithRanges.java to 15. This >>>> include options of different types(intx, uintx etc.) and with >>>> different >>>> combination of min/max range. TestOptionsWithRangesDynamic.java leaved >>>> as is, because amount of manageable numeric options is very small and >>>> currently only 3 of them have range. Also, I improve code for double >>>> option. >>>> >>>> Webrev: http://cr.openjdk.java.net/~ddmitriev/8059557/webrev.03/ >>>> >>> >>> Only a few style/grammar nits (the downside of writing so many doc >>> comments :) ). >>> >>> Meta-question: is there a specific reason to use the package >>> "options validation"? It looks odd to me to have >>> OptionsValidation/common/optionsvalidation/ in the paths. >>> >>> General doc-comment comments: >>> - @param/@return descriptions should start with lower-case (you >>> currently mix-n-match) >>> - @throws description should start with "if", so: >>> @throws IOException if an error occurred reading the data >>> >>> >>> General Java-style comments: >>> - access modifiers (public, private, protected) always come first >>> >>> --- >>> >>> test/runtime/CommandLine/OptionsValidation/common/optionsvalidation/IntJVMOption.java >>> >>> >>> 265 * passed value is negative then error will be >>> catched earlier for >>> >>> catched -> caught >>> >>> --- >>> >>> test/runtime/CommandLine/OptionsValidation/common/optionsvalidation/JVMOption.java >>> >>> >>> 327 * @param param Tested parameter passed to the java >>> >>> "the java" is not a noun - suggest "the JVM" ? >>> >>> Maybe change Java to JVM to avoid use of "java" as a noun everywhere. >>> >>> 350 failedMessage(name, fullOptionString, valid, "JVM >>> output reports about fatal error. JVM exit with code " + returnCode >>> + "!"); >>> >>> The message isn't grammatically correct: about -> a; exit -> exited >>> >>> Similarly "JVM exit" -> "JVM exited" >>> >>> 377 failedMessage(name, fullOptionString, valid, >>> "JVM output not contains " >>> >>> not contains -> does not contain >>> >>> 400 * Return list of strings which contain options with valid >>> values which used >>> >>> which used -> which can be used >>> >>> 416 * Return list of strings which contain options with >>> invalid values which >>> 417 * used for testing on command line >>> >>> Ditto >>> >>> --- >>> >>> test/runtime/CommandLine/OptionsValidation/common/optionsvalidation/JVMOptionsUtils.java >>> >>> >>> 101 * Add dependency for option depending on it's type. E.g. >>> ran java in >>> >>> ran java -> run the JVM >>> >>> 119 * @param withRanges true if needed options with defined ranges >>> >>> I'm not sure what this means. Occurs elswhere too. >>> >>> 121 * "product", "diagnostic" etc. Accept option only if >>> acceptOrigin return >>> >>> return -> returns (or even return -> evaluates). Occurs elsewhere too. >>> >>> 260 * methods. Tested only writeable options. >>> >>> Suggestion: Only tests writeable options. Occurs elsewhere too. >>> >>> 264 * @throws Exception >>> >>> When? Why? Occurs elsewhere too. >>> >>> Thanks, >>> David >>> ----- >>> >>>> Thanks, >>>> Dmitry >>>> >>>> >>>> On 21.05.2015 23:57, Dmitry Dmitriev wrote: >>>>> Hello all, >>>>> >>>>> Recently I correct several typos, so here a new webrev for tests: >>>>> http://cr.openjdk.java.net/~ddmitriev/8059557/webrev.02/ >>>>> >>>>> >>>>> Thanks, >>>>> Dmitry >>>>> >>>>> On 18.05.2015 18:48, Dmitry Dmitriev wrote: >>>>>> Hello all, >>>>>> >>>>>> Please review test set for verifying functionality implemented by >>>>>> JEP >>>>>> 245 "Validate JVM Command-Line Flag Arguments"(JDK-8059557). Review >>>>>> request for this JEP can be found there: >>>>>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-May/018539.html >>>>>> >>>>>> >>>>>> I create 3 tests for verifying options with ranges. The tests mostly >>>>>> rely on common/optionsvalidation/JVMOptionsUtils.java. Class in this >>>>>> file contains functions to get options with ranges as list(by >>>>>> parsing >>>>>> new option "-XX:+PrintFlagsRanges" output), run command line test >>>>>> for >>>>>> list of options and other. The actual test code contained in >>>>>> common/optionsvalidation/JVMOption.java file - testCommandLine(), >>>>>> testDynamic(), testJcmd() and testAttach() methods. >>>>>> common/optionsvalidation/IntJVMOption.java and >>>>>> common/optionsvalidation/DoubleJVMOption.java source files contain >>>>>> classes derived from JVMOption class for integer and double JVM >>>>>> options correspondingly. >>>>>> >>>>>> Here are description of the tests: >>>>>> 1) >>>>>> hotspot/test/runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java >>>>>> >>>>>> >>>>>> >>>>>> This test get all options with ranges by parsing output of new >>>>>> option >>>>>> "-XX:+PrintFlagsRanges" and verify these options by starting Java >>>>>> and >>>>>> passing options in command line with valid and invalid values. >>>>>> Currently it verifies about 106 options which have ranges. >>>>>> Invalid values are values which out-of-range. In test used values >>>>>> "min-1" and "max+1".In this case Java should always exit with code 1 >>>>>> and print error message about out-of-range value(with one exception, >>>>>> if option is unsigned and passing negative value, then out-of-range >>>>>> error message is not printed because error occurred earlier). >>>>>> Valid values are values in range, e.g. min&max and also several >>>>>> additional values. In this case Java should successfully exit(exit >>>>>> code 0) or exit with error code 1 for other reasons(low memory with >>>>>> certain option value etc.). In any case for values in range Java >>>>>> should not print messages about out of range value. >>>>>> In any case Java should not crash. >>>>>> This test excluded from JPRT because it takes long time to execute >>>>>> and also fails - some options with value in valid range cause >>>>>> Java to >>>>>> crash(bugs are submitted). >>>>>> >>>>>> 2) >>>>>> hotspot/test/runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java >>>>>> >>>>>> >>>>>> >>>>>> This test get all writeable options with ranges by parsing output of >>>>>> new option "-XX:+PrintFlagsRanges" and verify these options by >>>>>> dynamically changing it's values to the valid and invalid values. >>>>>> Used 3 methods for that: DynamicVMOption isValidValue and >>>>>> isInvalidValue methods, Jcmd and by attach method. Currently 3 >>>>>> writeable options with ranges are verified by this test. >>>>>> This test pass in JPRT. >>>>>> >>>>>> 3) >>>>>> hotspot/test/runtime/CommandLine/OptionsValidation/TestJcmdOutput.java >>>>>> >>>>>> >>>>>> This test verified output of Jcmd when out-of-range value is set to >>>>>> the writeable option or value violates option constraint. Also this >>>>>> test verify that jcmd not write error message to the target process. >>>>>> This test pass in JPRT. >>>>>> >>>>>> >>>>>> I am not write special tests for constraints for this JEP because >>>>>> there are exist test for that(e.g. >>>>>> test/runtime/CompressedOops/ObjectAlignment.java for >>>>>> ObjectAlignmentInBytes or >>>>>> hotspot/test/gc/arguments/TestHeapFreeRatio.java for >>>>>> MinHeapFreeRatio/MaxHeapFreeRatio). >>>>>> >>>>>> Webrev: http://cr.openjdk.java.net/~ddmitriev/8059557/webrev.00/ >>>>>> >>>>>> >>>>>> JEP: https://bugs.openjdk.java.net/browse/JDK-8059557 >>>>>> >>>>>> Thanks, >>>>>> Dmitry >>>>>> >>>>> >>>> >> > From dmitry.dmitriev at oracle.com Wed Jun 17 15:14:08 2015 From: dmitry.dmitriev at oracle.com (Dmitry Dmitriev) Date: Wed, 17 Jun 2015 18:14:08 +0300 Subject: RFR 8059557: Test set for "Validate JVM Command-Line Flag Arguments" In-Reply-To: <55818D36.3020908@oracle.com> References: <555A09B8.7010402@oracle.com> <555E46A7.4020402@oracle.com> <55671906.10000@oracle.com> <556D3597.8090508@oracle.com> <556F0559.3080601@oracle.com> <558047AC.6040705@oracle.com> <55818D36.3020908@oracle.com> Message-ID: <55818EC0.50406@oracle.com> Hi Gerard, Thank you for review! About CICompiler - no, I not fill an issue, but I mention about that in a sub-task for compiler flags, i.e. that this flag need additional investigation. Regards, Dmitry On 17.06.2015 18:07, Gerard Ziemski wrote: > hi Dmitry, > > Please consider this reviewed (with small "r"). > > Just one quick question: is there an issue filed to followup on why > the test hangs with CICompiler and to enable it back, once we figure > it out? > > > cheers > > On 6/16/2015 10:58 AM, Dmitry Dmitriev wrote: >> Hello, >> >> Here a updated version of test set for Command Line Option >> Validation. The main changes are: added new options types - int and >> uint, added @modules, test all options with range in >> TestOptionsWithRanges.java test. >> >> Tested: JPRT >> >> Webrev: http://cr.openjdk.java.net/~ddmitriev/8059557/webrev.05/ >> >> Webrev incremental(from 04): >> http://cr.openjdk.java.net/~ddmitriev/8059557/webrev.05.incremental/ >> >> JEP: https://bugs.openjdk.java.net/browse/JDK-8059557 >> >> Thanks, >> Dmitry >> >> On 03.06.2015 16:47, Dmitry Dmitriev wrote: >>> Hello David, >>> >>> Thank you for pointing on style/grammar mistakes! I corrected all of >>> them. >>> Here a link to the updated >>> webrev:http://cr.openjdk.java.net/~ddmitriev/8059557/webrev.04/ >>> >>> >>> About "options validation" package - I agree that this looks odd, >>> but if you don't mind I prefer to leave it. It slightly simplify >>> calling static methods by using static import and also I use >>> package-private access level. >>> >>> Regards, >>> Dmitry >>> >>> On 02.06.2015 7:48, David Holmes wrote: >>>> Hi Dmitry, >>>> >>>> On 28/05/2015 11:32 PM, Dmitry Dmitriev wrote: >>>>> Hello all, >>>>> >>>>> Here is a 3 version of the tests taking into account feedback from >>>>> Christian, David and Gerard. >>>>> >>>>> I limit number of options in TestOptionsWithRanges.java to 15. This >>>>> include options of different types(intx, uintx etc.) and with >>>>> different >>>>> combination of min/max range. TestOptionsWithRangesDynamic.java >>>>> leaved >>>>> as is, because amount of manageable numeric options is very small and >>>>> currently only 3 of them have range. Also, I improve code for double >>>>> option. >>>>> >>>>> Webrev: http://cr.openjdk.java.net/~ddmitriev/8059557/webrev.03/ >>>>> >>>> >>>> Only a few style/grammar nits (the downside of writing so many doc >>>> comments :) ). >>>> >>>> Meta-question: is there a specific reason to use the package >>>> "options validation"? It looks odd to me to have >>>> OptionsValidation/common/optionsvalidation/ in the paths. >>>> >>>> General doc-comment comments: >>>> - @param/@return descriptions should start with lower-case (you >>>> currently mix-n-match) >>>> - @throws description should start with "if", so: >>>> @throws IOException if an error occurred reading the data >>>> >>>> >>>> General Java-style comments: >>>> - access modifiers (public, private, protected) always come first >>>> >>>> --- >>>> >>>> test/runtime/CommandLine/OptionsValidation/common/optionsvalidation/IntJVMOption.java >>>> >>>> >>>> 265 * passed value is negative then error will be >>>> catched earlier for >>>> >>>> catched -> caught >>>> >>>> --- >>>> >>>> test/runtime/CommandLine/OptionsValidation/common/optionsvalidation/JVMOption.java >>>> >>>> >>>> 327 * @param param Tested parameter passed to the java >>>> >>>> "the java" is not a noun - suggest "the JVM" ? >>>> >>>> Maybe change Java to JVM to avoid use of "java" as a noun everywhere. >>>> >>>> 350 failedMessage(name, fullOptionString, valid, "JVM >>>> output reports about fatal error. JVM exit with code " + returnCode >>>> + "!"); >>>> >>>> The message isn't grammatically correct: about -> a; exit -> exited >>>> >>>> Similarly "JVM exit" -> "JVM exited" >>>> >>>> 377 failedMessage(name, fullOptionString, valid, >>>> "JVM output not contains " >>>> >>>> not contains -> does not contain >>>> >>>> 400 * Return list of strings which contain options with valid >>>> values which used >>>> >>>> which used -> which can be used >>>> >>>> 416 * Return list of strings which contain options with >>>> invalid values which >>>> 417 * used for testing on command line >>>> >>>> Ditto >>>> >>>> --- >>>> >>>> test/runtime/CommandLine/OptionsValidation/common/optionsvalidation/JVMOptionsUtils.java >>>> >>>> >>>> 101 * Add dependency for option depending on it's type. E.g. >>>> ran java in >>>> >>>> ran java -> run the JVM >>>> >>>> 119 * @param withRanges true if needed options with defined >>>> ranges >>>> >>>> I'm not sure what this means. Occurs elswhere too. >>>> >>>> 121 * "product", "diagnostic" etc. Accept option only if >>>> acceptOrigin return >>>> >>>> return -> returns (or even return -> evaluates). Occurs elsewhere too. >>>> >>>> 260 * methods. Tested only writeable options. >>>> >>>> Suggestion: Only tests writeable options. Occurs elsewhere too. >>>> >>>> 264 * @throws Exception >>>> >>>> When? Why? Occurs elsewhere too. >>>> >>>> Thanks, >>>> David >>>> ----- >>>> >>>>> Thanks, >>>>> Dmitry >>>>> >>>>> >>>>> On 21.05.2015 23:57, Dmitry Dmitriev wrote: >>>>>> Hello all, >>>>>> >>>>>> Recently I correct several typos, so here a new webrev for tests: >>>>>> http://cr.openjdk.java.net/~ddmitriev/8059557/webrev.02/ >>>>>> >>>>>> >>>>>> Thanks, >>>>>> Dmitry >>>>>> >>>>>> On 18.05.2015 18:48, Dmitry Dmitriev wrote: >>>>>>> Hello all, >>>>>>> >>>>>>> Please review test set for verifying functionality implemented >>>>>>> by JEP >>>>>>> 245 "Validate JVM Command-Line Flag Arguments"(JDK-8059557). Review >>>>>>> request for this JEP can be found there: >>>>>>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-May/018539.html >>>>>>> >>>>>>> >>>>>>> I create 3 tests for verifying options with ranges. The tests >>>>>>> mostly >>>>>>> rely on common/optionsvalidation/JVMOptionsUtils.java. Class in >>>>>>> this >>>>>>> file contains functions to get options with ranges as list(by >>>>>>> parsing >>>>>>> new option "-XX:+PrintFlagsRanges" output), run command line >>>>>>> test for >>>>>>> list of options and other. The actual test code contained in >>>>>>> common/optionsvalidation/JVMOption.java file - testCommandLine(), >>>>>>> testDynamic(), testJcmd() and testAttach() methods. >>>>>>> common/optionsvalidation/IntJVMOption.java and >>>>>>> common/optionsvalidation/DoubleJVMOption.java source files contain >>>>>>> classes derived from JVMOption class for integer and double JVM >>>>>>> options correspondingly. >>>>>>> >>>>>>> Here are description of the tests: >>>>>>> 1) >>>>>>> hotspot/test/runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java >>>>>>> >>>>>>> >>>>>>> >>>>>>> This test get all options with ranges by parsing output of new >>>>>>> option >>>>>>> "-XX:+PrintFlagsRanges" and verify these options by starting >>>>>>> Java and >>>>>>> passing options in command line with valid and invalid values. >>>>>>> Currently it verifies about 106 options which have ranges. >>>>>>> Invalid values are values which out-of-range. In test used values >>>>>>> "min-1" and "max+1".In this case Java should always exit with >>>>>>> code 1 >>>>>>> and print error message about out-of-range value(with one >>>>>>> exception, >>>>>>> if option is unsigned and passing negative value, then out-of-range >>>>>>> error message is not printed because error occurred earlier). >>>>>>> Valid values are values in range, e.g. min&max and also several >>>>>>> additional values. In this case Java should successfully exit(exit >>>>>>> code 0) or exit with error code 1 for other reasons(low memory with >>>>>>> certain option value etc.). In any case for values in range Java >>>>>>> should not print messages about out of range value. >>>>>>> In any case Java should not crash. >>>>>>> This test excluded from JPRT because it takes long time to execute >>>>>>> and also fails - some options with value in valid range cause >>>>>>> Java to >>>>>>> crash(bugs are submitted). >>>>>>> >>>>>>> 2) >>>>>>> hotspot/test/runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java >>>>>>> >>>>>>> >>>>>>> >>>>>>> This test get all writeable options with ranges by parsing >>>>>>> output of >>>>>>> new option "-XX:+PrintFlagsRanges" and verify these options by >>>>>>> dynamically changing it's values to the valid and invalid values. >>>>>>> Used 3 methods for that: DynamicVMOption isValidValue and >>>>>>> isInvalidValue methods, Jcmd and by attach method. Currently 3 >>>>>>> writeable options with ranges are verified by this test. >>>>>>> This test pass in JPRT. >>>>>>> >>>>>>> 3) >>>>>>> hotspot/test/runtime/CommandLine/OptionsValidation/TestJcmdOutput.java >>>>>>> >>>>>>> >>>>>>> This test verified output of Jcmd when out-of-range value is set to >>>>>>> the writeable option or value violates option constraint. Also this >>>>>>> test verify that jcmd not write error message to the target >>>>>>> process. >>>>>>> This test pass in JPRT. >>>>>>> >>>>>>> >>>>>>> I am not write special tests for constraints for this JEP because >>>>>>> there are exist test for that(e.g. >>>>>>> test/runtime/CompressedOops/ObjectAlignment.java for >>>>>>> ObjectAlignmentInBytes or >>>>>>> hotspot/test/gc/arguments/TestHeapFreeRatio.java for >>>>>>> MinHeapFreeRatio/MaxHeapFreeRatio). >>>>>>> >>>>>>> Webrev: http://cr.openjdk.java.net/~ddmitriev/8059557/webrev.00/ >>>>>>> >>>>>>> >>>>>>> JEP: https://bugs.openjdk.java.net/browse/JDK-8059557 >>>>>>> >>>>>>> Thanks, >>>>>>> Dmitry >>>>>>> >>>>>> >>>>> >>> >> > From manasthakur17 at gmail.com Wed Jun 17 16:02:44 2015 From: manasthakur17 at gmail.com (Manas Thakur) Date: Wed, 17 Jun 2015 21:32:44 +0530 Subject: How is stack-trace constructed? In-Reply-To: References: Message-ID: Typo: By call sites of a method, I meant the whole call stack of the method. > On 17-Jun-2015, at 4:25 pm, Manas Thakur wrote: > > Hello all > > Whenever an exception is thrown at runtime, we get the full stack-trace, listing all the call sites of the method. This is possible irrespective of whether the method enclosing exception site is compiled by C1 or C2, or interpreted. Can someone help me out in finding the data structures that store this call-site information? > > Regards, > Manas From karen.kinnear at oracle.com Wed Jun 17 17:01:58 2015 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Wed, 17 Jun 2015 13:01:58 -0400 Subject: CFV: New HotSpot Group Lead: Vladimir Kozlov In-Reply-To: References: Message-ID: <4E5792C5-4C7C-45C6-8A46-7E156BD0E1FD@oracle.com> Vote: yes thanks, Karen On Jun 15, 2015, at 12:56 PM, Christian Thalinger wrote: > I hereby nominate Vladimir Kozlov to HotSpot Group Lead [1]. > > Vladimir is a member of the HotSpot Group since OpenJDK was > established, is working on the HotSpot JVM for more than 12 years > and is well known in the HotSpot OpenJDK community. > > Votes are due by June 26, 2015 12:00 PST. > > Only current Members of the HotSpot Group [2] are eligible to > vote on this nomination. Votes must be cast in the open by > replying to this mailing list. > > For Simple Majority voting instructions, see [3]. > > Thanks, > Christian Thalinger > > [1]: http://openjdk.java.net/bylaws#group-lead > [2]: http://openjdk.java.net/census#hotspot > [3]: http://openjdk.java.net/groups#lead-vote From anthony.scarpino at oracle.com Wed Jun 17 17:40:43 2015 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Wed, 17 Jun 2015 10:40:43 -0700 Subject: RFR: 8073108: GHASH Intrinsics [need second reviewer] In-Reply-To: References: <54E25D03.7090705@oracle.com> <5579CD0E.2070801@oracle.com> <557B5A47.5090008@oracle.com> <557F5F14.70709@oracle.com> Message-ID: <5581B11B.3050903@oracle.com> On 06/15/2015 05:20 PM, John Rose wrote: > Thanks for taking this on. > > It looks good, except for one thing. The intrinsic does not need to be > an instance method, and doing so creates an undesirable coupling between > the JVM and JDK. Specifically, the JDK should not need to know about > subkeyH and state fields. The Java code should pass those as plain > (array long[2]) arguments to the intrinsic method processBlocks, which > should be adjusted to be static. The domain check routine should be > adjusted to be static also. > > On my wish list for the future (but not now) is even less coupling > with the JVM. The loop code for processBlocks should be written in Java, > with various intrinsics (xmulx*) for dealing with single operations on > 128-bit values (stored in long[2] boxes and 64-bit registers). I forgot the exact numbers, but having the loop in assembly instead of java resulted in about 10-15% performance improvement. The tighter loop was definitely beneficial. > The > Unsafe misaligned access routines could help simplify this also, if the > coding were done in Java. This is not too hard to express in Java and > compile to excellent code. There will be a little extra awkwardness > working with 64x2-vectors in a way that will compile naturally to a > range of ALUs (both 64- and 128-bit). I would have to look back at that again.. At first I was going to use Unsafe, but it seemed more complicated coding-wise compared to the assembly I saw that was in AES and SHA already. > If we get it right we can reduce > the amount of assembly code in the JVM and get even more timely access > to new data-processing instructions. Would you please file a followup > bug (low pri. for now) to track this, at least for GHASH and other > crypto loops? > > ? John Sure, I can file them. Tony From stefan.karlsson at oracle.com Wed Jun 17 17:59:51 2015 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Wed, 17 Jun 2015 19:59:51 +0200 Subject: RFR: 8087322: Implement a Semaphore utility class In-Reply-To: <557F3582.6060401@oracle.com> References: <557AF8E4.9040804@oracle.com> <557F3582.6060401@oracle.com> Message-ID: <5581B597.5080900@oracle.com> Hi again, Here's a version that gets rid of the max parameter: http://cr.openjdk.java.net/~stefank/8087322/webrev.02.delta http://cr.openjdk.java.net/~stefank/8087322/webrev.02 The patch also contains a few minor cleanups and removes the redundant BsdSemaphore::trywait(), which is already defined in PosixSemaphore. Thanks, StefanK On 2015-06-15 22:28, Stefan Karlsson wrote: > Hi again, > > I've hopefully addressed some of Kim's and David's concerns with the > following version: > > http://cr.openjdk.java.net/~stefank/8087322/webrev.01.delta/ > http://cr.openjdk.java.net/~stefank/8087322/webrev.01/ > > Changes in the current version of the patch: > > - Created a POSIX version that is used by Linux and Solaris (and maybe > AIX?). > > - Use asserts instead of guarantees. (I've got offline feedback that > others preferred at least some of the guarantees.) > > - Print the errno value and the errno string in the posix version > > - Removed trywait and timedwait from the Semaphore class and added > that functionality in platform-specific semaphore classes. This gets > rid of the Unimplemented() functions in os_windows.cpp. > > - I removed the IMPLEMENTS_SEMAPHORE_CLASS define. > > Some comments about the current patch: > > - I have not removed the 'max' parameter, since I haven't yet figured > out what the max value should be used for windows. > > - OS X doesn't implement unamed POSIX semaphores, so I have to go > through hoops to compile out the POXIS version when building on OS X. > > - I had to add -lrt to get the patch to link on Solaris. > > Tested with JPRT, > > Thanks, > StefanK > > On 2015-06-12 17:21, Stefan Karlsson wrote: >> Hi all, >> >> Please review this patch to create a Semaphore utility class. I need >> this class to implementing faster GC thread synchronization [1]. >> >> http://cr.openjdk.java.net/~stefank/8087322/webrev.00/ >> https://bugs.openjdk.java.net/browse/JDK-8087322 >> >> Some of our platforms already implement a Semaphore class, but those >> classes are hidden inside os_.cpp. I've moved the class >> declaration to semaphore.hpp, but the implementation is left in the >> os_.hpp. I considered creating semaphore_.cpp files, but I >> ended up having to restructure too much code and I wanted to focus on >> the feature in [1] instead. Should I create a RFE to move the >> semaphore implementations? >> >> There seems to be another opportunity to cleanup the code. If we take >> os_linux.cpp, as an example, the code uses both the existing >> Semaphore class and the global ::sem_wait and ::sem_post functions. >> We might want to consider unifying that code. >> >> Since HotSpot is built on platforms that I don't have access to and >> can't test, I've added the IMPLEMENTS_SEMAPHORE_CLASS define. So, >> that I can detect if the the current platform implements the >> Semaphore class, and choose what synchronization primitive to use by >> the GC. >> >> The os_bsd.cpp file has support for "non-apple BSD", but I've only >> tested this patch with OS X. >> >> This patch has been tested in JPRT and our nightly testing together >> with the patches in [1]. The patch also contains a few unit tests in >> semaphore.cpp. >> >> Thanks, >> StefanK >> >> [1] >> http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2015-June/013829.html > From john.r.rose at oracle.com Wed Jun 17 18:40:22 2015 From: john.r.rose at oracle.com (John Rose) Date: Wed, 17 Jun 2015 11:40:22 -0700 Subject: RFR: 8073108: GHASH Intrinsics [need second reviewer] In-Reply-To: <5581B11B.3050903@oracle.com> References: <54E25D03.7090705@oracle.com> <5579CD0E.2070801@oracle.com> <557B5A47.5090008@oracle.com> <557F5F14.70709@oracle.com> <5581B11B.3050903@oracle.com> Message-ID: On Jun 17, 2015, at 10:40 AM, Anthony Scarpino wrote: > > On 06/15/2015 05:20 PM, John Rose wrote: >> Thanks for taking this on. >> >> It looks good, except for one thing. The intrinsic does not need to be >> an instance method, and doing so creates an undesirable coupling between >> the JVM and JDK. Specifically, the JDK should not need to know about >> subkeyH and state fields. The Java code should pass those as plain >> (array long[2]) arguments to the intrinsic method processBlocks, which >> should be adjusted to be static. The domain check routine should be >> adjusted to be static also. >> >> On my wish list for the future (but not now) is even less coupling >> with the JVM. The loop code for processBlocks should be written in Java, >> with various intrinsics (xmulx*) for dealing with single operations on >> 128-bit values (stored in long[2] boxes and 64-bit registers). > > I forgot the exact numbers, but having the loop in assembly instead of java resulted in about 10-15% performance improvement. The tighter loop was definitely beneficial. That's good information; please put it in the RFE. IMO the best (overall) way to get that 10-15% back is to get the JIT to tighten the loop. If that works, it will of course benefit all Java loops. > The >> Unsafe misaligned access routines could help simplify this also, if the >> coding were done in Java. This is not too hard to express in Java and >> compile to excellent code. There will be a little extra awkwardness >> working with 64x2-vectors in a way that will compile naturally to a >> range of ALUs (both 64- and 128-bit). > > I would have to look back at that again.. At first I was going to use Unsafe, but it seemed more complicated coding-wise compared to the assembly I saw that was in AES and SHA already. Yes; that makes perfect sense. I want to get to the place, eventually, when the next coder looks at how "stuff gets done", they will see less assembly and more Java, and take the Java route. > >> If we get it right we can reduce >> the amount of assembly code in the JVM and get even more timely access >> to new data-processing instructions. Would you please file a followup >> bug (low pri. for now) to track this, at least for GHASH and other >> crypto loops? >> >> ? John > > Sure, I can file them. Good; thanks. ? John From dmitry.dmitriev at oracle.com Wed Jun 17 19:29:36 2015 From: dmitry.dmitriev at oracle.com (Dmitry Dmitriev) Date: Wed, 17 Jun 2015 22:29:36 +0300 Subject: RFR 8059557: Test set for "Validate JVM Command-Line Flag Arguments" In-Reply-To: <55818D36.3020908@oracle.com> References: <555A09B8.7010402@oracle.com> <555E46A7.4020402@oracle.com> <55671906.10000@oracle.com> <556D3597.8090508@oracle.com> <556F0559.3080601@oracle.com> <558047AC.6040705@oracle.com> <55818D36.3020908@oracle.com> Message-ID: <5581CAA0.8010606@oracle.com> Hi Gerard, Can you please look at small enhancement that I made by Christian suggestion - ran test JVM with the same type as current(for all cases, not only for "-client" as in 06 webrev). Tested by JPRT. Sorry for confusion. Thank you! Webrev: http://cr.openjdk.java.net/~ddmitriev/8059557/webrev.07/ Webrev incremental(from 06): http://cr.openjdk.java.net/~ddmitriev/8059557/webrev.07.incremental.from06/ Regards, Dmitry On 17.06.2015 18:07, Gerard Ziemski wrote: > hi Dmitry, > > Please consider this reviewed (with small "r"). > > Just one quick question: is there an issue filed to followup on why > the test hangs with CICompiler and to enable it back, once we figure > it out? > > > cheers > > On 6/16/2015 10:58 AM, Dmitry Dmitriev wrote: >> Hello, >> >> Here a updated version of test set for Command Line Option >> Validation. The main changes are: added new options types - int and >> uint, added @modules, test all options with range in >> TestOptionsWithRanges.java test. >> >> Tested: JPRT >> >> Webrev: http://cr.openjdk.java.net/~ddmitriev/8059557/webrev.05/ >> >> Webrev incremental(from 04): >> http://cr.openjdk.java.net/~ddmitriev/8059557/webrev.05.incremental/ >> >> JEP: https://bugs.openjdk.java.net/browse/JDK-8059557 >> >> Thanks, >> Dmitry >> >> On 03.06.2015 16:47, Dmitry Dmitriev wrote: >>> Hello David, >>> >>> Thank you for pointing on style/grammar mistakes! I corrected all of >>> them. >>> Here a link to the updated >>> webrev:http://cr.openjdk.java.net/~ddmitriev/8059557/webrev.04/ >>> >>> >>> About "options validation" package - I agree that this looks odd, >>> but if you don't mind I prefer to leave it. It slightly simplify >>> calling static methods by using static import and also I use >>> package-private access level. >>> >>> Regards, >>> Dmitry >>> >>> On 02.06.2015 7:48, David Holmes wrote: >>>> Hi Dmitry, >>>> >>>> On 28/05/2015 11:32 PM, Dmitry Dmitriev wrote: >>>>> Hello all, >>>>> >>>>> Here is a 3 version of the tests taking into account feedback from >>>>> Christian, David and Gerard. >>>>> >>>>> I limit number of options in TestOptionsWithRanges.java to 15. This >>>>> include options of different types(intx, uintx etc.) and with >>>>> different >>>>> combination of min/max range. TestOptionsWithRangesDynamic.java >>>>> leaved >>>>> as is, because amount of manageable numeric options is very small and >>>>> currently only 3 of them have range. Also, I improve code for double >>>>> option. >>>>> >>>>> Webrev: http://cr.openjdk.java.net/~ddmitriev/8059557/webrev.03/ >>>>> >>>> >>>> Only a few style/grammar nits (the downside of writing so many doc >>>> comments :) ). >>>> >>>> Meta-question: is there a specific reason to use the package >>>> "options validation"? It looks odd to me to have >>>> OptionsValidation/common/optionsvalidation/ in the paths. >>>> >>>> General doc-comment comments: >>>> - @param/@return descriptions should start with lower-case (you >>>> currently mix-n-match) >>>> - @throws description should start with "if", so: >>>> @throws IOException if an error occurred reading the data >>>> >>>> >>>> General Java-style comments: >>>> - access modifiers (public, private, protected) always come first >>>> >>>> --- >>>> >>>> test/runtime/CommandLine/OptionsValidation/common/optionsvalidation/IntJVMOption.java >>>> >>>> >>>> 265 * passed value is negative then error will be >>>> catched earlier for >>>> >>>> catched -> caught >>>> >>>> --- >>>> >>>> test/runtime/CommandLine/OptionsValidation/common/optionsvalidation/JVMOption.java >>>> >>>> >>>> 327 * @param param Tested parameter passed to the java >>>> >>>> "the java" is not a noun - suggest "the JVM" ? >>>> >>>> Maybe change Java to JVM to avoid use of "java" as a noun everywhere. >>>> >>>> 350 failedMessage(name, fullOptionString, valid, "JVM >>>> output reports about fatal error. JVM exit with code " + returnCode >>>> + "!"); >>>> >>>> The message isn't grammatically correct: about -> a; exit -> exited >>>> >>>> Similarly "JVM exit" -> "JVM exited" >>>> >>>> 377 failedMessage(name, fullOptionString, valid, >>>> "JVM output not contains " >>>> >>>> not contains -> does not contain >>>> >>>> 400 * Return list of strings which contain options with valid >>>> values which used >>>> >>>> which used -> which can be used >>>> >>>> 416 * Return list of strings which contain options with >>>> invalid values which >>>> 417 * used for testing on command line >>>> >>>> Ditto >>>> >>>> --- >>>> >>>> test/runtime/CommandLine/OptionsValidation/common/optionsvalidation/JVMOptionsUtils.java >>>> >>>> >>>> 101 * Add dependency for option depending on it's type. E.g. >>>> ran java in >>>> >>>> ran java -> run the JVM >>>> >>>> 119 * @param withRanges true if needed options with defined >>>> ranges >>>> >>>> I'm not sure what this means. Occurs elswhere too. >>>> >>>> 121 * "product", "diagnostic" etc. Accept option only if >>>> acceptOrigin return >>>> >>>> return -> returns (or even return -> evaluates). Occurs elsewhere too. >>>> >>>> 260 * methods. Tested only writeable options. >>>> >>>> Suggestion: Only tests writeable options. Occurs elsewhere too. >>>> >>>> 264 * @throws Exception >>>> >>>> When? Why? Occurs elsewhere too. >>>> >>>> Thanks, >>>> David >>>> ----- >>>> >>>>> Thanks, >>>>> Dmitry >>>>> >>>>> >>>>> On 21.05.2015 23:57, Dmitry Dmitriev wrote: >>>>>> Hello all, >>>>>> >>>>>> Recently I correct several typos, so here a new webrev for tests: >>>>>> http://cr.openjdk.java.net/~ddmitriev/8059557/webrev.02/ >>>>>> >>>>>> >>>>>> Thanks, >>>>>> Dmitry >>>>>> >>>>>> On 18.05.2015 18:48, Dmitry Dmitriev wrote: >>>>>>> Hello all, >>>>>>> >>>>>>> Please review test set for verifying functionality implemented >>>>>>> by JEP >>>>>>> 245 "Validate JVM Command-Line Flag Arguments"(JDK-8059557). Review >>>>>>> request for this JEP can be found there: >>>>>>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-May/018539.html >>>>>>> >>>>>>> >>>>>>> I create 3 tests for verifying options with ranges. The tests >>>>>>> mostly >>>>>>> rely on common/optionsvalidation/JVMOptionsUtils.java. Class in >>>>>>> this >>>>>>> file contains functions to get options with ranges as list(by >>>>>>> parsing >>>>>>> new option "-XX:+PrintFlagsRanges" output), run command line >>>>>>> test for >>>>>>> list of options and other. The actual test code contained in >>>>>>> common/optionsvalidation/JVMOption.java file - testCommandLine(), >>>>>>> testDynamic(), testJcmd() and testAttach() methods. >>>>>>> common/optionsvalidation/IntJVMOption.java and >>>>>>> common/optionsvalidation/DoubleJVMOption.java source files contain >>>>>>> classes derived from JVMOption class for integer and double JVM >>>>>>> options correspondingly. >>>>>>> >>>>>>> Here are description of the tests: >>>>>>> 1) >>>>>>> hotspot/test/runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java >>>>>>> >>>>>>> >>>>>>> >>>>>>> This test get all options with ranges by parsing output of new >>>>>>> option >>>>>>> "-XX:+PrintFlagsRanges" and verify these options by starting >>>>>>> Java and >>>>>>> passing options in command line with valid and invalid values. >>>>>>> Currently it verifies about 106 options which have ranges. >>>>>>> Invalid values are values which out-of-range. In test used values >>>>>>> "min-1" and "max+1".In this case Java should always exit with >>>>>>> code 1 >>>>>>> and print error message about out-of-range value(with one >>>>>>> exception, >>>>>>> if option is unsigned and passing negative value, then out-of-range >>>>>>> error message is not printed because error occurred earlier). >>>>>>> Valid values are values in range, e.g. min&max and also several >>>>>>> additional values. In this case Java should successfully exit(exit >>>>>>> code 0) or exit with error code 1 for other reasons(low memory with >>>>>>> certain option value etc.). In any case for values in range Java >>>>>>> should not print messages about out of range value. >>>>>>> In any case Java should not crash. >>>>>>> This test excluded from JPRT because it takes long time to execute >>>>>>> and also fails - some options with value in valid range cause >>>>>>> Java to >>>>>>> crash(bugs are submitted). >>>>>>> >>>>>>> 2) >>>>>>> hotspot/test/runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java >>>>>>> >>>>>>> >>>>>>> >>>>>>> This test get all writeable options with ranges by parsing >>>>>>> output of >>>>>>> new option "-XX:+PrintFlagsRanges" and verify these options by >>>>>>> dynamically changing it's values to the valid and invalid values. >>>>>>> Used 3 methods for that: DynamicVMOption isValidValue and >>>>>>> isInvalidValue methods, Jcmd and by attach method. Currently 3 >>>>>>> writeable options with ranges are verified by this test. >>>>>>> This test pass in JPRT. >>>>>>> >>>>>>> 3) >>>>>>> hotspot/test/runtime/CommandLine/OptionsValidation/TestJcmdOutput.java >>>>>>> >>>>>>> >>>>>>> This test verified output of Jcmd when out-of-range value is set to >>>>>>> the writeable option or value violates option constraint. Also this >>>>>>> test verify that jcmd not write error message to the target >>>>>>> process. >>>>>>> This test pass in JPRT. >>>>>>> >>>>>>> >>>>>>> I am not write special tests for constraints for this JEP because >>>>>>> there are exist test for that(e.g. >>>>>>> test/runtime/CompressedOops/ObjectAlignment.java for >>>>>>> ObjectAlignmentInBytes or >>>>>>> hotspot/test/gc/arguments/TestHeapFreeRatio.java for >>>>>>> MinHeapFreeRatio/MaxHeapFreeRatio). >>>>>>> >>>>>>> Webrev: http://cr.openjdk.java.net/~ddmitriev/8059557/webrev.00/ >>>>>>> >>>>>>> >>>>>>> JEP: https://bugs.openjdk.java.net/browse/JDK-8059557 >>>>>>> >>>>>>> Thanks, >>>>>>> Dmitry >>>>>>> >>>>>> >>>>> >>> >> > From anthony.scarpino at oracle.com Wed Jun 17 22:31:44 2015 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Wed, 17 Jun 2015 15:31:44 -0700 Subject: RFR: 8073108: GHASH Intrinsics [need second reviewer] In-Reply-To: References: <54E25D03.7090705@oracle.com> <5579CD0E.2070801@oracle.com> <557B5A47.5090008@oracle.com> <557F5F14.70709@oracle.com> Message-ID: <5581F550.3080403@oracle.com> On 06/15/2015 05:20 PM, John Rose wrote: > Thanks for taking this on. > > It looks good, except for one thing. The intrinsic does not need to > be an instance method, and doing so creates an undesirable coupling > between the JVM and JDK. Specifically, the JDK should not need to > know about subkeyH and state fields. The Java code should pass those > as plain (array long[2]) arguments to the intrinsic method > processBlocks, which should be adjusted to be static. The domain > check routine should be adjusted to be static also. > Hi John, the updated webrevs are at: http://cr.openjdk.java.net/~ascarpino/8073108/hotspot/webrev.04/ http://cr.openjdk.java.net/~ascarpino/8073108/jdk/webrev.04/ thanks Tony From john.r.rose at oracle.com Wed Jun 17 23:06:40 2015 From: john.r.rose at oracle.com (John Rose) Date: Wed, 17 Jun 2015 16:06:40 -0700 Subject: RFR: 8073108: GHASH Intrinsics [need second reviewer] In-Reply-To: <5581F550.3080403@oracle.com> References: <54E25D03.7090705@oracle.com> <5579CD0E.2070801@oracle.com> <557B5A47.5090008@oracle.com> <557F5F14.70709@oracle.com> <5581F550.3080403@oracle.com> Message-ID: Thumbs up. Thanks! ? John On Jun 17, 2015, at 3:31 PM, Anthony Scarpino wrote: > > On 06/15/2015 05:20 PM, John Rose wrote: >> Thanks for taking this on. >> >> It looks good, except for one thing. The intrinsic does not need to >> be an instance method, and doing so creates an undesirable coupling >> between the JVM and JDK. Specifically, the JDK should not need to >> know about subkeyH and state fields. The Java code should pass those >> as plain (array long[2]) arguments to the intrinsic method >> processBlocks, which should be adjusted to be static. The domain >> check routine should be adjusted to be static also. >> > > Hi John, > > the updated webrevs are at: > http://cr.openjdk.java.net/~ascarpino/8073108/hotspot/webrev.04/ > http://cr.openjdk.java.net/~ascarpino/8073108/jdk/webrev.04/ > > thanks > > Tony > From vladimir.kozlov at oracle.com Wed Jun 17 23:40:37 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 17 Jun 2015 16:40:37 -0700 Subject: RFR: 8073108: GHASH Intrinsics [need second reviewer] In-Reply-To: <5581F550.3080403@oracle.com> References: <54E25D03.7090705@oracle.com> <5579CD0E.2070801@oracle.com> <557B5A47.5090008@oracle.com> <557F5F14.70709@oracle.com> <5581F550.3080403@oracle.com> Message-ID: <55820575.3040706@oracle.com> Looks good to me too. Please, push into jdk9/hs-comp so we get testing of intrinsic in Hotspot nightly testing. Thanks, Vladimir On 6/17/15 3:31 PM, Anthony Scarpino wrote: > On 06/15/2015 05:20 PM, John Rose wrote: >> Thanks for taking this on. >> >> It looks good, except for one thing. The intrinsic does not need to >> be an instance method, and doing so creates an undesirable coupling >> between the JVM and JDK. Specifically, the JDK should not need to >> know about subkeyH and state fields. The Java code should pass those >> as plain (array long[2]) arguments to the intrinsic method >> processBlocks, which should be adjusted to be static. The domain >> check routine should be adjusted to be static also. >> > > Hi John, > > the updated webrevs are at: > http://cr.openjdk.java.net/~ascarpino/8073108/hotspot/webrev.04/ > http://cr.openjdk.java.net/~ascarpino/8073108/jdk/webrev.04/ > > thanks > > Tony > From david.holmes at oracle.com Thu Jun 18 04:31:04 2015 From: david.holmes at oracle.com (David Holmes) Date: Thu, 18 Jun 2015 14:31:04 +1000 Subject: RFR [S] 8081406: cleanup and minor extensions of the debugging facilities in CodeStrings In-Reply-To: <558154D4.8090405@oracle.com> References: <55674A24.4050501@oracle.com> <5580D094.8060803@oracle.com> <558154D4.8090405@oracle.com> Message-ID: <55824988.2030109@oracle.com> On 17/06/2015 9:07 PM, Bertrand Delsart wrote: > Thanks David, > > Updated webrev. See below my inlined comments for additional > explanations on the changes. > > http://cr.openjdk.java.net/~bdelsart/8081406/webrev.01/ > > This is a subset of the previous changes: > - free was reverted to its initial definition but its behavior > is now clearly documented (e.g. the fact that it must invalidate > the object since this was David's concern) Okay. I guess there's no point discussing things no longer changed, so as long as this works you. > - assign is nearly reverted too but still ensures _defunct is set Yep - sorry I got my _defunct comment completely backwards. Doh. Looks good. Thanks, David > Regards, > > Bertrand. > > On 17/06/2015 03:42, David Holmes wrote: >> Hi Bertrand, >> >> On 29/05/2015 3:02 AM, Bertrand Delsart wrote: >>> Hi all, >>> >>> Small RFR to address minor issues in debug mode with CodeStrings >> >> Not something I'm familiar with so I may be missing some things here. >> >>> https://bugs.openjdk.java.net/browse/JDK-8081406 >>> http://cr.openjdk.java.net/~bdelsart/8081406/webrev.00/ >>> >>> The change does not impact the product mode. >> >> So the initialization of CodeBlob::_strings and >> CodeBuffer::_code_strings does happen in product mode as well, but the >> resulting CodeStrings object does nothing. Suggests to me that *_strings >> should be a non-product field only (but that's an aside to this set of >> changes). >> >> src/share/vm/asm/codeBuffer.hpp >> >> The ifdef style in this file is quite awful IMO but the changes are >> consistent with it. >> >> 308 // FREE strings; invalidate if contains non comment strings. >> >> if -> if it > > OK. > > [ Will in fact just be "invalidate this" due to your other feedback ] > >> >> --- >> >> src/share/vm/asm/codeBuffer.cpp >> >> 1105 *this = other; // copy all fields (including _defunct when it >> exists) >> >> I can see the need to free() the existing CodeStrings if present, but >> otherwise why does the original logic need to change from: >> >> _strings = other._strings; >> _other.set_null_and_invalidate(); >> >> to the somewhat cryptic: >> >> *this = other; >> other.set_null_and_invalidate(); >> >> I'm not even certain what that assignment will do. It's also not clear >> why _defunct needs to be copied over rather than just being set to true >> (as _other can't have _defunct==false as we already called >> check_valid() ). > > First, the fields declared in CodeStrings depends on several ifdefs > (ASSERT and PRODUCT). "*this=" is a way to avoid the "awful ifdef style" > :-) > > In addition, this is slightly more robust IMHO. For instance, it makes > the assignment copy independent of the internals of CodeStrings. In > particular, _defunct would have to be set to false, not true :-) > > Now, I did check that this had not lead to issue in JPRT and with other > test in debug mode, including on exotic platforms, but it is impossible > to prove that all C++ compilers will handle correctly "*this=" which > should just be an assignment copy between two C++ objects (and a NOP in > product mode, where the CodeStrings are of size 0). > > Since this RFR is blocking later pushes, I'll avoid further delays and > replace > *this = other > by : > _strings = other._strings > #ifdef ASSERT > _defunct = false; > #endif > >> The change of semantics of free() does make me concerned whether >> existing uses of it now have their assumptions invalidated? It isn't >> clear to me why you would want to free() something but retain validity - >> more of a clear()/reset() operation. But then I don't understand the >> significance of comment versus non-comment with regards to validity ?? > > I see your concern about free(). To make that clearer, I added > explicitly next to the declaration of free the fact that it invalidates > the buffer. > > My change was initially due to closed code in JDK-8087333 (an RFE > concurrently being reviewed). Extending the meaning of _valid had > allowed the closed code to be cleaner and more robust, catching errors > in the handling on non-comment strings (see below) but this may no > longer be necessary. I'll look for an alternate solution if needed (for > instance adding a new clear() method; thanks for the suggestion). > > Reverting free() in the current webrev means I'll also remove from > CodeStrings::assign the > > + if (!is_null()) { > + // The assignment replaces the old content. > + // Delete old CodeStrings, invalidating it if there are non-comment > + // strings. > + free(); > + check_valid(); // else the container may reference freed strings > + } > > and add back the > > - assert(is_null(), "Cannot assign onto non-empty CodeStrings"); > > FYI, some information on the comment versus non-comment. > > Non-comment strings in CodeStrings are (currently) used only in for > debug functionalities (verify_oop, unimplemented, untested, ...) but > they are necessary to correctly report errors. If deleted, the VM may > crash when trying to print a debug message. Since CodeStrings are > embedded into a CodeBlob container, marking the CodeStrings invalid when > freed allowed to detect that the CodeBlob was no longer valid. On the > other hand, a comment string is something which is not necessary for > correct execution. It is only used when dumping the code. > > Removing a comment from a CodeStrings has no impact on the execution of > the Java application... and freeing them was the most efficient way to > handle them for JDK-8087333. My change allowed to detect as a side > effect of the free whether we had safely deleted only comments or > whether there was a non-comment string that had not been properly > handled. As stated above, I'll look for an alternative to provide the > same robustness without impacting the existing methods, avoiding all risks. > > Regards, > > Bertrand. > >> >> Thanks, >> David >> >>> In non product mode, CodeStrings allows to associate a linked list of >>> strings to a CodeBuffer, CodeBlob or Stub. In addition, with ASSERTS, it >>> defines a boolean asserting whether the list of strings are valid. >> >> >> >>> Here are the issues addressed by this CR: >>> >>> - The old code mentioned the fact that CodeStrings was not always >>> correctly initialized. This is addressed by the fix, allowing >>> check_valid to be added at a few locations where it could currently >>> failed due to uninitialized values (like at the beginning of >>> CodeStrings::free). This also makes the code more robust against future >>> versions of CodeStrings. >>> >>> - As a minor extension, it is now possible for platform dependent code >>> to modify the comment separator used by print_block_comment, which was >>> hard coded to " ;; ". >>> >>> - As another minor extension, related to the validity assertions, >>> freeing a code string no longer necessarily marks it (and hence its >>> Stub/CodeBlob/CodeBuffer) as invalid. If CodeStrings contains only >>> comment, removing them does not change the validity of the CodeStrings. >>> For similar reason, assignment over a non null CodeStrings is now valid >>> when we can safely free the old string. >>> >>> The modified code passes JPRT. It was also validated in fastdebug mode >>> with the vm.compiler.testlist to check that the validity assertion were >>> not triggered. One of our closed extensions also validated advanced use >>> of CodeStrings::assign (included cases where the target of the >>> assignment was not free). >>> >>> Best regards, >>> >>> Bertrand. >>> > > From david.holmes at oracle.com Thu Jun 18 07:40:04 2015 From: david.holmes at oracle.com (David Holmes) Date: Thu, 18 Jun 2015 17:40:04 +1000 Subject: [verona.stage] RFR 8087203: Add support for PATCH field and remove unused fields of new version string In-Reply-To: <5580A953.8090905@oracle.com> References: <5580A953.8090905@oracle.com> Message-ID: <558275D4.6030306@oracle.com> Hi Alejandro, I looked at the hotspot and JDK changes. On 17/06/2015 8:55 AM, Alejandro E Murillo wrote: > > Please review these changes: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8087202 > Webrev: http://cr.openjdk.java.net/~amurillo/9/8087202 hotspot/make/Makefile + # VERSION_PATCH Security number for version (e.g. 0) Comment is wrong. --- hotspot/src/share/vm/prims/jvm.cpp 3659 info->patch_version = 0; Why is this hard-wired to zero? Surely this should be a build variable. --- hotspot/src/share/vm/prims/jvm.h jdk/src/java.base/share/native/include/jvm.h These two files should be identical, but now have different comments in places. 1188 unsigned int patch_version : 8; 1215 unsigned int patch_version : 8; In each case you removed two 8 bit fields and added one 8 bit field so your bitfields no longer add up to 32 (8+8+16). But these structs seem obsolete (due to no hotspot-express) even before the new version changes. So I think there is still a bit of follow up work to do here. --- hotspot/src/share/vm/runtime/java.hpp 110 _partially_initialized(false), Isn't the whole partially vs fully initialized issue dead now? Else why delete the other code pertaining to that? --- jdk/src/java.base/share/classes/sun/misc/Version.java.template * @since JDK9 Is that the right format? I would have expected @since 9. 248 private static native boolean getJvmVersionInfo(); Does that method still need to return a boolean ? See next comment --- jdk/src/java.base/share/native/libjava/Version.c 50 if (!JDK_InitJvmHandle()) { 51 JNU_ThrowInternalError(env, "Handle for JVM not found for symbol lookup"); 52 return JNI_FALSE; 53 } 54 func_p = (GetJvmVersionInfo_fp) JDK_FindJvmEntry("JVM_GetVersionInfo"); 55 if (func_p == NULL) { 56 return JNI_FALSE; 57 } this seems dead code now and so the method can't fail or throw an exception. Thanks, David ----- > These are intended to: > > (1) Add support for the patch field of the new version string format > (2) Remove unused fields remaining from the old version string format > (3) Patch some jaxp initialization code to be able to handle the new > version string. > this will be pushed under a different bug number, but is required > to be able to run and pass all the tests associated with > "-testset hotspot" > (for JFR tests the VM can't be started without that). > These will be pushed under this sub-task: > https://bugs.openjdk.java.net/browse/JDK-8098588 > > (4) Additional notes: > (a) Some pieces of code, only necessary for 1.5 or older, were removed > (b) update_version and special_update_version were removed > (c) The code to parse the version string in > jdk/test/sun/misc/Version/Version.java > will probably change when the Version.java class is available. > (d) As with the changes for 8085822, this is all being pushed to [1] and > then later to jdk9/dev > (e) These changes should address most, if not all, of the issues raised > during > the code review for JDK-8085822 (see also > https://bugs.openjdk.java.net/browse/JDK-8087203) > (f) All builds and tests pass for "-testset hotspot". > > [1] http://hg.openjdk.java.net/verona/stage > > Thanks > From david.holmes at oracle.com Thu Jun 18 07:59:08 2015 From: david.holmes at oracle.com (David Holmes) Date: Thu, 18 Jun 2015 17:59:08 +1000 Subject: Revision3: Corrected: RFR 8059557 (XL): Validate JVM Command-Line Flag Arguments In-Reply-To: <55818C49.7010100@oracle.com> References: <557C3EF0.3030107@oracle.com> <557E38F9.9010105@oracle.com> <558090F4.6000105@oracle.com> <5580EFF8.3080900@oracle.com> <55818C49.7010100@oracle.com> Message-ID: <55827A4C.2060604@oracle.com> On 18/06/2015 1:03 AM, Gerard Ziemski wrote: > > > On 6/16/2015 10:56 PM, David Holmes wrote: >> Hi Gerard, >> >> On 17/06/2015 7:11 AM, Gerard Ziemski wrote: >>> Coleen, Dmitry, David, Kim, Derek and Bengt, >>> >>> I have create an incremental webrev as requested: >>> http://cr.openjdk.java.net/~gziemski/8059557_rev2_to_rev3 >>> >>> As per suggestion from Kim and Coleen, I will not be spinning webrev4 >>> unless there is a blocker in the code that we haven't found yet. >>> >>> The plan right now is to check in rev3 and have >>> https://bugs.openjdk.java.net/browse/JDK-8112746 track any follow up >>> issues, which I already populated with comments from Coleen, Dmitry and >>> Kim. >>> >>> Can I have a final sign off on this webrev rev3 from all of you please? >> >> Other than the D->%d issue Dmitry spotted I have no further comments. > > It's in the followup issue. It should be fixed here - trivial, no need for an updated webrev. Thanks, David > Thank you David! > From aph at redhat.com Thu Jun 18 07:59:12 2015 From: aph at redhat.com (Andrew Haley) Date: Thu, 18 Jun 2015 08:59:12 +0100 Subject: RFR: 8079315: UseCondCardMark broken in conjunction with CMS precleaning In-Reply-To: <1434534101.6640.1.camel@oracle.com> References: <5548D913.1030507@redhat.com> <554A1CA0.6070801@oracle.com> <473C887F-8CC5-4E67-BD9A-1882660CFD3C@lnu.se> <554B3B5E.8000705@oracle.com> <8EE73C49-83CD-4162-A3EF-19DDA2C2CDFA@lnu.se> <554FC66F.20307@oracle.com> <55507BE4.3050605@redhat.com> <03C141D8-952E-4E7A-BDAD-024CE2239010@lnu.se> <55508B60.1000200@redhat.com> <8868A273-7C97-45F0-BF10-85DDE5859E85@lnu.se> <5550B182.7090009@redhat.com> <5551FA97.9090502@oracle.com> <5551FD72.1020504@oracle.com> <38CAAA0B-6F32-4508-818F-AD9D248E8B35@lnu.se> <55524C58.4030904@oracle.com> <55524E8C.6080709@redhat.com> <55526041.1030709@redhat.com> <7C4CBC57-D7B2-4779-9353-DEACCB626370@lnu.se> <5552838B.3020305@oracle.com> <556D5EF9.6030702@redhat.com> <556D7692.3070707@oracle.com> <557D3D59.4000806@redhat.com> <558034E0.6060600@redhat.com> <1434534101.6640.1.camel@oracle.! com> Message-ID: <55827A50.2070202@redhat.com> On 17/06/15 10:41, Thomas Schatzl wrote: > looks good. Am I correct to assume that the CR that this issue has > been based on (8078438) needs a sponsor too? I'm sorry, I don't know the answer to this. Andrew. From bengt.rutisson at oracle.com Thu Jun 18 08:31:22 2015 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Thu, 18 Jun 2015 10:31:22 +0200 Subject: Revision3: Corrected: RFR 8059557 (XL): Validate JVM Command-Line Flag Arguments In-Reply-To: <558090F4.6000105@oracle.com> References: <557C3EF0.3030107@oracle.com> <557E38F9.9010105@oracle.com> <558090F4.6000105@oracle.com> Message-ID: <558281DA.9030705@oracle.com> Hi Gerard, On 2015-06-16 23:11, Gerard Ziemski wrote: > Coleen, Dmitry, David, Kim, Derek and Bengt, > > I have create an incremental webrev as requested: > http://cr.openjdk.java.net/~gziemski/8059557_rev2_to_rev3 Thanks for putting together the incremental webrev. I'm a bit short on time and I don't want to block this work. Since Kim, David and Dmitry have already reviewed and approved I'm fine with this being pushed without me looking at it too. No need to list me as a reviewer on this change. Thanks, Bengt > > As per suggestion from Kim and Coleen, I will not be spinning webrev4 > unless there is a blocker in the code that we haven't found yet. > > The plan right now is to check in rev3 and have > https://bugs.openjdk.java.net/browse/JDK-8112746 track any follow up > issues, which I already populated with comments from Coleen, Dmitry > and Kim. > > Can I have a final sign off on this webrev rev3 from all of you please? > > > cheers > > On 6/14/2015 9:31 PM, David Holmes wrote: >> Hi Gerard, >> >> Any chance you could produce and incremental webrev please? >> >> Thanks, >> David >> >> On 14/06/2015 12:32 AM, Gerard Ziemski wrote: >>> hi all, >>> >>> Thank you for the reviews so far! >>> >>> Here is a revision 3 of the feature taking into account feedback >>> from Kim Barrett, David Holmes, Derek White and Bengt Rutisson. I >>> have also merged the changes to the latest jdk9. >>> >>> We introduce a new mechanism that allows specification of a valid >>> range per flag that is then used to automatically validate given >>> flag's value every time it changes. Ranges values must be constant >>> and can not change. Optionally, a constraint can also be specified >>> and applied every time a flag value changes for those flags whose >>> valid value can not be trivially checked by a simple min and max >>> (ex. whether it's power of 2, or bigger or smaller than some other >>> flag that can also change) >>> >>> I have chosen to modify the table macros (ex. RUNTIME_FLAGS in >>> globals.hpp) instead of using a more sophisticated solution, such as >>> C++ templates, because even though macros were unfriendly when >>> initially developing, once a solution was arrived at, subsequent >>> additions to the tables of new ranges, or constraint are trivial >>> from developer's point of view. (The intial development >>> unfriendliness of macros was mitigated by using a pre-processor, >>> which for those using a modern IDE like Xcode, is easily available >>> from a menu). Using macros also allowed for more minimal code changes. >>> >>> The presented solution is based on expansion of macros using >>> variadic functions and can be readily seen in >>> runtime/commandLineFlagConstraintList.cpp and >>> runtime/commandLineFlagRangeList.cpp >>> >>> In commandLineFlagConstraintList.cpp or >>> commandLineFlagRangesList.cpp, there is bunch of classes and methods >>> that seems to beg for C++ template to be used. I have tried, but >>> when the compiler tries to generate code for both uintx and size_t, >>> which happen to have the same underlying type (on BSD), it fails to >>> compile overridden methods with same type, but different name. If >>> someone has a way of simplifying the new code via C++ templates, >>> however, we can file a new enhancement request to address that. >>> >>> This webrev represents only the initial range checking framework and >>> only 100 or so flags that were ported from an existing ad hoc range >>> checking code to this new mechanism. There are about 250 remaining >>> flags that still need their ranges determined and ported over to >>> this new mechanism and they are tracked by individual subtasks. >>> >>> I had to modify several existing tests to change the error message >>> that they expected when VM refuses to run, which was changed to >>> provide uniform error messages. >>> >>> To help with testing and subtask efforts I have introduced a new >>> runtime flag: >>> >>> PrintFlagsRanges: "Print VM flags and their ranges and exit VM" >>> >>> which in addition to the already existing flags: "PrintFlagsInitial" >>> and "PrintFlagsFinal" allow for thorough examination of the flags >>> values and their ranges. >>> >>> The code change builds and passes JPRT (-testset hotspot) and UTE >>> (vm.quick.testlist) >>> >>> >>> References: >>> >>> Webrev:http://cr.openjdk.java.net/~gziemski/8059557_rev3 >>> JEP:https://bugs.openjdk.java.net/browse/JDK-8059557 >>> Compiler subtask:https://bugs.openjdk.java.net/browse/JDK-8078554 >>> GC subtask:https://bugs.openjdk.java.net/browse/JDK-8078555 >>> Runtime subtask:https://bugs.openjdk.java.net/browse/JDK-8078556 >>> >>> Note: due to "awk" limit of 50 pats the Frames diff is not available >>> for "src/share/vm/runtime/arguments.cpp? and >>> "src/share/vm/runtime/globals.cpp? >>> >>> >>> Followup issues: >>> >>> JDK-8085866: There are 99 uses of FLAG_SET_ERGO, should they check >>> the return value? >>> JDK-8085864: FLAG_SET_CMDLINE in TestGenCollectorPolicy() currently >>> ignore the return values >>> JDK-8081842: Find a better place for >>> EMIT_{CONSTRAINTS,RANGES}_FOR_GLOBALS_EXT >>> JDK-8081833: There is a large amount of code near-duplication among >>> the various CommandLineFlagRange_ classes >>> JDK-8081519: Split globals.hpp to factor out the Flag values needed >>> by JDK-8059557 >>> >>> >>> hgstat: >>> >>> src/cpu/ppc/vm/globals_ppc.hpp | 2 +- >>> src/cpu/sparc/vm/globals_sparc.hpp | 2 +- >>> src/cpu/x86/vm/globals_x86.hpp | 2 +- >>> src/cpu/zero/vm/globals_zero.hpp | 3 +- >>> src/os/aix/vm/globals_aix.hpp | 2 +- >>> src/os/bsd/vm/globals_bsd.hpp | 29 +- >>> src/os/linux/vm/globals_linux.hpp | 9 +- >>> src/os/solaris/vm/globals_solaris.hpp | 4 +- >>> src/os/windows/vm/globals_windows.hpp | 5 +- >>> src/share/vm/c1/c1_globals.cpp | 4 +- >>> src/share/vm/c1/c1_globals.hpp | 17 +- >>> src/share/vm/gc/g1/g1_globals.cpp | 14 +- >>> src/share/vm/gc/g1/g1_globals.hpp | 38 +- >>> src/share/vm/opto/c2_globals.cpp | 12 +- >>> src/share/vm/opto/c2_globals.hpp | 40 +- >>> src/share/vm/prims/whitebox.cpp | 12 +- >>> src/share/vm/runtime/arguments.cpp | 765 ++++++---------- >>> src/share/vm/runtime/arguments.hpp | 24 +- >>> src/share/vm/runtime/commandLineFlagConstraintList.cpp | 286 ++++++ >>> src/share/vm/runtime/commandLineFlagConstraintList.hpp | 80 + >>> src/share/vm/runtime/commandLineFlagConstraintsCompiler.cpp | 44 + >>> src/share/vm/runtime/commandLineFlagConstraintsCompiler.hpp | 39 + >>> src/share/vm/runtime/commandLineFlagConstraintsGC.cpp | 235 +++++ >>> src/share/vm/runtime/commandLineFlagConstraintsGC.hpp | 58 + >>> src/share/vm/runtime/commandLineFlagConstraintsRuntime.cpp | 65 + >>> src/share/vm/runtime/commandLineFlagConstraintsRuntime.hpp | 41 + >>> src/share/vm/runtime/commandLineFlagRangeList.cpp | 367 ++++++++ >>> src/share/vm/runtime/commandLineFlagRangeList.hpp | 71 + >>> src/share/vm/runtime/globals.cpp | 721 ++++++++++++--- >>> src/share/vm/runtime/globals.hpp | 343 ++++++- >>> src/share/vm/runtime/globals_extension.hpp | 105 +- >>> src/share/vm/runtime/init.cpp | 5 +- >>> src/share/vm/runtime/os_ext.hpp | 7 +- >>> src/share/vm/runtime/thread.cpp | 6 + >>> src/share/vm/services/attachListener.cpp | 4 +- >>> src/share/vm/services/classLoadingService.cpp | 12 +- >>> src/share/vm/services/diagnosticCommand.cpp | 3 +- >>> src/share/vm/services/management.cpp | 6 +- >>> src/share/vm/services/memoryService.cpp | 4 +- >>> src/share/vm/services/writeableFlags.cpp | 183 ++- >>> src/share/vm/services/writeableFlags.hpp | 60 +- >>> test/compiler/c2/7200264/Test7200264.sh | 5 +- >>> test/compiler/startup/NumCompilerThreadsCheck.java | 2 +- >>> test/gc/arguments/TestHeapFreeRatio.java | 23 +- >>> test/gc/arguments/TestSurvivorAlignmentInBytesOption.java | 6 +- >>> test/gc/g1/TestStringDeduplicationTools.java | 6 +- >>> test/runtime/CompressedOops/CompressedClassSpaceSize.java | 4 +- >>> test/runtime/CompressedOops/ObjectAlignment.java | 9 +- >>> test/runtime/contended/Options.java | 10 +- >>> 49 files changed, 2851 insertions(+), 943 deletions(-) >>> >> > From goetz.lindenmaier at sap.com Thu Jun 18 10:41:59 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 18 Jun 2015 10:41:59 +0000 Subject: RFR(S): 8087183: Fix call to inline function is_oop in header debugInfo.hpp. [needs sponsor] Message-ID: <4295855A5C1DE049A61835A1887419CC2CFFB8BF@DEWDFEMB12A.global.corp.sap> Hi, could someone please sponsor this fix? It's required to fix the fastdebug build on aix. Thanks a lot! Goetz. -----Original Message----- From: Lindenmaier, Goetz Sent: Montag, 15. Juni 2015 11:21 To: 'David Holmes'; 'Kim Barrett' Cc: 'HotSpot Developers' Subject: RE: RFR(S): 8087183: Fix call to inline function is_oop in header debugInfo.hpp. Hi, I updated the call to is_oop to do "or_null", and fixed the Copyrights. I also added the reviewers to the change comment. http://cr.openjdk.java.net/~goetz/webrevs/8087183-is_oop/webrev-02/ Could someone please sponsor this tiny change? Thanks and best regards, Goetz. -----Original Message----- From: Lindenmaier, Goetz Sent: Freitag, 12. Juni 2015 08:54 To: 'David Holmes'; Kim Barrett Cc: HotSpot Developers Subject: RE: RFR(S): 8087183: Fix call to inline function is_oop in header debugInfo.hpp. Hi, Thanks for the reviews! Could someone please sponsor this? We started to track down the cause by searching and building the repo, but then we narrowed in down to two merges ... and aix builds rather slow. I quit this task then. But the file drags in a lot of os/aix and os_cpu/aix_ppc files. The includes in these files differ from those in other platform directories. And with one of the include cleanup changes in a shared file the indirect include that must have been there at some point vanished I guess. But no matter, is_oop should not be called in a header file ... Best regards, Goetz. -----Original Message----- From: David Holmes [mailto:david.holmes at oracle.com] Sent: Freitag, 12. Juni 2015 04:07 To: Kim Barrett; Lindenmaier, Goetz Cc: HotSpot Developers Subject: Re: RFR(S): 8087183: Fix call to inline function is_oop in header debugInfo.hpp. On 12/06/2015 3:17 AM, Kim Barrett wrote: > On Jun 11, 2015, at 5:02 AM, Lindenmaier, Goetz wrote: >> >> Hi, >> >> in debugInfo.hpp is_oop() is called. This is an inline function defined in oop.inline.hpp. >> As oop.inline.hpp is not included in debugInfo.hpp, and it should not be included there, >> this leads to compilation failures in the fastdebug build on aix. >> >> To fix this, I just move the function calling is_oop to debugInfo.cpp. In that file also the >> only call to that function is located, so that it still can be inlined. >> >> Please review this change. I please need a sponsor. >> http://cr.openjdk.java.net/~goetz/webrevs/8087183-is_oop/webrev-01/ >> >> Best regards, >> Goetz. > > Looks good. > > I'm mildly surprised this doesn't run into problems on other platforms. Me too. My first thought was precompiled headers, but this code has been in place for a couple of years - so why is it now a problem ?? David > The assert could use oop->is_oop_or_null(), though it makes no difference for this problem. > From david.holmes at oracle.com Thu Jun 18 10:57:08 2015 From: david.holmes at oracle.com (David Holmes) Date: Thu, 18 Jun 2015 20:57:08 +1000 Subject: RFR(S): 8087183: Fix call to inline function is_oop in header debugInfo.hpp. [needs sponsor] In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CFFB8BF@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CFFB8BF@DEWDFEMB12A.global.corp.sap> Message-ID: <5582A404.8040204@oracle.com> Hi Goetz, I can sponsor in about 11 hours if noone else picks it up overnight :) David On 18/06/2015 8:41 PM, Lindenmaier, Goetz wrote: > Hi, > > could someone please sponsor this fix? > It's required to fix the fastdebug build on aix. > > Thanks a lot! > Goetz. > > -----Original Message----- > From: Lindenmaier, Goetz > Sent: Montag, 15. Juni 2015 11:21 > To: 'David Holmes'; 'Kim Barrett' > Cc: 'HotSpot Developers' > Subject: RE: RFR(S): 8087183: Fix call to inline function is_oop in header debugInfo.hpp. > > Hi, > > I updated the call to is_oop to do "or_null", and fixed the Copyrights. > I also added the reviewers to the change comment. > http://cr.openjdk.java.net/~goetz/webrevs/8087183-is_oop/webrev-02/ > > Could someone please sponsor this tiny change? > > Thanks and best regards, > Goetz. > > -----Original Message----- > From: Lindenmaier, Goetz > Sent: Freitag, 12. Juni 2015 08:54 > To: 'David Holmes'; Kim Barrett > Cc: HotSpot Developers > Subject: RE: RFR(S): 8087183: Fix call to inline function is_oop in header debugInfo.hpp. > > Hi, > > Thanks for the reviews! Could someone please sponsor this? > > We started to track down the cause by searching and building the repo, but then > we narrowed in down to two merges ... and aix builds rather slow. I quit this task > then. > > But the file drags in a lot of os/aix and os_cpu/aix_ppc files. The includes in these > files differ from those in other platform directories. And with one of the > include cleanup changes in a shared file the indirect include that must have been > there at some point vanished I guess. > > But no matter, is_oop should not be called in a header file ... > > Best regards, > Goetz. > > -----Original Message----- > From: David Holmes [mailto:david.holmes at oracle.com] > Sent: Freitag, 12. Juni 2015 04:07 > To: Kim Barrett; Lindenmaier, Goetz > Cc: HotSpot Developers > Subject: Re: RFR(S): 8087183: Fix call to inline function is_oop in header debugInfo.hpp. > > On 12/06/2015 3:17 AM, Kim Barrett wrote: >> On Jun 11, 2015, at 5:02 AM, Lindenmaier, Goetz wrote: >>> >>> Hi, >>> >>> in debugInfo.hpp is_oop() is called. This is an inline function defined in oop.inline.hpp. >>> As oop.inline.hpp is not included in debugInfo.hpp, and it should not be included there, >>> this leads to compilation failures in the fastdebug build on aix. >>> >>> To fix this, I just move the function calling is_oop to debugInfo.cpp. In that file also the >>> only call to that function is located, so that it still can be inlined. >>> >>> Please review this change. I please need a sponsor. >>> http://cr.openjdk.java.net/~goetz/webrevs/8087183-is_oop/webrev-01/ >>> >>> Best regards, >>> Goetz. >> >> Looks good. >> >> I'm mildly surprised this doesn't run into problems on other platforms. > > Me too. My first thought was precompiled headers, but this code has been > in place for a couple of years - so why is it now a problem ?? > > David > > >> The assert could use oop->is_oop_or_null(), though it makes no difference for this problem. >> From mikael.gerdin at oracle.com Thu Jun 18 11:06:27 2015 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Thu, 18 Jun 2015 13:06:27 +0200 Subject: RFR(S): 8087183: Fix call to inline function is_oop in header debugInfo.hpp. [needs sponsor] In-Reply-To: <5582A404.8040204@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CFFB8BF@DEWDFEMB12A.global.corp.sap> <5582A404.8040204@oracle.com> Message-ID: <5582A633.3020603@oracle.com> I can sponsor it. /Mikael On 2015-06-18 12:57, David Holmes wrote: > Hi Goetz, > > I can sponsor in about 11 hours if noone else picks it up overnight :) > > David > > On 18/06/2015 8:41 PM, Lindenmaier, Goetz wrote: >> Hi, >> >> could someone please sponsor this fix? >> It's required to fix the fastdebug build on aix. >> >> Thanks a lot! >> Goetz. >> >> -----Original Message----- >> From: Lindenmaier, Goetz >> Sent: Montag, 15. Juni 2015 11:21 >> To: 'David Holmes'; 'Kim Barrett' >> Cc: 'HotSpot Developers' >> Subject: RE: RFR(S): 8087183: Fix call to inline function is_oop in >> header debugInfo.hpp. >> >> Hi, >> >> I updated the call to is_oop to do "or_null", and fixed the Copyrights. >> I also added the reviewers to the change comment. >> http://cr.openjdk.java.net/~goetz/webrevs/8087183-is_oop/webrev-02/ >> >> Could someone please sponsor this tiny change? >> >> Thanks and best regards, >> Goetz. >> >> -----Original Message----- >> From: Lindenmaier, Goetz >> Sent: Freitag, 12. Juni 2015 08:54 >> To: 'David Holmes'; Kim Barrett >> Cc: HotSpot Developers >> Subject: RE: RFR(S): 8087183: Fix call to inline function is_oop in >> header debugInfo.hpp. >> >> Hi, >> >> Thanks for the reviews! Could someone please sponsor this? >> >> We started to track down the cause by searching and building the repo, >> but then >> we narrowed in down to two merges ... and aix builds rather slow. I >> quit this task >> then. >> >> But the file drags in a lot of os/aix and os_cpu/aix_ppc files. The >> includes in these >> files differ from those in other platform directories. And with one >> of the >> include cleanup changes in a shared file the indirect include that >> must have been >> there at some point vanished I guess. >> >> But no matter, is_oop should not be called in a header file ... >> >> Best regards, >> Goetz. >> >> -----Original Message----- >> From: David Holmes [mailto:david.holmes at oracle.com] >> Sent: Freitag, 12. Juni 2015 04:07 >> To: Kim Barrett; Lindenmaier, Goetz >> Cc: HotSpot Developers >> Subject: Re: RFR(S): 8087183: Fix call to inline function is_oop in >> header debugInfo.hpp. >> >> On 12/06/2015 3:17 AM, Kim Barrett wrote: >>> On Jun 11, 2015, at 5:02 AM, Lindenmaier, Goetz >>> wrote: >>>> >>>> Hi, >>>> >>>> in debugInfo.hpp is_oop() is called. This is an inline function >>>> defined in oop.inline.hpp. >>>> As oop.inline.hpp is not included in debugInfo.hpp, and it should >>>> not be included there, >>>> this leads to compilation failures in the fastdebug build on aix. >>>> >>>> To fix this, I just move the function calling is_oop to >>>> debugInfo.cpp. In that file also the >>>> only call to that function is located, so that it still can be inlined. >>>> >>>> Please review this change. I please need a sponsor. >>>> http://cr.openjdk.java.net/~goetz/webrevs/8087183-is_oop/webrev-01/ >>>> >>>> Best regards, >>>> Goetz. >>> >>> Looks good. >>> >>> I'm mildly surprised this doesn't run into problems on other platforms. >> >> Me too. My first thought was precompiled headers, but this code has been >> in place for a couple of years - so why is it now a problem ?? >> >> David >> >> >>> The assert could use oop->is_oop_or_null(), though it makes no >>> difference for this problem. >>> From goetz.lindenmaier at sap.com Thu Jun 18 12:02:53 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 18 Jun 2015 12:02:53 +0000 Subject: RFR(S): 8087183: Fix call to inline function is_oop in header debugInfo.hpp. [needs sponsor] In-Reply-To: <5582A404.8040204@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CFFB8BF@DEWDFEMB12A.global.corp.sap> <5582A404.8040204@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2CFFB934@DEWDFEMB12A.global.corp.sap> That would be great! Thanks! Best regards, Goetz. -----Original Message----- From: David Holmes [mailto:david.holmes at oracle.com] Sent: Donnerstag, 18. Juni 2015 12:57 To: Lindenmaier, Goetz; Kim Barrett Cc: HotSpot Developers Subject: Re: RFR(S): 8087183: Fix call to inline function is_oop in header debugInfo.hpp. [needs sponsor] Hi Goetz, I can sponsor in about 11 hours if noone else picks it up overnight :) David On 18/06/2015 8:41 PM, Lindenmaier, Goetz wrote: > Hi, > > could someone please sponsor this fix? > It's required to fix the fastdebug build on aix. > > Thanks a lot! > Goetz. > > -----Original Message----- > From: Lindenmaier, Goetz > Sent: Montag, 15. Juni 2015 11:21 > To: 'David Holmes'; 'Kim Barrett' > Cc: 'HotSpot Developers' > Subject: RE: RFR(S): 8087183: Fix call to inline function is_oop in header debugInfo.hpp. > > Hi, > > I updated the call to is_oop to do "or_null", and fixed the Copyrights. > I also added the reviewers to the change comment. > http://cr.openjdk.java.net/~goetz/webrevs/8087183-is_oop/webrev-02/ > > Could someone please sponsor this tiny change? > > Thanks and best regards, > Goetz. > > -----Original Message----- > From: Lindenmaier, Goetz > Sent: Freitag, 12. Juni 2015 08:54 > To: 'David Holmes'; Kim Barrett > Cc: HotSpot Developers > Subject: RE: RFR(S): 8087183: Fix call to inline function is_oop in header debugInfo.hpp. > > Hi, > > Thanks for the reviews! Could someone please sponsor this? > > We started to track down the cause by searching and building the repo, but then > we narrowed in down to two merges ... and aix builds rather slow. I quit this task > then. > > But the file drags in a lot of os/aix and os_cpu/aix_ppc files. The includes in these > files differ from those in other platform directories. And with one of the > include cleanup changes in a shared file the indirect include that must have been > there at some point vanished I guess. > > But no matter, is_oop should not be called in a header file ... > > Best regards, > Goetz. > > -----Original Message----- > From: David Holmes [mailto:david.holmes at oracle.com] > Sent: Freitag, 12. Juni 2015 04:07 > To: Kim Barrett; Lindenmaier, Goetz > Cc: HotSpot Developers > Subject: Re: RFR(S): 8087183: Fix call to inline function is_oop in header debugInfo.hpp. > > On 12/06/2015 3:17 AM, Kim Barrett wrote: >> On Jun 11, 2015, at 5:02 AM, Lindenmaier, Goetz wrote: >>> >>> Hi, >>> >>> in debugInfo.hpp is_oop() is called. This is an inline function defined in oop.inline.hpp. >>> As oop.inline.hpp is not included in debugInfo.hpp, and it should not be included there, >>> this leads to compilation failures in the fastdebug build on aix. >>> >>> To fix this, I just move the function calling is_oop to debugInfo.cpp. In that file also the >>> only call to that function is located, so that it still can be inlined. >>> >>> Please review this change. I please need a sponsor. >>> http://cr.openjdk.java.net/~goetz/webrevs/8087183-is_oop/webrev-01/ >>> >>> Best regards, >>> Goetz. >> >> Looks good. >> >> I'm mildly surprised this doesn't run into problems on other platforms. > > Me too. My first thought was precompiled headers, but this code has been > in place for a couple of years - so why is it now a problem ?? > > David > > >> The assert could use oop->is_oop_or_null(), though it makes no difference for this problem. >> From goetz.lindenmaier at sap.com Thu Jun 18 12:07:57 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 18 Jun 2015 12:07:57 +0000 Subject: RFR(S): 8087183: Fix call to inline function is_oop in header debugInfo.hpp. [needs sponsor] In-Reply-To: <5582A633.3020603@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CFFB8BF@DEWDFEMB12A.global.corp.sap> <5582A404.8040204@oracle.com> <5582A633.3020603@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2CFFB94F@DEWDFEMB12A.global.corp.sap> Hi Mikael, Thanks! David offered to sponsor too. Please tell him in case you pushed it to jprt, I can only tell once it's submitted. Best regards, Goetz. -----Original Message----- From: Mikael Gerdin [mailto:mikael.gerdin at oracle.com] Sent: Donnerstag, 18. Juni 2015 13:06 To: David Holmes; Lindenmaier, Goetz; Kim Barrett Cc: HotSpot Developers Subject: Re: RFR(S): 8087183: Fix call to inline function is_oop in header debugInfo.hpp. [needs sponsor] I can sponsor it. /Mikael On 2015-06-18 12:57, David Holmes wrote: > Hi Goetz, > > I can sponsor in about 11 hours if noone else picks it up overnight :) > > David > > On 18/06/2015 8:41 PM, Lindenmaier, Goetz wrote: >> Hi, >> >> could someone please sponsor this fix? >> It's required to fix the fastdebug build on aix. >> >> Thanks a lot! >> Goetz. >> >> -----Original Message----- >> From: Lindenmaier, Goetz >> Sent: Montag, 15. Juni 2015 11:21 >> To: 'David Holmes'; 'Kim Barrett' >> Cc: 'HotSpot Developers' >> Subject: RE: RFR(S): 8087183: Fix call to inline function is_oop in >> header debugInfo.hpp. >> >> Hi, >> >> I updated the call to is_oop to do "or_null", and fixed the Copyrights. >> I also added the reviewers to the change comment. >> http://cr.openjdk.java.net/~goetz/webrevs/8087183-is_oop/webrev-02/ >> >> Could someone please sponsor this tiny change? >> >> Thanks and best regards, >> Goetz. >> >> -----Original Message----- >> From: Lindenmaier, Goetz >> Sent: Freitag, 12. Juni 2015 08:54 >> To: 'David Holmes'; Kim Barrett >> Cc: HotSpot Developers >> Subject: RE: RFR(S): 8087183: Fix call to inline function is_oop in >> header debugInfo.hpp. >> >> Hi, >> >> Thanks for the reviews! Could someone please sponsor this? >> >> We started to track down the cause by searching and building the repo, >> but then >> we narrowed in down to two merges ... and aix builds rather slow. I >> quit this task >> then. >> >> But the file drags in a lot of os/aix and os_cpu/aix_ppc files. The >> includes in these >> files differ from those in other platform directories. And with one >> of the >> include cleanup changes in a shared file the indirect include that >> must have been >> there at some point vanished I guess. >> >> But no matter, is_oop should not be called in a header file ... >> >> Best regards, >> Goetz. >> >> -----Original Message----- >> From: David Holmes [mailto:david.holmes at oracle.com] >> Sent: Freitag, 12. Juni 2015 04:07 >> To: Kim Barrett; Lindenmaier, Goetz >> Cc: HotSpot Developers >> Subject: Re: RFR(S): 8087183: Fix call to inline function is_oop in >> header debugInfo.hpp. >> >> On 12/06/2015 3:17 AM, Kim Barrett wrote: >>> On Jun 11, 2015, at 5:02 AM, Lindenmaier, Goetz >>> wrote: >>>> >>>> Hi, >>>> >>>> in debugInfo.hpp is_oop() is called. This is an inline function >>>> defined in oop.inline.hpp. >>>> As oop.inline.hpp is not included in debugInfo.hpp, and it should >>>> not be included there, >>>> this leads to compilation failures in the fastdebug build on aix. >>>> >>>> To fix this, I just move the function calling is_oop to >>>> debugInfo.cpp. In that file also the >>>> only call to that function is located, so that it still can be inlined. >>>> >>>> Please review this change. I please need a sponsor. >>>> http://cr.openjdk.java.net/~goetz/webrevs/8087183-is_oop/webrev-01/ >>>> >>>> Best regards, >>>> Goetz. >>> >>> Looks good. >>> >>> I'm mildly surprised this doesn't run into problems on other platforms. >> >> Me too. My first thought was precompiled headers, but this code has been >> in place for a couple of years - so why is it now a problem ?? >> >> David >> >> >>> The assert could use oop->is_oop_or_null(), though it makes no >>> difference for this problem. >>> From mikael.gerdin at oracle.com Thu Jun 18 12:32:24 2015 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Thu, 18 Jun 2015 14:32:24 +0200 Subject: RFR(S): 8087183: Fix call to inline function is_oop in header debugInfo.hpp. [needs sponsor] In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CFFB94F@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CFFB8BF@DEWDFEMB12A.global.corp.sap> <5582A404.8040204@oracle.com> <5582A633.3020603@oracle.com> <4295855A5C1DE049A61835A1887419CC2CFFB94F@DEWDFEMB12A.global.corp.sap> Message-ID: <5582BA58.2070109@oracle.com> Hi Goetz, I tried to push the fix to hs-comp but the test job failed due to https://bugs.openjdk.java.net/browse/JDK-8129094 It would be better to wait for that fix to be integrated before trying to push to hs-comp again, I think. If you need it urgently I can push it to hs-rt but there are quite a few known issues in hs-rt as well. /Mikael On 2015-06-18 14:07, Lindenmaier, Goetz wrote: > Hi Mikael, > > Thanks! David offered to sponsor too. > Please tell him in case you pushed it to jprt, I can only > tell once it's submitted. > > Best regards, > Goetz. > > -----Original Message----- > From: Mikael Gerdin [mailto:mikael.gerdin at oracle.com] > Sent: Donnerstag, 18. Juni 2015 13:06 > To: David Holmes; Lindenmaier, Goetz; Kim Barrett > Cc: HotSpot Developers > Subject: Re: RFR(S): 8087183: Fix call to inline function is_oop in header debugInfo.hpp. [needs sponsor] > > I can sponsor it. > /Mikael > > On 2015-06-18 12:57, David Holmes wrote: >> Hi Goetz, >> >> I can sponsor in about 11 hours if noone else picks it up overnight :) >> >> David >> >> On 18/06/2015 8:41 PM, Lindenmaier, Goetz wrote: >>> Hi, >>> >>> could someone please sponsor this fix? >>> It's required to fix the fastdebug build on aix. >>> >>> Thanks a lot! >>> Goetz. >>> >>> -----Original Message----- >>> From: Lindenmaier, Goetz >>> Sent: Montag, 15. Juni 2015 11:21 >>> To: 'David Holmes'; 'Kim Barrett' >>> Cc: 'HotSpot Developers' >>> Subject: RE: RFR(S): 8087183: Fix call to inline function is_oop in >>> header debugInfo.hpp. >>> >>> Hi, >>> >>> I updated the call to is_oop to do "or_null", and fixed the Copyrights. >>> I also added the reviewers to the change comment. >>> http://cr.openjdk.java.net/~goetz/webrevs/8087183-is_oop/webrev-02/ >>> >>> Could someone please sponsor this tiny change? >>> >>> Thanks and best regards, >>> Goetz. >>> >>> -----Original Message----- >>> From: Lindenmaier, Goetz >>> Sent: Freitag, 12. Juni 2015 08:54 >>> To: 'David Holmes'; Kim Barrett >>> Cc: HotSpot Developers >>> Subject: RE: RFR(S): 8087183: Fix call to inline function is_oop in >>> header debugInfo.hpp. >>> >>> Hi, >>> >>> Thanks for the reviews! Could someone please sponsor this? >>> >>> We started to track down the cause by searching and building the repo, >>> but then >>> we narrowed in down to two merges ... and aix builds rather slow. I >>> quit this task >>> then. >>> >>> But the file drags in a lot of os/aix and os_cpu/aix_ppc files. The >>> includes in these >>> files differ from those in other platform directories. And with one >>> of the >>> include cleanup changes in a shared file the indirect include that >>> must have been >>> there at some point vanished I guess. >>> >>> But no matter, is_oop should not be called in a header file ... >>> >>> Best regards, >>> Goetz. >>> >>> -----Original Message----- >>> From: David Holmes [mailto:david.holmes at oracle.com] >>> Sent: Freitag, 12. Juni 2015 04:07 >>> To: Kim Barrett; Lindenmaier, Goetz >>> Cc: HotSpot Developers >>> Subject: Re: RFR(S): 8087183: Fix call to inline function is_oop in >>> header debugInfo.hpp. >>> >>> On 12/06/2015 3:17 AM, Kim Barrett wrote: >>>> On Jun 11, 2015, at 5:02 AM, Lindenmaier, Goetz >>>> wrote: >>>>> >>>>> Hi, >>>>> >>>>> in debugInfo.hpp is_oop() is called. This is an inline function >>>>> defined in oop.inline.hpp. >>>>> As oop.inline.hpp is not included in debugInfo.hpp, and it should >>>>> not be included there, >>>>> this leads to compilation failures in the fastdebug build on aix. >>>>> >>>>> To fix this, I just move the function calling is_oop to >>>>> debugInfo.cpp. In that file also the >>>>> only call to that function is located, so that it still can be inlined. >>>>> >>>>> Please review this change. I please need a sponsor. >>>>> http://cr.openjdk.java.net/~goetz/webrevs/8087183-is_oop/webrev-01/ >>>>> >>>>> Best regards, >>>>> Goetz. >>>> >>>> Looks good. >>>> >>>> I'm mildly surprised this doesn't run into problems on other platforms. >>> >>> Me too. My first thought was precompiled headers, but this code has been >>> in place for a couple of years - so why is it now a problem ?? >>> >>> David >>> >>> >>>> The assert could use oop->is_oop_or_null(), though it makes no >>>> difference for this problem. >>>> From thomas.schatzl at oracle.com Thu Jun 18 12:37:32 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Thu, 18 Jun 2015 14:37:32 +0200 Subject: Dynamic G1 barrier elision for C2 in young In-Reply-To: <2F2AB31D-E6E4-4E8F-BF58-C8DEE0325264@lnu.se> References: <2F2AB31D-E6E4-4E8F-BF58-C8DEE0325264@lnu.se> Message-ID: <1434631052.2569.7.camel@oracle.com> Hi Erik, On Sun, 2015-06-14 at 00:53 +0000, Erik ?sterlund wrote: > Hi Vitaly, > > Thank you for liking the idea! What I had in mind was optimizing young > objects because it?s easy to reason about consistency, but I suppose in > such cases even old objects could be optimized. But that would require > more care and I don?t know how common such applications are as Java is > widely marketed as having cheap allocations. I like the idea too. I will run it through a few benchmarks and see if there is more than dacapo benchmarks giving better numbers. > Anyway, the approach could be refined much more if plugged into an > engine for points-to analysis. It gives a set of possible allocation > points for object references, which could in our case be exploited > when emitting reference store code. If objects are then given different > Klass pointers (soft handles) for different allocation points at runtime, > then the approach could find more opportunities for barrier elision. In > cases where the same class is used in different parts of code, sometimes > as temporary objects and sometimes as old objects, the difference would > be identified and barriers would be elided for the code dealing with the > always temporary variants of the class, but not for code dealing with > the potentially old objects of the same class. Not sure how low hanging > that fruit is though? but C2 does some of that stuff already for lock > elision using escape analysis I think, although not intra-procedural > (yet) if I get it right. Could have a look when I have time if anyone is > interested in this kind of stuff. Always :) I believe there is a *lot* of untapped potential in making the compiler consider GC activity for compilation. Thanks, Thomas From Alan.Bateman at oracle.com Thu Jun 18 13:41:49 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 18 Jun 2015 14:41:49 +0100 Subject: [verona.stage] RFR 8087203: Add support for PATCH field and remove unused fields of new version string In-Reply-To: <5580A953.8090905@oracle.com> References: <5580A953.8090905@oracle.com> Message-ID: <5582CA9D.9070207@oracle.com> On 16/06/2015 23:55, Alejandro E Murillo wrote: > > Please review these changes: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8087202 > Webrev: http://cr.openjdk.java.net/~amurillo/9/8087202 The implementation of isJavaVersionAtLeast in the JAXP classes look okay although I think this is code that could be removed. Joe Wang can confirm but I think it dates back to when the JAXP API was a standalone API and there was an attempt to keep the code in sync across major versions. I'll create a separate bug re-examine this as it looks like some clean-up can be done here. Just on the comment "In JDK9 the version string was changed ..." will date quickly and would be nice to say that "In JDK 8 and older then it assumes 1.N and for JDK 9 and newer it assumes N. In sun.misc.Version.initVersions then InternalError instead of RuntimeException might be more appropriate as something is really broken if that happens. Also as David pointed out, it shouldn't be @since JDK9 in the new method. This reminds me to check if the JEP says anything about @since tags because we already have quite a few @since 1.9. In the Version.java test then the line with the pattern is really long, maybe that could be split up to make future side-by-side views easier to read. Otherwise looks okay to me. -Alan. From vladimir.kozlov at oracle.com Thu Jun 18 14:14:50 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 18 Jun 2015 07:14:50 -0700 Subject: RFR: 8079315: UseCondCardMark broken in conjunction with CMS precleaning In-Reply-To: <55827A50.2070202@redhat.com> References: <5548D913.1030507@redhat.com> <473C887F-8CC5-4E67-BD9A-1882660CFD3C@lnu.se> <554B3B5E.8000705@oracle.com> <8EE73C49-83CD-4162-A3EF-19DDA2C2CDFA@lnu.se> <554FC66F.20307@oracle.com> <55507BE4.3050605@redhat.com> <03C141D8-952E-4E7A-BDAD-024CE2239010@lnu.se> <55508B60.1000200@redhat.com> <8868A273-7C97-45F0-BF10-85DDE5859E85@lnu.se> <5550B182.7090009@redhat.com> <5551FA97.9090502@oracle.com> <5551FD72.1020504@oracle.com> <38CAAA0B-6F32-4508-818F-AD9D248E8B35@lnu.se> <55524C58.4030904@oracle.com> <55524E8C.6080709@redhat.com> <55526041.1030709@redhat.com> <7C4CBC57-D7B2-4779-9353-DEACCB626370@lnu.se> <5552838B.3020305@oracle.com> <556D5EF9.6030702@redhat.com> <556D7692.3070707@oracle.com> <557D3D59.4000806@redhat.com> <558034E0.6060600@redhat.com> <1434534101.6640.1.camel@oracle.! com> <55827A50.2070202@redha! t.com> Message-ID: <5582D25A.1010307@oracle.com> Yes, it needs sponsor too (pushed through JPRT) since it is a change in our core platform we support. http://cr.openjdk.java.net/~shade/8078438/webrev.03/ Thanks, Vladimir On 6/18/15 12:59 AM, Andrew Haley wrote: > On 17/06/15 10:41, Thomas Schatzl wrote: >> looks good. Am I correct to assume that the CR that this issue has >> been based on (8078438) needs a sponsor too? > > I'm sorry, I don't know the answer to this. > > Andrew. > From volker.simonis at gmail.com Thu Jun 18 14:15:17 2015 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 18 Jun 2015 16:15:17 +0200 Subject: RFR(S): 8087183: Fix call to inline function is_oop in header debugInfo.hpp. [needs sponsor] In-Reply-To: <5582BA58.2070109@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CFFB8BF@DEWDFEMB12A.global.corp.sap> <5582A404.8040204@oracle.com> <5582A633.3020603@oracle.com> <4295855A5C1DE049A61835A1887419CC2CFFB94F@DEWDFEMB12A.global.corp.sap> <5582BA58.2070109@oracle.com> Message-ID: Hi Mikael, it's great if you'll take care of this change. Please push it as soon as the repository is clean again. Thanks for your help, Volker On 6/18/15, Mikael Gerdin wrote: > Hi Goetz, > > I tried to push the fix to hs-comp but the test job failed due to > https://bugs.openjdk.java.net/browse/JDK-8129094 > It would be better to wait for that fix to be integrated before trying > to push to hs-comp again, I think. > If you need it urgently I can push it to hs-rt but there are quite a few > known issues in hs-rt as well. > > /Mikael > > On 2015-06-18 14:07, Lindenmaier, Goetz wrote: >> Hi Mikael, >> >> Thanks! David offered to sponsor too. >> Please tell him in case you pushed it to jprt, I can only >> tell once it's submitted. >> >> Best regards, >> Goetz. >> >> -----Original Message----- >> From: Mikael Gerdin [mailto:mikael.gerdin at oracle.com] >> Sent: Donnerstag, 18. Juni 2015 13:06 >> To: David Holmes; Lindenmaier, Goetz; Kim Barrett >> Cc: HotSpot Developers >> Subject: Re: RFR(S): 8087183: Fix call to inline function is_oop in header >> debugInfo.hpp. [needs sponsor] >> >> I can sponsor it. >> /Mikael >> >> On 2015-06-18 12:57, David Holmes wrote: >>> Hi Goetz, >>> >>> I can sponsor in about 11 hours if noone else picks it up overnight :) >>> >>> David >>> >>> On 18/06/2015 8:41 PM, Lindenmaier, Goetz wrote: >>>> Hi, >>>> >>>> could someone please sponsor this fix? >>>> It's required to fix the fastdebug build on aix. >>>> >>>> Thanks a lot! >>>> Goetz. >>>> >>>> -----Original Message----- >>>> From: Lindenmaier, Goetz >>>> Sent: Montag, 15. Juni 2015 11:21 >>>> To: 'David Holmes'; 'Kim Barrett' >>>> Cc: 'HotSpot Developers' >>>> Subject: RE: RFR(S): 8087183: Fix call to inline function is_oop in >>>> header debugInfo.hpp. >>>> >>>> Hi, >>>> >>>> I updated the call to is_oop to do "or_null", and fixed the Copyrights. >>>> I also added the reviewers to the change comment. >>>> http://cr.openjdk.java.net/~goetz/webrevs/8087183-is_oop/webrev-02/ >>>> >>>> Could someone please sponsor this tiny change? >>>> >>>> Thanks and best regards, >>>> Goetz. >>>> >>>> -----Original Message----- >>>> From: Lindenmaier, Goetz >>>> Sent: Freitag, 12. Juni 2015 08:54 >>>> To: 'David Holmes'; Kim Barrett >>>> Cc: HotSpot Developers >>>> Subject: RE: RFR(S): 8087183: Fix call to inline function is_oop in >>>> header debugInfo.hpp. >>>> >>>> Hi, >>>> >>>> Thanks for the reviews! Could someone please sponsor this? >>>> >>>> We started to track down the cause by searching and building the repo, >>>> but then >>>> we narrowed in down to two merges ... and aix builds rather slow. I >>>> quit this task >>>> then. >>>> >>>> But the file drags in a lot of os/aix and os_cpu/aix_ppc files. The >>>> includes in these >>>> files differ from those in other platform directories. And with one >>>> of the >>>> include cleanup changes in a shared file the indirect include that >>>> must have been >>>> there at some point vanished I guess. >>>> >>>> But no matter, is_oop should not be called in a header file ... >>>> >>>> Best regards, >>>> Goetz. >>>> >>>> -----Original Message----- >>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>> Sent: Freitag, 12. Juni 2015 04:07 >>>> To: Kim Barrett; Lindenmaier, Goetz >>>> Cc: HotSpot Developers >>>> Subject: Re: RFR(S): 8087183: Fix call to inline function is_oop in >>>> header debugInfo.hpp. >>>> >>>> On 12/06/2015 3:17 AM, Kim Barrett wrote: >>>>> On Jun 11, 2015, at 5:02 AM, Lindenmaier, Goetz >>>>> wrote: >>>>>> >>>>>> Hi, >>>>>> >>>>>> in debugInfo.hpp is_oop() is called. This is an inline function >>>>>> defined in oop.inline.hpp. >>>>>> As oop.inline.hpp is not included in debugInfo.hpp, and it should >>>>>> not be included there, >>>>>> this leads to compilation failures in the fastdebug build on aix. >>>>>> >>>>>> To fix this, I just move the function calling is_oop to >>>>>> debugInfo.cpp. In that file also the >>>>>> only call to that function is located, so that it still can be >>>>>> inlined. >>>>>> >>>>>> Please review this change. I please need a sponsor. >>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8087183-is_oop/webrev-01/ >>>>>> >>>>>> Best regards, >>>>>> Goetz. >>>>> >>>>> Looks good. >>>>> >>>>> I'm mildly surprised this doesn't run into problems on other >>>>> platforms. >>>> >>>> Me too. My first thought was precompiled headers, but this code has >>>> been >>>> in place for a couple of years - so why is it now a problem ?? >>>> >>>> David >>>> >>>> >>>>> The assert could use oop->is_oop_or_null(), though it makes no >>>>> difference for this problem. >>>>> > From christian.thalinger at oracle.com Thu Jun 18 16:02:20 2015 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 18 Jun 2015 09:02:20 -0700 Subject: Ping: RFR(M): 8086069: Adapt runtime calls to recent intrinsics to pass ints as long In-Reply-To: References: <4295855A5C1DE049A61835A1887419CC2CFF9D17@DEWDFEMB12A.global.corp.sap> <57EF8CC4-3CB7-488E-89D4-5AE5EA3C99AA@oracle.com> <557F68C6.4050805@oracle.com> <557F9E91.7020603@oracle.com> Message-ID: <754964BF-CC0D-4324-8AAC-11799847BFEE@oracle.com> > On Jun 15, 2015, at 9:13 PM, John Rose wrote: > > On Jun 15, 2015, at 8:57 PM, Dean Long wrote: >> >> Thanks for the explanation. It sounds like we are modeling the abstract Java stack representation of long and double, and this wouldn't be >> easy to change, because I see things like "TypeFunc::Parms + 1" and "argument(2)" that would need to change before this could go away. > > Indeed. Slot pairs are a mess, an optimization (or concession) for platforms that no longer matter. (Primitives might look like that in a few years.) Some messes in HotSpot stem (IMO) from excessive attention to the bytecode syntax, designing a managed execution engine around the oddities of a code format. > > In an ideal world, I would like to isolate, deprecate, and eventually remove the "evil twin" slots, since they no longer have any meaning (except maybe on some 32-bit systems). Doing it at all levels will be hard, except in the context of some other breaking change. But it could be done locally in the JVM, removing the notion of twin slots from modules that don't have an absolute need to work with them. JITs shouldn't have to know about them, IMO; maybe not even the interpreter (though that would involve a renumbering prepass). > > When we get value types, we may be able to make such a change, even to the bytecode syntax itself. Or perhaps we will perpetuate the "evil twin" convention, but apply it to all value types (plus long and double). Or perhaps (happy thought) we can make every value/ref/prim occupy one stack slot, in some bytecode of the future. I?m all for happy thoughts :-) > > ? John From gerard.ziemski at oracle.com Thu Jun 18 19:58:26 2015 From: gerard.ziemski at oracle.com (Gerard Ziemski) Date: Thu, 18 Jun 2015 14:58:26 -0500 Subject: RFR 8059557: Test set for "Validate JVM Command-Line Flag Arguments" In-Reply-To: <5581CAA0.8010606@oracle.com> References: <555A09B8.7010402@oracle.com> <555E46A7.4020402@oracle.com> <55671906.10000@oracle.com> <556D3597.8090508@oracle.com> <556F0559.3080601@oracle.com> <558047AC.6040705@oracle.com> <55818D36.3020908@oracle.com> <5581CAA0.8010606@oracle.com> Message-ID: <558322E2.4050501@oracle.com> Looks good! cheers On 6/17/2015 2:29 PM, Dmitry Dmitriev wrote: > Hi Gerard, > > Can you please look at small enhancement that I made by Christian > suggestion - ran test JVM with the same type as current(for all cases, > not only for "-client" as in 06 webrev). Tested by JPRT. Sorry for > confusion. Thank you! > > Webrev: http://cr.openjdk.java.net/~ddmitriev/8059557/webrev.07/ > Webrev incremental(from 06): > http://cr.openjdk.java.net/~ddmitriev/8059557/webrev.07.incremental.from06/ > > Regards, > Dmitry > > On 17.06.2015 18:07, Gerard Ziemski wrote: >> hi Dmitry, >> >> Please consider this reviewed (with small "r"). >> >> Just one quick question: is there an issue filed to followup on why >> the test hangs with CICompiler and to enable it back, once we figure >> it out? >> >> >> cheers >> >> On 6/16/2015 10:58 AM, Dmitry Dmitriev wrote: >>> Hello, >>> >>> Here a updated version of test set for Command Line Option >>> Validation. The main changes are: added new options types - int and >>> uint, added @modules, test all options with range in >>> TestOptionsWithRanges.java test. >>> >>> Tested: JPRT >>> >>> Webrev: http://cr.openjdk.java.net/~ddmitriev/8059557/webrev.05/ >>> >>> Webrev incremental(from 04): >>> http://cr.openjdk.java.net/~ddmitriev/8059557/webrev.05.incremental/ >>> >>> JEP: https://bugs.openjdk.java.net/browse/JDK-8059557 >>> >>> Thanks, >>> Dmitry >>> >>> On 03.06.2015 16:47, Dmitry Dmitriev wrote: >>>> Hello David, >>>> >>>> Thank you for pointing on style/grammar mistakes! I corrected all >>>> of them. >>>> Here a link to the updated >>>> webrev:http://cr.openjdk.java.net/~ddmitriev/8059557/webrev.04/ >>>> >>>> >>>> About "options validation" package - I agree that this looks odd, >>>> but if you don't mind I prefer to leave it. It slightly simplify >>>> calling static methods by using static import and also I use >>>> package-private access level. >>>> >>>> Regards, >>>> Dmitry >>>> >>>> On 02.06.2015 7:48, David Holmes wrote: >>>>> Hi Dmitry, >>>>> >>>>> On 28/05/2015 11:32 PM, Dmitry Dmitriev wrote: >>>>>> Hello all, >>>>>> >>>>>> Here is a 3 version of the tests taking into account feedback from >>>>>> Christian, David and Gerard. >>>>>> >>>>>> I limit number of options in TestOptionsWithRanges.java to 15. This >>>>>> include options of different types(intx, uintx etc.) and with >>>>>> different >>>>>> combination of min/max range. TestOptionsWithRangesDynamic.java >>>>>> leaved >>>>>> as is, because amount of manageable numeric options is very small >>>>>> and >>>>>> currently only 3 of them have range. Also, I improve code for double >>>>>> option. >>>>>> >>>>>> Webrev: http://cr.openjdk.java.net/~ddmitriev/8059557/webrev.03/ >>>>>> >>>>> >>>>> Only a few style/grammar nits (the downside of writing so many doc >>>>> comments :) ). >>>>> >>>>> Meta-question: is there a specific reason to use the package >>>>> "options validation"? It looks odd to me to have >>>>> OptionsValidation/common/optionsvalidation/ in the paths. >>>>> >>>>> General doc-comment comments: >>>>> - @param/@return descriptions should start with lower-case (you >>>>> currently mix-n-match) >>>>> - @throws description should start with "if", so: >>>>> @throws IOException if an error occurred reading the data >>>>> >>>>> >>>>> General Java-style comments: >>>>> - access modifiers (public, private, protected) always come first >>>>> >>>>> --- >>>>> >>>>> test/runtime/CommandLine/OptionsValidation/common/optionsvalidation/IntJVMOption.java >>>>> >>>>> >>>>> 265 * passed value is negative then error will be >>>>> catched earlier for >>>>> >>>>> catched -> caught >>>>> >>>>> --- >>>>> >>>>> test/runtime/CommandLine/OptionsValidation/common/optionsvalidation/JVMOption.java >>>>> >>>>> >>>>> 327 * @param param Tested parameter passed to the java >>>>> >>>>> "the java" is not a noun - suggest "the JVM" ? >>>>> >>>>> Maybe change Java to JVM to avoid use of "java" as a noun everywhere. >>>>> >>>>> 350 failedMessage(name, fullOptionString, valid, "JVM >>>>> output reports about fatal error. JVM exit with code " + >>>>> returnCode + "!"); >>>>> >>>>> The message isn't grammatically correct: about -> a; exit -> exited >>>>> >>>>> Similarly "JVM exit" -> "JVM exited" >>>>> >>>>> 377 failedMessage(name, fullOptionString, valid, >>>>> "JVM output not contains " >>>>> >>>>> not contains -> does not contain >>>>> >>>>> 400 * Return list of strings which contain options with valid >>>>> values which used >>>>> >>>>> which used -> which can be used >>>>> >>>>> 416 * Return list of strings which contain options with >>>>> invalid values which >>>>> 417 * used for testing on command line >>>>> >>>>> Ditto >>>>> >>>>> --- >>>>> >>>>> test/runtime/CommandLine/OptionsValidation/common/optionsvalidation/JVMOptionsUtils.java >>>>> >>>>> >>>>> 101 * Add dependency for option depending on it's type. E.g. >>>>> ran java in >>>>> >>>>> ran java -> run the JVM >>>>> >>>>> 119 * @param withRanges true if needed options with defined >>>>> ranges >>>>> >>>>> I'm not sure what this means. Occurs elswhere too. >>>>> >>>>> 121 * "product", "diagnostic" etc. Accept option only if >>>>> acceptOrigin return >>>>> >>>>> return -> returns (or even return -> evaluates). Occurs elsewhere >>>>> too. >>>>> >>>>> 260 * methods. Tested only writeable options. >>>>> >>>>> Suggestion: Only tests writeable options. Occurs elsewhere too. >>>>> >>>>> 264 * @throws Exception >>>>> >>>>> When? Why? Occurs elsewhere too. >>>>> >>>>> Thanks, >>>>> David >>>>> ----- >>>>> >>>>>> Thanks, >>>>>> Dmitry >>>>>> >>>>>> >>>>>> On 21.05.2015 23:57, Dmitry Dmitriev wrote: >>>>>>> Hello all, >>>>>>> >>>>>>> Recently I correct several typos, so here a new webrev for tests: >>>>>>> http://cr.openjdk.java.net/~ddmitriev/8059557/webrev.02/ >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Dmitry >>>>>>> >>>>>>> On 18.05.2015 18:48, Dmitry Dmitriev wrote: >>>>>>>> Hello all, >>>>>>>> >>>>>>>> Please review test set for verifying functionality implemented >>>>>>>> by JEP >>>>>>>> 245 "Validate JVM Command-Line Flag Arguments"(JDK-8059557). >>>>>>>> Review >>>>>>>> request for this JEP can be found there: >>>>>>>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-May/018539.html >>>>>>>> >>>>>>>> >>>>>>>> I create 3 tests for verifying options with ranges. The tests >>>>>>>> mostly >>>>>>>> rely on common/optionsvalidation/JVMOptionsUtils.java. Class in >>>>>>>> this >>>>>>>> file contains functions to get options with ranges as list(by >>>>>>>> parsing >>>>>>>> new option "-XX:+PrintFlagsRanges" output), run command line >>>>>>>> test for >>>>>>>> list of options and other. The actual test code contained in >>>>>>>> common/optionsvalidation/JVMOption.java file - testCommandLine(), >>>>>>>> testDynamic(), testJcmd() and testAttach() methods. >>>>>>>> common/optionsvalidation/IntJVMOption.java and >>>>>>>> common/optionsvalidation/DoubleJVMOption.java source files contain >>>>>>>> classes derived from JVMOption class for integer and double JVM >>>>>>>> options correspondingly. >>>>>>>> >>>>>>>> Here are description of the tests: >>>>>>>> 1) >>>>>>>> hotspot/test/runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> This test get all options with ranges by parsing output of new >>>>>>>> option >>>>>>>> "-XX:+PrintFlagsRanges" and verify these options by starting >>>>>>>> Java and >>>>>>>> passing options in command line with valid and invalid values. >>>>>>>> Currently it verifies about 106 options which have ranges. >>>>>>>> Invalid values are values which out-of-range. In test used values >>>>>>>> "min-1" and "max+1".In this case Java should always exit with >>>>>>>> code 1 >>>>>>>> and print error message about out-of-range value(with one >>>>>>>> exception, >>>>>>>> if option is unsigned and passing negative value, then >>>>>>>> out-of-range >>>>>>>> error message is not printed because error occurred earlier). >>>>>>>> Valid values are values in range, e.g. min&max and also several >>>>>>>> additional values. In this case Java should successfully exit(exit >>>>>>>> code 0) or exit with error code 1 for other reasons(low memory >>>>>>>> with >>>>>>>> certain option value etc.). In any case for values in range Java >>>>>>>> should not print messages about out of range value. >>>>>>>> In any case Java should not crash. >>>>>>>> This test excluded from JPRT because it takes long time to execute >>>>>>>> and also fails - some options with value in valid range cause >>>>>>>> Java to >>>>>>>> crash(bugs are submitted). >>>>>>>> >>>>>>>> 2) >>>>>>>> hotspot/test/runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> This test get all writeable options with ranges by parsing >>>>>>>> output of >>>>>>>> new option "-XX:+PrintFlagsRanges" and verify these options by >>>>>>>> dynamically changing it's values to the valid and invalid values. >>>>>>>> Used 3 methods for that: DynamicVMOption isValidValue and >>>>>>>> isInvalidValue methods, Jcmd and by attach method. Currently 3 >>>>>>>> writeable options with ranges are verified by this test. >>>>>>>> This test pass in JPRT. >>>>>>>> >>>>>>>> 3) >>>>>>>> hotspot/test/runtime/CommandLine/OptionsValidation/TestJcmdOutput.java >>>>>>>> >>>>>>>> >>>>>>>> This test verified output of Jcmd when out-of-range value is >>>>>>>> set to >>>>>>>> the writeable option or value violates option constraint. Also >>>>>>>> this >>>>>>>> test verify that jcmd not write error message to the target >>>>>>>> process. >>>>>>>> This test pass in JPRT. >>>>>>>> >>>>>>>> >>>>>>>> I am not write special tests for constraints for this JEP because >>>>>>>> there are exist test for that(e.g. >>>>>>>> test/runtime/CompressedOops/ObjectAlignment.java for >>>>>>>> ObjectAlignmentInBytes or >>>>>>>> hotspot/test/gc/arguments/TestHeapFreeRatio.java for >>>>>>>> MinHeapFreeRatio/MaxHeapFreeRatio). >>>>>>>> >>>>>>>> Webrev: http://cr.openjdk.java.net/~ddmitriev/8059557/webrev.00/ >>>>>>>> >>>>>>>> >>>>>>>> JEP: https://bugs.openjdk.java.net/browse/JDK-8059557 >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Dmitry >>>>>>>> >>>>>>> >>>>>> >>>> >>> >> > From david.holmes at oracle.com Thu Jun 18 22:25:11 2015 From: david.holmes at oracle.com (David Holmes) Date: Fri, 19 Jun 2015 08:25:11 +1000 Subject: RFR(S): 8087183: Fix call to inline function is_oop in header debugInfo.hpp. [needs sponsor] In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CFFB94F@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CFFB8BF@DEWDFEMB12A.global.corp.sap> <5582A404.8040204@oracle.com> <5582A633.3020603@oracle.com> <4295855A5C1DE049A61835A1887419CC2CFFB94F@DEWDFEMB12A.global.corp.sap> Message-ID: <55834547.4020400@oracle.com> Submitted to hs-comp. David On 18/06/2015 10:07 PM, Lindenmaier, Goetz wrote: > Hi Mikael, > > Thanks! David offered to sponsor too. > Please tell him in case you pushed it to jprt, I can only > tell once it's submitted. > > Best regards, > Goetz. > > -----Original Message----- > From: Mikael Gerdin [mailto:mikael.gerdin at oracle.com] > Sent: Donnerstag, 18. Juni 2015 13:06 > To: David Holmes; Lindenmaier, Goetz; Kim Barrett > Cc: HotSpot Developers > Subject: Re: RFR(S): 8087183: Fix call to inline function is_oop in header debugInfo.hpp. [needs sponsor] > > I can sponsor it. > /Mikael > > On 2015-06-18 12:57, David Holmes wrote: >> Hi Goetz, >> >> I can sponsor in about 11 hours if noone else picks it up overnight :) >> >> David >> >> On 18/06/2015 8:41 PM, Lindenmaier, Goetz wrote: >>> Hi, >>> >>> could someone please sponsor this fix? >>> It's required to fix the fastdebug build on aix. >>> >>> Thanks a lot! >>> Goetz. >>> >>> -----Original Message----- >>> From: Lindenmaier, Goetz >>> Sent: Montag, 15. Juni 2015 11:21 >>> To: 'David Holmes'; 'Kim Barrett' >>> Cc: 'HotSpot Developers' >>> Subject: RE: RFR(S): 8087183: Fix call to inline function is_oop in >>> header debugInfo.hpp. >>> >>> Hi, >>> >>> I updated the call to is_oop to do "or_null", and fixed the Copyrights. >>> I also added the reviewers to the change comment. >>> http://cr.openjdk.java.net/~goetz/webrevs/8087183-is_oop/webrev-02/ >>> >>> Could someone please sponsor this tiny change? >>> >>> Thanks and best regards, >>> Goetz. >>> >>> -----Original Message----- >>> From: Lindenmaier, Goetz >>> Sent: Freitag, 12. Juni 2015 08:54 >>> To: 'David Holmes'; Kim Barrett >>> Cc: HotSpot Developers >>> Subject: RE: RFR(S): 8087183: Fix call to inline function is_oop in >>> header debugInfo.hpp. >>> >>> Hi, >>> >>> Thanks for the reviews! Could someone please sponsor this? >>> >>> We started to track down the cause by searching and building the repo, >>> but then >>> we narrowed in down to two merges ... and aix builds rather slow. I >>> quit this task >>> then. >>> >>> But the file drags in a lot of os/aix and os_cpu/aix_ppc files. The >>> includes in these >>> files differ from those in other platform directories. And with one >>> of the >>> include cleanup changes in a shared file the indirect include that >>> must have been >>> there at some point vanished I guess. >>> >>> But no matter, is_oop should not be called in a header file ... >>> >>> Best regards, >>> Goetz. >>> >>> -----Original Message----- >>> From: David Holmes [mailto:david.holmes at oracle.com] >>> Sent: Freitag, 12. Juni 2015 04:07 >>> To: Kim Barrett; Lindenmaier, Goetz >>> Cc: HotSpot Developers >>> Subject: Re: RFR(S): 8087183: Fix call to inline function is_oop in >>> header debugInfo.hpp. >>> >>> On 12/06/2015 3:17 AM, Kim Barrett wrote: >>>> On Jun 11, 2015, at 5:02 AM, Lindenmaier, Goetz >>>> wrote: >>>>> >>>>> Hi, >>>>> >>>>> in debugInfo.hpp is_oop() is called. This is an inline function >>>>> defined in oop.inline.hpp. >>>>> As oop.inline.hpp is not included in debugInfo.hpp, and it should >>>>> not be included there, >>>>> this leads to compilation failures in the fastdebug build on aix. >>>>> >>>>> To fix this, I just move the function calling is_oop to >>>>> debugInfo.cpp. In that file also the >>>>> only call to that function is located, so that it still can be inlined. >>>>> >>>>> Please review this change. I please need a sponsor. >>>>> http://cr.openjdk.java.net/~goetz/webrevs/8087183-is_oop/webrev-01/ >>>>> >>>>> Best regards, >>>>> Goetz. >>>> >>>> Looks good. >>>> >>>> I'm mildly surprised this doesn't run into problems on other platforms. >>> >>> Me too. My first thought was precompiled headers, but this code has been >>> in place for a couple of years - so why is it now a problem ?? >>> >>> David >>> >>> >>>> The assert could use oop->is_oop_or_null(), though it makes no >>>> difference for this problem. >>>> From alejandro.murillo at oracle.com Thu Jun 18 22:56:04 2015 From: alejandro.murillo at oracle.com (Alejandro E Murillo) Date: Thu, 18 Jun 2015 16:56:04 -0600 Subject: [verona.stage] RFR 8087203: Add support for PATCH field and remove unused fields of new version string In-Reply-To: <558275D4.6030306@oracle.com> References: <5580A953.8090905@oracle.com> <558275D4.6030306@oracle.com> Message-ID: <55834C84.8010408@oracle.com> Hi David, thanks for the review, see below On 6/18/2015 1:40 AM, David Holmes wrote: > Hi Alejandro, > > I looked at the hotspot and JDK changes. > > On 17/06/2015 8:55 AM, Alejandro E Murillo wrote: >> >> Please review these changes: >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8087202 >> Webrev: http://cr.openjdk.java.net/~amurillo/9/8087202 > > hotspot/make/Makefile > > + # VERSION_PATCH Security number for version (e.g. 0) > > Comment is wrong. cut and paste. Will fix > > --- > > hotspot/src/share/vm/prims/jvm.cpp > > 3659 info->patch_version = 0; > > Why is this hard-wired to zero? Surely this should be a build variable. good catch! That should be initialized from VM_Version as well (was mimicking update version, but that was always zero for hotspot which is not the case for patch). New webrev: http://cr.openjdk.java.net/~amurillo/9/8087202.v2/hotspot/src/share/vm/prims/jvm.cpp.udiff.html > > --- > > hotspot/src/share/vm/prims/jvm.h > jdk/src/java.base/share/native/include/jvm.h > > These two files should be identical, but now have different comments > in places. will add the missing comments > > 1188 unsigned int patch_version : 8; > 1215 unsigned int patch_version : 8; > > In each case you removed two 8 bit fields and added one 8 bit field so > your bitfields no longer add up to 32 (8+8+16). But these structs seem > obsolete (due to no hotspot-express) even before the new version > changes. So I think there is still a bit of follow up work to do here. oh yes, looks like I need to keep the size of the whole structure, to avoid any misalignment that may impact performance. I thought about declaring patch to be short (16) instead, but I ended up adding a padding member, reserved3, size 8, to keep the structure size unchanged. I guess I could have changed reserved2 to 24, let me know if there's any advantage using either of those. New webrev: http://cr.openjdk.java.net/~amurillo/9/8087202.v2/hotspot/src/share/vm/prims/jvm.h.udiff.html > > --- > > hotspot/src/share/vm/runtime/java.hpp > > 110 _partially_initialized(false), > > Isn't the whole partially vs fully initialized issue dead now? Else > why delete the other code pertaining to that? yeah, I should have removed the remaining uses of that. It's gone now. > > --- > > jdk/src/java.base/share/classes/sun/misc/Version.java.template > > * @since JDK9 > > Is that the right format? I would have expected @since 9. I meant to double check that. I changed it > > 248 private static native boolean getJvmVersionInfo(); > > Does that method still need to return a boolean ? See next comment > > --- > > jdk/src/java.base/share/native/libjava/Version.c > > 50 if (!JDK_InitJvmHandle()) { > 51 JNU_ThrowInternalError(env, "Handle for JVM not found for > symbol lookup"); > 52 return JNI_FALSE; > 53 } > 54 func_p = (GetJvmVersionInfo_fp) > JDK_FindJvmEntry("JVM_GetVersionInfo"); > 55 if (func_p == NULL) { -- > 56 return JNI_FALSE; > 57 } > > this seems dead code now and so the method can't fail or throw an > exception. I thought about changing that, but I prefer if it's done as a separate change for now. will file a follow up bug, Are you ok with that? New webrev here (I tested these with JPRT, testsets hotspot and pit): http://cr.openjdk.java.net/~amurillo/9/8087202.v2/ Thanks Alejandro > > Thanks, > David > ----- > >> These are intended to: >> >> (1) Add support for the patch field of the new version string format >> (2) Remove unused fields remaining from the old version string format >> (3) Patch some jaxp initialization code to be able to handle the new >> version string. >> this will be pushed under a different bug number, but is required >> to be able to run and pass all the tests associated with >> "-testset hotspot" >> (for JFR tests the VM can't be started without that). >> These will be pushed under this sub-task: >> https://bugs.openjdk.java.net/browse/JDK-8098588 >> >> (4) Additional notes: >> (a) Some pieces of code, only necessary for 1.5 or older, were removed >> (b) update_version and special_update_version were removed >> (c) The code to parse the version string in >> jdk/test/sun/misc/Version/Version.java >> will probably change when the Version.java class is available. >> (d) As with the changes for 8085822, this is all being pushed to [1] and >> then later to jdk9/dev >> (e) These changes should address most, if not all, of the issues raised >> during >> the code review for JDK-8085822 (see also >> https://bugs.openjdk.java.net/browse/JDK-8087203) >> (f) All builds and tests pass for "-testset hotspot". >> >> [1] http://hg.openjdk.java.net/verona/stage >> >> Thanks >> -- Alejandro From alejandro.murillo at oracle.com Thu Jun 18 22:56:11 2015 From: alejandro.murillo at oracle.com (Alejandro E Murillo) Date: Thu, 18 Jun 2015 16:56:11 -0600 Subject: [verona.stage] RFR 8087203: Add support for PATCH field and remove unused fields of new version string In-Reply-To: <5582CA9D.9070207@oracle.com> References: <5580A953.8090905@oracle.com> <5582CA9D.9070207@oracle.com> Message-ID: <55834C8B.2060803@oracle.com> Thanks Alan, see below On 6/18/2015 7:41 AM, Alan Bateman wrote: > > > On 16/06/2015 23:55, Alejandro E Murillo wrote: >> >> Please review these changes: >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8087202 >> Webrev: http://cr.openjdk.java.net/~amurillo/9/8087202 > > The implementation of isJavaVersionAtLeast in the JAXP classes look > okay although I think this is code that could be removed. Joe Wang can > confirm but I think it dates back to when the JAXP API was a > standalone API and there was an attempt to keep the code in sync > across major versions. I'll create a separate bug re-examine this as > it looks like some clean-up can be done here. sounds good, in general, that code can be called a lot, so changes need to be carefully done as to avoid perf impact. So it might be better if that check can be removed > > Just on the comment "In JDK9 the version string was changed ..." will > date quickly and would be nice to say that "In JDK 8 and older then it > assumes 1.N and for JDK 9 and newer it assumes N. > > In sun.misc.Version.initVersions then InternalError instead of > RuntimeException might be more appropriate as something is really > broken if that happens. Indeed. Changed. > > Also as David pointed out, it shouldn't be @since JDK9 in the new > method. This reminds me to check if the JEP says anything about @since > tags because we already have quite a few @since 1.9. yeah, I had meant to double check that. Will change it to 9 > > In the Version.java test then the line with the pattern is really > long, maybe that could be split up to make future side-by-side views > easier to read. sure, will make it into several lines, based on components, like this: String jep223Pattern = "^([0-9]+)(\\.([0-9]+))?(\\.([0-9]+))?(\\.([0-9]+))?" + // $VNUM "(-([a-zA-Z]+))?(\\.([a-zA-Z]+))?" + // $PRE "(\\+([0-9]+))?" + // Build Number "(([-a-zA-Z0-9.]+))?$"; // $OPT see new webrev: http://cr.openjdk.java.net/~amurillo/9/8087202.v2/jdk/src/java.base/share/classes/sun/misc/Version.java.template.udiff.html > > Otherwise looks okay to me. great, thanks! Here's the new webrev (I tested these with JPRT, testsets hotspot and pit): http://cr.openjdk.java.net/~amurillo/9/8087202.v2/ Thanks! -- Alejandro From david.holmes at oracle.com Thu Jun 18 23:58:34 2015 From: david.holmes at oracle.com (David Holmes) Date: Fri, 19 Jun 2015 09:58:34 +1000 Subject: [verona.stage] RFR 8087203: Add support for PATCH field and remove unused fields of new version string In-Reply-To: <55834C84.8010408@oracle.com> References: <5580A953.8090905@oracle.com> <558275D4.6030306@oracle.com> <55834C84.8010408@oracle.com> Message-ID: <55835B2A.5060809@oracle.com> On 19/06/2015 8:56 AM, Alejandro E Murillo wrote: > > Hi David, > thanks for the review, see below > > On 6/18/2015 1:40 AM, David Holmes wrote: >> Hi Alejandro, >> >> I looked at the hotspot and JDK changes. >> >> On 17/06/2015 8:55 AM, Alejandro E Murillo wrote: >>> >>> Please review these changes: >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8087202 >>> Webrev: http://cr.openjdk.java.net/~amurillo/9/8087202 >> >> hotspot/make/Makefile >> >> + # VERSION_PATCH Security number for version (e.g. 0) >> >> Comment is wrong. > cut and paste. Will fix >> >> --- >> >> hotspot/src/share/vm/prims/jvm.cpp >> >> 3659 info->patch_version = 0; >> >> Why is this hard-wired to zero? Surely this should be a build variable. > good catch! That should be initialized from VM_Version as well > (was mimicking update version, but that was always zero for hotspot > which is not the case for patch). New webrev: > http://cr.openjdk.java.net/~amurillo/9/8087202.v2/hotspot/src/share/vm/prims/jvm.cpp.udiff.html Looks good. >> hotspot/src/share/vm/prims/jvm.h >> jdk/src/java.base/share/native/include/jvm.h >> >> These two files should be identical, but now have different comments >> in places. > will add the missing comments Ok. >> >> 1188 unsigned int patch_version : 8; >> 1215 unsigned int patch_version : 8; >> >> In each case you removed two 8 bit fields and added one 8 bit field so >> your bitfields no longer add up to 32 (8+8+16). But these structs seem >> obsolete (due to no hotspot-express) even before the new version >> changes. So I think there is still a bit of follow up work to do here. > oh yes, looks like I need to keep the size of the whole structure, > to avoid any misalignment that may impact performance. > I thought about declaring patch to be short (16) instead, > but I ended up adding a padding member, reserved3, size 8, > to keep the structure size unchanged. I guess I could have changed > reserved2 to 24, let me know if there's any advantage using either of > those. > New webrev: > http://cr.openjdk.java.net/~amurillo/9/8087202.v2/hotspot/src/share/vm/prims/jvm.h.udiff.html Looks okay, but I still think there is scope to revisit the whole purpose of this struct and the use of the reserved fields etc. Adding the 8-bit padding was the right call. >> hotspot/src/share/vm/runtime/java.hpp >> >> 110 _partially_initialized(false), >> >> Isn't the whole partially vs fully initialized issue dead now? Else >> why delete the other code pertaining to that? > yeah, I should have removed the remaining uses of that. > It's gone now. Looks good. >> jdk/src/java.base/share/classes/sun/misc/Version.java.template >> >> * @since JDK9 >> >> Is that the right format? I would have expected @since 9. > I meant to double check that. I changed it Ok. As Alan says the use of 9 versus 1.9 will need to be sorted out but that's a separate issue. >> >> 248 private static native boolean getJvmVersionInfo(); >> >> Does that method still need to return a boolean ? See next comment >> >> --- >> >> jdk/src/java.base/share/native/libjava/Version.c >> >> 50 if (!JDK_InitJvmHandle()) { >> 51 JNU_ThrowInternalError(env, "Handle for JVM not found for >> symbol lookup"); >> 52 return JNI_FALSE; >> 53 } >> 54 func_p = (GetJvmVersionInfo_fp) >> JDK_FindJvmEntry("JVM_GetVersionInfo"); >> 55 if (func_p == NULL) { -- >> 56 return JNI_FALSE; >> 57 } >> >> this seems dead code now and so the method can't fail or throw an >> exception. > I thought about changing that, but I prefer if it's done > as a separate change for now. will file a follow up bug, > Are you ok with that? Follow up RFE is fine. > New webrev here (I tested these with JPRT, testsets hotspot and pit): > > http://cr.openjdk.java.net/~amurillo/9/8087202.v2/ No further comments from me. Thanks, David > Thanks > Alejandro > >> >> Thanks, >> David >> ----- >> >>> These are intended to: >>> >>> (1) Add support for the patch field of the new version string format >>> (2) Remove unused fields remaining from the old version string format >>> (3) Patch some jaxp initialization code to be able to handle the new >>> version string. >>> this will be pushed under a different bug number, but is required >>> to be able to run and pass all the tests associated with >>> "-testset hotspot" >>> (for JFR tests the VM can't be started without that). >>> These will be pushed under this sub-task: >>> https://bugs.openjdk.java.net/browse/JDK-8098588 >>> >>> (4) Additional notes: >>> (a) Some pieces of code, only necessary for 1.5 or older, were removed >>> (b) update_version and special_update_version were removed >>> (c) The code to parse the version string in >>> jdk/test/sun/misc/Version/Version.java >>> will probably change when the Version.java class is available. >>> (d) As with the changes for 8085822, this is all being pushed to [1] and >>> then later to jdk9/dev >>> (e) These changes should address most, if not all, of the issues raised >>> during >>> the code review for JDK-8085822 (see also >>> https://bugs.openjdk.java.net/browse/JDK-8087203) >>> (f) All builds and tests pass for "-testset hotspot". >>> >>> [1] http://hg.openjdk.java.net/verona/stage >>> >>> Thanks >>> > From vladimir.kozlov at oracle.com Fri Jun 19 01:21:25 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 18 Jun 2015 18:21:25 -0700 Subject: RFR(S): 8087183: Fix call to inline function is_oop in header debugInfo.hpp. [needs sponsor] In-Reply-To: <55834547.4020400@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CFFB8BF@DEWDFEMB12A.global.corp.sap> <5582A404.8040204@oracle.com> <5582A633.3020603@oracle.com> <4295855A5C1DE049A61835A1887419CC2CFFB94F@DEWDFEMB12A.global.corp.sap> <55834547.4020400@oracle.com> Message-ID: <55836E95.8010400@oracle.com> David, I rerun your job, it passed second time. New GHASH intrinsic code size is bigger then reserved stubs size only on some Windows machines: code_size2 = 22000 // simply increase if too small (assembler will crash if too small) May be because some external addresses which are accessed in code are far and additional register is used to load it. The fix is coming (increase code_size2). Thanks, Vladimir On 6/18/15 3:25 PM, David Holmes wrote: > Submitted to hs-comp. > > David > > On 18/06/2015 10:07 PM, Lindenmaier, Goetz wrote: >> Hi Mikael, >> >> Thanks! David offered to sponsor too. >> Please tell him in case you pushed it to jprt, I can only >> tell once it's submitted. >> >> Best regards, >> Goetz. >> >> -----Original Message----- >> From: Mikael Gerdin [mailto:mikael.gerdin at oracle.com] >> Sent: Donnerstag, 18. Juni 2015 13:06 >> To: David Holmes; Lindenmaier, Goetz; Kim Barrett >> Cc: HotSpot Developers >> Subject: Re: RFR(S): 8087183: Fix call to inline function is_oop in >> header debugInfo.hpp. [needs sponsor] >> >> I can sponsor it. >> /Mikael >> >> On 2015-06-18 12:57, David Holmes wrote: >>> Hi Goetz, >>> >>> I can sponsor in about 11 hours if noone else picks it up overnight :) >>> >>> David >>> >>> On 18/06/2015 8:41 PM, Lindenmaier, Goetz wrote: >>>> Hi, >>>> >>>> could someone please sponsor this fix? >>>> It's required to fix the fastdebug build on aix. >>>> >>>> Thanks a lot! >>>> Goetz. >>>> >>>> -----Original Message----- >>>> From: Lindenmaier, Goetz >>>> Sent: Montag, 15. Juni 2015 11:21 >>>> To: 'David Holmes'; 'Kim Barrett' >>>> Cc: 'HotSpot Developers' >>>> Subject: RE: RFR(S): 8087183: Fix call to inline function is_oop in >>>> header debugInfo.hpp. >>>> >>>> Hi, >>>> >>>> I updated the call to is_oop to do "or_null", and fixed the Copyrights. >>>> I also added the reviewers to the change comment. >>>> http://cr.openjdk.java.net/~goetz/webrevs/8087183-is_oop/webrev-02/ >>>> >>>> Could someone please sponsor this tiny change? >>>> >>>> Thanks and best regards, >>>> Goetz. >>>> >>>> -----Original Message----- >>>> From: Lindenmaier, Goetz >>>> Sent: Freitag, 12. Juni 2015 08:54 >>>> To: 'David Holmes'; Kim Barrett >>>> Cc: HotSpot Developers >>>> Subject: RE: RFR(S): 8087183: Fix call to inline function is_oop in >>>> header debugInfo.hpp. >>>> >>>> Hi, >>>> >>>> Thanks for the reviews! Could someone please sponsor this? >>>> >>>> We started to track down the cause by searching and building the repo, >>>> but then >>>> we narrowed in down to two merges ... and aix builds rather slow. I >>>> quit this task >>>> then. >>>> >>>> But the file drags in a lot of os/aix and os_cpu/aix_ppc files. The >>>> includes in these >>>> files differ from those in other platform directories. And with one >>>> of the >>>> include cleanup changes in a shared file the indirect include that >>>> must have been >>>> there at some point vanished I guess. >>>> >>>> But no matter, is_oop should not be called in a header file ... >>>> >>>> Best regards, >>>> Goetz. >>>> >>>> -----Original Message----- >>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>> Sent: Freitag, 12. Juni 2015 04:07 >>>> To: Kim Barrett; Lindenmaier, Goetz >>>> Cc: HotSpot Developers >>>> Subject: Re: RFR(S): 8087183: Fix call to inline function is_oop in >>>> header debugInfo.hpp. >>>> >>>> On 12/06/2015 3:17 AM, Kim Barrett wrote: >>>>> On Jun 11, 2015, at 5:02 AM, Lindenmaier, Goetz >>>>> wrote: >>>>>> >>>>>> Hi, >>>>>> >>>>>> in debugInfo.hpp is_oop() is called. This is an inline function >>>>>> defined in oop.inline.hpp. >>>>>> As oop.inline.hpp is not included in debugInfo.hpp, and it should >>>>>> not be included there, >>>>>> this leads to compilation failures in the fastdebug build on aix. >>>>>> >>>>>> To fix this, I just move the function calling is_oop to >>>>>> debugInfo.cpp. In that file also the >>>>>> only call to that function is located, so that it still can be >>>>>> inlined. >>>>>> >>>>>> Please review this change. I please need a sponsor. >>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8087183-is_oop/webrev-01/ >>>>>> >>>>>> Best regards, >>>>>> Goetz. >>>>> >>>>> Looks good. >>>>> >>>>> I'm mildly surprised this doesn't run into problems on other >>>>> platforms. >>>> >>>> Me too. My first thought was precompiled headers, but this code has >>>> been >>>> in place for a couple of years - so why is it now a problem ?? >>>> >>>> David >>>> >>>> >>>>> The assert could use oop->is_oop_or_null(), though it makes no >>>>> difference for this problem. >>>>> From david.holmes at oracle.com Fri Jun 19 01:27:14 2015 From: david.holmes at oracle.com (David Holmes) Date: Fri, 19 Jun 2015 11:27:14 +1000 Subject: RFR: 8087322: Implement a Semaphore utility class In-Reply-To: <5581B597.5080900@oracle.com> References: <557AF8E4.9040804@oracle.com> <557F3582.6060401@oracle.com> <5581B597.5080900@oracle.com> Message-ID: <55836FF2.6070604@oracle.com> Hi Stefan, Sorry for the delay ... On 18/06/2015 3:59 AM, Stefan Karlsson wrote: > Hi again, > > Here's a version that gets rid of the max parameter: Great! This is looking really good! > http://cr.openjdk.java.net/~stefank/8087322/webrev.02.delta > http://cr.openjdk.java.net/~stefank/8087322/webrev.02 > > The patch also contains a few minor cleanups and removes the redundant > BsdSemaphore::trywait(), which is already defined in PosixSemaphore. The interaction with the sr_semaphore complicates things. If we push its API up to being the Semaphore API then we have to implement unused functionality on Windows (and perhaps AIX?). If instead we subclass Semaphore to extend the API then we have to duplicate some of the code, even across POSIX systems. :( Unfortunate but I don't see a better approach than what you have chosen (and the Apple vs other-BSD also complicates things). One thing I am tempted to clean up a little more is the timedwait call. PosixSemaphore timedwait takes a timespec to pass to the underlying sem_timedwait. But the primary API is timed_wait(long secs, int nsecs) which each PosixSemaphore subclass has to add, and each then has to perform the "unpackTime" mechanics (which in itself is something screaming to be cleaned up). What if PosixSemaphore defined: class PosixSemaphore : public Semaphore { public: PosixSemaphore(uint value = 0) : Semaphore(value) {} bool trywait(); bool timedwait(unsigned int sec, int nsec); protected: virtual void rel_to_abs_timespec(struct timespec* ts, unsigned int sec, int nsec) = 0; }; then: bool os::PosixSemaphore::timedwait(unsigned int sec, int nsec) { struct timespec ts; rel_to_abs_timespec(&ts, sec nsecs); while (true) { int result = sem_timedwait(&_semaphore, &ts); ... } } and then just define the rel_to_abs_timespec functions for BSD, linux and Solaris subclasses. ? --- The sr_semaphore appears to be being initialized by C++ static initialization, which is a concern for me, primarily because Semaphore construction requires allocation support (it's a CHeapObj) and utilizes NMT. I get very nervous when NMT gets involved prior to VM initialization. Can we make sr_semaphore a pointer instead and initialize it in one of the os::init methods? --- A few specific comments ... src/os/posix/vm/os_posix.cpp Two nits that I know have been copied from the existing code: 1061 while (1) { I prefer while (true) 1069 } else { 1070 return false; 1071 } This is returning false when an error has occurred. At a minimum there should be an assert(false, "...") so that we detect this in debug builds. --- src/share/vm/utilities/semaphore.hpp Can we not implement this: 53 void signal(); 54 void signal(uint count); as simply: void signal(uint count = 1); ? --- src/share/vm/utilities/semaphore.cpp: The logic in test_semaphore_many isn't quite right. For example if you call it with value=0, max=2, increment=1, then you will end up performing two signals() but only one wait(). Thanks, David ----- > Thanks, > StefanK > > On 2015-06-15 22:28, Stefan Karlsson wrote: >> Hi again, >> >> I've hopefully addressed some of Kim's and David's concerns with the >> following version: >> >> http://cr.openjdk.java.net/~stefank/8087322/webrev.01.delta/ >> http://cr.openjdk.java.net/~stefank/8087322/webrev.01/ >> >> Changes in the current version of the patch: >> >> - Created a POSIX version that is used by Linux and Solaris (and maybe >> AIX?). >> >> - Use asserts instead of guarantees. (I've got offline feedback that >> others preferred at least some of the guarantees.) >> >> - Print the errno value and the errno string in the posix version >> >> - Removed trywait and timedwait from the Semaphore class and added >> that functionality in platform-specific semaphore classes. This gets >> rid of the Unimplemented() functions in os_windows.cpp. >> >> - I removed the IMPLEMENTS_SEMAPHORE_CLASS define. >> >> Some comments about the current patch: >> >> - I have not removed the 'max' parameter, since I haven't yet figured >> out what the max value should be used for windows. >> >> - OS X doesn't implement unamed POSIX semaphores, so I have to go >> through hoops to compile out the POXIS version when building on OS X. >> >> - I had to add -lrt to get the patch to link on Solaris. >> >> Tested with JPRT, >> >> Thanks, >> StefanK >> >> On 2015-06-12 17:21, Stefan Karlsson wrote: >>> Hi all, >>> >>> Please review this patch to create a Semaphore utility class. I need >>> this class to implementing faster GC thread synchronization [1]. >>> >>> http://cr.openjdk.java.net/~stefank/8087322/webrev.00/ >>> https://bugs.openjdk.java.net/browse/JDK-8087322 >>> >>> Some of our platforms already implement a Semaphore class, but those >>> classes are hidden inside os_.cpp. I've moved the class >>> declaration to semaphore.hpp, but the implementation is left in the >>> os_.hpp. I considered creating semaphore_.cpp files, but I >>> ended up having to restructure too much code and I wanted to focus on >>> the feature in [1] instead. Should I create a RFE to move the >>> semaphore implementations? >>> >>> There seems to be another opportunity to cleanup the code. If we take >>> os_linux.cpp, as an example, the code uses both the existing >>> Semaphore class and the global ::sem_wait and ::sem_post functions. >>> We might want to consider unifying that code. >>> >>> Since HotSpot is built on platforms that I don't have access to and >>> can't test, I've added the IMPLEMENTS_SEMAPHORE_CLASS define. So, >>> that I can detect if the the current platform implements the >>> Semaphore class, and choose what synchronization primitive to use by >>> the GC. >>> >>> The os_bsd.cpp file has support for "non-apple BSD", but I've only >>> tested this patch with OS X. >>> >>> This patch has been tested in JPRT and our nightly testing together >>> with the patches in [1]. The patch also contains a few unit tests in >>> semaphore.cpp. >>> >>> Thanks, >>> StefanK >>> >>> [1] >>> http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2015-June/013829.html >>> >> > From david.holmes at oracle.com Fri Jun 19 01:56:42 2015 From: david.holmes at oracle.com (David Holmes) Date: Fri, 19 Jun 2015 11:56:42 +1000 Subject: RFR(S): 8087183: Fix call to inline function is_oop in header debugInfo.hpp. [needs sponsor] In-Reply-To: <55836E95.8010400@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CFFB8BF@DEWDFEMB12A.global.corp.sap> <5582A404.8040204@oracle.com> <5582A633.3020603@oracle.com> <4295855A5C1DE049A61835A1887419CC2CFFB94F@DEWDFEMB12A.global.corp.sap> <55834547.4020400@oracle.com> <55836E95.8010400@oracle.com> Message-ID: <558376DA.6060003@oracle.com> On 19/06/2015 11:21 AM, Vladimir Kozlov wrote: > David, > > I rerun your job, it passed second time. I re-ran it too :) I wondered how I then got two "success" emails a few minutes apart. > New GHASH intrinsic code size is bigger then reserved stubs size only on > some Windows machines: > > code_size2 = 22000 // simply increase if too small > (assembler will crash if too small) > > May be because some external addresses which are accessed in code are > far and additional register is used to load it. The fix is coming > (increase code_size2). The initial failure was this AFAICS: https://bugs.openjdk.java.net/browse/JDK-8080157 Thanks, David > Thanks, > Vladimir > > On 6/18/15 3:25 PM, David Holmes wrote: >> Submitted to hs-comp. >> >> David >> >> On 18/06/2015 10:07 PM, Lindenmaier, Goetz wrote: >>> Hi Mikael, >>> >>> Thanks! David offered to sponsor too. >>> Please tell him in case you pushed it to jprt, I can only >>> tell once it's submitted. >>> >>> Best regards, >>> Goetz. >>> >>> -----Original Message----- >>> From: Mikael Gerdin [mailto:mikael.gerdin at oracle.com] >>> Sent: Donnerstag, 18. Juni 2015 13:06 >>> To: David Holmes; Lindenmaier, Goetz; Kim Barrett >>> Cc: HotSpot Developers >>> Subject: Re: RFR(S): 8087183: Fix call to inline function is_oop in >>> header debugInfo.hpp. [needs sponsor] >>> >>> I can sponsor it. >>> /Mikael >>> >>> On 2015-06-18 12:57, David Holmes wrote: >>>> Hi Goetz, >>>> >>>> I can sponsor in about 11 hours if noone else picks it up overnight :) >>>> >>>> David >>>> >>>> On 18/06/2015 8:41 PM, Lindenmaier, Goetz wrote: >>>>> Hi, >>>>> >>>>> could someone please sponsor this fix? >>>>> It's required to fix the fastdebug build on aix. >>>>> >>>>> Thanks a lot! >>>>> Goetz. >>>>> >>>>> -----Original Message----- >>>>> From: Lindenmaier, Goetz >>>>> Sent: Montag, 15. Juni 2015 11:21 >>>>> To: 'David Holmes'; 'Kim Barrett' >>>>> Cc: 'HotSpot Developers' >>>>> Subject: RE: RFR(S): 8087183: Fix call to inline function is_oop in >>>>> header debugInfo.hpp. >>>>> >>>>> Hi, >>>>> >>>>> I updated the call to is_oop to do "or_null", and fixed the >>>>> Copyrights. >>>>> I also added the reviewers to the change comment. >>>>> http://cr.openjdk.java.net/~goetz/webrevs/8087183-is_oop/webrev-02/ >>>>> >>>>> Could someone please sponsor this tiny change? >>>>> >>>>> Thanks and best regards, >>>>> Goetz. >>>>> >>>>> -----Original Message----- >>>>> From: Lindenmaier, Goetz >>>>> Sent: Freitag, 12. Juni 2015 08:54 >>>>> To: 'David Holmes'; Kim Barrett >>>>> Cc: HotSpot Developers >>>>> Subject: RE: RFR(S): 8087183: Fix call to inline function is_oop in >>>>> header debugInfo.hpp. >>>>> >>>>> Hi, >>>>> >>>>> Thanks for the reviews! Could someone please sponsor this? >>>>> >>>>> We started to track down the cause by searching and building the repo, >>>>> but then >>>>> we narrowed in down to two merges ... and aix builds rather slow. I >>>>> quit this task >>>>> then. >>>>> >>>>> But the file drags in a lot of os/aix and os_cpu/aix_ppc files. The >>>>> includes in these >>>>> files differ from those in other platform directories. And with one >>>>> of the >>>>> include cleanup changes in a shared file the indirect include that >>>>> must have been >>>>> there at some point vanished I guess. >>>>> >>>>> But no matter, is_oop should not be called in a header file ... >>>>> >>>>> Best regards, >>>>> Goetz. >>>>> >>>>> -----Original Message----- >>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>> Sent: Freitag, 12. Juni 2015 04:07 >>>>> To: Kim Barrett; Lindenmaier, Goetz >>>>> Cc: HotSpot Developers >>>>> Subject: Re: RFR(S): 8087183: Fix call to inline function is_oop in >>>>> header debugInfo.hpp. >>>>> >>>>> On 12/06/2015 3:17 AM, Kim Barrett wrote: >>>>>> On Jun 11, 2015, at 5:02 AM, Lindenmaier, Goetz >>>>>> wrote: >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> in debugInfo.hpp is_oop() is called. This is an inline function >>>>>>> defined in oop.inline.hpp. >>>>>>> As oop.inline.hpp is not included in debugInfo.hpp, and it should >>>>>>> not be included there, >>>>>>> this leads to compilation failures in the fastdebug build on aix. >>>>>>> >>>>>>> To fix this, I just move the function calling is_oop to >>>>>>> debugInfo.cpp. In that file also the >>>>>>> only call to that function is located, so that it still can be >>>>>>> inlined. >>>>>>> >>>>>>> Please review this change. I please need a sponsor. >>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8087183-is_oop/webrev-01/ >>>>>>> >>>>>>> Best regards, >>>>>>> Goetz. >>>>>> >>>>>> Looks good. >>>>>> >>>>>> I'm mildly surprised this doesn't run into problems on other >>>>>> platforms. >>>>> >>>>> Me too. My first thought was precompiled headers, but this code has >>>>> been >>>>> in place for a couple of years - so why is it now a problem ?? >>>>> >>>>> David >>>>> >>>>> >>>>>> The assert could use oop->is_oop_or_null(), though it makes no >>>>>> difference for this problem. >>>>>> From vladimir.kozlov at oracle.com Fri Jun 19 02:20:05 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 18 Jun 2015 19:20:05 -0700 Subject: RFR(S): 8087183: Fix call to inline function is_oop in header debugInfo.hpp. [needs sponsor] In-Reply-To: <558376DA.6060003@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CFFB8BF@DEWDFEMB12A.global.corp.sap> <5582A404.8040204@oracle.com> <5582A633.3020603@oracle.com> <4295855A5C1DE049A61835A1887419CC2CFFB94F@DEWDFEMB12A.global.corp.sap> <55834547.4020400@oracle.com> <55836E95.8010400@oracle.com> <558376DA.6060003@oracle.com> Message-ID: <55837C55.8080203@oracle.com> Thank you for pointing 8080157. I took it. Thanks, Vladimir On 6/18/15 6:56 PM, David Holmes wrote: > On 19/06/2015 11:21 AM, Vladimir Kozlov wrote: >> David, >> >> I rerun your job, it passed second time. > > I re-ran it too :) I wondered how I then got two "success" emails a few > minutes apart. > >> New GHASH intrinsic code size is bigger then reserved stubs size only on >> some Windows machines: >> >> code_size2 = 22000 // simply increase if too small >> (assembler will crash if too small) >> >> May be because some external addresses which are accessed in code are >> far and additional register is used to load it. The fix is coming >> (increase code_size2). > > The initial failure was this AFAICS: > > https://bugs.openjdk.java.net/browse/JDK-8080157 > > Thanks, > David > >> Thanks, >> Vladimir >> >> On 6/18/15 3:25 PM, David Holmes wrote: >>> Submitted to hs-comp. >>> >>> David >>> >>> On 18/06/2015 10:07 PM, Lindenmaier, Goetz wrote: >>>> Hi Mikael, >>>> >>>> Thanks! David offered to sponsor too. >>>> Please tell him in case you pushed it to jprt, I can only >>>> tell once it's submitted. >>>> >>>> Best regards, >>>> Goetz. >>>> >>>> -----Original Message----- >>>> From: Mikael Gerdin [mailto:mikael.gerdin at oracle.com] >>>> Sent: Donnerstag, 18. Juni 2015 13:06 >>>> To: David Holmes; Lindenmaier, Goetz; Kim Barrett >>>> Cc: HotSpot Developers >>>> Subject: Re: RFR(S): 8087183: Fix call to inline function is_oop in >>>> header debugInfo.hpp. [needs sponsor] >>>> >>>> I can sponsor it. >>>> /Mikael >>>> >>>> On 2015-06-18 12:57, David Holmes wrote: >>>>> Hi Goetz, >>>>> >>>>> I can sponsor in about 11 hours if noone else picks it up overnight :) >>>>> >>>>> David >>>>> >>>>> On 18/06/2015 8:41 PM, Lindenmaier, Goetz wrote: >>>>>> Hi, >>>>>> >>>>>> could someone please sponsor this fix? >>>>>> It's required to fix the fastdebug build on aix. >>>>>> >>>>>> Thanks a lot! >>>>>> Goetz. >>>>>> >>>>>> -----Original Message----- >>>>>> From: Lindenmaier, Goetz >>>>>> Sent: Montag, 15. Juni 2015 11:21 >>>>>> To: 'David Holmes'; 'Kim Barrett' >>>>>> Cc: 'HotSpot Developers' >>>>>> Subject: RE: RFR(S): 8087183: Fix call to inline function is_oop in >>>>>> header debugInfo.hpp. >>>>>> >>>>>> Hi, >>>>>> >>>>>> I updated the call to is_oop to do "or_null", and fixed the >>>>>> Copyrights. >>>>>> I also added the reviewers to the change comment. >>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8087183-is_oop/webrev-02/ >>>>>> >>>>>> Could someone please sponsor this tiny change? >>>>>> >>>>>> Thanks and best regards, >>>>>> Goetz. >>>>>> >>>>>> -----Original Message----- >>>>>> From: Lindenmaier, Goetz >>>>>> Sent: Freitag, 12. Juni 2015 08:54 >>>>>> To: 'David Holmes'; Kim Barrett >>>>>> Cc: HotSpot Developers >>>>>> Subject: RE: RFR(S): 8087183: Fix call to inline function is_oop in >>>>>> header debugInfo.hpp. >>>>>> >>>>>> Hi, >>>>>> >>>>>> Thanks for the reviews! Could someone please sponsor this? >>>>>> >>>>>> We started to track down the cause by searching and building the >>>>>> repo, >>>>>> but then >>>>>> we narrowed in down to two merges ... and aix builds rather slow. I >>>>>> quit this task >>>>>> then. >>>>>> >>>>>> But the file drags in a lot of os/aix and os_cpu/aix_ppc files. The >>>>>> includes in these >>>>>> files differ from those in other platform directories. And with one >>>>>> of the >>>>>> include cleanup changes in a shared file the indirect include that >>>>>> must have been >>>>>> there at some point vanished I guess. >>>>>> >>>>>> But no matter, is_oop should not be called in a header file ... >>>>>> >>>>>> Best regards, >>>>>> Goetz. >>>>>> >>>>>> -----Original Message----- >>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>> Sent: Freitag, 12. Juni 2015 04:07 >>>>>> To: Kim Barrett; Lindenmaier, Goetz >>>>>> Cc: HotSpot Developers >>>>>> Subject: Re: RFR(S): 8087183: Fix call to inline function is_oop in >>>>>> header debugInfo.hpp. >>>>>> >>>>>> On 12/06/2015 3:17 AM, Kim Barrett wrote: >>>>>>> On Jun 11, 2015, at 5:02 AM, Lindenmaier, Goetz >>>>>>> wrote: >>>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> in debugInfo.hpp is_oop() is called. This is an inline function >>>>>>>> defined in oop.inline.hpp. >>>>>>>> As oop.inline.hpp is not included in debugInfo.hpp, and it should >>>>>>>> not be included there, >>>>>>>> this leads to compilation failures in the fastdebug build on aix. >>>>>>>> >>>>>>>> To fix this, I just move the function calling is_oop to >>>>>>>> debugInfo.cpp. In that file also the >>>>>>>> only call to that function is located, so that it still can be >>>>>>>> inlined. >>>>>>>> >>>>>>>> Please review this change. I please need a sponsor. >>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8087183-is_oop/webrev-01/ >>>>>>>> >>>>>>>> Best regards, >>>>>>>> Goetz. >>>>>>> >>>>>>> Looks good. >>>>>>> >>>>>>> I'm mildly surprised this doesn't run into problems on other >>>>>>> platforms. >>>>>> >>>>>> Me too. My first thought was precompiled headers, but this code has >>>>>> been >>>>>> in place for a couple of years - so why is it now a problem ?? >>>>>> >>>>>> David >>>>>> >>>>>> >>>>>>> The assert could use oop->is_oop_or_null(), though it makes no >>>>>>> difference for this problem. >>>>>>> From david.holmes at oracle.com Fri Jun 19 03:32:11 2015 From: david.holmes at oracle.com (David Holmes) Date: Fri, 19 Jun 2015 13:32:11 +1000 Subject: RFR(s): 8078513: [linux] Clean up code relevant to LinuxThreads implementation In-Reply-To: References: <554FF886.7030502@oracle.com> <55540B22.70807@oracle.com> <555C48F0.8090205@oracle.com> <557A3DB3.5040002@oracle.com> Message-ID: <55838D3B.4040806@oracle.com> On 15/06/2015 10:57 PM, Thomas St?fe wrote: > Hi Volker, David, > > Volker, thanks for the review! > > new version: > > http://cr.openjdk.java.net/~stuefe/webrevs/8078513/webrev.04/webrev/ > > I added all changes Volker wanted. The copyright notice change in agent/src/os/linux/proc_service.h has the wrong format - needs comma after second year and has to remain on a single line. I'll fix before pushing. > Oh, and I forgot to add Volker as a Reviewer, please add him when pushing. Will do. I also forgot that a CCC request needed to be put in to deprecate ThreadSafetyMargin :( That will delay the push a while I'm afraid. Thanks, David > Kind Regards, Thomas > > > > > > > > On Mon, Jun 15, 2015 at 11:23 AM, Thomas St?fe > wrote: > > Hi, > > sorry, dropped the ball on this one. Will post an updated version soon. > > Thomas > > On Fri, Jun 12, 2015 at 4:02 AM, David Holmes > > wrote: > > Hi Thomas, > > If you can address Volker's comments we can move forward with > this. I'll be primary Reviewer and Volker a second reviewer. > > Thanks, > David > > On 3/06/2015 3:52 PM, Thomas St?fe wrote: > > Ping... > > Still need a second reviewer. > > Thanks! > > On Wednesday, May 20, 2015, Thomas St?fe > > >> wrote: > > David, thanks! > > to all: could I have a second reviewer, please? > > Thanks & Kind Regards, Thomas > > On Wed, May 20, 2015 at 10:42 AM, David Holmes > > ');>> wrote: > > Hi Thomas, > > Summary: ok - need second reviewer ( I think Coleen > is away) > > More inline ... > > On 19/05/2015 10:26 PM, Thomas St?fe wrote: > > Hi David, > > new webrev: > http://cr.openjdk.java.net/~stuefe/webrevs/8078513/webrev.02/webrev/ > > Only two things changed. I reverted my comment > change in the > SA and in > os_linux.cpp I massaged the > "expand-thread-stack" comment > text a bit. > > More details inline. > > On Thu, May 14, 2015 at 4:40 AM, David Holmes > > > ');> > > > ');>>> > wrote: > > Hi Thomas, > > On 14/05/2015 2:32 AM, Thomas St?fe wrote: > > Hi David, > > here the new version: > http://cr.openjdk.java.net/~stuefe/webrevs/8078513/webrev.01/webrev/ > > Differences to the old version are > just comment > changes, and I also > modified some comments in the SA as > Staffan requested. > > > agent/src/os/linux/libproc.h > > Modified comments still refer to "both thread > libraries" but now the > two libraries have not been mentioned, so > there is no > context to > know what the two libraries are. > > > I reverted my comment change to the original > version. I > think I do not > know enough about the SA internals to make the > comment clear and > concise. Someone with more SA knowledge may be > better suited > to change > that comment. > > > Ok. I think you were pretty close anyway, just need > to get rid > of the "both thread libraries" references. > > > > More commentary inline below (with > trimming)... > > > See remarks inline: > > os_linux.cpp: > > The whole MAP_GROWSDOWN > discussion and code > also seems to be no > longer relevant. > > > I spent a lot of time digging around > in the history > of this > thing. I am > unsure whether that stack expansion > coding can be > removed. There are > some rare case where they may still be > needed: > > That whole coding revolves around the > question > whether thread stacks > need to be expanded manually. > > Nowadays, normal threads allocated > with a modern > pthread library > (NPTL) > just allocate the whole stack with > mmap(without > MAP_NORESERVE), so the > memory is committed right away. See > glibc sources, > nptl/allocate_stack.c. > > In former times (LinuxThreads) thread > stacks were > allocated using > mmap(MAP_GROWSDOWN), which needed > cooperation from > the linux kernel: > kernel caught faults caused by > expanding the stack > and transparently > mapped the next page. It needed to > distinguish real > page faults from > stack expansion page faults, and seems > the logic > did not always > work, so > manual expansion was needed - see > os_linux.cpp, > "os::Linux::manually_expand_stack". > > I think there may still be cases where > we run on > threads whose > stacks > are allocated with > mmap(MAP_GROWSDOWN), even though > LinuxThreads > is gone: > > - with primordial threads (not sure, > did not test). > We do not run on > primordial thread but someone may > write a launcher > and start a > VM from > the primordial thread or attach the > primordial > thread to the VM. > > > This is already a very grey area in the > VM. See: > > https://bugs.openjdk.java.net/browse/JDK-6516512 > > "HotSpot:thread terminology should be > clearer or > cleaned up." > > So until that is investigated and cleaned > up this code > can't really > be touched. > > > Interesting and well written bug report. > Unfortunately, the > issue seems > to be in deep sleep. > > > Sadly often true :( > > At SAP, we explicitly forbid all our internal > users to > invoke the VM on > the primordial thread, and have done so since a > long time. > We tell all > our users to spawn off an own pthread for VM > creation. I > think the AIX > port will not even come up, we just assert. > > But this is more of a political question. If we > pull support > for running > on the primordial thread in the OpenJDK, there > may be > applications which > break. On the other hand, does this scenario - > running on > the primordial > thread - get tested? Would we even notice if it > were not to > work anymore? > > > There may be some JNI tests that use the primordial > thread but I > can't say for sure. > > - someone may write its own thread > implementation > using clone and > mmap(MAP_GROWSDOWN) allocated stacks. > > These cases are probably extremely > rare, and I > would have no qualms > removing support for them, but I do > not want to > decide that. > > > Fair enough. As I said I think this > expands into a > cleanup up of the > whole "initial thread" business anyway. > > Sidenote: These cases are inherently > unsafe because > mmap(MAP_GROWSDOWN) > is too. Ulrich Drepper tried without > success to > remove support > for these > flags from the linux kernel: > https://lwn.net/Articles/294001/ > > I added some comment to os_linux.cpp > to explain > this a bit better. > > > The two comments don't rely flow together > due to the > "Force Linux > kernel to expand current thread stack." > lead-in of the > second > comment (which isn't actually a > grammatically correct > sentence). But > I can't really think of anything to do > that doesn't > start making > numerous changes to what is already a > confusing and > disjointed > comment block. > > > I tried to improve the comment a bit, to > clearly distinguish > it from the > older comment and to provide enough information > for whenever > we decide > to clean up this expand-thread-stack coding. > > > Revised comment is much clearer - thanks! > > David > ----- > > > Kind Regards, Thomas > > > > > The gcc 2.x workarounds can also > be removed I > think. > > I wonder if we can also eradicate > WorkAroundNPTLTimedWaitHang :) > > > I do not dare to do that - I do not > know enough > about this issue. > > > Separate RFE. I doubt we care about the > old systems > that had this > problem. > > > Aside: The createThread_lock (now > unused) > seems to have > been copied > into src/os/aix/vm/os_aix.hpp as > part of the > AIX port and > should be > removed at some point. > > > Yes I know :-) It is not the only > Linux-specific > code which > crept into > our AIX port. We actually have a bug > open to deal > with that: > https://bugs.openjdk.java.net/browse/JDK-8079125 > > > Good to know :) > > Thanks, > David > ----- > > > --- > > src/os/linux/vm/os_linux.hpp > > Copyright needs updating. > > > done > > --- > > > src/os_cpu/linux_x86/vm/os_linux_x86.cpp > > Copyright needs updating. > > done > > > os::Linux::supports_variable_stack_size() is > now dead > code (value > is true for all arch's AFAICS) so > can be > removed from all > > src/os_cpu/linux_XXX/os_linux_XXX.cpp. > > I think > supports_variable_stack_size() is > also always true > on other > platforms (AIX, BSD) and so could > be cleaned > up in that > code too > (separate clean-up CR okay for that). > > > I agree, lets do this in a different > RFR because > this would touch > non-linux sources and I want to keep > this linux > specific. I opened > https://bugs.openjdk.java.net/browse/JDK-8080298 for this. > > > Thanks for filing. > > > > --- > > > src/os_cpu/linux_x86/vm/threadLS_linux_x86.cpp > > Copyright needs updating. > > done > > --- > > I'm happy to sponsor this for you. > > Thanks, > David > ----- > > > > This change removes (I hope > all) remnants > of code > dealing with > LinuxThreads > from the hotspot. > > Discussion of the changes: > > 1) on LinuxThreads, each > thread had an own > pid, so getpid() > would return a > unique pid for every thread > it was invoked > in. On NPTL, > this is > not an > issue anymore; getpid() works > as expected > returning a > global pid. > For LinuxThreads, there was a > workaround > where at VM > startup the > pid was > captured (on the thread invoking > CreateJavaVM) and this > pid was > stored in > static variable _initial_pid > and returned in > os::current_process_id(). > Later another workaround was > added because > CreateJavaVM > was not > invoked on > the primordial thread > anymore, so the pid > was handed in > via a > define (see > > Arguments::sun_java_launcher_pid()). > > Both workaround were removed and > os::current_process_id() was > changed to > just return getpid(). > > > We should remove the code on the > JDK side as > well - > possibly as a > follow up clean up (but via the > same forest as > this will be > pushed): > > > ./java.base/unix/native/libjli/java_md_solinux.c > > void SetJavaLauncherPlatformProps() { > /* Linux only */ > #ifdef __linux__ > const char *substr = > "-Dsun.java.launcher.pid="; > char *pid_prop_str = (char > *)JLI_MemAlloc(JLI_StrLen(substr) + > MAX_PID_STR_SZ + 1); > sprintf(pid_prop_str, > "%s%d", substr, > getpid()); > AddOption(pid_prop_str, NULL); > #endif /* __linux__ */ > > } > > > Unfortunately, sun.launcher.pid gets > used in the > wild, e.g.: > > http://stackoverflow.com/questions/35842/how-can-a-java-program-get-its-own-process-id > > Kind Regards, Thomas > > > > > 2) os::Linux::gettid(): Linux > uses the > kernel thread id for > OSThread thread > id - I did not change that. > But by now the > system call > gettid > should be > available in every Linux > kernel, so I > removed the > fallback handling. > > 3) A number of changes dealt > with the way > LinuxThreads > allocated > thread > stacks (with mmap and the > MAP_GROWSDOWN > flag). On > LinuxThreads, > it was not > possible to change the size > of thread > stacks (to start > a new > thread with a > different stack size). NPTL > can do this > and all the > places where > we dealt > with fixed stacks I changed. > > 4) On LinuxThreads, there is > the problem > that the > thread stacks > - which > grow down and are allocated > with MAP_FIXED > - may at > some point > trash the > java heap. To prevent this, every > allocation done with > os::reserve_memory() > and friends recorded a > "_highest_vm_reserved_address". > There was > a function > called "_thread_safety_check" > which > prevented start of new > threads if > thread stacks came > dangerously close to > the highest > reserved > address + a > gap; latter gap could be set > via parameter > ThreadSafetyMargin. > > All this coding was removed. > Note that > this coding > probably was > already > broken since a long time, > because there > are many > allocations > which were not > tracked. > > 5) Recognition of glibc > version and > pthread library > version were > very > elaborate to deal with > recognition of > LinuxThreads > implementation. Those > were dumbed down and now just > assert in > the highly > unlikely case > that we > encounter a LinuxThreads > implementation. > > The rest of the stuff is more > straight-forward. > > --- > > I built the changes on Linux > x64, x86 and > ppc64 and ran > jtreg tests > (hotspot/test) on these > platforms too. I > did not see > any issues, > but I'd > like to get a couple of > reviews for this. > > Kind Regards, > Thomas > > > > > > From david.holmes at oracle.com Fri Jun 19 04:09:58 2015 From: david.holmes at oracle.com (David Holmes) Date: Fri, 19 Jun 2015 14:09:58 +1000 Subject: RFR 8059557: Test set for "Validate JVM Command-Line Flag Arguments" In-Reply-To: <5581CAA0.8010606@oracle.com> References: <555A09B8.7010402@oracle.com> <555E46A7.4020402@oracle.com> <55671906.10000@oracle.com> <556D3597.8090508@oracle.com> <556F0559.3080601@oracle.com> <558047AC.6040705@oracle.com> <55818D36.3020908@oracle.com> <5581CAA0.8010606@oracle.com> Message-ID: <55839616.3010906@oracle.com> Hi Dmitry, I have no further comments. Thanks, David On 18/06/2015 5:29 AM, Dmitry Dmitriev wrote: > Hi Gerard, > > Can you please look at small enhancement that I made by Christian > suggestion - ran test JVM with the same type as current(for all cases, > not only for "-client" as in 06 webrev). Tested by JPRT. Sorry for > confusion. Thank you! > > Webrev: > http://cr.openjdk.java.net/~ddmitriev/8059557/webrev.07/ > Webrev incremental(from 06): > http://cr.openjdk.java.net/~ddmitriev/8059557/webrev.07.incremental.from06/ > > Regards, > Dmitry > > On 17.06.2015 18:07, Gerard Ziemski wrote: >> hi Dmitry, >> >> Please consider this reviewed (with small "r"). >> >> Just one quick question: is there an issue filed to followup on why >> the test hangs with CICompiler and to enable it back, once we figure >> it out? >> >> >> cheers >> >> On 6/16/2015 10:58 AM, Dmitry Dmitriev wrote: >>> Hello, >>> >>> Here a updated version of test set for Command Line Option >>> Validation. The main changes are: added new options types - int and >>> uint, added @modules, test all options with range in >>> TestOptionsWithRanges.java test. >>> >>> Tested: JPRT >>> >>> Webrev: http://cr.openjdk.java.net/~ddmitriev/8059557/webrev.05/ >>> >>> Webrev incremental(from 04): >>> http://cr.openjdk.java.net/~ddmitriev/8059557/webrev.05.incremental/ >>> >>> JEP: https://bugs.openjdk.java.net/browse/JDK-8059557 >>> >>> Thanks, >>> Dmitry >>> >>> On 03.06.2015 16:47, Dmitry Dmitriev wrote: >>>> Hello David, >>>> >>>> Thank you for pointing on style/grammar mistakes! I corrected all of >>>> them. >>>> Here a link to the updated >>>> webrev:http://cr.openjdk.java.net/~ddmitriev/8059557/webrev.04/ >>>> >>>> >>>> About "options validation" package - I agree that this looks odd, >>>> but if you don't mind I prefer to leave it. It slightly simplify >>>> calling static methods by using static import and also I use >>>> package-private access level. >>>> >>>> Regards, >>>> Dmitry >>>> >>>> On 02.06.2015 7:48, David Holmes wrote: >>>>> Hi Dmitry, >>>>> >>>>> On 28/05/2015 11:32 PM, Dmitry Dmitriev wrote: >>>>>> Hello all, >>>>>> >>>>>> Here is a 3 version of the tests taking into account feedback from >>>>>> Christian, David and Gerard. >>>>>> >>>>>> I limit number of options in TestOptionsWithRanges.java to 15. This >>>>>> include options of different types(intx, uintx etc.) and with >>>>>> different >>>>>> combination of min/max range. TestOptionsWithRangesDynamic.java >>>>>> leaved >>>>>> as is, because amount of manageable numeric options is very small and >>>>>> currently only 3 of them have range. Also, I improve code for double >>>>>> option. >>>>>> >>>>>> Webrev: http://cr.openjdk.java.net/~ddmitriev/8059557/webrev.03/ >>>>>> >>>>> >>>>> Only a few style/grammar nits (the downside of writing so many doc >>>>> comments :) ). >>>>> >>>>> Meta-question: is there a specific reason to use the package >>>>> "options validation"? It looks odd to me to have >>>>> OptionsValidation/common/optionsvalidation/ in the paths. >>>>> >>>>> General doc-comment comments: >>>>> - @param/@return descriptions should start with lower-case (you >>>>> currently mix-n-match) >>>>> - @throws description should start with "if", so: >>>>> @throws IOException if an error occurred reading the data >>>>> >>>>> >>>>> General Java-style comments: >>>>> - access modifiers (public, private, protected) always come first >>>>> >>>>> --- >>>>> >>>>> test/runtime/CommandLine/OptionsValidation/common/optionsvalidation/IntJVMOption.java >>>>> >>>>> >>>>> 265 * passed value is negative then error will be >>>>> catched earlier for >>>>> >>>>> catched -> caught >>>>> >>>>> --- >>>>> >>>>> test/runtime/CommandLine/OptionsValidation/common/optionsvalidation/JVMOption.java >>>>> >>>>> >>>>> 327 * @param param Tested parameter passed to the java >>>>> >>>>> "the java" is not a noun - suggest "the JVM" ? >>>>> >>>>> Maybe change Java to JVM to avoid use of "java" as a noun everywhere. >>>>> >>>>> 350 failedMessage(name, fullOptionString, valid, "JVM >>>>> output reports about fatal error. JVM exit with code " + returnCode >>>>> + "!"); >>>>> >>>>> The message isn't grammatically correct: about -> a; exit -> exited >>>>> >>>>> Similarly "JVM exit" -> "JVM exited" >>>>> >>>>> 377 failedMessage(name, fullOptionString, valid, >>>>> "JVM output not contains " >>>>> >>>>> not contains -> does not contain >>>>> >>>>> 400 * Return list of strings which contain options with valid >>>>> values which used >>>>> >>>>> which used -> which can be used >>>>> >>>>> 416 * Return list of strings which contain options with >>>>> invalid values which >>>>> 417 * used for testing on command line >>>>> >>>>> Ditto >>>>> >>>>> --- >>>>> >>>>> test/runtime/CommandLine/OptionsValidation/common/optionsvalidation/JVMOptionsUtils.java >>>>> >>>>> >>>>> 101 * Add dependency for option depending on it's type. E.g. >>>>> ran java in >>>>> >>>>> ran java -> run the JVM >>>>> >>>>> 119 * @param withRanges true if needed options with defined >>>>> ranges >>>>> >>>>> I'm not sure what this means. Occurs elswhere too. >>>>> >>>>> 121 * "product", "diagnostic" etc. Accept option only if >>>>> acceptOrigin return >>>>> >>>>> return -> returns (or even return -> evaluates). Occurs elsewhere too. >>>>> >>>>> 260 * methods. Tested only writeable options. >>>>> >>>>> Suggestion: Only tests writeable options. Occurs elsewhere too. >>>>> >>>>> 264 * @throws Exception >>>>> >>>>> When? Why? Occurs elsewhere too. >>>>> >>>>> Thanks, >>>>> David >>>>> ----- >>>>> >>>>>> Thanks, >>>>>> Dmitry >>>>>> >>>>>> >>>>>> On 21.05.2015 23:57, Dmitry Dmitriev wrote: >>>>>>> Hello all, >>>>>>> >>>>>>> Recently I correct several typos, so here a new webrev for tests: >>>>>>> http://cr.openjdk.java.net/~ddmitriev/8059557/webrev.02/ >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Dmitry >>>>>>> >>>>>>> On 18.05.2015 18:48, Dmitry Dmitriev wrote: >>>>>>>> Hello all, >>>>>>>> >>>>>>>> Please review test set for verifying functionality implemented >>>>>>>> by JEP >>>>>>>> 245 "Validate JVM Command-Line Flag Arguments"(JDK-8059557). Review >>>>>>>> request for this JEP can be found there: >>>>>>>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-May/018539.html >>>>>>>> >>>>>>>> >>>>>>>> I create 3 tests for verifying options with ranges. The tests >>>>>>>> mostly >>>>>>>> rely on common/optionsvalidation/JVMOptionsUtils.java. Class in >>>>>>>> this >>>>>>>> file contains functions to get options with ranges as list(by >>>>>>>> parsing >>>>>>>> new option "-XX:+PrintFlagsRanges" output), run command line >>>>>>>> test for >>>>>>>> list of options and other. The actual test code contained in >>>>>>>> common/optionsvalidation/JVMOption.java file - testCommandLine(), >>>>>>>> testDynamic(), testJcmd() and testAttach() methods. >>>>>>>> common/optionsvalidation/IntJVMOption.java and >>>>>>>> common/optionsvalidation/DoubleJVMOption.java source files contain >>>>>>>> classes derived from JVMOption class for integer and double JVM >>>>>>>> options correspondingly. >>>>>>>> >>>>>>>> Here are description of the tests: >>>>>>>> 1) >>>>>>>> hotspot/test/runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> This test get all options with ranges by parsing output of new >>>>>>>> option >>>>>>>> "-XX:+PrintFlagsRanges" and verify these options by starting >>>>>>>> Java and >>>>>>>> passing options in command line with valid and invalid values. >>>>>>>> Currently it verifies about 106 options which have ranges. >>>>>>>> Invalid values are values which out-of-range. In test used values >>>>>>>> "min-1" and "max+1".In this case Java should always exit with >>>>>>>> code 1 >>>>>>>> and print error message about out-of-range value(with one >>>>>>>> exception, >>>>>>>> if option is unsigned and passing negative value, then out-of-range >>>>>>>> error message is not printed because error occurred earlier). >>>>>>>> Valid values are values in range, e.g. min&max and also several >>>>>>>> additional values. In this case Java should successfully exit(exit >>>>>>>> code 0) or exit with error code 1 for other reasons(low memory with >>>>>>>> certain option value etc.). In any case for values in range Java >>>>>>>> should not print messages about out of range value. >>>>>>>> In any case Java should not crash. >>>>>>>> This test excluded from JPRT because it takes long time to execute >>>>>>>> and also fails - some options with value in valid range cause >>>>>>>> Java to >>>>>>>> crash(bugs are submitted). >>>>>>>> >>>>>>>> 2) >>>>>>>> hotspot/test/runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> This test get all writeable options with ranges by parsing >>>>>>>> output of >>>>>>>> new option "-XX:+PrintFlagsRanges" and verify these options by >>>>>>>> dynamically changing it's values to the valid and invalid values. >>>>>>>> Used 3 methods for that: DynamicVMOption isValidValue and >>>>>>>> isInvalidValue methods, Jcmd and by attach method. Currently 3 >>>>>>>> writeable options with ranges are verified by this test. >>>>>>>> This test pass in JPRT. >>>>>>>> >>>>>>>> 3) >>>>>>>> hotspot/test/runtime/CommandLine/OptionsValidation/TestJcmdOutput.java >>>>>>>> >>>>>>>> >>>>>>>> This test verified output of Jcmd when out-of-range value is set to >>>>>>>> the writeable option or value violates option constraint. Also this >>>>>>>> test verify that jcmd not write error message to the target >>>>>>>> process. >>>>>>>> This test pass in JPRT. >>>>>>>> >>>>>>>> >>>>>>>> I am not write special tests for constraints for this JEP because >>>>>>>> there are exist test for that(e.g. >>>>>>>> test/runtime/CompressedOops/ObjectAlignment.java for >>>>>>>> ObjectAlignmentInBytes or >>>>>>>> hotspot/test/gc/arguments/TestHeapFreeRatio.java for >>>>>>>> MinHeapFreeRatio/MaxHeapFreeRatio). >>>>>>>> >>>>>>>> Webrev: http://cr.openjdk.java.net/~ddmitriev/8059557/webrev.00/ >>>>>>>> >>>>>>>> >>>>>>>> JEP: https://bugs.openjdk.java.net/browse/JDK-8059557 >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Dmitry >>>>>>>> >>>>>>> >>>>>> >>>> >>> >> > From kim.barrett at oracle.com Fri Jun 19 06:50:12 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Fri, 19 Jun 2015 02:50:12 -0400 Subject: RFR: 8087322: Implement a Semaphore utility class In-Reply-To: <55836FF2.6070604@oracle.com> References: <557AF8E4.9040804@oracle.com> <557F3582.6060401@oracle.com> <5581B597.5080900@oracle.com> <55836FF2.6070604@oracle.com> Message-ID: <8763FF39-D04F-478B-8846-1200DF21FB19@oracle.com> On Jun 18, 2015, at 9:27 PM, David Holmes wrote: > > Hi Stefan, > > Sorry for the delay ? Stefan and I have been discussing various different approaches in separate email. I think I?ve received 5 (substantially) different variants from him, and offered him one of my own so far. I?m hopeful that we?re approaching agreement though. And hopefully we?ll end up in a place that will look good to the rest of you too. > One thing I am tempted to clean up a little more is the timedwait call. I think that can likely be made common to all non-Apple posix systems, at least for those Oracle supports or that otherwise exist in the open repository. All those posix variants appear to support clock_gettime of CLOCK_REALTIME, at least according to their documentation. Certainly the minimum Oracle-supported Linux and Solaris versions have it (and at least for Linux, have for a long time). Both BSD and AIX documentation put it in their libc, so we don?t even need to update the libraries to link against. So I think we can also unify the time access for all of the non-Apple posix variants. If someone is porting to some other ?posix? platform that doesn?t supply clock_gettime, they?ll need to do some additional work, and we might end up needing to tweak the modularity a bit to support that, but I?m inclined to wait for such a request to actually be made. > The sr_semaphore appears to be being initialized by C++ static initialization, which is a concern for me, primarily because Semaphore construction requires allocation support (it's a CHeapObj) and utilizes NMT. I get very nervous when NMT gets involved prior to VM initialization. Can we make sr_semaphore a pointer instead and initialize it in one of the os::init methods? I think that as long as we?re not allocating any CHeapObj subobjects, that isn?t a problem. The fact that it is a CHeapObj permits, but does not require, allocation using the CHeapObj allocator. At least, I think that?s true. Certainly it won?t be allocated using its associated operator new, so I don?t see how NMT could get involved. > 1069 } else { > 1070 return false; > 1071 } > > This is returning false when an error has occurred. At a minimum there should be an assert(false, "...") so that we detect this in debug builds. One of the things I worked on in the version I gave to Stefan was being pedantic about error checking. > Can we not implement this: > > 53 void signal(); > 54 void signal(uint count); > > as simply: > > void signal(uint count = 1); I think it ends up being more convenient in the implementation to have them be separate. If that ultimately turns out not to be the case then we can change it. It doesn?t affect the client API at all (unless someone starts using pointers to member functions). From david.holmes at oracle.com Fri Jun 19 08:43:31 2015 From: david.holmes at oracle.com (David Holmes) Date: Fri, 19 Jun 2015 18:43:31 +1000 Subject: RFR: 8087322: Implement a Semaphore utility class In-Reply-To: <8763FF39-D04F-478B-8846-1200DF21FB19@oracle.com> References: <557AF8E4.9040804@oracle.com> <557F3582.6060401@oracle.com> <5581B597.5080900@oracle.com> <55836FF2.6070604@oracle.com> <8763FF39-D04F-478B-8846-1200DF21FB19@oracle.com> Message-ID: <5583D633.7080301@oracle.com> Very quick response as I exit for the weekend :) On 19/06/2015 4:50 PM, Kim Barrett wrote: > On Jun 18, 2015, at 9:27 PM, David Holmes wrote: >> >> Hi Stefan, >> >> Sorry for the delay ? > > Stefan and I have been discussing various different approaches in separate email. I think I?ve received 5 (substantially) different variants from him, and offered him one of my own so far. I?m hopeful that we?re approaching agreement though. And hopefully we?ll end up in a place that will look good to the rest of you too. > >> One thing I am tempted to clean up a little more is the timedwait call. > > I think that can likely be made common to all non-Apple posix systems, at least for those Oracle supports or that otherwise exist in the open repository. All those posix variants appear to support clock_gettime of CLOCK_REALTIME, at least according to their documentation. Certainly the minimum Oracle-supported Linux and Solaris versions have it (and at least for Linux, have for a long time). Both BSD and AIX documentation put it in their libc, so we don?t even need to update the libraries to link against. So I think we can also unify the time access for all of the non-Apple posix variants. If someone is porting to some other ?posix? platform that doesn?t supply clock_gettime, they?ll need to do some additional work, and we might end up needing to tweak the modularity a bit to support that, but I?m inclined to wait for such a request to actually be made. Not that although clock_getime is supported by all POSIX systems: a) we don't use it anywhere in Solaris code (conversion to POSIX APIs is a long standing wishlist item) b) we dynamically lookup clock_gettime on Linux. Again this is historical and unnecessary given the supported platforms, but a cleanup that is yet to be implemented. >> The sr_semaphore appears to be being initialized by C++ static initialization, which is a concern for me, primarily because Semaphore construction requires allocation support (it's a CHeapObj) and utilizes NMT. I get very nervous when NMT gets involved prior to VM initialization. Can we make sr_semaphore a pointer instead and initialize it in one of the os::init methods? > > I think that as long as we?re not allocating any CHeapObj subobjects, that isn?t a problem. The fact that it is a CHeapObj permits, but does not require, allocation using the CHeapObj allocator. At least, I think that?s true. Certainly it won?t be allocated using its associated operator new, so I don?t see how NMT could get involved. OK. I'm not a fan of using C++ based initialization for any non-trivial classes we define. >> 1069 } else { >> 1070 return false; >> 1071 } >> >> This is returning false when an error has occurred. At a minimum there should be an assert(false, "...") so that we detect this in debug builds. > > One of the things I worked on in the version I gave to Stefan was being pedantic about error checking. > >> Can we not implement this: >> >> 53 void signal(); >> 54 void signal(uint count); >> >> as simply: >> >> void signal(uint count = 1); > > I think it ends up being more convenient in the implementation to have them be separate. If that ultimately turns out not to be the case then we can change it. It doesn?t affect the client API at all (unless someone starts using pointers to member functions). Ah yes I see that now = signal(n) is n calls to signal(). Thanks, David > From thomas.schatzl at oracle.com Fri Jun 19 08:58:59 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Fri, 19 Jun 2015 10:58:59 +0200 Subject: RFR: 8079315: UseCondCardMark broken in conjunction with CMS precleaning In-Reply-To: <5582D25A.1010307@oracle.com> References: <5548D913.1030507@redhat.com> <473C887F-8CC5-4E67-BD9A-1882660CFD3C@lnu.se> <554B3B5E.8000705@oracle.com> <8EE73C49-83CD-4162-A3EF-19DDA2C2CDFA@lnu.se> <554FC66F.20307@oracle.com> <55507BE4.3050605@redhat.com> <03C141D8-952E-4E7A-BDAD-024CE2239010@lnu.se> <55508B60.1000200@redhat.com> <8868A273-7C97-45F0-BF10-85DDE5859E85@lnu.se> <5550B182.7090009@redhat.com> <5551FA97.9090502@oracle.com> <5551FD72.1020504@oracle.com> <38CAAA0B-6F32-4508-818F-AD9D248E8B35@lnu.se> <55524C58.4030904@oracle.com> <55524E8C.6080709@redhat.com> <55526041.1030709@redhat.com> <7C4CBC57-D7B2-4779-9353-DEACCB626370@lnu.se> <5552838B.3020305@oracle.com> <556D5EF9.6030702@redhat.com> <556D7692.3070707@oracle.com> <557D3D59.4000806@redhat.com> <558034E0.6060600@redhat.com> <1434534101.6640.1.camel@oracle.! com> <55827A50.2070202@redhat.com> <5582D25A.1010307@oracle.com> Message-ID: <1434704339.2532.6.camel@oracle.com> Hi all, On Thu, 2015-06-18 at 07:14 -0700, Vladimir Kozlov wrote: > Yes, it needs sponsor too (pushed through JPRT) since it is a change in our core platform we support. > > http://cr.openjdk.java.net/~shade/8078438/webrev.03/ I pushed both changes (8078438 and 8079315; still running, but almost through) after renaming them slightly (adding platform specific "on XYZ" strings), and created new issues: https://bugs.openjdk.java.net/browse/JDK-8129324 SPARC: Interpreter should support conditional card marks https://bugs.openjdk.java.net/browse/JDK-8129325 UseCondCardMark broken in conjunction with CMS on SPARC and aarch64 Of course the second could be further split. Sorry for the delays. I hope the follow-ups can be handled more quickly. Thanks, Thomas From goetz.lindenmaier at sap.com Fri Jun 19 09:16:33 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 19 Jun 2015 09:16:33 +0000 Subject: RFR(S): 8087183: Fix call to inline function is_oop in header debugInfo.hpp. [needs sponsor] In-Reply-To: <55837C55.8080203@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CFFB8BF@DEWDFEMB12A.global.corp.sap> <5582A404.8040204@oracle.com> <5582A633.3020603@oracle.com> <4295855A5C1DE049A61835A1887419CC2CFFB94F@DEWDFEMB12A.global.corp.sap> <55834547.4020400@oracle.com> <55836E95.8010400@oracle.com> <558376DA.6060003@oracle.com> <55837C55.8080203@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2CFFC07E@DEWDFEMB12A.global.corp.sap> David, Mikael, Vladimir, Thanks for taking care of my change! Best regards, Goetz. -----Original Message----- From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] Sent: Freitag, 19. Juni 2015 04:20 To: David Holmes; Lindenmaier, Goetz Cc: HotSpot Developers Subject: Re: RFR(S): 8087183: Fix call to inline function is_oop in header debugInfo.hpp. [needs sponsor] Thank you for pointing 8080157. I took it. Thanks, Vladimir On 6/18/15 6:56 PM, David Holmes wrote: > On 19/06/2015 11:21 AM, Vladimir Kozlov wrote: >> David, >> >> I rerun your job, it passed second time. > > I re-ran it too :) I wondered how I then got two "success" emails a few > minutes apart. > >> New GHASH intrinsic code size is bigger then reserved stubs size only on >> some Windows machines: >> >> code_size2 = 22000 // simply increase if too small >> (assembler will crash if too small) >> >> May be because some external addresses which are accessed in code are >> far and additional register is used to load it. The fix is coming >> (increase code_size2). > > The initial failure was this AFAICS: > > https://bugs.openjdk.java.net/browse/JDK-8080157 > > Thanks, > David > >> Thanks, >> Vladimir >> >> On 6/18/15 3:25 PM, David Holmes wrote: >>> Submitted to hs-comp. >>> >>> David >>> >>> On 18/06/2015 10:07 PM, Lindenmaier, Goetz wrote: >>>> Hi Mikael, >>>> >>>> Thanks! David offered to sponsor too. >>>> Please tell him in case you pushed it to jprt, I can only >>>> tell once it's submitted. >>>> >>>> Best regards, >>>> Goetz. >>>> >>>> -----Original Message----- >>>> From: Mikael Gerdin [mailto:mikael.gerdin at oracle.com] >>>> Sent: Donnerstag, 18. Juni 2015 13:06 >>>> To: David Holmes; Lindenmaier, Goetz; Kim Barrett >>>> Cc: HotSpot Developers >>>> Subject: Re: RFR(S): 8087183: Fix call to inline function is_oop in >>>> header debugInfo.hpp. [needs sponsor] >>>> >>>> I can sponsor it. >>>> /Mikael >>>> >>>> On 2015-06-18 12:57, David Holmes wrote: >>>>> Hi Goetz, >>>>> >>>>> I can sponsor in about 11 hours if noone else picks it up overnight :) >>>>> >>>>> David >>>>> >>>>> On 18/06/2015 8:41 PM, Lindenmaier, Goetz wrote: >>>>>> Hi, >>>>>> >>>>>> could someone please sponsor this fix? >>>>>> It's required to fix the fastdebug build on aix. >>>>>> >>>>>> Thanks a lot! >>>>>> Goetz. >>>>>> >>>>>> -----Original Message----- >>>>>> From: Lindenmaier, Goetz >>>>>> Sent: Montag, 15. Juni 2015 11:21 >>>>>> To: 'David Holmes'; 'Kim Barrett' >>>>>> Cc: 'HotSpot Developers' >>>>>> Subject: RE: RFR(S): 8087183: Fix call to inline function is_oop in >>>>>> header debugInfo.hpp. >>>>>> >>>>>> Hi, >>>>>> >>>>>> I updated the call to is_oop to do "or_null", and fixed the >>>>>> Copyrights. >>>>>> I also added the reviewers to the change comment. >>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8087183-is_oop/webrev-02/ >>>>>> >>>>>> Could someone please sponsor this tiny change? >>>>>> >>>>>> Thanks and best regards, >>>>>> Goetz. >>>>>> >>>>>> -----Original Message----- >>>>>> From: Lindenmaier, Goetz >>>>>> Sent: Freitag, 12. Juni 2015 08:54 >>>>>> To: 'David Holmes'; Kim Barrett >>>>>> Cc: HotSpot Developers >>>>>> Subject: RE: RFR(S): 8087183: Fix call to inline function is_oop in >>>>>> header debugInfo.hpp. >>>>>> >>>>>> Hi, >>>>>> >>>>>> Thanks for the reviews! Could someone please sponsor this? >>>>>> >>>>>> We started to track down the cause by searching and building the >>>>>> repo, >>>>>> but then >>>>>> we narrowed in down to two merges ... and aix builds rather slow. I >>>>>> quit this task >>>>>> then. >>>>>> >>>>>> But the file drags in a lot of os/aix and os_cpu/aix_ppc files. The >>>>>> includes in these >>>>>> files differ from those in other platform directories. And with one >>>>>> of the >>>>>> include cleanup changes in a shared file the indirect include that >>>>>> must have been >>>>>> there at some point vanished I guess. >>>>>> >>>>>> But no matter, is_oop should not be called in a header file ... >>>>>> >>>>>> Best regards, >>>>>> Goetz. >>>>>> >>>>>> -----Original Message----- >>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>> Sent: Freitag, 12. Juni 2015 04:07 >>>>>> To: Kim Barrett; Lindenmaier, Goetz >>>>>> Cc: HotSpot Developers >>>>>> Subject: Re: RFR(S): 8087183: Fix call to inline function is_oop in >>>>>> header debugInfo.hpp. >>>>>> >>>>>> On 12/06/2015 3:17 AM, Kim Barrett wrote: >>>>>>> On Jun 11, 2015, at 5:02 AM, Lindenmaier, Goetz >>>>>>> wrote: >>>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> in debugInfo.hpp is_oop() is called. This is an inline function >>>>>>>> defined in oop.inline.hpp. >>>>>>>> As oop.inline.hpp is not included in debugInfo.hpp, and it should >>>>>>>> not be included there, >>>>>>>> this leads to compilation failures in the fastdebug build on aix. >>>>>>>> >>>>>>>> To fix this, I just move the function calling is_oop to >>>>>>>> debugInfo.cpp. In that file also the >>>>>>>> only call to that function is located, so that it still can be >>>>>>>> inlined. >>>>>>>> >>>>>>>> Please review this change. I please need a sponsor. >>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8087183-is_oop/webrev-01/ >>>>>>>> >>>>>>>> Best regards, >>>>>>>> Goetz. >>>>>>> >>>>>>> Looks good. >>>>>>> >>>>>>> I'm mildly surprised this doesn't run into problems on other >>>>>>> platforms. >>>>>> >>>>>> Me too. My first thought was precompiled headers, but this code has >>>>>> been >>>>>> in place for a couple of years - so why is it now a problem ?? >>>>>> >>>>>> David >>>>>> >>>>>> >>>>>>> The assert could use oop->is_oop_or_null(), though it makes no >>>>>>> difference for this problem. >>>>>>> From alejandro.murillo at oracle.com Fri Jun 19 16:53:32 2015 From: alejandro.murillo at oracle.com (Alejandro E Murillo) Date: Fri, 19 Jun 2015 10:53:32 -0600 Subject: [verona.stage] RFR 8087203: Add support for PATCH field and remove unused fields of new version string In-Reply-To: <55834C8B.2060803@oracle.com> References: <5580A953.8090905@oracle.com> <5582CA9D.9070207@oracle.com> <55834C8B.2060803@oracle.com> Message-ID: <5584490C.3050408@oracle.com> Hi Alan, just to you. didn't hear back from you, so I'll assume you are fine with the corrections. We want to get this into further testing so I'm going to push the changes cheers Alejandro On 6/18/2015 4:56 PM, Alejandro E Murillo wrote: > > Thanks Alan, > see below > > On 6/18/2015 7:41 AM, Alan Bateman wrote: >> >> >> On 16/06/2015 23:55, Alejandro E Murillo wrote: >>> >>> Please review these changes: >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8087202 >>> Webrev: http://cr.openjdk.java.net/~amurillo/9/8087202 >> >> The implementation of isJavaVersionAtLeast in the JAXP classes look >> okay although I think this is code that could be removed. Joe Wang >> can confirm but I think it dates back to when the JAXP API was a >> standalone API and there was an attempt to keep the code in sync >> across major versions. I'll create a separate bug re-examine this as >> it looks like some clean-up can be done here. > sounds good, > in general, that code can be called a lot, so changes need to be > carefully done > as to avoid perf impact. So it might be better if that check can be > removed > >> >> Just on the comment "In JDK9 the version string was changed ..." will >> date quickly and would be nice to say that "In JDK 8 and older then >> it assumes 1.N and for JDK 9 and newer it assumes N. >> >> In sun.misc.Version.initVersions then InternalError instead of >> RuntimeException might be more appropriate as something is really >> broken if that happens. > Indeed. Changed. >> >> Also as David pointed out, it shouldn't be @since JDK9 in the new >> method. This reminds me to check if the JEP says anything about >> @since tags because we already have quite a few @since 1.9. > yeah, I had meant to double check that. Will change it to 9 >> >> In the Version.java test then the line with the pattern is really >> long, maybe that could be split up to make future side-by-side views >> easier to read. > sure, will make it into several lines, based on components, like this: > > String jep223Pattern = > "^([0-9]+)(\\.([0-9]+))?(\\.([0-9]+))?(\\.([0-9]+))?" + // $VNUM > "(-([a-zA-Z]+))?(\\.([a-zA-Z]+))?" + // $PRE > "(\\+([0-9]+))?" + // Build Number > "(([-a-zA-Z0-9.]+))?$"; // $OPT > > see new webrev: > http://cr.openjdk.java.net/~amurillo/9/8087202.v2/jdk/src/java.base/share/classes/sun/misc/Version.java.template.udiff.html > > >> >> Otherwise looks okay to me. > great, thanks! > > Here's the new webrev (I tested these with JPRT, testsets hotspot and > pit): > > http://cr.openjdk.java.net/~amurillo/9/8087202.v2/ > > Thanks! > -- Alejandro From kim.barrett at oracle.com Fri Jun 19 18:35:41 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Fri, 19 Jun 2015 14:35:41 -0400 Subject: RFR: 8087322: Implement a Semaphore utility class In-Reply-To: <5583D633.7080301@oracle.com> References: <557AF8E4.9040804@oracle.com> <557F3582.6060401@oracle.com> <5581B597.5080900@oracle.com> <55836FF2.6070604@oracle.com> <8763FF39-D04F-478B-8846-1200DF21FB19@oracle.com> <5583D633.7080301@oracle.com> Message-ID: <330A49A8-8E8B-4C15-87BF-E8053C21C495@oracle.com> On Jun 19, 2015, at 4:43 AM, David Holmes wrote: > > On 19/06/2015 4:50 PM, Kim Barrett wrote: >> On Jun 18, 2015, at 9:27 PM, David Holmes wrote: >>> One thing I am tempted to clean up a little more is the timedwait call. >> >> I think that can likely be made common to all non-Apple posix systems, [?]. All those posix variants appear to support clock_gettime of CLOCK_REALTIME, at least according to their documentation. [?] > > Not that although clock_getime is supported by all POSIX systems: > > a) we don't use it anywhere in Solaris code (conversion to POSIX APIs is a long standing wishlist item) Right, though I'm hoping it isn't a problem to use clock_gettime in (hopefully) shared POSIX code that happens to be used by the Solaris ports. > b) we dynamically lookup clock_gettime on Linux. Again this is historical and unnecessary given the supported platforms, but a cleanup that is yet to be implemented. Yes, I saw that. I'm hoping that problem is sufficiently ancient that it can be ignored. Tracing through the bug reports, that doesn't seem unreasonable: 6348968 -> 6336247 -> 4885046 leads to a discussion about it being a bug in Redhat 9 when using NPTL, and that it had been fixed in upstream NPTL but that fix hadn't yet made it's way into RH9 (and apparently not into RH AS4 either at that point). Just in general, there seems to be a lot of accumulated workarounds and possibly unnecessary code duplication in the unixy os_xxx.cpp variants (and possibly other files nearby that I haven't looked at). I was talking to Coleen yesterday about this, and she said she's been thinking it might be time to send a cleanup crew in there. Merging the semaphores would help with that; it's something that would probably have been done as part of such a cleanup anyway. >>> The sr_semaphore appears to be being initialized by C++ static initialization, which is a concern for me, primarily because Semaphore construction requires allocation support (it's a CHeapObj) and utilizes NMT. I get very nervous when NMT gets involved prior to VM initialization. Can we make sr_semaphore a pointer instead and initialize it in one of the os::init methods? >> >> I think that as long as we?re not allocating any CHeapObj subobjects, that isn?t a problem. The fact that it is a CHeapObj permits, but does not require, allocation using the CHeapObj allocator. At least, I think that?s true. Certainly it won?t be allocated using its associated operator new, so I don?t see how NMT could get involved. > > OK. I'm not a fan of using C++ based initialization for any non-trivial classes we define. You of course mean "static initialization". And I agree; static initialization can cause a lot of problems. I don't think we were planning on changing anything other than the type of the sr_semaphore's unless we had to though, leaving that sort of cleanup to other tasks. But that's a good reminder; at least one of the variants Stefan came up would probably run into problems here. >>> Can we not implement this: >>> >>> 53 void signal(); >>> 54 void signal(uint count); >>> >>> as simply: >>> >>> void signal(uint count = 1); >> >> I think it ends up being more convenient in the implementation to have them be separate. If that ultimately turns out not to be the case then we can change it. It doesn?t affect the client API at all (unless someone starts using pointers to member functions). > > Ah yes I see that now = signal(n) is n calls to signal(). Except that for Windows the natural implementation is the other way around. But for the POSIX variants, we can have one signal(n) that calls the platform-specific (Apple semaphore_t or POSIX sem_t) signal(). From alejandro.murillo at oracle.com Fri Jun 19 22:03:16 2015 From: alejandro.murillo at oracle.com (Alejandro E Murillo) Date: Fri, 19 Jun 2015 16:03:16 -0600 Subject: [verona.stage] RFR 8087203: Add support for PATCH field and remove unused fields of new version string In-Reply-To: <55849019.8000902@oracle.com> References: <5580A953.8090905@oracle.com> <5582CA9D.9070207@oracle.com> <55834C8B.2060803@oracle.com> <5584490C.3050408@oracle.com> <55849019.8000902@oracle.com> Message-ID: <558491A4.2000706@oracle.com> Sounds good Joe, I will push those soon. Thanks Alejandro On 6/19/2015 3:56 PM, huizhe wang wrote: > Hi Alejandro, > > Alan's right about the JAXP version-check code. But since this is > urgently needed, I agree you can push the change as is. I'll create a > separate bug to re-examine version related code in jaxp. As Alan > pointed out, it would be some clean-up. > > Thanks, > Joe > > On 6/19/2015 9:53 AM, Alejandro E Murillo wrote: >> >> Hi Alan, just to you. >> didn't hear back from you, so I'll assume you are fine with >> the corrections. We want to get this into further testing >> so I'm going to push the changes >> >> cheers >> Alejandro >> >> On 6/18/2015 4:56 PM, Alejandro E Murillo wrote: >>> >>> Thanks Alan, >>> see below >>> >>> On 6/18/2015 7:41 AM, Alan Bateman wrote: >>>> >>>> >>>> On 16/06/2015 23:55, Alejandro E Murillo wrote: >>>>> >>>>> Please review these changes: >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8087202 >>>>> Webrev: http://cr.openjdk.java.net/~amurillo/9/8087202 >>>> >>>> The implementation of isJavaVersionAtLeast in the JAXP classes look >>>> okay although I think this is code that could be removed. Joe Wang >>>> can confirm but I think it dates back to when the JAXP API was a >>>> standalone API and there was an attempt to keep the code in sync >>>> across major versions. I'll create a separate bug re-examine this >>>> as it looks like some clean-up can be done here. >>> sounds good, >>> in general, that code can be called a lot, so changes need to be >>> carefully done >>> as to avoid perf impact. So it might be better if that check can be >>> removed >>> >>>> >>>> Just on the comment "In JDK9 the version string was changed ..." >>>> will date quickly and would be nice to say that "In JDK 8 and older >>>> then it assumes 1.N and for JDK 9 and newer it assumes N. >>>> >>>> In sun.misc.Version.initVersions then InternalError instead of >>>> RuntimeException might be more appropriate as something is really >>>> broken if that happens. >>> Indeed. Changed. >>>> >>>> Also as David pointed out, it shouldn't be @since JDK9 in the new >>>> method. This reminds me to check if the JEP says anything about >>>> @since tags because we already have quite a few @since 1.9. >>> yeah, I had meant to double check that. Will change it to 9 >>>> >>>> In the Version.java test then the line with the pattern is really >>>> long, maybe that could be split up to make future side-by-side >>>> views easier to read. >>> sure, will make it into several lines, based on components, like this: >>> >>> String jep223Pattern = >>> "^([0-9]+)(\\.([0-9]+))?(\\.([0-9]+))?(\\.([0-9]+))?" + // $VNUM >>> "(-([a-zA-Z]+))?(\\.([a-zA-Z]+))?" + // $PRE >>> "(\\+([0-9]+))?" + // Build Number >>> "(([-a-zA-Z0-9.]+))?$"; // $OPT >>> >>> see new webrev: >>> http://cr.openjdk.java.net/~amurillo/9/8087202.v2/jdk/src/java.base/share/classes/sun/misc/Version.java.template.udiff.html >>> >>> >>>> >>>> Otherwise looks okay to me. >>> great, thanks! >>> >>> Here's the new webrev (I tested these with JPRT, testsets hotspot >>> and pit): >>> >>> http://cr.openjdk.java.net/~amurillo/9/8087202.v2/ >>> >>> Thanks! >>> >> > -- Alejandro From huizhe.wang at oracle.com Fri Jun 19 21:56:41 2015 From: huizhe.wang at oracle.com (huizhe wang) Date: Fri, 19 Jun 2015 14:56:41 -0700 Subject: [verona.stage] RFR 8087203: Add support for PATCH field and remove unused fields of new version string In-Reply-To: <5584490C.3050408@oracle.com> References: <5580A953.8090905@oracle.com> <5582CA9D.9070207@oracle.com> <55834C8B.2060803@oracle.com> <5584490C.3050408@oracle.com> Message-ID: <55849019.8000902@oracle.com> Hi Alejandro, Alan's right about the JAXP version-check code. But since this is urgently needed, I agree you can push the change as is. I'll create a separate bug to re-examine version related code in jaxp. As Alan pointed out, it would be some clean-up. Thanks, Joe On 6/19/2015 9:53 AM, Alejandro E Murillo wrote: > > Hi Alan, just to you. > didn't hear back from you, so I'll assume you are fine with > the corrections. We want to get this into further testing > so I'm going to push the changes > > cheers > Alejandro > > On 6/18/2015 4:56 PM, Alejandro E Murillo wrote: >> >> Thanks Alan, >> see below >> >> On 6/18/2015 7:41 AM, Alan Bateman wrote: >>> >>> >>> On 16/06/2015 23:55, Alejandro E Murillo wrote: >>>> >>>> Please review these changes: >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8087202 >>>> Webrev: http://cr.openjdk.java.net/~amurillo/9/8087202 >>> >>> The implementation of isJavaVersionAtLeast in the JAXP classes look >>> okay although I think this is code that could be removed. Joe Wang >>> can confirm but I think it dates back to when the JAXP API was a >>> standalone API and there was an attempt to keep the code in sync >>> across major versions. I'll create a separate bug re-examine this as >>> it looks like some clean-up can be done here. >> sounds good, >> in general, that code can be called a lot, so changes need to be >> carefully done >> as to avoid perf impact. So it might be better if that check can be >> removed >> >>> >>> Just on the comment "In JDK9 the version string was changed ..." >>> will date quickly and would be nice to say that "In JDK 8 and older >>> then it assumes 1.N and for JDK 9 and newer it assumes N. >>> >>> In sun.misc.Version.initVersions then InternalError instead of >>> RuntimeException might be more appropriate as something is really >>> broken if that happens. >> Indeed. Changed. >>> >>> Also as David pointed out, it shouldn't be @since JDK9 in the new >>> method. This reminds me to check if the JEP says anything about >>> @since tags because we already have quite a few @since 1.9. >> yeah, I had meant to double check that. Will change it to 9 >>> >>> In the Version.java test then the line with the pattern is really >>> long, maybe that could be split up to make future side-by-side views >>> easier to read. >> sure, will make it into several lines, based on components, like this: >> >> String jep223Pattern = >> "^([0-9]+)(\\.([0-9]+))?(\\.([0-9]+))?(\\.([0-9]+))?" + // $VNUM >> "(-([a-zA-Z]+))?(\\.([a-zA-Z]+))?" + // $PRE >> "(\\+([0-9]+))?" + // Build Number >> "(([-a-zA-Z0-9.]+))?$"; // $OPT >> >> see new webrev: >> http://cr.openjdk.java.net/~amurillo/9/8087202.v2/jdk/src/java.base/share/classes/sun/misc/Version.java.template.udiff.html >> >> >>> >>> Otherwise looks okay to me. >> great, thanks! >> >> Here's the new webrev (I tested these with JPRT, testsets hotspot and >> pit): >> >> http://cr.openjdk.java.net/~amurillo/9/8087202.v2/ >> >> Thanks! >> > From goetz.lindenmaier at sap.com Mon Jun 22 12:38:50 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 22 Jun 2015 12:38:50 +0000 Subject: RFR(XS): 8129423: Fix unlink() of LogCompilation tmp files lost in merge of 8007993 and 8060074. Message-ID: <4295855A5C1DE049A61835A1887419CC2CFFC4B3@DEWDFEMB12A.global.corp.sap> Hi, I detected a small flaw introduced by a merge. This webrev fixes it: http://cr.openjdk.java.net/~goetz/webrevs/8129423-LogComp/webrev-01/ Please review this fix. I please need a sponsor. With LogCompilation each compiler thread writes information to its own temp log file. During shutdown these files are concatenated into a single log file with the specified name. The temp files should be deleted, but we found files of jtreg test TestUnstableIfTrap.java left over in the /tmp directory. Also, a simple run with LogCompilation leaves these files in the /tmp directory. 8007993 fixed a problem with writing these log files and moved the unlink() of the temp files. This unlink() got lost in the merge with 8060074. Merge: http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/674657ff61c6 8060074: http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/a0dd995271c4 8007993: http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/c13eb14ebf5c Best regards, Goetz. From goetz.lindenmaier at sap.com Mon Jun 22 12:54:30 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 22 Jun 2015 12:54:30 +0000 Subject: Ping: RFR(M): 8086069: Adapt runtime calls to recent intrinsics to pass ints as long In-Reply-To: <754964BF-CC0D-4324-8AAC-11799847BFEE@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CFF9D17@DEWDFEMB12A.global.corp.sap> <57EF8CC4-3CB7-488E-89D4-5AE5EA3C99AA@oracle.com> <557F68C6.4050805@oracle.com> <557F9E91.7020603@oracle.com> <754964BF-CC0D-4324-8AAC-11799847BFEE@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2CFFC4DE@DEWDFEMB12A.global.corp.sap> Hi, I would like to ping again for my change. I want to recall that this only extends the existing mechanism guarded by CCallingConventionRequiresIntsAsLongs to multiplyToLen, CRC32, AES and SHA. http://cr.openjdk.java.net/~goetz/webrevs/8086069-call_conv/webrev.01/ Could somebody please review this change? I please need a sponsor. Thanks and best regards, Goetz. -----Original Message----- From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Christian Thalinger Sent: Donnerstag, 18. Juni 2015 18:02 To: John Rose Cc: HotSpot Developers; aarch64-port-dev at openjdk.java.net Subject: Re: Ping: RFR(M): 8086069: Adapt runtime calls to recent intrinsics to pass ints as long > On Jun 15, 2015, at 9:13 PM, John Rose wrote: > > On Jun 15, 2015, at 8:57 PM, Dean Long wrote: >> >> Thanks for the explanation. It sounds like we are modeling the abstract Java stack representation of long and double, and this wouldn't be >> easy to change, because I see things like "TypeFunc::Parms + 1" and "argument(2)" that would need to change before this could go away. > > Indeed. Slot pairs are a mess, an optimization (or concession) for platforms that no longer matter. (Primitives might look like that in a few years.) Some messes in HotSpot stem (IMO) from excessive attention to the bytecode syntax, designing a managed execution engine around the oddities of a code format. > > In an ideal world, I would like to isolate, deprecate, and eventually remove the "evil twin" slots, since they no longer have any meaning (except maybe on some 32-bit systems). Doing it at all levels will be hard, except in the context of some other breaking change. But it could be done locally in the JVM, removing the notion of twin slots from modules that don't have an absolute need to work with them. JITs shouldn't have to know about them, IMO; maybe not even the interpreter (though that would involve a renumbering prepass). > > When we get value types, we may be able to make such a change, even to the bytecode syntax itself. Or perhaps we will perpetuate the "evil twin" convention, but apply it to all value types (plus long and double). Or perhaps (happy thought) we can make every value/ref/prim occupy one stack slot, in some bytecode of the future. I?m all for happy thoughts :-) > > ? John From edward.nevill at gmail.com Mon Jun 22 13:23:21 2015 From: edward.nevill at gmail.com (Edward Nevill) Date: Mon, 22 Jun 2015 14:23:21 +0100 Subject: RFR: 8129426: aarch64: add support for PopCount in C2 Message-ID: <1434979401.21282.31.camel@mint> Hi, Aarch64 currently does not support the PopCountI and PopCountL nodes in aarch64.ad The following webrev adds support for these using the SIMD instructions 'cnt' and 'addv' http://cr.openjdk.java.net/~enevill/8129426/webrev.01/ This patch was contributed by alexander.alexeev at caviumnetworks.com The patch only modifies aarch64 specific files. I have merged the patch in and tested it with JTreg / hotspot with the following results. Original: Test results: passed: 847; failed: 13; error: 6 Revised: Test results: passed: 848; failed: 12; error: 6 The single additional failure in the original is the test FAILED: compiler/intrinsics/squaretolen/TestSquareToLen.java which is an intermittent failure in the original. I have benchmarked the patch on four different partner platforms. The average improvement was 2.6X for PopCountI and 2.5X for PopCountL. Please review and if OK I will push, Thanks, Ed. From aph at redhat.com Mon Jun 22 14:04:10 2015 From: aph at redhat.com (Andrew Haley) Date: Mon, 22 Jun 2015 15:04:10 +0100 Subject: [aarch64-port-dev ] RFR: 8129426: aarch64: add support for PopCount in C2 In-Reply-To: <1434979401.21282.31.camel@mint> References: <1434979401.21282.31.camel@mint> Message-ID: <558815DA.8020500@redhat.com> On 06/22/2015 02:23 PM, Edward Nevill wrote: > Aarch64 currently does not support the PopCountI and PopCountL nodes in aarch64.ad > > Please review and if OK I will push, Shouldn't mov in the IregI case be movw? And iRegI be iRegIorL2I? I'm guessing that C2 won't do the MOVs itself if you specify the instruction as vRegD src. Andrew. From volker.simonis at gmail.com Mon Jun 22 14:21:00 2015 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 22 Jun 2015 16:21:00 +0200 Subject: RFR(XS): 8129423: Fix unlink() of LogCompilation tmp files lost in merge of 8007993 and 8060074. In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CFFC4B3@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CFFC4B3@DEWDFEMB12A.global.corp.sap> Message-ID: Hi Goetz, thanks for finding this bug. I agree with your analysis and think your fix is good. Regards, Volker On Mon, Jun 22, 2015 at 2:38 PM, Lindenmaier, Goetz wrote: > Hi, > > I detected a small flaw introduced by a merge. This webrev fixes it: > http://cr.openjdk.java.net/~goetz/webrevs/8129423-LogComp/webrev-01/ > Please review this fix. I please need a sponsor. > > With LogCompilation each compiler thread writes information to its own temp log file. During shutdown > these files are concatenated into a single log file with the specified name. The temp files should be > deleted, but we found files of jtreg test TestUnstableIfTrap.java left over in the /tmp directory. Also, a simple > run with LogCompilation leaves these files in the /tmp directory. > > 8007993 fixed a problem with writing these log files and moved the unlink() of the temp > files. This unlink() got lost in the merge with 8060074. > > Merge: http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/674657ff61c6 > 8060074: http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/a0dd995271c4 > 8007993: http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/c13eb14ebf5c > > Best regards, > Goetz. > From stefan.karlsson at oracle.com Mon Jun 22 14:28:08 2015 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Mon, 22 Jun 2015 16:28:08 +0200 Subject: RFR: 8087322: Implement a Semaphore utility class In-Reply-To: <55836FF2.6070604@oracle.com> References: <557AF8E4.9040804@oracle.com> <557F3582.6060401@oracle.com> <5581B597.5080900@oracle.com> <55836FF2.6070604@oracle.com> Message-ID: <55881B78.3040909@oracle.com> Hi David, Updated webrevs: http://cr.openjdk.java.net/~stefank/8087322/webrev.03.delta http://cr.openjdk.java.net/~stefank/8087322/webrev.03 Comments inlined: On 2015-06-19 03:27, David Holmes wrote: > Hi Stefan, > > Sorry for the delay ... > > On 18/06/2015 3:59 AM, Stefan Karlsson wrote: >> Hi again, >> >> Here's a version that gets rid of the max parameter: > > Great! This is looking really good! Thanks. > >> http://cr.openjdk.java.net/~stefank/8087322/webrev.02.delta >> http://cr.openjdk.java.net/~stefank/8087322/webrev.02 >> >> The patch also contains a few minor cleanups and removes the redundant >> BsdSemaphore::trywait(), which is already defined in PosixSemaphore. > > The interaction with the sr_semaphore complicates things. If we push > its API up to being the Semaphore API then we have to implement unused > functionality on Windows (and perhaps AIX?). If instead we subclass > Semaphore to extend the API then we have to duplicate some of the > code, even across POSIX systems. :( Unfortunate but I don't see a > better approach than what you have chosen (and the Apple vs other-BSD > also complicates things). > > One thing I am tempted to clean up a little more is the timedwait > call. PosixSemaphore timedwait takes a timespec to pass to the > underlying sem_timedwait. But the primary API is timed_wait(long secs, > int nsecs) which each PosixSemaphore subclass has to add, and each > then has to perform the "unpackTime" mechanics (which in itself is > something screaming to be cleaned up). What if PosixSemaphore defined: > > class PosixSemaphore : public Semaphore { > public: > PosixSemaphore(uint value = 0) : Semaphore(value) {} > > bool trywait(); > bool timedwait(unsigned int sec, int nsec); > > protected: > virtual void rel_to_abs_timespec(struct timespec* ts, unsigned int > sec, int nsec) = 0; > }; > > then: > > bool os::PosixSemaphore::timedwait(unsigned int sec, int nsec) { > struct timespec ts; > rel_to_abs_timespec(&ts, sec nsecs); > while (true) { > int result = sem_timedwait(&_semaphore, &ts); > ... > } > } > > and then just define the rel_to_abs_timespec functions for BSD, linux > and Solaris subclasses. ? I did something similar while prototyping alternative implementations of this. I named the function to PosixSemaphore::create_timespec, but I can change that name if you want to. > --- > > The sr_semaphore appears to be being initialized by C++ static > initialization, which is a concern for me, primarily because Semaphore > construction requires allocation support (it's a CHeapObj) and > utilizes NMT. I get very nervous when NMT gets involved prior to VM > initialization. Can we make sr_semaphore a pointer instead and > initialize it in one of the os::init methods? The current code doesn't use the CHeapObj new operator, so NMT isn't involved here. I'd prefer if this could be changed as a separate RFE. > > --- > > A few specific comments ... > > src/os/posix/vm/os_posix.cpp > > Two nits that I know have been copied from the existing code: > > 1061 while (1) { > > I prefer while (true) > > 1069 } else { > 1070 return false; > 1071 } > > This is returning false when an error has occurred. At a minimum there > should be an assert(false, "...") so that we detect this in debug builds. Done. > > --- > > src/share/vm/utilities/semaphore.hpp > > Can we not implement this: > > 53 void signal(); > 54 void signal(uint count); > > as simply: > > void signal(uint count = 1); > > ? Done. > --- > > src/share/vm/utilities/semaphore.cpp: > > The logic in test_semaphore_many isn't quite right. For example if you > call it with value=0, max=2, increment=1, then you will end up > performing two signals() but only one wait(). Fixed. Thanks, StefanK > > Thanks, > David > ----- > > >> Thanks, >> StefanK >> >> On 2015-06-15 22:28, Stefan Karlsson wrote: >>> Hi again, >>> >>> I've hopefully addressed some of Kim's and David's concerns with the >>> following version: >>> >>> http://cr.openjdk.java.net/~stefank/8087322/webrev.01.delta/ >>> http://cr.openjdk.java.net/~stefank/8087322/webrev.01/ >>> >>> Changes in the current version of the patch: >>> >>> - Created a POSIX version that is used by Linux and Solaris (and maybe >>> AIX?). >>> >>> - Use asserts instead of guarantees. (I've got offline feedback that >>> others preferred at least some of the guarantees.) >>> >>> - Print the errno value and the errno string in the posix version >>> >>> - Removed trywait and timedwait from the Semaphore class and added >>> that functionality in platform-specific semaphore classes. This gets >>> rid of the Unimplemented() functions in os_windows.cpp. >>> >>> - I removed the IMPLEMENTS_SEMAPHORE_CLASS define. >>> >>> Some comments about the current patch: >>> >>> - I have not removed the 'max' parameter, since I haven't yet figured >>> out what the max value should be used for windows. >>> >>> - OS X doesn't implement unamed POSIX semaphores, so I have to go >>> through hoops to compile out the POXIS version when building on OS X. >>> >>> - I had to add -lrt to get the patch to link on Solaris. >>> >>> Tested with JPRT, >>> >>> Thanks, >>> StefanK >>> >>> On 2015-06-12 17:21, Stefan Karlsson wrote: >>>> Hi all, >>>> >>>> Please review this patch to create a Semaphore utility class. I need >>>> this class to implementing faster GC thread synchronization [1]. >>>> >>>> http://cr.openjdk.java.net/~stefank/8087322/webrev.00/ >>>> https://bugs.openjdk.java.net/browse/JDK-8087322 >>>> >>>> Some of our platforms already implement a Semaphore class, but those >>>> classes are hidden inside os_.cpp. I've moved the class >>>> declaration to semaphore.hpp, but the implementation is left in the >>>> os_.hpp. I considered creating semaphore_.cpp files, but I >>>> ended up having to restructure too much code and I wanted to focus on >>>> the feature in [1] instead. Should I create a RFE to move the >>>> semaphore implementations? >>>> >>>> There seems to be another opportunity to cleanup the code. If we take >>>> os_linux.cpp, as an example, the code uses both the existing >>>> Semaphore class and the global ::sem_wait and ::sem_post functions. >>>> We might want to consider unifying that code. >>>> >>>> Since HotSpot is built on platforms that I don't have access to and >>>> can't test, I've added the IMPLEMENTS_SEMAPHORE_CLASS define. So, >>>> that I can detect if the the current platform implements the >>>> Semaphore class, and choose what synchronization primitive to use by >>>> the GC. >>>> >>>> The os_bsd.cpp file has support for "non-apple BSD", but I've only >>>> tested this patch with OS X. >>>> >>>> This patch has been tested in JPRT and our nightly testing together >>>> with the patches in [1]. The patch also contains a few unit tests in >>>> semaphore.cpp. >>>> >>>> Thanks, >>>> StefanK >>>> >>>> [1] >>>> http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2015-June/013829.html >>>> >>>> >>> >> From adinn at redhat.com Mon Jun 22 14:34:05 2015 From: adinn at redhat.com (Andrew Dinn) Date: Mon, 22 Jun 2015 15:34:05 +0100 Subject: [aarch64-port-dev ] RFR: 8129426: aarch64: add support for PopCount in C2 In-Reply-To: <558815DA.8020500@redhat.com> References: <1434979401.21282.31.camel@mint> <558815DA.8020500@redhat.com> Message-ID: <55881CDD.2080009@redhat.com> On 22/06/15 15:04, Andrew Haley wrote: > On 06/22/2015 02:23 PM, Edward Nevill wrote: >> Aarch64 currently does not support the PopCountI and PopCountL nodes in aarch64.ad > >> >> Please review and if OK I will push, > > Shouldn't mov in the IregI case be movw? And iRegI be iRegIorL2I? Agreed on both counts. Strictly, for the PopCountI encoding /both/ mov operations -- i.e. to and fro -- should be a movw (I assume that means passing enum tag T1F in place of T1D?). However, using mov for the restore to $dst is safe as we know the top 32 bits will be zero. > I'm guessing that C2 won't do the MOVs itself if you specify the > instruction as vRegD src. I believe you guess right. regards, Andrew Dinn ----------- From volker.simonis at gmail.com Mon Jun 22 14:53:23 2015 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 22 Jun 2015 16:53:23 +0200 Subject: CFW: New hotspot Group Member: Goetz Lindenmaier Message-ID: I hereby nominate Goetz Lindenmaier to Membership in the hotspot Group. Goetz (actually G?tz for those of you who can read umlauts :) is a long standing member of the JVM team at SAP, one of the architects of our Itanium and PowerPC ports and a real C2 maven. He's the main contributor of the C2 PowerPC port but has also contributed changes in many other parts of the VM including memory ordering changes, code cleanups, simplifications and bug fixes. He's a jdk8u committer, jdk9 reviewer and has contributed/reviewed more than 120 changes: http://hg.openjdk.java.net/jdk9/hs/hotspot/search/?rev=goetz&revcount=125 Votes are due by July 6, 18:00 CET. Only current Members of the hotspot Group [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list For Lazy Consensus voting instructions, see [2]. Kind Regards, Volker Simonis [1] http://openjdk.java.net/census [2] http://openjdk.java.net/groups/#member-vote From mikael.gerdin at oracle.com Mon Jun 22 14:55:05 2015 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Mon, 22 Jun 2015 16:55:05 +0200 Subject: CFW: New hotspot Group Member: Goetz Lindenmaier In-Reply-To: References: Message-ID: <558821C9.8090000@oracle.com> Vote: yes On 2015-06-22 16:53, Volker Simonis wrote: > I hereby nominate Goetz Lindenmaier to Membership in the hotspot Group. > > Goetz (actually G?tz for those of you who can read umlauts :) is a > long standing member of the JVM team at SAP, one of the architects of > our Itanium and PowerPC ports and a real C2 maven. He's the main > contributor of the C2 PowerPC port but has also contributed changes in > many other parts of the VM including memory ordering changes, code > cleanups, simplifications and bug fixes. He's a jdk8u committer, > jdk9 reviewer and has contributed/reviewed more than 120 changes: > > http://hg.openjdk.java.net/jdk9/hs/hotspot/search/?rev=goetz&revcount=125 > > Votes are due by July 6, 18:00 CET. > > Only current Members of the hotspot Group [1] are eligible to vote on > this nomination. Votes must be cast in the open by replying to this > mailing list > > For Lazy Consensus voting instructions, see [2]. > > Kind Regards, > Volker Simonis > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/groups/#member-vote > From edward.nevill at gmail.com Mon Jun 22 14:59:42 2015 From: edward.nevill at gmail.com (Edward Nevill) Date: Mon, 22 Jun 2015 15:59:42 +0100 Subject: [aarch64-port-dev ] RFR: 8129426: aarch64: add support for PopCount in C2 In-Reply-To: <558815DA.8020500@redhat.com> References: <1434979401.21282.31.camel@mint> <558815DA.8020500@redhat.com> Message-ID: <1434985182.21282.34.camel@mint> On Mon, 2015-06-22 at 15:04 +0100, Andrew Haley wrote: > On 06/22/2015 02:23 PM, Edward Nevill wrote: > > Aarch64 currently does not support the PopCountI and PopCountL nodes in aarch64.ad > > > > > Please review and if OK I will push, > > Shouldn't mov in the IregI case be movw? And iRegI be iRegIorL2I? No. It needs 0s in the top 32 bits. The reason is that the following CNT instruction is only available in 8B or 16B forms. It was iRegIorL2I before, I changed it to IregI because of this problem. Regards, Ed. From vladimir.kozlov at oracle.com Mon Jun 22 14:59:56 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 22 Jun 2015 07:59:56 -0700 Subject: CFW: New hotspot Group Member: Goetz Lindenmaier In-Reply-To: References: Message-ID: <558822EC.6070301@oracle.com> Vote: yes Vladimir On 6/22/15 7:53 AM, Volker Simonis wrote: > I hereby nominate Goetz Lindenmaier to Membership in the hotspot Group. > > Goetz (actually G?tz for those of you who can read umlauts :) is a > long standing member of the JVM team at SAP, one of the architects of > our Itanium and PowerPC ports and a real C2 maven. He's the main > contributor of the C2 PowerPC port but has also contributed changes in > many other parts of the VM including memory ordering changes, code > cleanups, simplifications and bug fixes. He's a jdk8u committer, > jdk9 reviewer and has contributed/reviewed more than 120 changes: > > http://hg.openjdk.java.net/jdk9/hs/hotspot/search/?rev=goetz&revcount=125 > > Votes are due by July 6, 18:00 CET. > > Only current Members of the hotspot Group [1] are eligible to vote on > this nomination. Votes must be cast in the open by replying to this > mailing list > > For Lazy Consensus voting instructions, see [2]. > > Kind Regards, > Volker Simonis > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/groups/#member-vote > From aph at redhat.com Mon Jun 22 15:04:29 2015 From: aph at redhat.com (Andrew Haley) Date: Mon, 22 Jun 2015 16:04:29 +0100 Subject: [aarch64-port-dev ] RFR: 8129426: aarch64: add support for PopCount in C2 In-Reply-To: <1434985182.21282.34.camel@mint> References: <1434979401.21282.31.camel@mint> <558815DA.8020500@redhat.com> <1434985182.21282.34.camel@mint> Message-ID: <558823FD.5080800@redhat.com> On 06/22/2015 03:59 PM, Edward Nevill wrote: > On Mon, 2015-06-22 at 15:04 +0100, Andrew Haley wrote: >> On 06/22/2015 02:23 PM, Edward Nevill wrote: >>> Aarch64 currently does not support the PopCountI and PopCountL nodes in aarch64.ad >> >>> >>> Please review and if OK I will push, >> >> Shouldn't mov in the IregI case be movw? And iRegI be iRegIorL2I? > > No. It needs 0s in the top 32 bits. > > The reason is that the following CNT instruction is only available in 8B or 16B forms. > > It was iRegIorL2I before, I changed it to IregI because of this problem. Well, you're asking for trouble. We've tried to make sure that the top half of an int register is always zero, but it's hard absolutely to guarantee it in all cases. Does movw to a vector register really not clear the top 32 bits of the dest? Andrew. From daniel.daugherty at oracle.com Mon Jun 22 15:08:23 2015 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Mon, 22 Jun 2015 09:08:23 -0600 Subject: CFW: New hotspot Group Member: Goetz Lindenmaier In-Reply-To: References: Message-ID: <558824E7.5050605@oracle.com> Vote: yes Dan On 6/22/15 8:53 AM, Volker Simonis wrote: > I hereby nominate Goetz Lindenmaier to Membership in the hotspot Group. > > Goetz (actually G?tz for those of you who can read umlauts :) is a > long standing member of the JVM team at SAP, one of the architects of > our Itanium and PowerPC ports and a real C2 maven. He's the main > contributor of the C2 PowerPC port but has also contributed changes in > many other parts of the VM including memory ordering changes, code > cleanups, simplifications and bug fixes. He's a jdk8u committer, > jdk9 reviewer and has contributed/reviewed more than 120 changes: > > http://hg.openjdk.java.net/jdk9/hs/hotspot/search/?rev=goetz&revcount=125 > > Votes are due by July 6, 18:00 CET. > > Only current Members of the hotspot Group [1] are eligible to vote on > this nomination. Votes must be cast in the open by replying to this > mailing list > > For Lazy Consensus voting instructions, see [2]. > > Kind Regards, > Volker Simonis > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/groups/#member-vote From adinn at redhat.com Mon Jun 22 15:29:22 2015 From: adinn at redhat.com (Andrew Dinn) Date: Mon, 22 Jun 2015 16:29:22 +0100 Subject: [aarch64-port-dev ] RFR: 8129426: aarch64: add support for PopCount in C2 In-Reply-To: <558823FD.5080800@redhat.com> References: <1434979401.21282.31.camel@mint> <558815DA.8020500@redhat.com> <1434985182.21282.34.camel@mint> <558823FD.5080800@redhat.com> Message-ID: <558829D2.4000503@redhat.com> On 22/06/15 16:04, Andrew Haley wrote: > On 06/22/2015 03:59 PM, Edward Nevill wrote: >> On Mon, 2015-06-22 at 15:04 +0100, Andrew Haley wrote: >>> On 06/22/2015 02:23 PM, Edward Nevill wrote: >>>> Aarch64 currently does not support the PopCountI and PopCountL nodes in aarch64.ad >>> >>>> >>>> Please review and if OK I will push, >>> >>> Shouldn't mov in the IregI case be movw? And iRegI be iRegIorL2I? >> >> No. It needs 0s in the top 32 bits. >> >> The reason is that the following CNT instruction is only available in 8B or 16B forms. >> >> It was iRegIorL2I before, I changed it to IregI because of this problem. > > Well, you're asking for trouble. We've tried to make sure that the > top half of an int register is always zero, but it's hard absolutely > to guarantee it in all cases. Does movw to a vector register really > not clear the top 32 bits of the dest? Aargh, after checking the Manuel (as a last resort) it appears that the 32 bit move carefully moves a 32 bit word into a 32 bit slot leaving the rest of the slots unchanged -- MOV is documented as an alias for INS which pretty much explains the semantics. It seems that the scalar fmovw instruction does the same (it is documented as overlapping the behaviour of the vector move instruction). So, it seems Ed is right to use iRegI and rely on an l2i conversion to zero the top word if the incoming value is long. regards, Andrew Dinn ----------- From aph at redhat.com Mon Jun 22 15:41:08 2015 From: aph at redhat.com (Andrew Haley) Date: Mon, 22 Jun 2015 16:41:08 +0100 Subject: [aarch64-port-dev ] RFR: 8129426: aarch64: add support for PopCount in C2 In-Reply-To: <558829D2.4000503@redhat.com> References: <1434979401.21282.31.camel@mint> <558815DA.8020500@redhat.com> <1434985182.21282.34.camel@mint> <558823FD.5080800@redhat.com> <558829D2.4000503@redhat.com> Message-ID: <55882C94.7030505@redhat.com> On 06/22/2015 04:29 PM, Andrew Dinn wrote: > So, it seems Ed is right to use iRegI and rely on an l2i conversion to > zero the top word if the incoming value is long. I don't think that's safe. I certainly don't think it's a good tradeoff. I think it'd be the only place in our entire code base where we assume that the high bits of a jint are zero. If it really wants zeros in the top bits we'd better put them there. Andrew. From adinn at redhat.com Mon Jun 22 15:50:36 2015 From: adinn at redhat.com (Andrew Dinn) Date: Mon, 22 Jun 2015 16:50:36 +0100 Subject: [aarch64-port-dev ] RFR: 8129426: aarch64: add support for PopCount in C2 In-Reply-To: <55882C94.7030505@redhat.com> References: <1434979401.21282.31.camel@mint> <558815DA.8020500@redhat.com> <1434985182.21282.34.camel@mint> <558823FD.5080800@redhat.com> <558829D2.4000503@redhat.com> <55882C94.7030505@redhat.com> Message-ID: <55882ECC.8030602@redhat.com> On 22/06/15 16:41, Andrew Haley wrote: > On 06/22/2015 04:29 PM, Andrew Dinn wrote: >> So, it seems Ed is right to use iRegI and rely on an l2i conversion to >> zero the top word if the incoming value is long. > > I don't think that's safe. I certainly don't think it's a good > tradeoff. I think it'd be the only place in our entire code base > where we assume that the high bits of a jint are zero. If it really > wants zeros in the top bits we'd better put them there. Well, yes, but it really /ought/ to be safe. Whenever we generate an iRegI dst output we should be using a foow instruction and end up with the top 32 bits zero. So, wherever we consume an iRegI src input we ought to be able to rely on it having top bits zero. Either it was generated directly as an iRegI output or it was generated as an iRegL output and passed in via an l2i conversion. If that assumption fails anywhere then it will only fail because we used a foo insn where we really needed a foow. I think we would be better to let any such errors fail as quickly as possible, find the error and fix the offending code to use foow. Your mileage may vary. regards, Andrew Dinn ----------- From aph at redhat.com Mon Jun 22 16:01:00 2015 From: aph at redhat.com (Andrew Haley) Date: Mon, 22 Jun 2015 17:01:00 +0100 Subject: [aarch64-port-dev ] RFR: 8129426: aarch64: add support for PopCount in C2 In-Reply-To: <55882ECC.8030602@redhat.com> References: <1434979401.21282.31.camel@mint> <558815DA.8020500@redhat.com> <1434985182.21282.34.camel@mint> <558823FD.5080800@redhat.com> <558829D2.4000503@redhat.com> <55882C94.7030505@redhat.com> <55882ECC.8030602@redhat.com> Message-ID: <5588313C.1070409@redhat.com> On 06/22/2015 04:50 PM, Andrew Dinn wrote: > On 22/06/15 16:41, Andrew Haley wrote: >> On 06/22/2015 04:29 PM, Andrew Dinn wrote: >>> So, it seems Ed is right to use iRegI and rely on an l2i conversion to >>> zero the top word if the incoming value is long. >> >> I don't think that's safe. I certainly don't think it's a good >> tradeoff. I think it'd be the only place in our entire code base >> where we assume that the high bits of a jint are zero. If it really >> wants zeros in the top bits we'd better put them there. > > Well, yes, but it really /ought/ to be safe. > > Whenever we generate an iRegI dst output we should be using a foow > instruction and end up with the top 32 bits zero. So, wherever we > consume an iRegI src input we ought to be able to rely on it having top > bits zero. Either it was generated directly as an iRegI output or it was > generated as an iRegL output and passed in via an l2i conversion. > > If that assumption fails anywhere then it will only fail because we used > a foo insn where we really needed a foow. I think we would be better to > let any such errors fail as quickly as possible, find the error and fix > the offending code to use foow. And how would we even notice it, yet alone find the error? > Your mileage may vary. Hmm. So far we've been very conservative, making sure that we always use the correct mode for inputs and the correct mode for outputs. If we're going to start making assumptions that top bits of int ops are always zero we could always elide l2i to a no-op. So far we have resisted that, and with good reason IMO. I wrote the deoptimization code and was pretty careful to do the right thing, but also very reassured that it probably didn't matter. I don't think we can guarantee that nowhere do we have a sign extension where there should be a zero extension. Andrew. From adinn at redhat.com Mon Jun 22 16:14:18 2015 From: adinn at redhat.com (Andrew Dinn) Date: Mon, 22 Jun 2015 17:14:18 +0100 Subject: [aarch64-port-dev ] RFR: 8129426: aarch64: add support for PopCount in C2 In-Reply-To: <5588313C.1070409@redhat.com> References: <1434979401.21282.31.camel@mint> <558815DA.8020500@redhat.com> <1434985182.21282.34.camel@mint> <558823FD.5080800@redhat.com> <558829D2.4000503@redhat.com> <55882C94.7030505@redhat.com> <55882ECC.8030602@redhat.com> <5588313C.1070409@redhat.com> Message-ID: <5588345A.4060708@redhat.com> On 22/06/15 17:01, Andrew Haley wrote: > On 06/22/2015 04:50 PM, Andrew Dinn wrote: >> If that assumption fails anywhere then it will only fail because we used >> a foo insn where we really needed a foow. I think we would be better to >> let any such errors fail as quickly as possible, find the error and fix >> the offending code to use foow. > > And how would we even notice it, yet alone find the error? I agree it will not necessarily be easy to spot. Bit we know exactly where to look (see below). >> Your mileage may vary. > > Hmm. So far we've been very conservative, making sure that we always > use the correct mode for inputs and the correct mode for outputs. If > we're going to start making assumptions that top bits of int ops are > always zero we could always elide l2i to a no-op. So far we have > resisted that, and with good reason IMO. No, that last statement is not at all correct. l2i is explicitly inserted into the ideal graph when the compiler knows that a value generated as long is being consumed as an int and so needs to be truncated. We have explicitly avoided performing any truncation to effect that l2i in every rule where we accept an input of iRegIorL2I. In all such cases we have ensured that the instruction which consumes the input is a foow not a foo. That's quite checkable by eyeball. For this one case, we also need to be sure that every instruction which generates an iRegI output uses a foow instruction which, (according to the manual) zeroes the top bits. That's also checkable by eyeball. We also need to be sure that anything spilled as a 32 bit int is restored as a 32 bit int with the top bits correspondingly zeroed. > I wrote the deoptimization code and was pretty careful to do the right > thing, but also very reassured that it probably didn't matter. I > don't think we can guarantee that nowhere do we have a sign extension > where there should be a zero extension. Well, you might not want to take this risk and instead add an explicit zero of the upper half. But I think we need to be clear what risk we are taking. regards, Andrew Dinn ----------- From jesper.wilhelmsson at oracle.com Mon Jun 22 16:22:17 2015 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Mon, 22 Jun 2015 18:22:17 +0200 Subject: CFW: New hotspot Group Member: Goetz Lindenmaier In-Reply-To: References: Message-ID: <55883639.3040503@oracle.com> Vote: Yes. /Jesper Volker Simonis skrev den 22/6/15 16:53: > I hereby nominate Goetz Lindenmaier to Membership in the hotspot Group. > > Goetz (actually G?tz for those of you who can read umlauts :) is a > long standing member of the JVM team at SAP, one of the architects of > our Itanium and PowerPC ports and a real C2 maven. He's the main > contributor of the C2 PowerPC port but has also contributed changes in > many other parts of the VM including memory ordering changes, code > cleanups, simplifications and bug fixes. He's a jdk8u committer, > jdk9 reviewer and has contributed/reviewed more than 120 changes: > > http://hg.openjdk.java.net/jdk9/hs/hotspot/search/?rev=goetz&revcount=125 > > Votes are due by July 6, 18:00 CET. > > Only current Members of the hotspot Group [1] are eligible to vote on > this nomination. Votes must be cast in the open by replying to this > mailing list > > For Lazy Consensus voting instructions, see [2]. > > Kind Regards, > Volker Simonis > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/groups/#member-vote > From ChrisPhi at LGonQn.Org Mon Jun 22 17:16:45 2015 From: ChrisPhi at LGonQn.Org (Chris Phillips @ T O) Date: Mon, 22 Jun 2015 13:16:45 -0400 Subject: CFW: New hotspot Group Member: Goetz Lindenmaier In-Reply-To: References: Message-ID: <558842FD.1030705@LGonQn.Org> Vote: yes Cheers! Chris On 22/06/15 10:53 AM, Volker Simonis wrote: > I hereby nominate Goetz Lindenmaier to Membership in the hotspot Group. > > Goetz (actually G?tz for those of you who can read umlauts :) is a > long standing member of the JVM team at SAP, one of the architects of > our Itanium and PowerPC ports and a real C2 maven. He's the main > contributor of the C2 PowerPC port but has also contributed changes in > many other parts of the VM including memory ordering changes, code > cleanups, simplifications and bug fixes. He's a jdk8u committer, > jdk9 reviewer and has contributed/reviewed more than 120 changes: > > http://hg.openjdk.java.net/jdk9/hs/hotspot/search/?rev=goetz&revcount=125 > > Votes are due by July 6, 18:00 CET. > > Only current Members of the hotspot Group [1] are eligible to vote on > this nomination. Votes must be cast in the open by replying to this > mailing list > > For Lazy Consensus voting instructions, see [2]. > > Kind Regards, > Volker Simonis > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/groups/#member-vote > > > From christian.thalinger at oracle.com Mon Jun 22 18:05:23 2015 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 22 Jun 2015 11:05:23 -0700 Subject: CFW: New hotspot Group Member: Goetz Lindenmaier In-Reply-To: References: Message-ID: Vote: yes > On Jun 22, 2015, at 7:53 AM, Volker Simonis wrote: > > I hereby nominate Goetz Lindenmaier to Membership in the hotspot Group. > > Goetz (actually G?tz for those of you who can read umlauts :) is a > long standing member of the JVM team at SAP, one of the architects of > our Itanium and PowerPC ports and a real C2 maven. He's the main > contributor of the C2 PowerPC port but has also contributed changes in > many other parts of the VM including memory ordering changes, code > cleanups, simplifications and bug fixes. He's a jdk8u committer, > jdk9 reviewer and has contributed/reviewed more than 120 changes: > > http://hg.openjdk.java.net/jdk9/hs/hotspot/search/?rev=goetz&revcount=125 > > Votes are due by July 6, 18:00 CET. > > Only current Members of the hotspot Group [1] are eligible to vote on > this nomination. Votes must be cast in the open by replying to this > mailing list > > For Lazy Consensus voting instructions, see [2]. > > Kind Regards, > Volker Simonis > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/groups/#member-vote From coleen.phillimore at oracle.com Mon Jun 22 19:08:36 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Mon, 22 Jun 2015 15:08:36 -0400 Subject: CFW: New hotspot Group Member: Goetz Lindenmaier In-Reply-To: References: Message-ID: <55885D34.1080109@oracle.com> Vote: yes On 6/22/15 10:53 AM, Volker Simonis wrote: > I hereby nominate Goetz Lindenmaier to Membership in the hotspot Group. > > Goetz (actually G?tz for those of you who can read umlauts :) is a > long standing member of the JVM team at SAP, one of the architects of > our Itanium and PowerPC ports and a real C2 maven. He's the main > contributor of the C2 PowerPC port but has also contributed changes in > many other parts of the VM including memory ordering changes, code > cleanups, simplifications and bug fixes. He's a jdk8u committer, > jdk9 reviewer and has contributed/reviewed more than 120 changes: > > http://hg.openjdk.java.net/jdk9/hs/hotspot/search/?rev=goetz&revcount=125 > > Votes are due by July 6, 18:00 CET. > > Only current Members of the hotspot Group [1] are eligible to vote on > this nomination. Votes must be cast in the open by replying to this > mailing list > > For Lazy Consensus voting instructions, see [2]. > > Kind Regards, > Volker Simonis > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/groups/#member-vote From ivan at azulsystems.com Mon Jun 22 19:36:44 2015 From: ivan at azulsystems.com (Ivan Krylov) Date: Mon, 22 Jun 2015 22:36:44 +0300 Subject: CFW: New hotspot Group Member: Goetz Lindenmaier In-Reply-To: References: Message-ID: <558863CC.6070601@azulsystems.com> Vote: yes Ivan On 22/06/2015 17:53, Volker Simonis wrote: > I hereby nominate Goetz Lindenmaier to Membership in the hotspot Group. > > Goetz (actually G?tz for those of you who can read umlauts :) is a > long standing member of the JVM team at SAP, one of the architects of > our Itanium and PowerPC ports and a real C2 maven. He's the main > contributor of the C2 PowerPC port but has also contributed changes in > many other parts of the VM including memory ordering changes, code > cleanups, simplifications and bug fixes. He's a jdk8u committer, > jdk9 reviewer and has contributed/reviewed more than 120 changes: > > http://hg.openjdk.java.net/jdk9/hs/hotspot/search/?rev=goetz&revcount=125 > > Votes are due by July 6, 18:00 CET. > > Only current Members of the hotspot Group [1] are eligible to vote on > this nomination. Votes must be cast in the open by replying to this > mailing list > > For Lazy Consensus voting instructions, see [2]. > > Kind Regards, > Volker Simonis > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/groups/#member-vote From kevin.walls at oracle.com Mon Jun 22 20:11:27 2015 From: kevin.walls at oracle.com (Kevin Walls) Date: Mon, 22 Jun 2015 21:11:27 +0100 Subject: CFV: New HotSpot Group Lead: Vladimir Kozlov In-Reply-To: References: Message-ID: <55886BEF.2070505@oracle.com> Vote: yes On 15/06/2015 17:56, Christian Thalinger wrote: > I hereby nominate Vladimir Kozlov to HotSpot Group Lead [1]. > > Vladimir is a member of the HotSpot Group since OpenJDK was > established, is working on the HotSpot JVM for more than 12 years > and is well known in the HotSpot OpenJDK community. > > Votes are due by June 26, 2015 12:00 PST. > > Only current Members of the HotSpot Group [2] are eligible to > vote on this nomination. Votes must be cast in the open by > replying to this mailing list. > > For Simple Majority voting instructions, see [3]. > > Thanks, > Christian Thalinger > > [1]: http://openjdk.java.net/bylaws#group-lead > [2]: http://openjdk.java.net/census#hotspot > [3]: http://openjdk.java.net/groups#lead-vote From mikael.vidstedt at oracle.com Mon Jun 22 22:47:17 2015 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Mon, 22 Jun 2015 15:47:17 -0700 Subject: RFR (XS): 8129518: Remove ParOldGC tests from the jprt hotspot testset Message-ID: <55889075.8030607@oracle.com> Please review the following small change which removes all the ParOldGC test targets from the jprt hotspot testset. The ParOldGC tests are run with the -XX:+UseParallelOldGC flag, but that has for some time already been the default when using the Parallel GC, and there are already corresponding tests which already test that configuration - namely the ParallelGC ones. This change simply removes the redundant test targets. Bug: https://bugs.openjdk.java.net/browse/JDK-8129518 Webrev: http://cr.openjdk.java.net/~mikael/webrevs/8129518/webrev.00/webrev/ Cheers, Mikael From vladimir.kozlov at oracle.com Mon Jun 22 23:03:53 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 22 Jun 2015 16:03:53 -0700 Subject: RFR (XS): 8129518: Remove ParOldGC tests from the jprt hotspot testset In-Reply-To: <55889075.8030607@oracle.com> References: <55889075.8030607@oracle.com> Message-ID: <55889459.5040501@oracle.com> Stupid question from not GC person? Are not we switching to G1 default? In such case will we run any ParOldGC tests? Thanks, Vladimir On 6/22/15 3:47 PM, Mikael Vidstedt wrote: > > Please review the following small change which removes all the ParOldGC test targets from the jprt hotspot testset. The > ParOldGC tests are run with the -XX:+UseParallelOldGC flag, but that has for some time already been the default when > using the Parallel GC, and there are already corresponding tests which already test that configuration - namely the > ParallelGC ones. This change simply removes the redundant test targets. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8129518 > Webrev: http://cr.openjdk.java.net/~mikael/webrevs/8129518/webrev.00/webrev/ > > Cheers, > Mikael > From mikael.vidstedt at oracle.com Mon Jun 22 23:16:23 2015 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Mon, 22 Jun 2015 16:16:23 -0700 Subject: RFR (XS): 8129518: Remove ParOldGC tests from the jprt hotspot testset In-Reply-To: <55889459.5040501@oracle.com> References: <55889075.8030607@oracle.com> <55889459.5040501@oracle.com> Message-ID: <55889747.6070708@oracle.com> Even with this change we still have ParallelGC tests explicitly listed, as well as G1, SerialGC and CMS. So no matter what the actual default is we will still run the ParallelGC tests, and therefore UseParallelOldGC since that's the default with Parallel. I believe that's reasonable in order to get some basic coverage of the major GCs. Cheers, Mikael On 2015-06-22 16:03, Vladimir Kozlov wrote: > Stupid question from not GC person? > Are not we switching to G1 default? In such case will we run any > ParOldGC tests? > > Thanks, > Vladimir > > On 6/22/15 3:47 PM, Mikael Vidstedt wrote: >> >> Please review the following small change which removes all the >> ParOldGC test targets from the jprt hotspot testset. The >> ParOldGC tests are run with the -XX:+UseParallelOldGC flag, but that >> has for some time already been the default when >> using the Parallel GC, and there are already corresponding tests >> which already test that configuration - namely the >> ParallelGC ones. This change simply removes the redundant test targets. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8129518 >> Webrev: >> http://cr.openjdk.java.net/~mikael/webrevs/8129518/webrev.00/webrev/ >> >> Cheers, >> Mikael >> From coleen.phillimore at oracle.com Tue Jun 23 01:16:57 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Mon, 22 Jun 2015 21:16:57 -0400 Subject: Revision3: Corrected: RFR 8059557 (XL): Validate JVM Command-Line Flag Arguments In-Reply-To: <557F63E6.2040501@oracle.com> References: <557C3EF0.3030107@oracle.com> <557F63E6.2040501@oracle.com> Message-ID: <5588B389.30305@oracle.com> Hi Gerard, I realized that I didn't send my code review to the public alias. None of these comments prevented checking it in but hopefully you fixed the first one at least, and the rest are RFEs. Thanks, Coleen On 6/15/15 7:46 PM, Coleen Phillimore wrote: > > Hi Gerard, > > I have read through the code again and the code still looks good to > me. I had a couple of questions, which you could either answer "no" > or have in a follow-up RFE. > > http://cr.openjdk.java.net/~gziemski/8059557_rev3/src/share/vm/runtime/commandLineFlagRangeList.cpp.html > 87 st->print("[ "INTX_FORMAT_W(-25)" ... "INTX_FORMAT_W(25)" ]", _min, _max); > In some C++15 code the lack of space between INTX_FORMAT and the > string is an error, can you fix these? I thought you had this comment > already but either I have an old webrev or you missed this one. > > http://cr.openjdk.java.net/~gziemski/8059557_rev3/src/share/vm/runtime/commandLineFlagConstraintsCompiler.cpp.html > 31 Flag::Error AliasLevelConstraintFunc(bool verbose, intx* value) { > In the constraint functions, the value parameter isn't set by the > function. Why is it a pointer rather than a value? Is this required > for instantiating the macro for the constraint functions? If so, > could you make the pointers const or would that also not instantiate > correctly with the macro? > > http://cr.openjdk.java.net/~gziemski/8059557_rev3/src/share/vm/runtime/commandLineFlagConstraintsRuntime.cpp.html > 33 if (verbose == true) { > 34 jio_fprintf(defaultStream::error_stream(), > 35 "ObjectAlignmentInBytes=" INTX_FORMAT " must be power of 2\n", > 36 *value); > 37 } > > It seems like a printing function like > print_command_line_error(verbose, const char* fmt, ...) would be nice > here since this code pattern exists in a lot of places and it'll catch > someone from forgetting the if (verbose) check. > > For booleans, the style is if (verbose) rather than if (verbose == > true), which I think people have pointed out. If the thing in the > conditional is a pointer, it should be explicitly checked for NULL: > if (ptr == NULL) or ideally if (NULL == ptr). > > This code looks ready to go except some issues that you've filed RFEs > for. We could look at this for months and still find items that are > good to change, but as a significant piece of work and in my opinion > the cleanups are small enough to do later. This follows our coding > standards for consistency and quality, and you've done an excellent > job answering people's comments and making sure that the tests run and > there are no regressions. > > Thank you! > Coleen > > > On 6/13/15 10:32 AM, Gerard Ziemski wrote: >> hi all, >> >> Thank you for the reviews so far! >> >> Here is a revision 3 of the feature taking into account feedback from Kim Barrett, David Holmes, Derek White and Bengt Rutisson. I have also merged the changes to the latest jdk9. >> >> We introduce a new mechanism that allows specification of a valid range per flag that is then used to automatically validate given flag's value every time it changes. Ranges values must be constant and can not change. Optionally, a constraint can also be specified and applied every time a flag value changes for those flags whose valid value can not be trivially checked by a simple min and max (ex. whether it's power of 2, or bigger or smaller than some other flag that can also change) >> >> I have chosen to modify the table macros (ex. RUNTIME_FLAGS in globals.hpp) instead of using a more sophisticated solution, such as C++ templates, because even though macros were unfriendly when initially developing, once a solution was arrived at, subsequent additions to the tables of new ranges, or constraint are trivial from developer's point of view. (The intial development unfriendliness of macros was mitigated by using a pre-processor, which for those using a modern IDE like Xcode, is easily available from a menu). Using macros also allowed for more minimal code changes. >> >> The presented solution is based on expansion of macros using variadic functions and can be readily seen in runtime/commandLineFlagConstraintList.cpp and runtime/commandLineFlagRangeList.cpp >> >> In commandLineFlagConstraintList.cpp or commandLineFlagRangesList.cpp, there is bunch of classes and methods that seems to beg for C++ template to be used. I have tried, but when the compiler tries to generate code for both uintx and size_t, which happen to have the same underlying type (on BSD), it fails to compile overridden methods with same type, but different name. If someone has a way of simplifying the new code via C++ templates, however, we can file a new enhancement request to address that. >> >> This webrev represents only the initial range checking framework and only 100 or so flags that were ported from an existing ad hoc range checking code to this new mechanism. There are about 250 remaining flags that still need their ranges determined and ported over to this new mechanism and they are tracked by individual subtasks. >> >> I had to modify several existing tests to change the error message that they expected when VM refuses to run, which was changed to provide uniform error messages. >> >> To help with testing and subtask efforts I have introduced a new runtime flag: >> >> PrintFlagsRanges: "Print VM flags and their ranges and exit VM" >> >> which in addition to the already existing flags: "PrintFlagsInitial" and "PrintFlagsFinal" allow for thorough examination of the flags values and their ranges. >> >> The code change builds and passes JPRT (-testset hotspot) and UTE (vm.quick.testlist) >> >> >> References: >> >> Webrev:http://cr.openjdk.java.net/~gziemski/8059557_rev3 >> JEP:https://bugs.openjdk.java.net/browse/JDK-8059557 >> Compiler subtask:https://bugs.openjdk.java.net/browse/JDK-8078554 >> GC subtask:https://bugs.openjdk.java.net/browse/JDK-8078555 >> Runtime subtask:https://bugs.openjdk.java.net/browse/JDK-8078556 >> >> Note: due to "awk" limit of 50 pats the Frames diff is not available for "src/share/vm/runtime/arguments.cpp? and "src/share/vm/runtime/globals.cpp? >> >> >> Followup issues: >> >> JDK-8085866: There are 99 uses of FLAG_SET_ERGO, should they check the return value? >> JDK-8085864: FLAG_SET_CMDLINE in TestGenCollectorPolicy() currently ignore the return values >> JDK-8081842: Find a better place for EMIT_{CONSTRAINTS,RANGES}_FOR_GLOBALS_EXT >> JDK-8081833: There is a large amount of code near-duplication among the various CommandLineFlagRange_ classes >> JDK-8081519: Split globals.hpp to factor out the Flag values needed by JDK-8059557 >> >> >> hgstat: >> >> src/cpu/ppc/vm/globals_ppc.hpp | 2 +- >> src/cpu/sparc/vm/globals_sparc.hpp | 2 +- >> src/cpu/x86/vm/globals_x86.hpp | 2 +- >> src/cpu/zero/vm/globals_zero.hpp | 3 +- >> src/os/aix/vm/globals_aix.hpp | 2 +- >> src/os/bsd/vm/globals_bsd.hpp | 29 +- >> src/os/linux/vm/globals_linux.hpp | 9 +- >> src/os/solaris/vm/globals_solaris.hpp | 4 +- >> src/os/windows/vm/globals_windows.hpp | 5 +- >> src/share/vm/c1/c1_globals.cpp | 4 +- >> src/share/vm/c1/c1_globals.hpp | 17 +- >> src/share/vm/gc/g1/g1_globals.cpp | 14 +- >> src/share/vm/gc/g1/g1_globals.hpp | 38 +- >> src/share/vm/opto/c2_globals.cpp | 12 +- >> src/share/vm/opto/c2_globals.hpp | 40 +- >> src/share/vm/prims/whitebox.cpp | 12 +- >> src/share/vm/runtime/arguments.cpp | 765 ++++++---------- >> src/share/vm/runtime/arguments.hpp | 24 +- >> src/share/vm/runtime/commandLineFlagConstraintList.cpp | 286 ++++++ >> src/share/vm/runtime/commandLineFlagConstraintList.hpp | 80 + >> src/share/vm/runtime/commandLineFlagConstraintsCompiler.cpp | 44 + >> src/share/vm/runtime/commandLineFlagConstraintsCompiler.hpp | 39 + >> src/share/vm/runtime/commandLineFlagConstraintsGC.cpp | 235 +++++ >> src/share/vm/runtime/commandLineFlagConstraintsGC.hpp | 58 + >> src/share/vm/runtime/commandLineFlagConstraintsRuntime.cpp | 65 + >> src/share/vm/runtime/commandLineFlagConstraintsRuntime.hpp | 41 + >> src/share/vm/runtime/commandLineFlagRangeList.cpp | 367 ++++++++ >> src/share/vm/runtime/commandLineFlagRangeList.hpp | 71 + >> src/share/vm/runtime/globals.cpp | 721 ++++++++++++--- >> src/share/vm/runtime/globals.hpp | 343 ++++++- >> src/share/vm/runtime/globals_extension.hpp | 105 +- >> src/share/vm/runtime/init.cpp | 5 +- >> src/share/vm/runtime/os_ext.hpp | 7 +- >> src/share/vm/runtime/thread.cpp | 6 + >> src/share/vm/services/attachListener.cpp | 4 +- >> src/share/vm/services/classLoadingService.cpp | 12 +- >> src/share/vm/services/diagnosticCommand.cpp | 3 +- >> src/share/vm/services/management.cpp | 6 +- >> src/share/vm/services/memoryService.cpp | 4 +- >> src/share/vm/services/writeableFlags.cpp | 183 ++- >> src/share/vm/services/writeableFlags.hpp | 60 +- >> test/compiler/c2/7200264/Test7200264.sh | 5 +- >> test/compiler/startup/NumCompilerThreadsCheck.java | 2 +- >> test/gc/arguments/TestHeapFreeRatio.java | 23 +- >> test/gc/arguments/TestSurvivorAlignmentInBytesOption.java | 6 +- >> test/gc/g1/TestStringDeduplicationTools.java | 6 +- >> test/runtime/CompressedOops/CompressedClassSpaceSize.java | 4 +- >> test/runtime/CompressedOops/ObjectAlignment.java | 9 +- >> test/runtime/contended/Options.java | 10 +- >> 49 files changed, 2851 insertions(+), 943 deletions(-) >> > From david.holmes at oracle.com Tue Jun 23 01:20:30 2015 From: david.holmes at oracle.com (David Holmes) Date: Tue, 23 Jun 2015 11:20:30 +1000 Subject: RFR(s): 8078513: [linux] Clean up code relevant to LinuxThreads implementation In-Reply-To: <55838D3B.4040806@oracle.com> References: <554FF886.7030502@oracle.com> <55540B22.70807@oracle.com> <555C48F0.8090205@oracle.com> <557A3DB3.5040002@oracle.com> <55838D3B.4040806@oracle.com> Message-ID: <5588B45E.30607@oracle.com> CCC approved and changes pushed. David On 19/06/2015 1:32 PM, David Holmes wrote: > On 15/06/2015 10:57 PM, Thomas St?fe wrote: >> Hi Volker, David, >> >> Volker, thanks for the review! >> >> new version: >> >> http://cr.openjdk.java.net/~stuefe/webrevs/8078513/webrev.04/webrev/ >> >> I added all changes Volker wanted. > > The copyright notice change in agent/src/os/linux/proc_service.h has the > wrong format - needs comma after second year and has to remain on a > single line. I'll fix before pushing. > >> Oh, and I forgot to add Volker as a Reviewer, please add him when >> pushing. > > Will do. > > I also forgot that a CCC request needed to be put in to deprecate > ThreadSafetyMargin :( That will delay the push a while I'm afraid. > > Thanks, > David > >> Kind Regards, Thomas >> >> >> >> >> >> >> >> On Mon, Jun 15, 2015 at 11:23 AM, Thomas St?fe > > wrote: >> >> Hi, >> >> sorry, dropped the ball on this one. Will post an updated version >> soon. >> >> Thomas >> >> On Fri, Jun 12, 2015 at 4:02 AM, David Holmes >> > wrote: >> >> Hi Thomas, >> >> If you can address Volker's comments we can move forward with >> this. I'll be primary Reviewer and Volker a second reviewer. >> >> Thanks, >> David >> >> On 3/06/2015 3:52 PM, Thomas St?fe wrote: >> >> Ping... >> >> Still need a second reviewer. >> >> Thanks! >> >> On Wednesday, May 20, 2015, Thomas St?fe >> >> > >> wrote: >> >> David, thanks! >> >> to all: could I have a second reviewer, please? >> >> Thanks & Kind Regards, Thomas >> >> On Wed, May 20, 2015 at 10:42 AM, David Holmes >> > >> > ');>> wrote: >> >> Hi Thomas, >> >> Summary: ok - need second reviewer ( I think Coleen >> is away) >> >> More inline ... >> >> On 19/05/2015 10:26 PM, Thomas St?fe wrote: >> >> Hi David, >> >> new webrev: >> >> http://cr.openjdk.java.net/~stuefe/webrevs/8078513/webrev.02/webrev/ >> >> Only two things changed. I reverted my comment >> change in the >> SA and in >> os_linux.cpp I massaged the >> "expand-thread-stack" comment >> text a bit. >> >> More details inline. >> >> On Thu, May 14, 2015 at 4:40 AM, David Holmes >> > >> >> > ');> >> > >> >> > ');>>> >> wrote: >> >> Hi Thomas, >> >> On 14/05/2015 2:32 AM, Thomas St?fe wrote: >> >> Hi David, >> >> here the new version: >> >> http://cr.openjdk.java.net/~stuefe/webrevs/8078513/webrev.01/webrev/ >> >> Differences to the old version are >> just comment >> changes, and I also >> modified some comments in the SA as >> Staffan requested. >> >> >> agent/src/os/linux/libproc.h >> >> Modified comments still refer to "both >> thread >> libraries" but now the >> two libraries have not been mentioned, so >> there is no >> context to >> know what the two libraries are. >> >> >> I reverted my comment change to the original >> version. I >> think I do not >> know enough about the SA internals to make the >> comment clear and >> concise. Someone with more SA knowledge may be >> better suited >> to change >> that comment. >> >> >> Ok. I think you were pretty close anyway, just need >> to get rid >> of the "both thread libraries" references. >> >> >> >> More commentary inline below (with >> trimming)... >> >> >> See remarks inline: >> >> os_linux.cpp: >> >> The whole MAP_GROWSDOWN >> discussion and code >> also seems to be no >> longer relevant. >> >> >> I spent a lot of time digging around >> in the history >> of this >> thing. I am >> unsure whether that stack expansion >> coding can be >> removed. There are >> some rare case where they may still be >> needed: >> >> That whole coding revolves around the >> question >> whether thread stacks >> need to be expanded manually. >> >> Nowadays, normal threads allocated >> with a modern >> pthread library >> (NPTL) >> just allocate the whole stack with >> mmap(without >> MAP_NORESERVE), so the >> memory is committed right away. See >> glibc sources, >> nptl/allocate_stack.c. >> >> In former times (LinuxThreads) thread >> stacks were >> allocated using >> mmap(MAP_GROWSDOWN), which needed >> cooperation from >> the linux kernel: >> kernel caught faults caused by >> expanding the stack >> and transparently >> mapped the next page. It needed to >> distinguish real >> page faults from >> stack expansion page faults, and seems >> the logic >> did not always >> work, so >> manual expansion was needed - see >> os_linux.cpp, >> "os::Linux::manually_expand_stack". >> >> I think there may still be cases where >> we run on >> threads whose >> stacks >> are allocated with >> mmap(MAP_GROWSDOWN), even though >> LinuxThreads >> is gone: >> >> - with primordial threads (not sure, >> did not test). >> We do not run on >> primordial thread but someone may >> write a launcher >> and start a >> VM from >> the primordial thread or attach the >> primordial >> thread to the VM. >> >> >> This is already a very grey area in the >> VM. See: >> >> https://bugs.openjdk.java.net/browse/JDK-6516512 >> >> "HotSpot:thread terminology should be >> clearer or >> cleaned up." >> >> So until that is investigated and cleaned >> up this code >> can't really >> be touched. >> >> >> Interesting and well written bug report. >> Unfortunately, the >> issue seems >> to be in deep sleep. >> >> >> Sadly often true :( >> >> At SAP, we explicitly forbid all our internal >> users to >> invoke the VM on >> the primordial thread, and have done so since a >> long time. >> We tell all >> our users to spawn off an own pthread for VM >> creation. I >> think the AIX >> port will not even come up, we just assert. >> >> But this is more of a political question. If we >> pull support >> for running >> on the primordial thread in the OpenJDK, there >> may be >> applications which >> break. On the other hand, does this scenario - >> running on >> the primordial >> thread - get tested? Would we even notice if it >> were not to >> work anymore? >> >> >> There may be some JNI tests that use the primordial >> thread but I >> can't say for sure. >> >> - someone may write its own thread >> implementation >> using clone and >> mmap(MAP_GROWSDOWN) allocated stacks. >> >> These cases are probably extremely >> rare, and I >> would have no qualms >> removing support for them, but I do >> not want to >> decide that. >> >> >> Fair enough. As I said I think this >> expands into a >> cleanup up of the >> whole "initial thread" business anyway. >> >> Sidenote: These cases are inherently >> unsafe because >> mmap(MAP_GROWSDOWN) >> is too. Ulrich Drepper tried without >> success to >> remove support >> for these >> flags from the linux kernel: >> https://lwn.net/Articles/294001/ >> >> I added some comment to os_linux.cpp >> to explain >> this a bit better. >> >> >> The two comments don't rely flow together >> due to the >> "Force Linux >> kernel to expand current thread stack." >> lead-in of the >> second >> comment (which isn't actually a >> grammatically correct >> sentence). But >> I can't really think of anything to do >> that doesn't >> start making >> numerous changes to what is already a >> confusing and >> disjointed >> comment block. >> >> >> I tried to improve the comment a bit, to >> clearly distinguish >> it from the >> older comment and to provide enough information >> for whenever >> we decide >> to clean up this expand-thread-stack coding. >> >> >> Revised comment is much clearer - thanks! >> >> David >> ----- >> >> >> Kind Regards, Thomas >> >> >> >> >> The gcc 2.x workarounds can also >> be removed I >> think. >> >> I wonder if we can also eradicate >> WorkAroundNPTLTimedWaitHang :) >> >> >> I do not dare to do that - I do not >> know enough >> about this issue. >> >> >> Separate RFE. I doubt we care about the >> old systems >> that had this >> problem. >> >> >> Aside: The createThread_lock (now >> unused) >> seems to have >> been copied >> into src/os/aix/vm/os_aix.hpp as >> part of the >> AIX port and >> should be >> removed at some point. >> >> >> Yes I know :-) It is not the only >> Linux-specific >> code which >> crept into >> our AIX port. We actually have a bug >> open to deal >> with that: >> https://bugs.openjdk.java.net/browse/JDK-8079125 >> >> >> Good to know :) >> >> Thanks, >> David >> ----- >> >> >> --- >> >> src/os/linux/vm/os_linux.hpp >> >> Copyright needs updating. >> >> >> done >> >> --- >> >> >> src/os_cpu/linux_x86/vm/os_linux_x86.cpp >> >> Copyright needs updating. >> >> done >> >> >> os::Linux::supports_variable_stack_size() is >> now dead >> code (value >> is true for all arch's AFAICS) so >> can be >> removed from all >> >> src/os_cpu/linux_XXX/os_linux_XXX.cpp. >> >> I think >> supports_variable_stack_size() is >> also always true >> on other >> platforms (AIX, BSD) and so could >> be cleaned >> up in that >> code too >> (separate clean-up CR okay for >> that). >> >> >> I agree, lets do this in a different >> RFR because >> this would touch >> non-linux sources and I want to keep >> this linux >> specific. I opened >> https://bugs.openjdk.java.net/browse/JDK-8080298 for this. >> >> >> Thanks for filing. >> >> >> >> --- >> >> >> src/os_cpu/linux_x86/vm/threadLS_linux_x86.cpp >> >> Copyright needs updating. >> >> done >> >> --- >> >> I'm happy to sponsor this for you. >> >> Thanks, >> David >> ----- >> >> >> >> This change removes (I hope >> all) remnants >> of code >> dealing with >> LinuxThreads >> from the hotspot. >> >> Discussion of the changes: >> >> 1) on LinuxThreads, each >> thread had an own >> pid, so getpid() >> would return a >> unique pid for every thread >> it was invoked >> in. On NPTL, >> this is >> not an >> issue anymore; getpid() works >> as expected >> returning a >> global pid. >> For LinuxThreads, there was a >> workaround >> where at VM >> startup the >> pid was >> captured (on the thread >> invoking >> CreateJavaVM) and this >> pid was >> stored in >> static variable _initial_pid >> and returned in >> os::current_process_id(). >> Later another workaround was >> added because >> CreateJavaVM >> was not >> invoked on >> the primordial thread >> anymore, so the pid >> was handed in >> via a >> define (see >> >> Arguments::sun_java_launcher_pid()). >> >> Both workaround were >> removed and >> os::current_process_id() was >> changed to >> just return getpid(). >> >> >> We should remove the code on the >> JDK side as >> well - >> possibly as a >> follow up clean up (but via the >> same forest as >> this will be >> pushed): >> >> >> ./java.base/unix/native/libjli/java_md_solinux.c >> >> void >> SetJavaLauncherPlatformProps() { >> /* Linux only */ >> #ifdef __linux__ >> const char *substr = >> "-Dsun.java.launcher.pid="; >> char *pid_prop_str = (char >> *)JLI_MemAlloc(JLI_StrLen(substr) + >> MAX_PID_STR_SZ + 1); >> sprintf(pid_prop_str, >> "%s%d", substr, >> getpid()); >> AddOption(pid_prop_str, >> NULL); >> #endif /* __linux__ */ >> >> } >> >> >> Unfortunately, sun.launcher.pid gets >> used in the >> wild, e.g.: >> >> >> http://stackoverflow.com/questions/35842/how-can-a-java-program-get-its-own-process-id >> >> >> Kind Regards, Thomas >> >> >> >> >> 2) os::Linux::gettid(): Linux >> uses the >> kernel thread id for >> OSThread thread >> id - I did not change that. >> But by now the >> system call >> gettid >> should be >> available in every Linux >> kernel, so I >> removed the >> fallback handling. >> >> 3) A number of changes dealt >> with the way >> LinuxThreads >> allocated >> thread >> stacks (with mmap and the >> MAP_GROWSDOWN >> flag). On >> LinuxThreads, >> it was not >> possible to change the size >> of thread >> stacks (to start >> a new >> thread with a >> different stack size). NPTL >> can do this >> and all the >> places where >> we dealt >> with fixed stacks I changed. >> >> 4) On LinuxThreads, there is >> the problem >> that the >> thread stacks >> - which >> grow down and are allocated >> with MAP_FIXED >> - may at >> some point >> trash the >> java heap. To prevent this, >> every >> allocation done with >> os::reserve_memory() >> and friends recorded a >> "_highest_vm_reserved_address". >> There was >> a function >> called "_thread_safety_check" >> which >> prevented start of new >> threads if >> thread stacks came >> dangerously close to >> the highest >> reserved >> address + a >> gap; latter gap could be set >> via parameter >> ThreadSafetyMargin. >> >> All this coding was removed. >> Note that >> this coding >> probably was >> already >> broken since a long time, >> because there >> are many >> allocations >> which were not >> tracked. >> >> 5) Recognition of glibc >> version and >> pthread library >> version were >> very >> elaborate to deal with >> recognition of >> LinuxThreads >> implementation. Those >> were dumbed down and now just >> assert in >> the highly >> unlikely case >> that we >> encounter a LinuxThreads >> implementation. >> >> The rest of the stuff is more >> straight-forward. >> >> --- >> >> I built the changes on Linux >> x64, x86 and >> ppc64 and ran >> jtreg tests >> (hotspot/test) on these >> platforms too. I >> did not see >> any issues, >> but I'd >> like to get a couple of >> reviews for this. >> >> Kind Regards, >> Thomas >> >> >> >> >> >> From vladimir.kozlov at oracle.com Tue Jun 23 02:11:47 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 22 Jun 2015 19:11:47 -0700 Subject: RFR(XS): 8129423: Fix unlink() of LogCompilation tmp files lost in merge of 8007993 and 8060074. In-Reply-To: References: <4295855A5C1DE049A61835A1887419CC2CFFC4B3@DEWDFEMB12A.global.corp.sap> Message-ID: <5588C063.7080404@oracle.com> +1. I submitted JPRT job to push it. Thanks, Vladimir On 6/22/15 7:21 AM, Volker Simonis wrote: > Hi Goetz, > > thanks for finding this bug. I agree with your analysis and think your > fix is good. > > Regards, > Volker > > > On Mon, Jun 22, 2015 at 2:38 PM, Lindenmaier, Goetz > wrote: >> Hi, >> >> I detected a small flaw introduced by a merge. This webrev fixes it: >> http://cr.openjdk.java.net/~goetz/webrevs/8129423-LogComp/webrev-01/ >> Please review this fix. I please need a sponsor. >> >> With LogCompilation each compiler thread writes information to its own temp log file. During shutdown >> these files are concatenated into a single log file with the specified name. The temp files should be >> deleted, but we found files of jtreg test TestUnstableIfTrap.java left over in the /tmp directory. Also, a simple >> run with LogCompilation leaves these files in the /tmp directory. >> >> 8007993 fixed a problem with writing these log files and moved the unlink() of the temp >> files. This unlink() got lost in the merge with 8060074. >> >> Merge: http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/674657ff61c6 >> 8060074: http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/a0dd995271c4 >> 8007993: http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/c13eb14ebf5c >> >> Best regards, >> Goetz. >> From david.holmes at oracle.com Tue Jun 23 04:53:21 2015 From: david.holmes at oracle.com (David Holmes) Date: Tue, 23 Jun 2015 14:53:21 +1000 Subject: CFW: New hotspot Group Member: Goetz Lindenmaier In-Reply-To: References: Message-ID: <5588E641.9020902@oracle.com> Vote: yes David On 23/06/2015 12:53 AM, Volker Simonis wrote: > I hereby nominate Goetz Lindenmaier to Membership in the hotspot Group. > > Goetz (actually G?tz for those of you who can read umlauts :) is a > long standing member of the JVM team at SAP, one of the architects of > our Itanium and PowerPC ports and a real C2 maven. He's the main > contributor of the C2 PowerPC port but has also contributed changes in > many other parts of the VM including memory ordering changes, code > cleanups, simplifications and bug fixes. He's a jdk8u committer, > jdk9 reviewer and has contributed/reviewed more than 120 changes: > > http://hg.openjdk.java.net/jdk9/hs/hotspot/search/?rev=goetz&revcount=125 > > Votes are due by July 6, 18:00 CET. > > Only current Members of the hotspot Group [1] are eligible to vote on > this nomination. Votes must be cast in the open by replying to this > mailing list > > For Lazy Consensus voting instructions, see [2]. > > Kind Regards, > Volker Simonis > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/groups/#member-vote > From david.holmes at oracle.com Tue Jun 23 05:43:52 2015 From: david.holmes at oracle.com (David Holmes) Date: Tue, 23 Jun 2015 15:43:52 +1000 Subject: RFR (XS): 8129518: Remove ParOldGC tests from the jprt hotspot testset In-Reply-To: <55889075.8030607@oracle.com> References: <55889075.8030607@oracle.com> Message-ID: <5588F218.8080801@oracle.com> Hi Mikael, On 23/06/2015 8:47 AM, Mikael Vidstedt wrote: > > Please review the following small change which removes all the ParOldGC > test targets from the jprt hotspot testset. The ParOldGC tests are run > with the -XX:+UseParallelOldGC flag, but that has for some time already > been the default when using the Parallel GC, and there are already > corresponding tests which already test that configuration - namely the > ParallelGC ones. This change simply removes the redundant test targets. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8129518 > Webrev: > http://cr.openjdk.java.net/~mikael/webrevs/8129518/webrev.00/webrev/ I was a bit confused by this change but eventually figured it out: turning on either of those flags also turns on the other and hence the result is the same (as long as we don't explicitly turn off UseParallelOldGC). That kind of begs the question as to what testing coverage we have for -XX:+UseParallelGC -XX:-UseParallelOldGC ? Thanks, David > Cheers, > Mikael > From goetz.lindenmaier at sap.com Tue Jun 23 06:31:37 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 23 Jun 2015 06:31:37 +0000 Subject: RFR(XS): 8129423: Fix unlink() of LogCompilation tmp files lost in merge of 8007993 and 8060074. In-Reply-To: <5588C063.7080404@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CFFC4B3@DEWDFEMB12A.global.corp.sap> <5588C063.7080404@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2CFFC74E@DEWDFEMB12A.global.corp.sap> Hi Vladimir, thanks for reviewing and sponsoring this! Best regards, Goetz. -----Original Message----- From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] Sent: Dienstag, 23. Juni 2015 04:12 To: Volker Simonis; Lindenmaier, Goetz Cc: HotSpot Developers Subject: Re: RFR(XS): 8129423: Fix unlink() of LogCompilation tmp files lost in merge of 8007993 and 8060074. +1. I submitted JPRT job to push it. Thanks, Vladimir On 6/22/15 7:21 AM, Volker Simonis wrote: > Hi Goetz, > > thanks for finding this bug. I agree with your analysis and think your > fix is good. > > Regards, > Volker > > > On Mon, Jun 22, 2015 at 2:38 PM, Lindenmaier, Goetz > wrote: >> Hi, >> >> I detected a small flaw introduced by a merge. This webrev fixes it: >> http://cr.openjdk.java.net/~goetz/webrevs/8129423-LogComp/webrev-01/ >> Please review this fix. I please need a sponsor. >> >> With LogCompilation each compiler thread writes information to its own temp log file. During shutdown >> these files are concatenated into a single log file with the specified name. The temp files should be >> deleted, but we found files of jtreg test TestUnstableIfTrap.java left over in the /tmp directory. Also, a simple >> run with LogCompilation leaves these files in the /tmp directory. >> >> 8007993 fixed a problem with writing these log files and moved the unlink() of the temp >> files. This unlink() got lost in the merge with 8060074. >> >> Merge: http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/674657ff61c6 >> 8060074: http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/a0dd995271c4 >> 8007993: http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/c13eb14ebf5c >> >> Best regards, >> Goetz. >> From goetz.lindenmaier at sap.com Tue Jun 23 06:34:02 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 23 Jun 2015 06:34:02 +0000 Subject: RFR(XS): 8129423: Fix unlink() of LogCompilation tmp files lost in merge of 8007993 and 8060074. In-Reply-To: References: <4295855A5C1DE049A61835A1887419CC2CFFC4B3@DEWDFEMB12A.global.corp.sap> Message-ID: <4295855A5C1DE049A61835A1887419CC2CFFC799@DEWDFEMB12A.global.corp.sap> Thanks Volker! Best regards, Goetz -----Original Message----- From: Volker Simonis [mailto:volker.simonis at gmail.com] Sent: Montag, 22. Juni 2015 16:21 To: Lindenmaier, Goetz Cc: HotSpot Developers Subject: Re: RFR(XS): 8129423: Fix unlink() of LogCompilation tmp files lost in merge of 8007993 and 8060074. Hi Goetz, thanks for finding this bug. I agree with your analysis and think your fix is good. Regards, Volker On Mon, Jun 22, 2015 at 2:38 PM, Lindenmaier, Goetz wrote: > Hi, > > I detected a small flaw introduced by a merge. This webrev fixes it: > http://cr.openjdk.java.net/~goetz/webrevs/8129423-LogComp/webrev-01/ > Please review this fix. I please need a sponsor. > > With LogCompilation each compiler thread writes information to its own temp log file. During shutdown > these files are concatenated into a single log file with the specified name. The temp files should be > deleted, but we found files of jtreg test TestUnstableIfTrap.java left over in the /tmp directory. Also, a simple > run with LogCompilation leaves these files in the /tmp directory. > > 8007993 fixed a problem with writing these log files and moved the unlink() of the temp > files. This unlink() got lost in the merge with 8060074. > > Merge: http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/674657ff61c6 > 8060074: http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/a0dd995271c4 > 8007993: http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/c13eb14ebf5c > > Best regards, > Goetz. > From bengt.rutisson at oracle.com Tue Jun 23 06:37:52 2015 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Tue, 23 Jun 2015 08:37:52 +0200 Subject: CFW: New hotspot Group Member: Goetz Lindenmaier In-Reply-To: References: Message-ID: <1D19D218-F344-4F58-B8C5-04549BF6EA50@oracle.com> Vote: yes Bengt > 22 jun 2015 kl. 16:53 skrev Volker Simonis : > > I hereby nominate Goetz Lindenmaier to Membership in the hotspot Group. > > Goetz (actually G?tz for those of you who can read umlauts :) is a > long standing member of the JVM team at SAP, one of the architects of > our Itanium and PowerPC ports and a real C2 maven. He's the main > contributor of the C2 PowerPC port but has also contributed changes in > many other parts of the VM including memory ordering changes, code > cleanups, simplifications and bug fixes. He's a jdk8u committer, > jdk9 reviewer and has contributed/reviewed more than 120 changes: > > http://hg.openjdk.java.net/jdk9/hs/hotspot/search/?rev=goetz&revcount=125 > > Votes are due by July 6, 18:00 CET. > > Only current Members of the hotspot Group [1] are eligible to vote on > this nomination. Votes must be cast in the open by replying to this > mailing list > > For Lazy Consensus voting instructions, see [2]. > > Kind Regards, > Volker Simonis > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/groups/#member-vote From erik.helin at oracle.com Tue Jun 23 07:36:33 2015 From: erik.helin at oracle.com (Erik Helin) Date: Tue, 23 Jun 2015 09:36:33 +0200 Subject: CFW: New hotspot Group Member: Goetz Lindenmaier In-Reply-To: References: Message-ID: <20150623073633.GD3266@ehelin.jrpg.bea.com> Vote: yes Erik On 2015-06-22, Volker Simonis wrote: > I hereby nominate Goetz Lindenmaier to Membership in the hotspot Group. > > Goetz (actually G?tz for those of you who can read umlauts :) is a > long standing member of the JVM team at SAP, one of the architects of > our Itanium and PowerPC ports and a real C2 maven. He's the main > contributor of the C2 PowerPC port but has also contributed changes in > many other parts of the VM including memory ordering changes, code > cleanups, simplifications and bug fixes. He's a jdk8u committer, > jdk9 reviewer and has contributed/reviewed more than 120 changes: > > http://hg.openjdk.java.net/jdk9/hs/hotspot/search/?rev=goetz&revcount=125 > > Votes are due by July 6, 18:00 CET. > > Only current Members of the hotspot Group [1] are eligible to vote on > this nomination. Votes must be cast in the open by replying to this > mailing list > > For Lazy Consensus voting instructions, see [2]. > > Kind Regards, > Volker Simonis > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/groups/#member-vote From stefan.karlsson at oracle.com Tue Jun 23 07:47:40 2015 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Tue, 23 Jun 2015 09:47:40 +0200 Subject: CFW: New hotspot Group Member: Goetz Lindenmaier In-Reply-To: References: Message-ID: <55890F1C.9060600@oracle.com> Vote: yes StefanK On 2015-06-22 16:53, Volker Simonis wrote: > I hereby nominate Goetz Lindenmaier to Membership in the hotspot Group. > > Goetz (actually G?tz for those of you who can read umlauts :) is a > long standing member of the JVM team at SAP, one of the architects of > our Itanium and PowerPC ports and a real C2 maven. He's the main > contributor of the C2 PowerPC port but has also contributed changes in > many other parts of the VM including memory ordering changes, code > cleanups, simplifications and bug fixes. He's a jdk8u committer, > jdk9 reviewer and has contributed/reviewed more than 120 changes: > > http://hg.openjdk.java.net/jdk9/hs/hotspot/search/?rev=goetz&revcount=125 > > Votes are due by July 6, 18:00 CET. > > Only current Members of the hotspot Group [1] are eligible to vote on > this nomination. Votes must be cast in the open by replying to this > mailing list > > For Lazy Consensus voting instructions, see [2]. > > Kind Regards, > Volker Simonis > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/groups/#member-vote From thomas.schatzl at oracle.com Tue Jun 23 07:56:33 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 23 Jun 2015 09:56:33 +0200 Subject: CFW: New hotspot Group Member: Goetz Lindenmaier In-Reply-To: <55890F1C.9060600@oracle.com> References: <55890F1C.9060600@oracle.com> Message-ID: <1435046193.2673.1.camel@oracle.com> Vote: yes From stefan.johansson at oracle.com Tue Jun 23 08:07:49 2015 From: stefan.johansson at oracle.com (Stefan Johansson) Date: Tue, 23 Jun 2015 10:07:49 +0200 Subject: RFR: 8081607: Change default GC for server configurations to G1 Message-ID: <558913D5.40301@oracle.com> Hi, Please review this change to make G1 the default GC: https://bugs.openjdk.java.net/browse/JDK-8081607 JEP: http://openjdk.java.net/jeps/248 Webrev: http://cr.openjdk.java.net/~sjohanss/8081607/hotspot.00/ Summary: Changing the the default GC for server configurations to G1 (but not on embedded). Also updated test to reflect the change. Testing: * JPRT * Ad-hoc RBT runs, some issues found and fixed. Thanks, Stefan From per.liden at oracle.com Tue Jun 23 08:23:37 2015 From: per.liden at oracle.com (Per Liden) Date: Tue, 23 Jun 2015 10:23:37 +0200 Subject: RFR: 8081607: Change default GC for server configurations to G1 In-Reply-To: <558913D5.40301@oracle.com> References: <558913D5.40301@oracle.com> Message-ID: <55891789.1070804@oracle.com> Looks good, but could we remove the negation to make it easier to read, i.e. turn: #if !defined(JAVASE_EMBEDDED) // Select G1 for non-embedded builds only. FLAG_SET_ERGO(bool, UseG1GC, true); #else FLAG_SET_ERGO(bool, UseParallelGC, true); #endif into: #if defined(JAVASE_EMBEDDED) FLAG_SET_ERGO(bool, UseParallelGC, true); #else FLAG_SET_ERGO(bool, UseG1GC, true); #endif (No need to send out a new webrev for that) cheers, /Per On 2015-06-23 10:07, Stefan Johansson wrote: > Hi, > > Please review this change to make G1 the default GC: > https://bugs.openjdk.java.net/browse/JDK-8081607 > > JEP: > http://openjdk.java.net/jeps/248 > > Webrev: > http://cr.openjdk.java.net/~sjohanss/8081607/hotspot.00/ > > Summary: > Changing the the default GC for server configurations to G1 (but not on > embedded). Also updated test to reflect the change. > > Testing: > * JPRT > * Ad-hoc RBT runs, some issues found and fixed. > > Thanks, > Stefan From stefan.johansson at oracle.com Tue Jun 23 08:24:19 2015 From: stefan.johansson at oracle.com (Stefan Johansson) Date: Tue, 23 Jun 2015 10:24:19 +0200 Subject: RFR: 8081607: Change default GC for server configurations to G1 In-Reply-To: <55891789.1070804@oracle.com> References: <558913D5.40301@oracle.com> <55891789.1070804@oracle.com> Message-ID: <558917B3.8040402@oracle.com> Thanks Per, Will change this before pushing. Stefan On 2015-06-23 10:23, Per Liden wrote: > Looks good, but could we remove the negation to make it easier to > read, i.e. turn: > > #if !defined(JAVASE_EMBEDDED) > // Select G1 for non-embedded builds only. > FLAG_SET_ERGO(bool, UseG1GC, true); > #else > FLAG_SET_ERGO(bool, UseParallelGC, true); > #endif > > into: > > #if defined(JAVASE_EMBEDDED) > FLAG_SET_ERGO(bool, UseParallelGC, true); > #else > FLAG_SET_ERGO(bool, UseG1GC, true); > #endif > > (No need to send out a new webrev for that) > > cheers, > /Per > > On 2015-06-23 10:07, Stefan Johansson wrote: >> Hi, >> >> Please review this change to make G1 the default GC: >> https://bugs.openjdk.java.net/browse/JDK-8081607 >> >> JEP: >> http://openjdk.java.net/jeps/248 >> >> Webrev: >> http://cr.openjdk.java.net/~sjohanss/8081607/hotspot.00/ >> >> Summary: >> Changing the the default GC for server configurations to G1 (but not on >> embedded). Also updated test to reflect the change. >> >> Testing: >> * JPRT >> * Ad-hoc RBT runs, some issues found and fixed. >> >> Thanks, >> Stefan From edward.nevill at linaro.org Tue Jun 23 08:55:48 2015 From: edward.nevill at linaro.org (Edward Nevill) Date: Tue, 23 Jun 2015 09:55:48 +0100 Subject: RFR: 8081294: aarch64: fails to build on ubuntu wily Message-ID: <1435049748.20837.6.camel@mylittlepony.linaroharston> Hi, One of our partners has reported that jdk9 fails to build for aarch64 on ubuntu 'wily' The failing buildlog is here https://launchpad.net/ubuntu/+source/openjdk-9/9~b64-1ubuntu1/+build/7441971 The following webrev fixes this http://cr.openjdk.java.net/~enevill/8081294/webrev/ I have verified that this fixes the problem by cross compiling against a sysroot. Our partner has also verified that this patch fixes the build. As this is a change to shared code I will need someone to sponsor this and push it through JPRT. Thanks for your help, Ed From thomas.schatzl at oracle.com Tue Jun 23 09:04:26 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 23 Jun 2015 11:04:26 +0200 Subject: RFR: 8081607: Change default GC for server configurations to G1 In-Reply-To: <558913D5.40301@oracle.com> References: <558913D5.40301@oracle.com> Message-ID: <1435050266.2673.7.camel@oracle.com> Hi, On Tue, 2015-06-23 at 10:07 +0200, Stefan Johansson wrote: > Hi, > > Please review this change to make G1 the default GC: > https://bugs.openjdk.java.net/browse/JDK-8081607 > > JEP: > http://openjdk.java.net/jeps/248 > > Webrev: > http://cr.openjdk.java.net/~sjohanss/8081607/hotspot.00/ > > Summary: > Changing the the default GC for server configurations to G1 (but not on > embedded). Also updated test to reflect the change. > Please use Platform.isServer()/isEmbedded() to find out the type of VM. I also recommend to remove the negation in the ifdef. Thanks, Thomas From stefan.johansson at oracle.com Tue Jun 23 09:26:08 2015 From: stefan.johansson at oracle.com (Stefan Johansson) Date: Tue, 23 Jun 2015 11:26:08 +0200 Subject: RFR: 8081607: Change default GC for server configurations to G1 In-Reply-To: <1435050266.2673.7.camel@oracle.com> References: <558913D5.40301@oracle.com> <1435050266.2673.7.camel@oracle.com> Message-ID: <55892630.4020307@oracle.com> Thanks for the review Thomas, New webrev: http://cr.openjdk.java.net/~sjohanss/8081607/hotspot.01/ Stefan On 2015-06-23 11:04, Thomas Schatzl wrote: > Hi, > > On Tue, 2015-06-23 at 10:07 +0200, Stefan Johansson wrote: >> Hi, >> >> Please review this change to make G1 the default GC: >> https://bugs.openjdk.java.net/browse/JDK-8081607 >> >> JEP: >> http://openjdk.java.net/jeps/248 >> >> Webrev: >> http://cr.openjdk.java.net/~sjohanss/8081607/hotspot.00/ >> >> Summary: >> Changing the the default GC for server configurations to G1 (but not on >> embedded). Also updated test to reflect the change. >> > Please use Platform.isServer()/isEmbedded() to find out the type of VM. > I also recommend to remove the negation in the ifdef. > > Thanks, > Thomas > > From aph at redhat.com Tue Jun 23 10:10:20 2015 From: aph at redhat.com (Andrew Haley) Date: Tue, 23 Jun 2015 11:10:20 +0100 Subject: [aarch64-port-dev ] RFR: 8129426: aarch64: add support for PopCount in C2 In-Reply-To: <5588345A.4060708@redhat.com> References: <1434979401.21282.31.camel@mint> <558815DA.8020500@redhat.com> <1434985182.21282.34.camel@mint> <558823FD.5080800@redhat.com> <558829D2.4000503@redhat.com> <55882C94.7030505@redhat.com> <55882ECC.8030602@redhat.com> <5588313C.1070409@redhat.com> <5588345A.4060708@redhat.com> Message-ID: <5589308C.6000309@redhat.com> On 22/06/15 17:14, Andrew Dinn wrote: > On 22/06/15 17:01, Andrew Haley wrote: >> On 06/22/2015 04:50 PM, Andrew Dinn wrote: >>> If that assumption fails anywhere then it will only fail because we used >>> a foo insn where we really needed a foow. I think we would be better to >>> let any such errors fail as quickly as possible, find the error and fix >>> the offending code to use foow. >> >> And how would we even notice it, yet alone find the error? > > I agree it will not necessarily be easy to spot. Bit we know exactly > where to look (see below). > >>> Your mileage may vary. >> >> Hmm. So far we've been very conservative, making sure that we always >> use the correct mode for inputs and the correct mode for outputs. If >> we're going to start making assumptions that top bits of int ops are >> always zero we could always elide l2i to a no-op. So far we have >> resisted that, and with good reason IMO. > > No, that last statement is not at all correct. l2i is explicitly > inserted into the ideal graph when the compiler knows that a value > generated as long is being consumed as an int and so needs to be > truncated. I'm sure that's true, but it's not really relevant to what I said. > We also need to be sure that anything spilled as a 32 bit int is > restored as a 32 bit int with the top bits correspondingly zeroed. That too. But C2 has to interact with C1, the interpreter, and all the stubs, and all the intrinsics. >> I wrote the deoptimization code and was pretty careful to do the right >> thing, but also very reassured that it probably didn't matter. I >> don't think we can guarantee that nowhere do we have a sign extension >> where there should be a zero extension. > > Well, you might not want to take this risk and instead add an explicit > zero of the upper half. But I think we need to be clear what risk we are > taking. It's this: if we don't explicitly zero the upper half we'll have to audit all the code which might present a sign-extended value (instead of a zero-extended one) in a register that's supposed to contain a jint. Andrew. From edward.nevill at linaro.org Tue Jun 23 10:12:12 2015 From: edward.nevill at linaro.org (Edward Nevill) Date: Tue, 23 Jun 2015 11:12:12 +0100 Subject: RFR: 8129551: some regressions introduced by addition of vectorisation code Message-ID: <1435054332.5083.15.camel@mylittlepony.linaroharston> Hi, The following webrev http://cr.openjdk.java.net/~enevill/8129551/webrev fixes a number of regressions introduced in the addition of vectorisation for aarch64 as follows:- java/math/BigInteger/BigIntegerTest.java fails with an assertion failure when run with fastdebug or slowdebug builds # Internal Error (/home/alexander/build-open-jdk/dev/jdk9/baseline/dev/hotspot/src/cpu/aarch64/vm/assembler_aarch64.hpp:2078), pid=8124, tid=0x0000007ec61eb1f0 # assert(op == 0 && 0 == 0) failed: must be MOVI and also in test java/math/BigInteger/ModPow.java java.math.BigInteger::add gets miscompiled. There is a ldr q16, [x17,x10,lsl #4] which should be a ldr q16, [x17,x10] I have also moved void MacroAssembler::mov(FloatRegister Vd, SIMD_Arrangement T, u_int32_t imm32) to macroAssembler_aarch64.cpp from macroAssembler_aarch64.hpp as it was getting much too large for a .hpp. I have tested the original and webrev version with JTreg (hotspot, langtools & jdk) with the following results:- Original:- hotspot: Test results: passed: 849; failed: 11; error: 6 langtools: Test results: passed: 3,240; error: 2 jdk: Test results: passed: 6,103; failed: 568; error: 26 Revised:- hotspot: Test results: passed: 849; failed: 11; error: 6 langtools: Test results: passed: 3,240; error: 2 jdk: Test results: passed: 6,108; failed: 567; error: 22 This changeset only affects aarch64 files. Please review and if OK I will push, Thanks, Ed. From aph at redhat.com Tue Jun 23 10:18:09 2015 From: aph at redhat.com (Andrew Haley) Date: Tue, 23 Jun 2015 11:18:09 +0100 Subject: RFR: 8129551: some regressions introduced by addition of vectorisation code In-Reply-To: <1435054332.5083.15.camel@mylittlepony.linaroharston> References: <1435054332.5083.15.camel@mylittlepony.linaroharston> Message-ID: <55893261.7030501@redhat.com> On 23/06/15 11:12, Edward Nevill wrote: > Hi, > > The following webrev > > http://cr.openjdk.java.net/~enevill/8129551/webrev > > fixes a number of regressions introduced in the addition of vectorisation for aarch64 as follows:- > > java/math/BigInteger/BigIntegerTest.java > > fails with an assertion failure when run with fastdebug or slowdebug builds > > # Internal Error (/home/alexander/build-open-jdk/dev/jdk9/baseline/dev/hotspot/src/cpu/aarch64/vm/assembler_aarch64.hpp:2078), pid=8124, tid=0x0000007ec61eb1f0 > # assert(op == 0 && 0 == 0) failed: must be MOVI > > and also in test > > java/math/BigInteger/ModPow.java > > java.math.BigInteger::add gets miscompiled. There is a > > ldr q16, [x17,x10,lsl #4] > > which should be a > > ldr q16, [x17,x10] > > I have also moved > > void MacroAssembler::mov(FloatRegister Vd, SIMD_Arrangement T, u_int32_t imm32) > > to macroAssembler_aarch64.cpp from macroAssembler_aarch64.hpp as it was getting much too large for a .hpp. > > I have tested the original and webrev version with JTreg (hotspot, langtools & jdk) with the following results:- > > Original:- > > hotspot: Test results: passed: 849; failed: 11; error: 6 > langtools: Test results: passed: 3,240; error: 2 > jdk: Test results: passed: 6,103; failed: 568; error: 26 > > Revised:- > > hotspot: Test results: passed: 849; failed: 11; error: 6 > langtools: Test results: passed: 3,240; error: 2 > jdk: Test results: passed: 6,108; failed: 567; error: 22 > > This changeset only affects aarch64 files. > > Please review and if OK I will push, Won't this fail to detect an overflow? 1418 if (T == T4H || T == T8H) { imm32 &= 0xffff; nimm32 &= 0xffff; } Otherwise this looks OK to me. Andrew. From per.liden at oracle.com Tue Jun 23 10:20:24 2015 From: per.liden at oracle.com (Per Liden) Date: Tue, 23 Jun 2015 12:20:24 +0200 Subject: RFR: 8081607: Change default GC for server configurations to G1 In-Reply-To: <55892630.4020307@oracle.com> References: <558913D5.40301@oracle.com> <1435050266.2673.7.camel@oracle.com> <55892630.4020307@oracle.com> Message-ID: <558932E8.6020402@oracle.com> On 2015-06-23 11:26, Stefan Johansson wrote: > Thanks for the review Thomas, > > New webrev: > http://cr.openjdk.java.net/~sjohanss/8081607/hotspot.01/ Looks good! /Per > > Stefan > > On 2015-06-23 11:04, Thomas Schatzl wrote: >> Hi, >> >> On Tue, 2015-06-23 at 10:07 +0200, Stefan Johansson wrote: >>> Hi, >>> >>> Please review this change to make G1 the default GC: >>> https://bugs.openjdk.java.net/browse/JDK-8081607 >>> >>> JEP: >>> http://openjdk.java.net/jeps/248 >>> >>> Webrev: >>> http://cr.openjdk.java.net/~sjohanss/8081607/hotspot.00/ >>> >>> Summary: >>> Changing the the default GC for server configurations to G1 (but not on >>> embedded). Also updated test to reflect the change. >>> >> Please use Platform.isServer()/isEmbedded() to find out the type of VM. >> I also recommend to remove the negation in the ifdef. >> >> Thanks, >> Thomas >> >> > From thomas.schatzl at oracle.com Tue Jun 23 10:22:53 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 23 Jun 2015 12:22:53 +0200 Subject: RFR: 8081607: Change default GC for server configurations to G1 In-Reply-To: <55892630.4020307@oracle.com> References: <558913D5.40301@oracle.com> <1435050266.2673.7.camel@oracle.com> <55892630.4020307@oracle.com> Message-ID: <1435054973.2673.12.camel@oracle.com> Hi, On Tue, 2015-06-23 at 11:26 +0200, Stefan Johansson wrote: > Thanks for the review Thomas, > > New webrev: > http://cr.openjdk.java.net/~sjohanss/8081607/hotspot.01/ > looks good. Thanks, Thomas From dmitry.dmitriev at oracle.com Tue Jun 23 10:35:43 2015 From: dmitry.dmitriev at oracle.com (Dmitry Dmitriev) Date: Tue, 23 Jun 2015 13:35:43 +0300 Subject: RFR (XS): 8078399: Deprecate -Xoss, -Xsqnopause, -Xoptimize and -Xboundthreads options in JDK 9 Message-ID: <5589367F.1040800@oracle.com> Hello, Please review this small fix which deprecate -Xoss, -Xsqnopause, -Xoptimize and -Xboundthreads options in JDK 9. Also, I need a sponsor for this fix, who can push it. Currently HotSpot silently ignore these 4 options. Here are description of these options: "-Xoss", "-Xsqnopause", "-Xoptimize" - EVM option leaved for compatibility. From Java 2 SDK for Solaris Developer's Guide: "Prior to version 1.3.0, the production releases of the Java 2 SDK for the Solaris Operating Environment shipped with a virtual-machine implementation known as the Exact VM (EVM). Beginning with version 1.3.0, the Exact VM is replaced by the Java HotSpot VM.". So, from Java 1.4 EVM is not used as VM for JDK on Solaris and these very old flags just silently ignored by HotSpot. "-Xboundthreads" - was used to bind user level threads to kernel threads on Solaris in case when new thread library is not available. But old T1 libthread has been removed from Solaris in release 10. JDK9 requires Solaris 10u9 or higher. So, this flag become useless. All these options are deprecated, i.e. following warning is printed when option is specified: "Java HotSpot(TM) 64-Bit Server VM warning: Option -Xoss was deprecated in version 9.0 and will likely be removed in a future release.". In next major release all these options can be removed. Webrev: http://cr.openjdk.java.net/~ddmitriev/8078399/webrev.00/ JBS: https://bugs.openjdk.java.net/browse/JDK-8078399 Tested: JPRT Thanks, Dmitry From adinn at redhat.com Tue Jun 23 10:32:50 2015 From: adinn at redhat.com (Andrew Dinn) Date: Tue, 23 Jun 2015 11:32:50 +0100 Subject: [aarch64-port-dev ] RFR: 8129426: aarch64: add support for PopCount in C2 In-Reply-To: <5589308C.6000309@redhat.com> References: <1434979401.21282.31.camel@mint> <558815DA.8020500@redhat.com> <1434985182.21282.34.camel@mint> <558823FD.5080800@redhat.com> <558829D2.4000503@redhat.com> <55882C94.7030505@redhat.com> <55882ECC.8030602@redhat.com> <5588313C.1070409@redhat.com> <5588345A.4060708@redhat.com> <5589308C.6000309@redhat.com> Message-ID: <558935D2.1020103@redhat.com> On 23/06/15 11:10, Andrew Haley wrote: > On 22/06/15 17:14, Andrew Dinn wrote: >> . . . >> Well, you might not want to take this risk and instead add an explicit >> zero of the upper half. But I think we need to be clear what risk we are >> taking. > > It's this: if we don't explicitly zero the upper half we'll have to > audit all the code which might present a sign-extended value (instead > of a zero-extended one) in a register that's supposed to contain a > jint. Ok, let's play safe. If Ed tweaks the patch to zero the upper word we can always revise that later if/when we decide we are feeling lucky. regards, Andrew Dinn ----------- From bengt.rutisson at oracle.com Tue Jun 23 10:43:56 2015 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Tue, 23 Jun 2015 12:43:56 +0200 Subject: RFR (XS): 8129518: Remove ParOldGC tests from the jprt hotspot testset In-Reply-To: <55889075.8030607@oracle.com> References: <55889075.8030607@oracle.com> Message-ID: <5589386C.4020908@oracle.com> Hi Mikael, On 2015-06-23 00:47, Mikael Vidstedt wrote: > > Please review the following small change which removes all the > ParOldGC test targets from the jprt hotspot testset. The ParOldGC > tests are run with the -XX:+UseParallelOldGC flag, but that has for > some time already been the default when using the Parallel GC, and > there are already corresponding tests which already test that > configuration - namely the ParallelGC ones. This change simply removes > the redundant test targets. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8129518 > Webrev: > http://cr.openjdk.java.net/~mikael/webrevs/8129518/webrev.00/webrev/ This looks good to me. Bengt > > Cheers, > Mikael > From bengt.rutisson at oracle.com Tue Jun 23 10:50:33 2015 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Tue, 23 Jun 2015 12:50:33 +0200 Subject: RFR (XS): 8129518: Remove ParOldGC tests from the jprt hotspot testset In-Reply-To: <5588F218.8080801@oracle.com> References: <55889075.8030607@oracle.com> <5588F218.8080801@oracle.com> Message-ID: <558939F9.3080605@oracle.com> Hi David, On 2015-06-23 07:43, David Holmes wrote: > Hi Mikael, > > On 23/06/2015 8:47 AM, Mikael Vidstedt wrote: >> >> Please review the following small change which removes all the ParOldGC >> test targets from the jprt hotspot testset. The ParOldGC tests are run >> with the -XX:+UseParallelOldGC flag, but that has for some time already >> been the default when using the Parallel GC, and there are already >> corresponding tests which already test that configuration - namely the >> ParallelGC ones. This change simply removes the redundant test targets. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8129518 >> Webrev: >> http://cr.openjdk.java.net/~mikael/webrevs/8129518/webrev.00/webrev/ > > I was a bit confused by this change but eventually figured it out: > turning on either of those flags also turns on the other and hence the > result is the same (as long as we don't explicitly turn off > UseParallelOldGC). Yes, ParallelOldGC was made default for ParallelGC back in 7u40. So, since then it has been working the way you describe. > > That kind of begs the question as to what testing coverage we have for > -XX:+UseParallelGC -XX:-UseParallelOldGC ? This combination (ParallelScavenge + SerialOld) is the last remaining supported GC combination that is a bit "odd". We deprecated the others in JDK 8 and removed them in JDK 9. We've always had very limited testing on the rarely used GC combinations. There are a couple of JTreg tests that are run as part of JPRT that do rudimentary testing. One of the nightly GC baselines also run this combination. Thanks, Bengt > > Thanks, > David > >> Cheers, >> Mikael >> From david.holmes at oracle.com Tue Jun 23 12:49:46 2015 From: david.holmes at oracle.com (David Holmes) Date: Tue, 23 Jun 2015 22:49:46 +1000 Subject: RFR (XS): 8078399: Deprecate -Xoss, -Xsqnopause, -Xoptimize and -Xboundthreads options in JDK 9 In-Reply-To: <5589367F.1040800@oracle.com> References: <5589367F.1040800@oracle.com> Message-ID: <558955EA.6020807@oracle.com> Hi Dmitry, On 23/06/2015 8:35 PM, Dmitry Dmitriev wrote: > Hello, > > Please review this small fix which deprecate -Xoss, -Xsqnopause, > -Xoptimize and -Xboundthreads options in JDK 9. Also, I need a sponsor > for this fix, who can push it. I can sponsor this for you. But first ... > Currently HotSpot silently ignore these 4 options. Here are description > of these options: > "-Xoss", "-Xsqnopause", "-Xoptimize" - EVM option leaved for > compatibility. From Java 2 SDK for Solaris Developer's Guide: "Prior to > version 1.3.0, the production releases of the Java 2 SDK for the Solaris > Operating Environment shipped with a virtual-machine implementation > known as the Exact VM (EVM). Beginning with version 1.3.0, the Exact VM > is replaced by the Java HotSpot VM.". So, from Java 1.4 EVM is not used > as VM for JDK on Solaris and these very old flags just silently ignored > by HotSpot. > "-Xboundthreads" - was used to bind user level threads to kernel threads > on Solaris in case when new thread library is not available. But old T1 > libthread has been removed from Solaris in release 10. JDK9 requires > Solaris 10u9 or higher. So, this flag become useless. > > All these options are deprecated, i.e. following warning is printed when > option is specified: "Java HotSpot(TM) 64-Bit Server VM warning: Option > -Xoss was deprecated in version 9.0 and will likely be removed in a > future release.". In next major release all these options can be removed. > > Webrev: http://cr.openjdk.java.net/~ddmitriev/8078399/webrev.00/ > > JBS: https://bugs.openjdk.java.net/browse/JDK-8078399 > Tested: JPRT Can you not add these options to the set of obsolete_flags ? (and delete the code that references them of course) Thanks, David > Thanks, > Dmitry From david.holmes at oracle.com Tue Jun 23 12:51:17 2015 From: david.holmes at oracle.com (David Holmes) Date: Tue, 23 Jun 2015 22:51:17 +1000 Subject: RFR (XS): 8129518: Remove ParOldGC tests from the jprt hotspot testset In-Reply-To: <558939F9.3080605@oracle.com> References: <55889075.8030607@oracle.com> <5588F218.8080801@oracle.com> <558939F9.3080605@oracle.com> Message-ID: <55895645.8070404@oracle.com> On 23/06/2015 8:50 PM, Bengt Rutisson wrote: > > Hi David, > > On 2015-06-23 07:43, David Holmes wrote: >> Hi Mikael, >> >> On 23/06/2015 8:47 AM, Mikael Vidstedt wrote: >>> >>> Please review the following small change which removes all the ParOldGC >>> test targets from the jprt hotspot testset. The ParOldGC tests are run >>> with the -XX:+UseParallelOldGC flag, but that has for some time already >>> been the default when using the Parallel GC, and there are already >>> corresponding tests which already test that configuration - namely the >>> ParallelGC ones. This change simply removes the redundant test targets. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8129518 >>> Webrev: >>> http://cr.openjdk.java.net/~mikael/webrevs/8129518/webrev.00/webrev/ >> >> I was a bit confused by this change but eventually figured it out: >> turning on either of those flags also turns on the other and hence the >> result is the same (as long as we don't explicitly turn off >> UseParallelOldGC). > > Yes, ParallelOldGC was made default for ParallelGC back in 7u40. So, > since then it has been working the way you describe. > >> >> That kind of begs the question as to what testing coverage we have for >> -XX:+UseParallelGC -XX:-UseParallelOldGC ? > > > This combination (ParallelScavenge + SerialOld) is the last remaining > supported GC combination that is a bit "odd". We deprecated the others > in JDK 8 and removed them in JDK 9. We've always had very limited > testing on the rarely used GC combinations. There are a couple of JTreg > tests that are run as part of JPRT that do rudimentary testing. One of > the nightly GC baselines also run this combination. Okay - thanks for the info. David > Thanks, > Bengt > >> >> Thanks, >> David >> >>> Cheers, >>> Mikael >>> > From dmitry.dmitriev at oracle.com Tue Jun 23 13:02:52 2015 From: dmitry.dmitriev at oracle.com (Dmitry Dmitriev) Date: Tue, 23 Jun 2015 16:02:52 +0300 Subject: RFR (XS): 8078399: Deprecate -Xoss, -Xsqnopause, -Xoptimize and -Xboundthreads options in JDK 9 In-Reply-To: <558955EA.6020807@oracle.com> References: <5589367F.1040800@oracle.com> <558955EA.6020807@oracle.com> Message-ID: <558958FC.4020704@oracle.com> Hello David, Please, see my comments inline. On 23.06.2015 15:49, David Holmes wrote: > Hi Dmitry, > > On 23/06/2015 8:35 PM, Dmitry Dmitriev wrote: >> Hello, >> >> Please review this small fix which deprecate -Xoss, -Xsqnopause, >> -Xoptimize and -Xboundthreads options in JDK 9. Also, I need a sponsor >> for this fix, who can push it. > > I can sponsor this for you. But first ... Thank you! > >> Currently HotSpot silently ignore these 4 options. Here are description >> of these options: >> "-Xoss", "-Xsqnopause", "-Xoptimize" - EVM option leaved for >> compatibility. From Java 2 SDK for Solaris Developer's Guide: "Prior to >> version 1.3.0, the production releases of the Java 2 SDK for the Solaris >> Operating Environment shipped with a virtual-machine implementation >> known as the Exact VM (EVM). Beginning with version 1.3.0, the Exact VM >> is replaced by the Java HotSpot VM.". So, from Java 1.4 EVM is not used >> as VM for JDK on Solaris and these very old flags just silently ignored >> by HotSpot. >> "-Xboundthreads" - was used to bind user level threads to kernel threads >> on Solaris in case when new thread library is not available. But old T1 >> libthread has been removed from Solaris in release 10. JDK9 requires >> Solaris 10u9 or higher. So, this flag become useless. >> >> All these options are deprecated, i.e. following warning is printed when >> option is specified: "Java HotSpot(TM) 64-Bit Server VM warning: Option >> -Xoss was deprecated in version 9.0 and will likely be removed in a >> future release.". In next major release all these options can be >> removed. >> >> Webrev: http://cr.openjdk.java.net/~ddmitriev/8078399/webrev.00/ >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8078399 >> Tested: JPRT > > Can you not add these options to the set of obsolete_flags ? (and > delete the code that references them of course) Unfortunately, I not understand what set of obsolete flags you mean. Do you mean os::obsolete_option method or obsolete_jvm_flags table? Since obsolete_jvm_flags is developed for "XX:" options I not see how it easily can be done. In case of os::obsolete_option methods then I will need to add these options to all implementations. Probably, I not understand you correctly. Thanks, Dmitry > > Thanks, > David > >> Thanks, >> Dmitry From adinn at redhat.com Tue Jun 23 13:14:45 2015 From: adinn at redhat.com (Andrew Dinn) Date: Tue, 23 Jun 2015 14:14:45 +0100 Subject: Fix for 8122937: [JEP 245] Validate JVM Command-Line Flag Arguments breaks AArch64 Message-ID: <55895BC5.7010607@redhat.com> I am trying to build the current hs-rt tree on AArch64 in order to test against Andrew Haley's UseCondCardMark patch (JDK-8079315). That tree now also includes the following fix for JDK-8122937: http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/5bbf25472731 The patch includes changes made to all the current cpus /except/ aarch64 which means that the aarch64 build now falls over with /home/adinn/openjdk/hs-rt/hotspot/src/share/vm/runtime/globals_extension.hpp:242:28: error: macro "ARCH_FLAGS" passed 7 arguments, but takes just 5 IGNORE_CONSTRAINT) I believe the only modification required is to add the extra 2 arguments range and constraint to macro ARCH_FLAGS (as per most of the other cpu-specific globals files). I am testing this now and will raise a JIRA and submit a webrev if that is indeed all that is needed. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in UK and Wales under Company Registration No. 3798903 Directors: Michael Cunningham (USA), Matt Parson (USA), Charlie Peters (USA), Michael O'Neill (Ireland) From edward.nevill at gmail.com Tue Jun 23 13:51:00 2015 From: edward.nevill at gmail.com (Edward Nevill) Date: Tue, 23 Jun 2015 14:51:00 +0100 Subject: [aarch64-port-dev ] RFR: 8129426: aarch64: add support for PopCount in C2 In-Reply-To: <558935D2.1020103@redhat.com> References: <1434979401.21282.31.camel@mint> <558815DA.8020500@redhat.com> <1434985182.21282.34.camel@mint> <558823FD.5080800@redhat.com> <558829D2.4000503@redhat.com> <55882C94.7030505@redhat.com> <55882ECC.8030602@redhat.com> <5588313C.1070409@redhat.com> <5588345A.4060708@redhat.com> <5589308C.6000309@redhat.com> <558935D2.1020103@redhat.com> Message-ID: <1435067460.5083.21.camel@mylittlepony.linaroharston> On Tue, 2015-06-23 at 11:32 +0100, Andrew Dinn wrote: > On 23/06/15 11:10, Andrew Haley wrote: > > On 22/06/15 17:14, Andrew Dinn wrote: > >> . . . > >> Well, you might not want to take this risk and instead add an explicit > >> zero of the upper half. But I think we need to be clear what risk we are > >> taking. > > > > It's this: if we don't explicitly zero the upper half we'll have to > > audit all the code which might present a sign-extended value (instead > > of a zero-extended one) in a register that's supposed to contain a > > jint. > > Ok, let's play safe. If Ed tweaks the patch to zero the upper word we > can always revise that later if/when we decide we are feeling lucky. > OK. New webrev at http://cr.openjdk.java.net/~enevill/8129426/webrev.02/ All the best, Ed. From adinn at redhat.com Tue Jun 23 14:41:22 2015 From: adinn at redhat.com (Andrew Dinn) Date: Tue, 23 Jun 2015 15:41:22 +0100 Subject: RFR: 8129584: Fix required for aarch64 after 8122937 Message-ID: <55897012.6040109@redhat.com> The following webrev against jdk9/hs-rt fixes AArch64 after it was broken by JDK-8122937: http://cr.openjdk.java.net/~adinn/8129584/webrev/ It is an AArch64-only patch. Could AArch64 reviewers please check it is ok? I'll also need someone to push it as I am not a committer. Thanks. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in UK and Wales under Company Registration No. 3798903 Directors: Michael Cunningham (USA), Matt Parson (USA), Charlie Peters (USA), Michael O'Neill (Ireland) From volker.simonis at gmail.com Tue Jun 23 15:22:10 2015 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 23 Jun 2015 17:22:10 +0200 Subject: RFR: 8129584: Fix required for aarch64 after 8122937 In-Reply-To: <55897012.6040109@redhat.com> References: <55897012.6040109@redhat.com> Message-ID: Hi Andrew, the change looks good! I can push it for you. Regards, Volker On Tue, Jun 23, 2015 at 4:41 PM, Andrew Dinn wrote: > The following webrev against jdk9/hs-rt fixes AArch64 after it was > broken by JDK-8122937: > > http://cr.openjdk.java.net/~adinn/8129584/webrev/ > > It is an AArch64-only patch. Could AArch64 reviewers please check it is > ok? I'll also need someone to push it as I am not a committer. Thanks. > > regards, > > > Andrew Dinn > ----------- > Senior Principal Software Engineer > Red Hat UK Ltd > Registered in UK and Wales under Company Registration No. 3798903 > Directors: Michael Cunningham (USA), Matt Parson (USA), Charlie Peters > (USA), Michael O'Neill (Ireland) From adinn at redhat.com Tue Jun 23 15:24:48 2015 From: adinn at redhat.com (Andrew Dinn) Date: Tue, 23 Jun 2015 16:24:48 +0100 Subject: RFR: 8129584: Fix required for aarch64 after 8122937 In-Reply-To: References: <55897012.6040109@redhat.com> Message-ID: <55897A40.4070908@redhat.com> On 23/06/15 16:22, Volker Simonis wrote: > the change looks good! > > I can push it for you. Thanks, Volker, that would be great. I think I still need one more reviewer though. Can anyone else help here? regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in UK and Wales under Company Registration No. 3798903 Directors: Michael Cunningham (USA), Matt Parson (USA), Charlie Peters (USA), Michael O'Neill (Ireland) From volker.simonis at gmail.com Tue Jun 23 15:31:21 2015 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 23 Jun 2015 17:31:21 +0200 Subject: RFR: 8129584: Fix required for aarch64 after 8122937 In-Reply-To: <55897A40.4070908@redhat.com> References: <55897012.6040109@redhat.com> <55897A40.4070908@redhat.com> Message-ID: You're welcome. I've updated the copyright and once a second review appears I'll push it. Regards, Volker On Tue, Jun 23, 2015 at 5:24 PM, Andrew Dinn wrote: > On 23/06/15 16:22, Volker Simonis wrote: >> the change looks good! >> >> I can push it for you. > > Thanks, Volker, that would be great. I think I still need one more > reviewer though. Can anyone else help here? > > regards, > > > Andrew Dinn > ----------- > Senior Principal Software Engineer > Red Hat UK Ltd > Registered in UK and Wales under Company Registration No. 3798903 > Directors: Michael Cunningham (USA), Matt Parson (USA), Charlie Peters > (USA), Michael O'Neill (Ireland) From vladimir.kozlov at oracle.com Tue Jun 23 15:32:51 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 23 Jun 2015 08:32:51 -0700 Subject: RFR: 8129584: Fix required for aarch64 after 8122937 In-Reply-To: References: <55897012.6040109@redhat.com> Message-ID: <55897C23.9090601@oracle.com> +1. Reviewed. Thanks, Vladimir On 6/23/15 8:22 AM, Volker Simonis wrote: > Hi Andrew, > > the change looks good! > > I can push it for you. > > Regards, > Volker > > > On Tue, Jun 23, 2015 at 4:41 PM, Andrew Dinn wrote: >> The following webrev against jdk9/hs-rt fixes AArch64 after it was >> broken by JDK-8122937: >> >> http://cr.openjdk.java.net/~adinn/8129584/webrev/ >> >> It is an AArch64-only patch. Could AArch64 reviewers please check it is >> ok? I'll also need someone to push it as I am not a committer. Thanks. >> >> regards, >> >> >> Andrew Dinn >> ----------- >> Senior Principal Software Engineer >> Red Hat UK Ltd >> Registered in UK and Wales under Company Registration No. 3798903 >> Directors: Michael Cunningham (USA), Matt Parson (USA), Charlie Peters >> (USA), Michael O'Neill (Ireland) From adinn at redhat.com Tue Jun 23 17:00:35 2015 From: adinn at redhat.com (Andrew Dinn) Date: Tue, 23 Jun 2015 18:00:35 +0100 Subject: RFR: 8129584: Fix required for aarch64 after 8122937 In-Reply-To: <55897C23.9090601@oracle.com> References: <55897012.6040109@redhat.com> <55897C23.9090601@oracle.com> Message-ID: <558990B3.6050905@redhat.com> On 23/06/15 16:32, Vladimir Kozlov wrote: > +1. Reviewed. Thanks, Vladimir. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in UK and Wales under Company Registration No. 3798903 Directors: Michael Cunningham (USA), Matt Parson (USA), Charlie Peters (USA), Michael O'Neill (Ireland) From edward.nevill at linaro.org Tue Jun 23 17:22:17 2015 From: edward.nevill at linaro.org (Edward Nevill) Date: Tue, 23 Jun 2015 18:22:17 +0100 Subject: RFR: 8129551: some regressions introduced by addition of vectorisation code In-Reply-To: <55893261.7030501@redhat.com> References: <1435054332.5083.15.camel@mylittlepony.linaroharston> <55893261.7030501@redhat.com> Message-ID: On 23 June 2015 at 11:18, Andrew Haley wrote: > On 23/06/15 11:12, Edward Nevill wrote: > > This changeset only affects aarch64 files. > > > > Please review and if OK I will push, > > Won't this fail to detect an overflow? > > 1418 if (T == T4H || T == T8H) { imm32 &= 0xffff; nimm32 &= 0xffff; } > > Otherwise this looks OK to me. > > Andrew. > > Updated webrev with asserts http://cr.openjdk.java.net/~enevill/8129551/webrev.01 Could a JDK9 Reviewer please review this, Thanks, Ed. From coleen.phillimore at oracle.com Tue Jun 23 17:45:22 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 23 Jun 2015 13:45:22 -0400 Subject: RFR (XS): 8078399: Deprecate -Xoss, -Xsqnopause, -Xoptimize and -Xboundthreads options in JDK 9 In-Reply-To: <558958FC.4020704@oracle.com> References: <5589367F.1040800@oracle.com> <558955EA.6020807@oracle.com> <558958FC.4020704@oracle.com> Message-ID: <55899B32.8080707@oracle.com> Dmitry, This code looks good to me. Thank you for doing this. I think you can't add them to the array static ObsoleteFlag obsolete_jvm_flags[] = { because it's only XX flags that this parses. Coleen On 6/23/15 9:02 AM, Dmitry Dmitriev wrote: > Hello David, > > Please, see my comments inline. > > On 23.06.2015 15:49, David Holmes wrote: >> Hi Dmitry, >> >> On 23/06/2015 8:35 PM, Dmitry Dmitriev wrote: >>> Hello, >>> >>> Please review this small fix which deprecate -Xoss, -Xsqnopause, >>> -Xoptimize and -Xboundthreads options in JDK 9. Also, I need a sponsor >>> for this fix, who can push it. >> >> I can sponsor this for you. But first ... > Thank you! >> >>> Currently HotSpot silently ignore these 4 options. Here are description >>> of these options: >>> "-Xoss", "-Xsqnopause", "-Xoptimize" - EVM option leaved for >>> compatibility. From Java 2 SDK for Solaris Developer's Guide: "Prior to >>> version 1.3.0, the production releases of the Java 2 SDK for the >>> Solaris >>> Operating Environment shipped with a virtual-machine implementation >>> known as the Exact VM (EVM). Beginning with version 1.3.0, the Exact VM >>> is replaced by the Java HotSpot VM.". So, from Java 1.4 EVM is not used >>> as VM for JDK on Solaris and these very old flags just silently ignored >>> by HotSpot. >>> "-Xboundthreads" - was used to bind user level threads to kernel >>> threads >>> on Solaris in case when new thread library is not available. But old T1 >>> libthread has been removed from Solaris in release 10. JDK9 requires >>> Solaris 10u9 or higher. So, this flag become useless. >>> >>> All these options are deprecated, i.e. following warning is printed >>> when >>> option is specified: "Java HotSpot(TM) 64-Bit Server VM warning: Option >>> -Xoss was deprecated in version 9.0 and will likely be removed in a >>> future release.". In next major release all these options can be >>> removed. >>> >>> Webrev: http://cr.openjdk.java.net/~ddmitriev/8078399/webrev.00/ >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8078399 >>> Tested: JPRT >> >> Can you not add these options to the set of obsolete_flags ? (and >> delete the code that references them of course) > Unfortunately, I not understand what set of obsolete flags you mean. > Do you mean os::obsolete_option method or obsolete_jvm_flags table? > Since obsolete_jvm_flags is developed for "XX:" options I not see how > it easily can be done. In case of os::obsolete_option methods then I > will need to add these options to all implementations. Probably, I not > understand you correctly. > > Thanks, > Dmitry > >> >> Thanks, >> David >> >>> Thanks, >>> Dmitry > From vladimir.kozlov at oracle.com Tue Jun 23 17:55:20 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 23 Jun 2015 10:55:20 -0700 Subject: RFR: 8129551: some regressions introduced by addition of vectorisation code In-Reply-To: References: <1435054332.5083.15.camel@mylittlepony.linaroharston> <55893261.7030501@redhat.com> Message-ID: <55899D88.8090904@oracle.com> asserts works only in debug VM so I would leave original imm32 &= 0xff and imm32 &= 0xffff. I think you should also move comments with table to macroAssembler_aarch64.cpp. Thanks, Vladimir On 6/23/15 10:22 AM, Edward Nevill wrote: > On 23 June 2015 at 11:18, Andrew Haley wrote: > >> On 23/06/15 11:12, Edward Nevill wrote: >>> This changeset only affects aarch64 files. >>> >>> Please review and if OK I will push, >> >> Won't this fail to detect an overflow? >> >> 1418 if (T == T4H || T == T8H) { imm32 &= 0xffff; nimm32 &= 0xffff; } >> >> Otherwise this looks OK to me. >> >> Andrew. >> >> > Updated webrev with asserts > > http://cr.openjdk.java.net/~enevill/8129551/webrev.01 > > Could a JDK9 Reviewer please review this, > > Thanks, > Ed. > From edward.nevill at linaro.org Tue Jun 23 19:01:44 2015 From: edward.nevill at linaro.org (Edward Nevill) Date: Tue, 23 Jun 2015 20:01:44 +0100 Subject: RFR: 8129551: some regressions introduced by addition of vectorisation code In-Reply-To: <55899D88.8090904@oracle.com> References: <1435054332.5083.15.camel@mylittlepony.linaroharston> <55893261.7030501@redhat.com> <55899D88.8090904@oracle.com> Message-ID: On 23 June 2015 at 18:55, Vladimir Kozlov wrote: > asserts works only in debug VM so I would leave original imm32 &= 0xff and > imm32 &= 0xffff. > I think you should also move comments with table to > macroAssembler_aarch64.cpp. Done. New webrev at http://cr.openjdk.java.net/~enevill/8129551/webrev.02 Does this look OK now? Thanks, Ed. From vladimir.kozlov at oracle.com Tue Jun 23 19:42:20 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 23 Jun 2015 12:42:20 -0700 Subject: RFR: 8129551: some regressions introduced by addition of vectorisation code In-Reply-To: References: <1435054332.5083.15.camel@mylittlepony.linaroharston> <55893261.7030501@redhat.com> <55899D88.8090904@oracle.com> Message-ID: <5589B69C.5050100@oracle.com> Yes, looks good. Thanks, Vladimir On 6/23/15 12:01 PM, Edward Nevill wrote: > > > On 23 June 2015 at 18:55, Vladimir Kozlov > wrote: > > asserts works only in debug VM so I would leave original imm32 &= > 0xff and imm32 &= 0xffff. > I think you should also move comments with table to > macroAssembler_aarch64.cpp. > > > Done. New webrev at > > http://cr.openjdk.java.net/~enevill/8129551/webrev.02 > > Does this look OK now? > > Thanks, > Ed. > > From gerard.ziemski at oracle.com Tue Jun 23 20:16:26 2015 From: gerard.ziemski at oracle.com (Gerard Ziemski) Date: Tue, 23 Jun 2015 15:16:26 -0500 Subject: Fix for 8122937: [JEP 245] Validate JVM Command-Line Flag Arguments breaks AArch64 In-Reply-To: <55895BC5.7010607@redhat.com> References: <55895BC5.7010607@redhat.com> Message-ID: <5589BE9A.1010209@oracle.com> hi Andrew, You are correct. jdk9/hotspot/src/cpu/aarch64/vm/globals_aarch64.hpp needs to have its ARCH_FLAGS macro table updated with "range" and "constraints" arguments. cheers On 6/23/2015 8:14 AM, Andrew Dinn wrote: > I am trying to build the current hs-rt tree on AArch64 in order to test > against Andrew Haley's UseCondCardMark patch (JDK-8079315). That tree > now also includes the following fix for JDK-8122937: > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/5bbf25472731 > > The patch includes changes made to all the current cpus /except/ aarch64 > which means that the aarch64 build now falls over with > > > /home/adinn/openjdk/hs-rt/hotspot/src/share/vm/runtime/globals_extension.hpp:242:28: > error: macro "ARCH_FLAGS" passed 7 arguments, but takes just 5 > IGNORE_CONSTRAINT) > > I believe the only modification required is to add the extra 2 arguments > range and constraint to macro ARCH_FLAGS (as per most of the other > cpu-specific globals files). I am testing this now and will raise a JIRA > and submit a webrev if that is indeed all that is needed. > > regards, > > > Andrew Dinn > ----------- > Senior Principal Software Engineer > Red Hat UK Ltd > Registered in UK and Wales under Company Registration No. 3798903 > Directors: Michael Cunningham (USA), Matt Parson (USA), Charlie Peters > (USA), Michael O'Neill (Ireland) > From mikael.vidstedt at oracle.com Tue Jun 23 20:57:21 2015 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Tue, 23 Jun 2015 13:57:21 -0700 Subject: RFR (XS): 8129615: Remove jbb from jprt hotspot testset Message-ID: <5589C831.2020604@oracle.com> Once upon a time SPECjbb2000 was used to drive total world domination in Java land. However, it is not really a very efficient test - neither in what it exercises, nor in the problems it finds. We should remove it from the jprt hotspot testset to make room for better, more efficient tests. Please review the following change which does exactly that: Bug: https://bugs.openjdk.java.net/browse/JDK-8129615 Webrev: http://cr.openjdk.java.net/~mikael/webrevs/8129615/webrev.00/webrev/ Cheers, Mikael From alejandro.murillo at oracle.com Tue Jun 23 21:11:15 2015 From: alejandro.murillo at oracle.com (Alejandro E Murillo) Date: Tue, 23 Jun 2015 15:11:15 -0600 Subject: [aarch64-port-dev ] RFR: 8129426: aarch64: add support for PopCount in C2 In-Reply-To: <1435067460.5083.21.camel@mylittlepony.linaroharston> References: <1434979401.21282.31.camel@mint> <558815DA.8020500@redhat.com> <1434985182.21282.34.camel@mint> <558823FD.5080800@redhat.com> <558829D2.4000503@redhat.com> <55882C94.7030505@redhat.com> <55882ECC.8030602@redhat.com> <5588313C.1070409@redhat.com> <5588345A.4060708@redhat.com> <5589308C.6000309@redhat.com> <558935D2.1020103@redhat.com> <1435067460.5083.21.camel@mylittlepony.linaroharston> Message-ID: <5589CB73.7020509@oracle.com> On 6/23/2015 7:51 AM, Edward Nevill wrote: > On Tue, 2015-06-23 at 11:32 +0100, Andrew Dinn wrote: >> On 23/06/15 11:10, Andrew Haley wrote: >>> On 22/06/15 17:14, Andrew Dinn wrote: >>>> . . . >>>> Well, you might not want to take this risk and instead add an explicit >>>> zero of the upper half. But I think we need to be clear what risk we are >>>> taking. >>> It's this: if we don't explicitly zero the upper half we'll have to >>> audit all the code which might present a sign-extended value (instead >>> of a zero-extended one) in a register that's supposed to contain a >>> jint. >> Ok, let's play safe. If Ed tweaks the patch to zero the upper word we >> can always revise that later if/when we decide we are feeling lucky. >> > OK. New webrev at > > http://cr.openjdk.java.net/~enevill/8129426/webrev.02/ > > All the best, > Ed. > > Hi, to be consistent with similar integrations and to avoid potential merging problems, going forward please work with the hs-rt repo for this kind of changes, as Volker has been doing. I'm working on getting this info on an external wiki Thanks Alejandro -- Alejandro From george.triantafillou at oracle.com Tue Jun 23 21:34:44 2015 From: george.triantafillou at oracle.com (George Triantafillou) Date: Tue, 23 Jun 2015 17:34:44 -0400 Subject: RFR (XS): 8129615: Remove jbb from jprt hotspot testset In-Reply-To: <5589C831.2020604@oracle.com> References: <5589C831.2020604@oracle.com> Message-ID: <5589D0F4.2060201@oracle.com> Hi Mikael, Looks good. Thanks for doing this! -George On 6/23/2015 4:57 PM, Mikael Vidstedt wrote: > > Once upon a time SPECjbb2000 was used to drive total world domination > in Java land. However, it is not really a very efficient test - > neither in what it exercises, nor in the problems it finds. We should > remove it from the jprt hotspot testset to make room for better, more > efficient tests. > > Please review the following change which does exactly that: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8129615 > Webrev: > http://cr.openjdk.java.net/~mikael/webrevs/8129615/webrev.00/webrev/ > > Cheers, > Mikael > From coleen.phillimore at oracle.com Tue Jun 23 22:36:30 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 23 Jun 2015 18:36:30 -0400 Subject: RFR (XS): 8129615: Remove jbb from jprt hotspot testset In-Reply-To: <5589D0F4.2060201@oracle.com> References: <5589C831.2020604@oracle.com> <5589D0F4.2060201@oracle.com> Message-ID: <5589DF6E.3030402@oracle.com> I agree, this looks good. Coleen On 6/23/15 5:34 PM, George Triantafillou wrote: > Hi Mikael, > > Looks good. Thanks for doing this! > > -George > > On 6/23/2015 4:57 PM, Mikael Vidstedt wrote: >> >> Once upon a time SPECjbb2000 was used to drive total world domination >> in Java land. However, it is not really a very efficient test - >> neither in what it exercises, nor in the problems it finds. We should >> remove it from the jprt hotspot testset to make room for better, more >> efficient tests. >> >> Please review the following change which does exactly that: >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8129615 >> Webrev: >> http://cr.openjdk.java.net/~mikael/webrevs/8129615/webrev.00/webrev/ >> >> Cheers, >> Mikael >> > From david.holmes at oracle.com Wed Jun 24 02:03:59 2015 From: david.holmes at oracle.com (David Holmes) Date: Wed, 24 Jun 2015 12:03:59 +1000 Subject: (URGENT) RFR (8u60) 8080600: AARCH64: testlibrary does not support AArch64 Message-ID: <558A100F.1080705@oracle.com> This is a partial backport of 8080600 to 8u60 so that the AArch64 platform is recognized. It is urgent to get in as the door closes on 8u60 via jdk8u/hs-dev on Thursday night. The changeset doesn't apply cleanly due to different file names and other minor content differences between 9 and 8u. Original changeset: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/3f334f56441e webrev for 8u60: http://cr.openjdk.java.net/~dholmes/8080600/webrev/ Also I'm dropping the IntrinicsBase part of the patch as it is not relevant to 8u at this time and the change would be untestable. Thanks, David From coleen.phillimore at oracle.com Wed Jun 24 02:11:21 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 23 Jun 2015 22:11:21 -0400 Subject: (URGENT) RFR (8u60) 8080600: AARCH64: testlibrary does not support AArch64 In-Reply-To: <558A100F.1080705@oracle.com> References: <558A100F.1080705@oracle.com> Message-ID: <558A11C9.6080905@oracle.com> This looks good to me. Coleen On 6/23/15 10:03 PM, David Holmes wrote: > This is a partial backport of 8080600 to 8u60 so that the AArch64 > platform is recognized. It is urgent to get in as the door closes on > 8u60 via jdk8u/hs-dev on Thursday night. > > The changeset doesn't apply cleanly due to different file names and > other minor content differences between 9 and 8u. > > Original changeset: > > http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/3f334f56441e > > webrev for 8u60: > > http://cr.openjdk.java.net/~dholmes/8080600/webrev/ > > Also I'm dropping the IntrinicsBase part of the patch as it is not > relevant to 8u at this time and the change would be untestable. > > Thanks, > David From david.holmes at oracle.com Wed Jun 24 02:12:32 2015 From: david.holmes at oracle.com (David Holmes) Date: Wed, 24 Jun 2015 12:12:32 +1000 Subject: (URGENT) RFR (8u60) 8080600: AARCH64: testlibrary does not support AArch64 In-Reply-To: <558A11C9.6080905@oracle.com> References: <558A100F.1080705@oracle.com> <558A11C9.6080905@oracle.com> Message-ID: <558A1210.5000401@oracle.com> Thanks Coleen! David On 24/06/2015 12:11 PM, Coleen Phillimore wrote: > > This looks good to me. > Coleen > > On 6/23/15 10:03 PM, David Holmes wrote: >> This is a partial backport of 8080600 to 8u60 so that the AArch64 >> platform is recognized. It is urgent to get in as the door closes on >> 8u60 via jdk8u/hs-dev on Thursday night. >> >> The changeset doesn't apply cleanly due to different file names and >> other minor content differences between 9 and 8u. >> >> Original changeset: >> >> http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/3f334f56441e >> >> webrev for 8u60: >> >> http://cr.openjdk.java.net/~dholmes/8080600/webrev/ >> >> Also I'm dropping the IntrinicsBase part of the patch as it is not >> relevant to 8u at this time and the change would be untestable. >> >> Thanks, >> David > From vladimir.kozlov at oracle.com Wed Jun 24 02:41:26 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 23 Jun 2015 19:41:26 -0700 Subject: (URGENT) RFR (8u60) 8080600: AARCH64: testlibrary does not support AArch64 In-Reply-To: <558A100F.1080705@oracle.com> References: <558A100F.1080705@oracle.com> Message-ID: <558A18D6.8050401@oracle.com> Looks good. I see that 8081790 is not backported too. Should we? Thanks, Vladimir On 6/23/15 7:03 PM, David Holmes wrote: > This is a partial backport of 8080600 to 8u60 so that the AArch64 > platform is recognized. It is urgent to get in as the door closes on > 8u60 via jdk8u/hs-dev on Thursday night. > > The changeset doesn't apply cleanly due to different file names and > other minor content differences between 9 and 8u. > > Original changeset: > > http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/3f334f56441e > > webrev for 8u60: > > http://cr.openjdk.java.net/~dholmes/8080600/webrev/ > > Also I'm dropping the IntrinicsBase part of the patch as it is not > relevant to 8u at this time and the change would be untestable. > > Thanks, > David From david.holmes at oracle.com Wed Jun 24 04:25:20 2015 From: david.holmes at oracle.com (David Holmes) Date: Wed, 24 Jun 2015 14:25:20 +1000 Subject: RFR (XS): 8078399: Deprecate -Xoss, -Xsqnopause, -Xoptimize and -Xboundthreads options in JDK 9 In-Reply-To: <558958FC.4020704@oracle.com> References: <5589367F.1040800@oracle.com> <558955EA.6020807@oracle.com> <558958FC.4020704@oracle.com> Message-ID: <558A3130.1050303@oracle.com> Hi Dmitry, On 23/06/2015 11:02 PM, Dmitry Dmitriev wrote: > Hello David, > > Please, see my comments inline. > > On 23.06.2015 15:49, David Holmes wrote: >> Hi Dmitry, >> >> On 23/06/2015 8:35 PM, Dmitry Dmitriev wrote: >>> Hello, >>> >>> Please review this small fix which deprecate -Xoss, -Xsqnopause, >>> -Xoptimize and -Xboundthreads options in JDK 9. Also, I need a sponsor >>> for this fix, who can push it. >> >> I can sponsor this for you. But first ... > Thank you! >> >>> Currently HotSpot silently ignore these 4 options. Here are description >>> of these options: >>> "-Xoss", "-Xsqnopause", "-Xoptimize" - EVM option leaved for >>> compatibility. From Java 2 SDK for Solaris Developer's Guide: "Prior to >>> version 1.3.0, the production releases of the Java 2 SDK for the Solaris >>> Operating Environment shipped with a virtual-machine implementation >>> known as the Exact VM (EVM). Beginning with version 1.3.0, the Exact VM >>> is replaced by the Java HotSpot VM.". So, from Java 1.4 EVM is not used >>> as VM for JDK on Solaris and these very old flags just silently ignored >>> by HotSpot. >>> "-Xboundthreads" - was used to bind user level threads to kernel threads >>> on Solaris in case when new thread library is not available. But old T1 >>> libthread has been removed from Solaris in release 10. JDK9 requires >>> Solaris 10u9 or higher. So, this flag become useless. >>> >>> All these options are deprecated, i.e. following warning is printed when >>> option is specified: "Java HotSpot(TM) 64-Bit Server VM warning: Option >>> -Xoss was deprecated in version 9.0 and will likely be removed in a >>> future release.". In next major release all these options can be >>> removed. >>> >>> Webrev: http://cr.openjdk.java.net/~ddmitriev/8078399/webrev.00/ >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8078399 >>> Tested: JPRT >> >> Can you not add these options to the set of obsolete_flags ? (and >> delete the code that references them of course) > Unfortunately, I not understand what set of obsolete flags you mean. Do > you mean os::obsolete_option method or obsolete_jvm_flags table? Since > obsolete_jvm_flags is developed for "XX:" options I not see how it > easily can be done. In case of os::obsolete_option methods then I will > need to add these options to all implementations. Probably, I not > understand you correctly. It was the obsolete_jvm_flags table I meant - sorry about the typo. Pity it doesn't support -X options. :( My only suggestion here is to at least use the same warning message as would be seen for obsolete -XX flags (something I should have suggested when reviewing the CCC request): warning("ignoring option %s; support was removed in %s", stripped_argname, version); ref: > java -XX:+UseOldInlining -version Java HotSpot(TM) Server VM warning: ignoring option UseOldInlining; support was removed in 9.0 vs > java -Xoss -version Java HotSpot(TM) Server VM warning: Option -Xoss was deprecated in version 9.0 and will likely be removed in a future release. and if you use an actual JVM_Version then this won't need to be updated when the new version string comes in. :) Thanks, David > Thanks, > Dmitry > >> >> Thanks, >> David >> >>> Thanks, >>> Dmitry > From stefan.johansson at oracle.com Wed Jun 24 06:34:58 2015 From: stefan.johansson at oracle.com (Stefan Johansson) Date: Wed, 24 Jun 2015 08:34:58 +0200 Subject: RFR: 8081607: Change default GC for server configurations to G1 In-Reply-To: <1435054973.2673.12.camel@oracle.com> References: <558913D5.40301@oracle.com> <1435050266.2673.7.camel@oracle.com> <55892630.4020307@oracle.com> <1435054973.2673.12.camel@oracle.com> Message-ID: <558A4F92.4010008@oracle.com> Thanks Per and Thomas for the reviews, Stefan On 2015-06-23 12:22, Thomas Schatzl wrote: > Hi, > > On Tue, 2015-06-23 at 11:26 +0200, Stefan Johansson wrote: >> Thanks for the review Thomas, >> >> New webrev: >> http://cr.openjdk.java.net/~sjohanss/8081607/hotspot.01/ >> > looks good. > > Thanks, > Thomas > From goetz.lindenmaier at sap.com Wed Jun 24 07:40:15 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 24 Jun 2015 07:40:15 +0000 Subject: RFR(S): 8129757: ppc/aarch: Fix passing thread to runtime after "8073165: Contended Locking fast exit bucket." Message-ID: <4295855A5C1DE049A61835A1887419CC2CFFED31@DEWDFEMB12A.global.corp.sap> Hi, Change 8073165 added a new argument to complete_monitor_unlocking_C(): the current thread. Moving this value into the argument registers before the runtime call issued in the native wrapper was missing on ppc and aarch. Please review this change: http://cr.openjdk.java.net/~goetz/webrevs/8129757-unlock/webrev-01/ Edward Nevill already had a look at the aarch changes and tested them. Best regards, Goetz. From adinn at redhat.com Wed Jun 24 07:51:29 2015 From: adinn at redhat.com (Andrew Dinn) Date: Wed, 24 Jun 2015 08:51:29 +0100 Subject: Fix for 8122937: [JEP 245] Validate JVM Command-Line Flag Arguments breaks AArch64 In-Reply-To: <5589BE9A.1010209@oracle.com> References: <55895BC5.7010607@redhat.com> <5589BE9A.1010209@oracle.com> Message-ID: <558A6181.7060108@redhat.com> On 23/06/15 21:16, Gerard Ziemski wrote: > hi Andrew, > > You are correct. > > jdk9/hotspot/src/cpu/aarch64/vm/globals_aarch64.hpp needs to have its > ARCH_FLAGS macro table updated with "range" and "constraints" arguments. Thanks for the confirmation, Gerald. The JIRA I promised is here https://bugs.openjdk.java.net/browse/JDK-8129584 and as you can see Volker has already pushed the patch :-) regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in UK and Wales under Company Registration No. 3798903 Directors: Michael Cunningham (USA), Matt Parson (USA), Charlie Peters (USA), Michael O'Neill (Ireland) From volker.simonis at gmail.com Wed Jun 24 08:21:54 2015 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 24 Jun 2015 10:21:54 +0200 Subject: RFR(S): 8129757: ppc/aarch: Fix passing thread to runtime after "8073165: Contended Locking fast exit bucket." In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CFFED31@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CFFED31@DEWDFEMB12A.global.corp.sap> Message-ID: Hi Goetz, the change looks good - at least the ppc part. I can't say anything about the aarch64 part:) Regards, Volker On Wed, Jun 24, 2015 at 9:40 AM, Lindenmaier, Goetz wrote: > Hi, > > Change 8073165 added a new argument to complete_monitor_unlocking_C(): the current thread. Moving this value into the argument registers before the runtime call issued in the native wrapper was missing on ppc and aarch. > > Please review this change: > http://cr.openjdk.java.net/~goetz/webrevs/8129757-unlock/webrev-01/ > > Edward Nevill already had a look at the aarch changes and tested them. > > Best regards, > Goetz. From goetz.lindenmaier at sap.com Wed Jun 24 08:26:22 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 24 Jun 2015 08:26:22 +0000 Subject: RFR(S): 8129757: ppc/aarch: Fix passing thread to runtime after "8073165: Contended Locking fast exit bucket." In-Reply-To: References: <4295855A5C1DE049A61835A1887419CC2CFFED31@DEWDFEMB12A.global.corp.sap> Message-ID: <4295855A5C1DE049A61835A1887419CC2CFFEE26@DEWDFEMB12A.global.corp.sap> Thanks Volker! Best regards, Goetz. -----Original Message----- From: Volker Simonis [mailto:volker.simonis at gmail.com] Sent: Mittwoch, 24. Juni 2015 10:22 To: Lindenmaier, Goetz Cc: HotSpot Developers Subject: Re: RFR(S): 8129757: ppc/aarch: Fix passing thread to runtime after "8073165: Contended Locking fast exit bucket." Hi Goetz, the change looks good - at least the ppc part. I can't say anything about the aarch64 part:) Regards, Volker On Wed, Jun 24, 2015 at 9:40 AM, Lindenmaier, Goetz wrote: > Hi, > > Change 8073165 added a new argument to complete_monitor_unlocking_C(): the current thread. Moving this value into the argument registers before the runtime call issued in the native wrapper was missing on ppc and aarch. > > Please review this change: > http://cr.openjdk.java.net/~goetz/webrevs/8129757-unlock/webrev-01/ > > Edward Nevill already had a look at the aarch changes and tested them. > > Best regards, > Goetz. From adinn at redhat.com Wed Jun 24 08:51:09 2015 From: adinn at redhat.com (Andrew Dinn) Date: Wed, 24 Jun 2015 09:51:09 +0100 Subject: RFR(S): 8129757: ppc/aarch: Fix passing thread to runtime after "8073165: Contended Locking fast exit bucket." In-Reply-To: References: <4295855A5C1DE049A61835A1887419CC2CFFED31@DEWDFEMB12A.global.corp.sap> Message-ID: <558A6F7D.2070207@redhat.com> On 24/06/15 09:21, Volker Simonis wrote: > Hi Goetz, > > the change looks good - at least the ppc part. > I can't say anything about the aarch64 part:) Ed Nevill (in cc) has tested the aarch64 part of this patch and oked it on the aarch64-port-dev list. I am also happy with this as far as aarch64 is concerned (for what that is worth -- I am not a JKD9 reviewer). regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in UK and Wales under Company Registration No. 3798903 Directors: Michael Cunningham (USA), Matt Parson (USA), Charlie Peters (USA), Michael O'Neill (Ireland) From goetz.lindenmaier at sap.com Wed Jun 24 08:56:27 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 24 Jun 2015 08:56:27 +0000 Subject: RFR(S): 8129757: ppc/aarch: Fix passing thread to runtime after "8073165: Contended Locking fast exit bucket." In-Reply-To: <558A6F7D.2070207@redhat.com> References: <4295855A5C1DE049A61835A1887419CC2CFFED31@DEWDFEMB12A.global.corp.sap> <558A6F7D.2070207@redhat.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2CFFEEAA@DEWDFEMB12A.global.corp.sap> Thanks Andrew! Best regards, Goetz. -----Original Message----- From: Andrew Dinn [mailto:adinn at redhat.com] Sent: Mittwoch, 24. Juni 2015 10:51 To: Volker Simonis; Lindenmaier, Goetz Cc: HotSpot Developers; Edward Nevill Subject: Re: RFR(S): 8129757: ppc/aarch: Fix passing thread to runtime after "8073165: Contended Locking fast exit bucket." On 24/06/15 09:21, Volker Simonis wrote: > Hi Goetz, > > the change looks good - at least the ppc part. > I can't say anything about the aarch64 part:) Ed Nevill (in cc) has tested the aarch64 part of this patch and oked it on the aarch64-port-dev list. I am also happy with this as far as aarch64 is concerned (for what that is worth -- I am not a JKD9 reviewer). regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in UK and Wales under Company Registration No. 3798903 Directors: Michael Cunningham (USA), Matt Parson (USA), Charlie Peters (USA), Michael O'Neill (Ireland) From thomas.schatzl at oracle.com Wed Jun 24 09:03:46 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Wed, 24 Jun 2015 11:03:46 +0200 Subject: RFR (XXS): 8129602: Incorrect GPL header causes RE script to create wrong output Message-ID: <1435136626.2512.15.camel@oracle.com> Hi all, I need reviews for a small set of fixes that removes superfluous commas after the year in the GPL header so that some release engineering script does not produce garbage. This CR fixes these issues for several files across the hotspot repository, bundling multiple similar problems. That's why this issue has been sent for review to hotspot-dev. CR (confidential, sorry): https://bugs.openjdk.java.net/browse/JDK-8129602 Webrev: http://cr.openjdk.java.net/~tschatzl/8129602/webrev.hotspot/ http://cr.openjdk.java.net/~tschatzl/8129602/webrev.hs-gc/ (for whitebox.cpp). Here is the corresponding 8u60 patch that differs in paths and adds a few more typos that have been fixed in 9. http://cr.openjdk.java.net/~tschatzl/8129602/webrev.8u60/ Thanks, Thomas From thomas.schatzl at oracle.com Wed Jun 24 09:25:33 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Wed, 24 Jun 2015 11:25:33 +0200 Subject: RFR (XXS): 8129602: Incorrect GPL header causes RE script to create wrong output In-Reply-To: <1435136626.2512.15.camel@oracle.com> References: <1435136626.2512.15.camel@oracle.com> Message-ID: <1435137933.2512.24.camel@oracle.com> Hi again, On Wed, 2015-06-24 at 11:03 +0200, Thomas Schatzl wrote: > Hi all, > > I need reviews for a small set of fixes that removes superfluous > commas after the year in the GPL header so that some release engineering > script does not produce garbage. Sorry, the description of the issue in the email is wrong. There are, in jdk9 - a few whitespace removals in some gpl headers in addition to that, in jdk8, - a few commas had to be *added* I wrote the email first, and then during rechecking the problems I found that actually most of them were about *adding* commas, not removing them. Initially, I got a bit confused about the problem, because in jdk9 the commas were all fixed (trying to apply the requested changes to jdk9 first - they are reported for 8u60), and thought that they need to be removed because the CRs constantly talk about messed up commas after the years. I.e. the bug reports all contain some copy&pasted text block that is completely unrelated :) That is actually not the case. I got confused by that. > > This CR fixes these issues for several files across the hotspot > repository, bundling multiple similar problems. That's why this issue > has been sent for review to hotspot-dev. > > CR (confidential, sorry): > https://bugs.openjdk.java.net/browse/JDK-8129602 > > Webrev: > http://cr.openjdk.java.net/~tschatzl/8129602/webrev.hotspot/ > http://cr.openjdk.java.net/~tschatzl/8129602/webrev.hs-gc/ (for > whitebox.cpp). > > Here is the corresponding 8u60 patch that differs in paths and adds a > few more typos that have been fixed in 9. > > http://cr.openjdk.java.net/~tschatzl/8129602/webrev.8u60/ I removed some removal of two empty lines at the end of one of the GPL headers that accidentally got through some last look at it. Thanks go to StefanK for that. Thanks, Thomas From stefan.karlsson at oracle.com Wed Jun 24 09:28:00 2015 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Wed, 24 Jun 2015 11:28:00 +0200 Subject: RFR (XXS): 8129602: Incorrect GPL header causes RE script to create wrong output In-Reply-To: <1435137933.2512.24.camel@oracle.com> References: <1435136626.2512.15.camel@oracle.com> <1435137933.2512.24.camel@oracle.com> Message-ID: <558A7820.8040204@oracle.com> On 2015-06-24 11:25, Thomas Schatzl wrote: > Hi again, > > On Wed, 2015-06-24 at 11:03 +0200, Thomas Schatzl wrote: >> Hi all, >> >> I need reviews for a small set of fixes that removes superfluous >> commas after the year in the GPL header so that some release engineering >> script does not produce garbage. > Sorry, the description of the issue in the email is wrong. There are, in > jdk9 > - a few whitespace removals in some gpl headers > > in addition to that, in jdk8, > - a few commas had to be *added* > > I wrote the email first, and then during rechecking the problems I found > that actually most of them were about *adding* commas, not removing > them. > > Initially, I got a bit confused about the problem, because in jdk9 the > commas were all fixed (trying to apply the requested changes to jdk9 > first - they are reported for 8u60), and thought that they need to be > removed because the CRs constantly talk about messed up commas after the > years. I.e. the bug reports all contain some copy&pasted text block that > is completely unrelated :) > > That is actually not the case. I got confused by that. > >> This CR fixes these issues for several files across the hotspot >> repository, bundling multiple similar problems. That's why this issue >> has been sent for review to hotspot-dev. >> >> CR (confidential, sorry): >> https://bugs.openjdk.java.net/browse/JDK-8129602 >> >> Webrev: >> http://cr.openjdk.java.net/~tschatzl/8129602/webrev.hotspot/ >> http://cr.openjdk.java.net/~tschatzl/8129602/webrev.hs-gc/ (for >> whitebox.cpp). >> >> Here is the corresponding 8u60 patch that differs in paths and adds a >> few more typos that have been fixed in 9. >> >> http://cr.openjdk.java.net/~tschatzl/8129602/webrev.8u60/ > I removed some removal of two empty lines at the end of one of the GPL > headers that accidentally got through some last look at it. Thanks go to > StefanK for that. All changes look good. Thanks for fixing this. StefanK > > Thanks, > Thomas > > > From bertrand.delsart at oracle.com Wed Jun 24 09:46:18 2015 From: bertrand.delsart at oracle.com (Bertrand Delsart) Date: Wed, 24 Jun 2015 11:46:18 +0200 Subject: RFR [S] 8081406: cleanup and minor extensions of the debugging facilities in CodeStrings In-Reply-To: <55824988.2030109@oracle.com> References: <55674A24.4050501@oracle.com> <5580D094.8060803@oracle.com> <558154D4.8090405@oracle.com> <55824988.2030109@oracle.com> Message-ID: <558A7C6A.8070502@oracle.com> Hi all, To avoid further delays since this is a pre-requisite for the closed part of 8087333, I've removed the two private accessors I had added: set_null() and invalidate(). They are no longer necessary after the cleanup suggested by David and their potential added value is currently not worth the concerns around their proper use :-) Updated webrev: http://cr.openjdk.java.net/~bdelsart/8081406/webrev.02/ Incremental diff: diff --git a/src/share/vm/asm/codeBuffer.hpp b/src/share/vm/asm/codeBuffer.hpp --- a/src/share/vm/asm/codeBuffer.hpp +++ b/src/share/vm/asm/codeBuffer.hpp @@ -264,21 +264,6 @@ #endif } - void set_null() { -#ifndef PRODUCT - _strings = NULL; -#endif - } - - void invalidate() { -#ifndef PRODUCT - assert(is_null(), "Should not invalidate non-empty CodeStrings"); -#ifdef ASSERT - _defunct = true; -#endif -#endif - } - public: CodeStrings() { #ifndef PRODUCT Regards, Bertrand. On 18/06/2015 06:31, David Holmes wrote: > On 17/06/2015 9:07 PM, Bertrand Delsart wrote: >> Thanks David, >> >> Updated webrev. See below my inlined comments for additional >> explanations on the changes. >> >> http://cr.openjdk.java.net/~bdelsart/8081406/webrev.01/ >> >> This is a subset of the previous changes: >> - free was reverted to its initial definition but its behavior >> is now clearly documented (e.g. the fact that it must invalidate >> the object since this was David's concern) > > Okay. I guess there's no point discussing things no longer changed, so > as long as this works you. > >> - assign is nearly reverted too but still ensures _defunct is set > > Yep - sorry I got my _defunct comment completely backwards. Doh. > > Looks good. > > Thanks, > David > > >> Regards, >> >> Bertrand. >> >> On 17/06/2015 03:42, David Holmes wrote: >>> Hi Bertrand, >>> >>> On 29/05/2015 3:02 AM, Bertrand Delsart wrote: >>>> Hi all, >>>> >>>> Small RFR to address minor issues in debug mode with CodeStrings >>> >>> Not something I'm familiar with so I may be missing some things here. >>> >>>> https://bugs.openjdk.java.net/browse/JDK-8081406 >>>> http://cr.openjdk.java.net/~bdelsart/8081406/webrev.00/ >>>> >>>> The change does not impact the product mode. >>> >>> So the initialization of CodeBlob::_strings and >>> CodeBuffer::_code_strings does happen in product mode as well, but the >>> resulting CodeStrings object does nothing. Suggests to me that *_strings >>> should be a non-product field only (but that's an aside to this set of >>> changes). >>> >>> src/share/vm/asm/codeBuffer.hpp >>> >>> The ifdef style in this file is quite awful IMO but the changes are >>> consistent with it. >>> >>> 308 // FREE strings; invalidate if contains non comment strings. >>> >>> if -> if it >> >> OK. >> >> [ Will in fact just be "invalidate this" due to your other feedback ] >> >>> >>> --- >>> >>> src/share/vm/asm/codeBuffer.cpp >>> >>> 1105 *this = other; // copy all fields (including _defunct when it >>> exists) >>> >>> I can see the need to free() the existing CodeStrings if present, but >>> otherwise why does the original logic need to change from: >>> >>> _strings = other._strings; >>> _other.set_null_and_invalidate(); >>> >>> to the somewhat cryptic: >>> >>> *this = other; >>> other.set_null_and_invalidate(); >>> >>> I'm not even certain what that assignment will do. It's also not clear >>> why _defunct needs to be copied over rather than just being set to true >>> (as _other can't have _defunct==false as we already called >>> check_valid() ). >> >> First, the fields declared in CodeStrings depends on several ifdefs >> (ASSERT and PRODUCT). "*this=" is a way to avoid the "awful ifdef style" >> :-) >> >> In addition, this is slightly more robust IMHO. For instance, it makes >> the assignment copy independent of the internals of CodeStrings. In >> particular, _defunct would have to be set to false, not true :-) >> >> Now, I did check that this had not lead to issue in JPRT and with other >> test in debug mode, including on exotic platforms, but it is impossible >> to prove that all C++ compilers will handle correctly "*this=" which >> should just be an assignment copy between two C++ objects (and a NOP in >> product mode, where the CodeStrings are of size 0). >> >> Since this RFR is blocking later pushes, I'll avoid further delays and >> replace >> *this = other >> by : >> _strings = other._strings >> #ifdef ASSERT >> _defunct = false; >> #endif >> >>> The change of semantics of free() does make me concerned whether >>> existing uses of it now have their assumptions invalidated? It isn't >>> clear to me why you would want to free() something but retain validity - >>> more of a clear()/reset() operation. But then I don't understand the >>> significance of comment versus non-comment with regards to validity ?? >> >> I see your concern about free(). To make that clearer, I added >> explicitly next to the declaration of free the fact that it invalidates >> the buffer. >> >> My change was initially due to closed code in JDK-8087333 (an RFE >> concurrently being reviewed). Extending the meaning of _valid had >> allowed the closed code to be cleaner and more robust, catching errors >> in the handling on non-comment strings (see below) but this may no >> longer be necessary. I'll look for an alternate solution if needed (for >> instance adding a new clear() method; thanks for the suggestion). >> >> Reverting free() in the current webrev means I'll also remove from >> CodeStrings::assign the >> >> + if (!is_null()) { >> + // The assignment replaces the old content. >> + // Delete old CodeStrings, invalidating it if there are non-comment >> + // strings. >> + free(); >> + check_valid(); // else the container may reference freed strings >> + } >> >> and add back the >> >> - assert(is_null(), "Cannot assign onto non-empty CodeStrings"); >> >> FYI, some information on the comment versus non-comment. >> >> Non-comment strings in CodeStrings are (currently) used only in for >> debug functionalities (verify_oop, unimplemented, untested, ...) but >> they are necessary to correctly report errors. If deleted, the VM may >> crash when trying to print a debug message. Since CodeStrings are >> embedded into a CodeBlob container, marking the CodeStrings invalid when >> freed allowed to detect that the CodeBlob was no longer valid. On the >> other hand, a comment string is something which is not necessary for >> correct execution. It is only used when dumping the code. >> >> Removing a comment from a CodeStrings has no impact on the execution of >> the Java application... and freeing them was the most efficient way to >> handle them for JDK-8087333. My change allowed to detect as a side >> effect of the free whether we had safely deleted only comments or >> whether there was a non-comment string that had not been properly >> handled. As stated above, I'll look for an alternative to provide the >> same robustness without impacting the existing methods, avoiding all >> risks. >> >> Regards, >> >> Bertrand. >> >>> >>> Thanks, >>> David >>> >>>> In non product mode, CodeStrings allows to associate a linked list of >>>> strings to a CodeBuffer, CodeBlob or Stub. In addition, with >>>> ASSERTS, it >>>> defines a boolean asserting whether the list of strings are valid. >>> >>> >>> >>>> Here are the issues addressed by this CR: >>>> >>>> - The old code mentioned the fact that CodeStrings was not always >>>> correctly initialized. This is addressed by the fix, allowing >>>> check_valid to be added at a few locations where it could currently >>>> failed due to uninitialized values (like at the beginning of >>>> CodeStrings::free). This also makes the code more robust against future >>>> versions of CodeStrings. >>>> >>>> - As a minor extension, it is now possible for platform dependent code >>>> to modify the comment separator used by print_block_comment, which was >>>> hard coded to " ;; ". >>>> >>>> - As another minor extension, related to the validity assertions, >>>> freeing a code string no longer necessarily marks it (and hence its >>>> Stub/CodeBlob/CodeBuffer) as invalid. If CodeStrings contains only >>>> comment, removing them does not change the validity of the CodeStrings. >>>> For similar reason, assignment over a non null CodeStrings is now valid >>>> when we can safely free the old string. >>>> >>>> The modified code passes JPRT. It was also validated in fastdebug mode >>>> with the vm.compiler.testlist to check that the validity assertion were >>>> not triggered. One of our closed extensions also validated advanced use >>>> of CodeStrings::assign (included cases where the target of the >>>> assignment was not free). >>>> >>>> Best regards, >>>> >>>> Bertrand. >>>> >> >> -- Bertrand Delsart, Grenoble Engineering Center Oracle, 180 av. de l'Europe, ZIRST de Montbonnot 38330 Montbonnot Saint Martin, FRANCE bertrand.delsart at oracle.com Phone : +33 4 76 18 81 23 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From david.holmes at oracle.com Wed Jun 24 09:48:39 2015 From: david.holmes at oracle.com (David Holmes) Date: Wed, 24 Jun 2015 19:48:39 +1000 Subject: RFR: 8081294: aarch64: fails to build on ubuntu wily In-Reply-To: <1435049748.20837.6.camel@mylittlepony.linaroharston> References: <1435049748.20837.6.camel@mylittlepony.linaroharston> Message-ID: <558A7CF7.7080101@oracle.com> Hi Ed, On 23/06/2015 6:55 PM, Edward Nevill wrote: > Hi, > > One of our partners has reported that jdk9 fails to build for aarch64 on ubuntu 'wily' > > The failing buildlog is here > > https://launchpad.net/ubuntu/+source/openjdk-9/9~b64-1ubuntu1/+build/7441971 > > The following webrev fixes this > > http://cr.openjdk.java.net/~enevill/8081294/webrev/ > > I have verified that this fixes the problem by cross compiling against a sysroot. > > Our partner has also verified that this patch fixes the build. > > As this is a change to shared code I will need someone to sponsor this and push it through JPRT. I'll handle this for you. As it is trivial and only affects aarch64 my Review is sufficient. Thanks, David > Thanks for your help, > Ed > > From david.holmes at oracle.com Wed Jun 24 09:56:59 2015 From: david.holmes at oracle.com (David Holmes) Date: Wed, 24 Jun 2015 19:56:59 +1000 Subject: RFR (XXS): 8129602: Incorrect GPL header causes RE script to create wrong output In-Reply-To: <1435136626.2512.15.camel@oracle.com> References: <1435136626.2512.15.camel@oracle.com> Message-ID: <558A7EEB.9040305@oracle.com> Hi Thomas, On 24/06/2015 7:03 PM, Thomas Schatzl wrote: > Hi all, > > I need reviews for a small set of fixes that removes superfluous > commas after the year in the GPL header so that some release engineering > script does not produce garbage. Actually add the missing commas where needed :) > This CR fixes these issues for several files across the hotspot > repository, bundling multiple similar problems. That's why this issue > has been sent for review to hotspot-dev. > > CR (confidential, sorry): > https://bugs.openjdk.java.net/browse/JDK-8129602 > > Webrev: > http://cr.openjdk.java.net/~tschatzl/8129602/webrev.hotspot/ You need to look at the patch to see the whitespace fix :) > http://cr.openjdk.java.net/~tschatzl/8129602/webrev.hs-gc/ (for > whitebox.cpp). Ditto. > Here is the corresponding 8u60 patch that differs in paths and adds a > few more typos that have been fixed in 9. > > http://cr.openjdk.java.net/~tschatzl/8129602/webrev.8u60/ This all looks fine too. So the commas are already fixed in 9? Thanks, David > Thanks, > Thomas > From david.holmes at oracle.com Wed Jun 24 09:58:37 2015 From: david.holmes at oracle.com (David Holmes) Date: Wed, 24 Jun 2015 19:58:37 +1000 Subject: RFR (XXS): 8129602: Incorrect GPL header causes RE script to create wrong output In-Reply-To: <558A7EEB.9040305@oracle.com> References: <1435136626.2512.15.camel@oracle.com> <558A7EEB.9040305@oracle.com> Message-ID: <558A7F4D.2000406@oracle.com> Just saw your follow up mail so all is good. Thanks, David On 24/06/2015 7:56 PM, David Holmes wrote: > Hi Thomas, > > On 24/06/2015 7:03 PM, Thomas Schatzl wrote: >> Hi all, >> >> I need reviews for a small set of fixes that removes superfluous >> commas after the year in the GPL header so that some release engineering >> script does not produce garbage. > > Actually add the missing commas where needed :) > >> This CR fixes these issues for several files across the hotspot >> repository, bundling multiple similar problems. That's why this issue >> has been sent for review to hotspot-dev. >> >> CR (confidential, sorry): >> https://bugs.openjdk.java.net/browse/JDK-8129602 >> >> Webrev: >> http://cr.openjdk.java.net/~tschatzl/8129602/webrev.hotspot/ > > You need to look at the patch to see the whitespace fix :) > >> http://cr.openjdk.java.net/~tschatzl/8129602/webrev.hs-gc/ (for >> whitebox.cpp). > > Ditto. > >> Here is the corresponding 8u60 patch that differs in paths and adds a >> few more typos that have been fixed in 9. >> >> http://cr.openjdk.java.net/~tschatzl/8129602/webrev.8u60/ > > This all looks fine too. So the commas are already fixed in 9? > > Thanks, > David > >> Thanks, >> Thomas >> From dmitry.dmitriev at oracle.com Wed Jun 24 10:36:13 2015 From: dmitry.dmitriev at oracle.com (Dmitry Dmitriev) Date: Wed, 24 Jun 2015 13:36:13 +0300 Subject: RFR (XS): 8078399: Deprecate -Xoss, -Xsqnopause, -Xoptimize and -Xboundthreads options in JDK 9 In-Reply-To: <558A3130.1050303@oracle.com> References: <5589367F.1040800@oracle.com> <558955EA.6020807@oracle.com> <558958FC.4020704@oracle.com> <558A3130.1050303@oracle.com> Message-ID: <558A881D.4010304@oracle.com> Hello David, I update code and now print similar message and use JVM_Version. Thank you! Webrev.01: http://cr.openjdk.java.net/~ddmitriev/8078399/webrev.01/ Now warning message looks like this: Java HotSpot(TM) 64-Bit Server VM warning: ignoring option -Xoss; support was removed in 9.0 This message have small difference with "-XX" options: "-XX" option strip "-XX:", but I print full optionString. But I can remove "-X" and just print option name(e.g. "oss") by passing "option->optionString + 2" to the warning function. What you think about that? Thank you, Dmitry On 24.06.2015 7:25, David Holmes wrote: > Hi Dmitry, > > On 23/06/2015 11:02 PM, Dmitry Dmitriev wrote: >> Hello David, >> >> Please, see my comments inline. >> >> On 23.06.2015 15:49, David Holmes wrote: >>> Hi Dmitry, >>> >>> On 23/06/2015 8:35 PM, Dmitry Dmitriev wrote: >>>> Hello, >>>> >>>> Please review this small fix which deprecate -Xoss, -Xsqnopause, >>>> -Xoptimize and -Xboundthreads options in JDK 9. Also, I need a sponsor >>>> for this fix, who can push it. >>> >>> I can sponsor this for you. But first ... >> Thank you! >>> >>>> Currently HotSpot silently ignore these 4 options. Here are >>>> description >>>> of these options: >>>> "-Xoss", "-Xsqnopause", "-Xoptimize" - EVM option leaved for >>>> compatibility. From Java 2 SDK for Solaris Developer's Guide: >>>> "Prior to >>>> version 1.3.0, the production releases of the Java 2 SDK for the >>>> Solaris >>>> Operating Environment shipped with a virtual-machine implementation >>>> known as the Exact VM (EVM). Beginning with version 1.3.0, the >>>> Exact VM >>>> is replaced by the Java HotSpot VM.". So, from Java 1.4 EVM is not >>>> used >>>> as VM for JDK on Solaris and these very old flags just silently >>>> ignored >>>> by HotSpot. >>>> "-Xboundthreads" - was used to bind user level threads to kernel >>>> threads >>>> on Solaris in case when new thread library is not available. But >>>> old T1 >>>> libthread has been removed from Solaris in release 10. JDK9 requires >>>> Solaris 10u9 or higher. So, this flag become useless. >>>> >>>> All these options are deprecated, i.e. following warning is printed >>>> when >>>> option is specified: "Java HotSpot(TM) 64-Bit Server VM warning: >>>> Option >>>> -Xoss was deprecated in version 9.0 and will likely be removed in a >>>> future release.". In next major release all these options can be >>>> removed. >>>> >>>> Webrev: http://cr.openjdk.java.net/~ddmitriev/8078399/webrev.00/ >>>> >>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8078399 >>>> Tested: JPRT >>> >>> Can you not add these options to the set of obsolete_flags ? (and >>> delete the code that references them of course) >> Unfortunately, I not understand what set of obsolete flags you mean. Do >> you mean os::obsolete_option method or obsolete_jvm_flags table? Since >> obsolete_jvm_flags is developed for "XX:" options I not see how it >> easily can be done. In case of os::obsolete_option methods then I will >> need to add these options to all implementations. Probably, I not >> understand you correctly. > > It was the obsolete_jvm_flags table I meant - sorry about the typo. > Pity it doesn't support -X options. :( > > My only suggestion here is to at least use the same warning message as > would be seen for obsolete -XX flags (something I should have > suggested when reviewing the CCC request): > > warning("ignoring option %s; support was removed in %s", > stripped_argname, version); > > ref: > > > java -XX:+UseOldInlining -version > Java HotSpot(TM) Server VM warning: ignoring option UseOldInlining; > support was removed in 9.0 > > vs > > > java -Xoss -version > Java HotSpot(TM) Server VM warning: Option -Xoss was deprecated in > version 9.0 and will likely be removed in a future release. > > > and if you use an actual JVM_Version then this won't need to be > updated when the new version string comes in. :) > > Thanks, > David > >> Thanks, >> Dmitry >> >>> >>> Thanks, >>> David >>> >>>> Thanks, >>>> Dmitry >> From dmitry.dmitriev at oracle.com Wed Jun 24 10:39:23 2015 From: dmitry.dmitriev at oracle.com (Dmitry Dmitriev) Date: Wed, 24 Jun 2015 13:39:23 +0300 Subject: RFR (XS): 8078399: Deprecate -Xoss, -Xsqnopause, -Xoptimize and -Xboundthreads options in JDK 9 In-Reply-To: <55899B32.8080707@oracle.com> References: <5589367F.1040800@oracle.com> <558955EA.6020807@oracle.com> <558958FC.4020704@oracle.com> <55899B32.8080707@oracle.com> Message-ID: <558A88DB.3000504@oracle.com> Hello Coleen, Thank you for review! I address David comments and put updated webrev: http://cr.openjdk.java.net/~ddmitriev/8078399/webrev.01/ Regards, Dmitry On 23.06.2015 20:45, Coleen Phillimore wrote: > > Dmitry, This code looks good to me. Thank you for doing this. > > I think you can't add them to the array > > static ObsoleteFlag obsolete_jvm_flags[] = { > > because it's only XX flags that this parses. > > Coleen > > On 6/23/15 9:02 AM, Dmitry Dmitriev wrote: >> Hello David, >> >> Please, see my comments inline. >> >> On 23.06.2015 15:49, David Holmes wrote: >>> Hi Dmitry, >>> >>> On 23/06/2015 8:35 PM, Dmitry Dmitriev wrote: >>>> Hello, >>>> >>>> Please review this small fix which deprecate -Xoss, -Xsqnopause, >>>> -Xoptimize and -Xboundthreads options in JDK 9. Also, I need a sponsor >>>> for this fix, who can push it. >>> >>> I can sponsor this for you. But first ... >> Thank you! >>> >>>> Currently HotSpot silently ignore these 4 options. Here are >>>> description >>>> of these options: >>>> "-Xoss", "-Xsqnopause", "-Xoptimize" - EVM option leaved for >>>> compatibility. From Java 2 SDK for Solaris Developer's Guide: >>>> "Prior to >>>> version 1.3.0, the production releases of the Java 2 SDK for the >>>> Solaris >>>> Operating Environment shipped with a virtual-machine implementation >>>> known as the Exact VM (EVM). Beginning with version 1.3.0, the >>>> Exact VM >>>> is replaced by the Java HotSpot VM.". So, from Java 1.4 EVM is not >>>> used >>>> as VM for JDK on Solaris and these very old flags just silently >>>> ignored >>>> by HotSpot. >>>> "-Xboundthreads" - was used to bind user level threads to kernel >>>> threads >>>> on Solaris in case when new thread library is not available. But >>>> old T1 >>>> libthread has been removed from Solaris in release 10. JDK9 requires >>>> Solaris 10u9 or higher. So, this flag become useless. >>>> >>>> All these options are deprecated, i.e. following warning is printed >>>> when >>>> option is specified: "Java HotSpot(TM) 64-Bit Server VM warning: >>>> Option >>>> -Xoss was deprecated in version 9.0 and will likely be removed in a >>>> future release.". In next major release all these options can be >>>> removed. >>>> >>>> Webrev: http://cr.openjdk.java.net/~ddmitriev/8078399/webrev.00/ >>>> >>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8078399 >>>> Tested: JPRT >>> >>> Can you not add these options to the set of obsolete_flags ? (and >>> delete the code that references them of course) >> Unfortunately, I not understand what set of obsolete flags you mean. >> Do you mean os::obsolete_option method or obsolete_jvm_flags table? >> Since obsolete_jvm_flags is developed for "XX:" options I not see how >> it easily can be done. In case of os::obsolete_option methods then I >> will need to add these options to all implementations. Probably, I >> not understand you correctly. >> >> Thanks, >> Dmitry >> >>> >>> Thanks, >>> David >>> >>>> Thanks, >>>> Dmitry >> > From stefan.karlsson at oracle.com Wed Jun 24 10:59:04 2015 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Wed, 24 Jun 2015 12:59:04 +0200 Subject: RFR: 8087322: Implement a Semaphore utility class In-Reply-To: <55881B78.3040909@oracle.com> References: <557AF8E4.9040804@oracle.com> <557F3582.6060401@oracle.com> <5581B597.5080900@oracle.com> <55836FF2.6070604@oracle.com> <55881B78.3040909@oracle.com> Message-ID: <558A8D78.5000209@oracle.com> Hi all, Updated webrev: http://cr.openjdk.java.net/~stefank/8087322/webrev.04 This patch: - Gets rid of the public inheritance between Semaphore class and the [OS]Semaphore classes. - Semaphore is now a wrapper around the [OS]Semaphore implementation, and only expose a limited API (signal, wait). The OS-specific extensions to the semaphore API is only exposed and implemented in the [OS]Semaphore classes. - Changed back to use a guarantee in the constructor of the [OS]Semaphore classes. - Added more asserts. There are a few pre-existing bugs in the OSX implementation, but it would be good to handle those as separate RFEs. Thanks, StefanK On 2015-06-22 16:28, Stefan Karlsson wrote: > Hi David, > > Updated webrevs: > http://cr.openjdk.java.net/~stefank/8087322/webrev.03.delta > http://cr.openjdk.java.net/~stefank/8087322/webrev.03 > > Comments inlined: > > On 2015-06-19 03:27, David Holmes wrote: >> Hi Stefan, >> >> Sorry for the delay ... >> >> On 18/06/2015 3:59 AM, Stefan Karlsson wrote: >>> Hi again, >>> >>> Here's a version that gets rid of the max parameter: >> >> Great! This is looking really good! > > Thanks. > >> >>> http://cr.openjdk.java.net/~stefank/8087322/webrev.02.delta >>> http://cr.openjdk.java.net/~stefank/8087322/webrev.02 >>> >>> The patch also contains a few minor cleanups and removes the redundant >>> BsdSemaphore::trywait(), which is already defined in PosixSemaphore. >> >> The interaction with the sr_semaphore complicates things. If we push >> its API up to being the Semaphore API then we have to implement >> unused functionality on Windows (and perhaps AIX?). If instead we >> subclass Semaphore to extend the API then we have to duplicate some >> of the code, even across POSIX systems. :( Unfortunate but I don't >> see a better approach than what you have chosen (and the Apple vs >> other-BSD also complicates things). >> >> One thing I am tempted to clean up a little more is the timedwait >> call. PosixSemaphore timedwait takes a timespec to pass to the >> underlying sem_timedwait. But the primary API is timed_wait(long >> secs, int nsecs) which each PosixSemaphore subclass has to add, and >> each then has to perform the "unpackTime" mechanics (which in itself >> is something screaming to be cleaned up). What if PosixSemaphore >> defined: >> >> class PosixSemaphore : public Semaphore { >> public: >> PosixSemaphore(uint value = 0) : Semaphore(value) {} >> >> bool trywait(); >> bool timedwait(unsigned int sec, int nsec); >> >> protected: >> virtual void rel_to_abs_timespec(struct timespec* ts, unsigned int >> sec, int nsec) = 0; >> }; >> >> then: >> >> bool os::PosixSemaphore::timedwait(unsigned int sec, int nsec) { >> struct timespec ts; >> rel_to_abs_timespec(&ts, sec nsecs); >> while (true) { >> int result = sem_timedwait(&_semaphore, &ts); >> ... >> } >> } >> >> and then just define the rel_to_abs_timespec functions for BSD, linux >> and Solaris subclasses. ? > > I did something similar while prototyping alternative implementations > of this. I named the function to PosixSemaphore::create_timespec, but > I can change that name if you want to. > >> --- >> >> The sr_semaphore appears to be being initialized by C++ static >> initialization, which is a concern for me, primarily because >> Semaphore construction requires allocation support (it's a CHeapObj) >> and utilizes NMT. I get very nervous when NMT gets involved prior to >> VM initialization. Can we make sr_semaphore a pointer instead and >> initialize it in one of the os::init methods? > > The current code doesn't use the CHeapObj new operator, so NMT isn't > involved here. I'd prefer if this could be changed as a separate RFE. > >> >> --- >> >> A few specific comments ... >> >> src/os/posix/vm/os_posix.cpp >> >> Two nits that I know have been copied from the existing code: >> >> 1061 while (1) { >> >> I prefer while (true) >> >> 1069 } else { >> 1070 return false; >> 1071 } >> >> This is returning false when an error has occurred. At a minimum >> there should be an assert(false, "...") so that we detect this in >> debug builds. > > Done. > >> >> --- >> >> src/share/vm/utilities/semaphore.hpp >> >> Can we not implement this: >> >> 53 void signal(); >> 54 void signal(uint count); >> >> as simply: >> >> void signal(uint count = 1); >> >> ? > > Done. > >> --- >> >> src/share/vm/utilities/semaphore.cpp: >> >> The logic in test_semaphore_many isn't quite right. For example if >> you call it with value=0, max=2, increment=1, then you will end up >> performing two signals() but only one wait(). > > Fixed. > > Thanks, > StefanK > >> >> Thanks, >> David >> ----- >> >> >>> Thanks, >>> StefanK >>> >>> On 2015-06-15 22:28, Stefan Karlsson wrote: >>>> Hi again, >>>> >>>> I've hopefully addressed some of Kim's and David's concerns with the >>>> following version: >>>> >>>> http://cr.openjdk.java.net/~stefank/8087322/webrev.01.delta/ >>>> http://cr.openjdk.java.net/~stefank/8087322/webrev.01/ >>>> >>>> Changes in the current version of the patch: >>>> >>>> - Created a POSIX version that is used by Linux and Solaris (and maybe >>>> AIX?). >>>> >>>> - Use asserts instead of guarantees. (I've got offline feedback that >>>> others preferred at least some of the guarantees.) >>>> >>>> - Print the errno value and the errno string in the posix version >>>> >>>> - Removed trywait and timedwait from the Semaphore class and added >>>> that functionality in platform-specific semaphore classes. This gets >>>> rid of the Unimplemented() functions in os_windows.cpp. >>>> >>>> - I removed the IMPLEMENTS_SEMAPHORE_CLASS define. >>>> >>>> Some comments about the current patch: >>>> >>>> - I have not removed the 'max' parameter, since I haven't yet figured >>>> out what the max value should be used for windows. >>>> >>>> - OS X doesn't implement unamed POSIX semaphores, so I have to go >>>> through hoops to compile out the POXIS version when building on OS X. >>>> >>>> - I had to add -lrt to get the patch to link on Solaris. >>>> >>>> Tested with JPRT, >>>> >>>> Thanks, >>>> StefanK >>>> >>>> On 2015-06-12 17:21, Stefan Karlsson wrote: >>>>> Hi all, >>>>> >>>>> Please review this patch to create a Semaphore utility class. I need >>>>> this class to implementing faster GC thread synchronization [1]. >>>>> >>>>> http://cr.openjdk.java.net/~stefank/8087322/webrev.00/ >>>>> https://bugs.openjdk.java.net/browse/JDK-8087322 >>>>> >>>>> Some of our platforms already implement a Semaphore class, but those >>>>> classes are hidden inside os_.cpp. I've moved the class >>>>> declaration to semaphore.hpp, but the implementation is left in the >>>>> os_.hpp. I considered creating semaphore_.cpp files, but I >>>>> ended up having to restructure too much code and I wanted to focus on >>>>> the feature in [1] instead. Should I create a RFE to move the >>>>> semaphore implementations? >>>>> >>>>> There seems to be another opportunity to cleanup the code. If we take >>>>> os_linux.cpp, as an example, the code uses both the existing >>>>> Semaphore class and the global ::sem_wait and ::sem_post functions. >>>>> We might want to consider unifying that code. >>>>> >>>>> Since HotSpot is built on platforms that I don't have access to and >>>>> can't test, I've added the IMPLEMENTS_SEMAPHORE_CLASS define. So, >>>>> that I can detect if the the current platform implements the >>>>> Semaphore class, and choose what synchronization primitive to use by >>>>> the GC. >>>>> >>>>> The os_bsd.cpp file has support for "non-apple BSD", but I've only >>>>> tested this patch with OS X. >>>>> >>>>> This patch has been tested in JPRT and our nightly testing together >>>>> with the patches in [1]. The patch also contains a few unit tests in >>>>> semaphore.cpp. >>>>> >>>>> Thanks, >>>>> StefanK >>>>> >>>>> [1] >>>>> http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2015-June/013829.html >>>>> >>>>> >>>> >>> > From coleen.phillimore at oracle.com Wed Jun 24 11:16:32 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 24 Jun 2015 07:16:32 -0400 Subject: RFR (XXS): 8129602: Incorrect GPL header causes RE script to create wrong output In-Reply-To: <558A7F4D.2000406@oracle.com> References: <1435136626.2512.15.camel@oracle.com> <558A7EEB.9040305@oracle.com> <558A7F4D.2000406@oracle.com> Message-ID: <558A9190.4030601@oracle.com> Thomas, This looks good (in case you haven't already pushed it). I think you fixed your removal of the extra blank lines in the final http://cr.openjdk.java.net/~tschatzl/8129602/webrev.8u60/hotspot.patch patch. I'm sorry I didn't address all of these issues when I did the one assigned to me. David pointed the other bugs out to me after I'd started my JPRT job. Now we know something will catch missing , at the end of copyright years. Coleen On 6/24/15 5:58 AM, David Holmes wrote: > Just saw your follow up mail so all is good. > > Thanks, > David > > On 24/06/2015 7:56 PM, David Holmes wrote: >> Hi Thomas, >> >> On 24/06/2015 7:03 PM, Thomas Schatzl wrote: >>> Hi all, >>> >>> I need reviews for a small set of fixes that removes superfluous >>> commas after the year in the GPL header so that some release >>> engineering >>> script does not produce garbage. >> >> Actually add the missing commas where needed :) >> >>> This CR fixes these issues for several files across the hotspot >>> repository, bundling multiple similar problems. That's why this issue >>> has been sent for review to hotspot-dev. >>> >>> CR (confidential, sorry): >>> https://bugs.openjdk.java.net/browse/JDK-8129602 >>> >>> Webrev: >>> http://cr.openjdk.java.net/~tschatzl/8129602/webrev.hotspot/ >> >> You need to look at the patch to see the whitespace fix :) >> >>> http://cr.openjdk.java.net/~tschatzl/8129602/webrev.hs-gc/ (for >>> whitebox.cpp). >> >> Ditto. >> >>> Here is the corresponding 8u60 patch that differs in paths and adds a >>> few more typos that have been fixed in 9. >>> >>> http://cr.openjdk.java.net/~tschatzl/8129602/webrev.8u60/ >> >> This all looks fine too. So the commas are already fixed in 9? >> >> Thanks, >> David >> >>> Thanks, >>> Thomas >>> From coleen.phillimore at oracle.com Wed Jun 24 11:20:53 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 24 Jun 2015 07:20:53 -0400 Subject: RFR [S] 8081406: cleanup and minor extensions of the debugging facilities in CodeStrings In-Reply-To: <558A7C6A.8070502@oracle.com> References: <55674A24.4050501@oracle.com> <5580D094.8060803@oracle.com> <558154D4.8090405@oracle.com> <55824988.2030109@oracle.com> <558A7C6A.8070502@oracle.com> Message-ID: <558A9295.4010909@oracle.com> Bertrand, This looks good. Thank you for removing the extra functions. Coleen On 6/24/15 5:46 AM, Bertrand Delsart wrote: > Hi all, > > To avoid further delays since this is a pre-requisite for the closed > part of 8087333, I've removed the two private accessors I had added: > set_null() and invalidate(). > > They are no longer necessary after the cleanup suggested by David and > their potential added value is currently not worth the concerns around > their proper use :-) > > Updated webrev: > > http://cr.openjdk.java.net/~bdelsart/8081406/webrev.02/ > > Incremental diff: > > diff --git a/src/share/vm/asm/codeBuffer.hpp > b/src/share/vm/asm/codeBuffer.hpp > --- a/src/share/vm/asm/codeBuffer.hpp > +++ b/src/share/vm/asm/codeBuffer.hpp > @@ -264,21 +264,6 @@ > #endif > } > > - void set_null() { > -#ifndef PRODUCT > - _strings = NULL; > -#endif > - } > - > - void invalidate() { > -#ifndef PRODUCT > - assert(is_null(), "Should not invalidate non-empty CodeStrings"); > -#ifdef ASSERT > - _defunct = true; > -#endif > -#endif > - } > - > public: > CodeStrings() { > #ifndef PRODUCT > > Regards, > > Bertrand. > > > On 18/06/2015 06:31, David Holmes wrote: >> On 17/06/2015 9:07 PM, Bertrand Delsart wrote: >>> Thanks David, >>> >>> Updated webrev. See below my inlined comments for additional >>> explanations on the changes. >>> >>> http://cr.openjdk.java.net/~bdelsart/8081406/webrev.01/ >>> >>> This is a subset of the previous changes: >>> - free was reverted to its initial definition but its behavior >>> is now clearly documented (e.g. the fact that it must invalidate >>> the object since this was David's concern) >> >> Okay. I guess there's no point discussing things no longer changed, so >> as long as this works you. >> >>> - assign is nearly reverted too but still ensures _defunct is set >> >> Yep - sorry I got my _defunct comment completely backwards. Doh. >> >> Looks good. >> >> Thanks, >> David >> >> >>> Regards, >>> >>> Bertrand. >>> >>> On 17/06/2015 03:42, David Holmes wrote: >>>> Hi Bertrand, >>>> >>>> On 29/05/2015 3:02 AM, Bertrand Delsart wrote: >>>>> Hi all, >>>>> >>>>> Small RFR to address minor issues in debug mode with CodeStrings >>>> >>>> Not something I'm familiar with so I may be missing some things here. >>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8081406 >>>>> http://cr.openjdk.java.net/~bdelsart/8081406/webrev.00/ >>>>> >>>>> The change does not impact the product mode. >>>> >>>> So the initialization of CodeBlob::_strings and >>>> CodeBuffer::_code_strings does happen in product mode as well, but the >>>> resulting CodeStrings object does nothing. Suggests to me that >>>> *_strings >>>> should be a non-product field only (but that's an aside to this set of >>>> changes). >>>> >>>> src/share/vm/asm/codeBuffer.hpp >>>> >>>> The ifdef style in this file is quite awful IMO but the changes are >>>> consistent with it. >>>> >>>> 308 // FREE strings; invalidate if contains non comment strings. >>>> >>>> if -> if it >>> >>> OK. >>> >>> [ Will in fact just be "invalidate this" due to your other feedback ] >>> >>>> >>>> --- >>>> >>>> src/share/vm/asm/codeBuffer.cpp >>>> >>>> 1105 *this = other; // copy all fields (including _defunct when it >>>> exists) >>>> >>>> I can see the need to free() the existing CodeStrings if present, but >>>> otherwise why does the original logic need to change from: >>>> >>>> _strings = other._strings; >>>> _other.set_null_and_invalidate(); >>>> >>>> to the somewhat cryptic: >>>> >>>> *this = other; >>>> other.set_null_and_invalidate(); >>>> >>>> I'm not even certain what that assignment will do. It's also not clear >>>> why _defunct needs to be copied over rather than just being set to >>>> true >>>> (as _other can't have _defunct==false as we already called >>>> check_valid() ). >>> >>> First, the fields declared in CodeStrings depends on several ifdefs >>> (ASSERT and PRODUCT). "*this=" is a way to avoid the "awful ifdef >>> style" >>> :-) >>> >>> In addition, this is slightly more robust IMHO. For instance, it makes >>> the assignment copy independent of the internals of CodeStrings. In >>> particular, _defunct would have to be set to false, not true :-) >>> >>> Now, I did check that this had not lead to issue in JPRT and with other >>> test in debug mode, including on exotic platforms, but it is impossible >>> to prove that all C++ compilers will handle correctly "*this=" which >>> should just be an assignment copy between two C++ objects (and a NOP in >>> product mode, where the CodeStrings are of size 0). >>> >>> Since this RFR is blocking later pushes, I'll avoid further delays and >>> replace >>> *this = other >>> by : >>> _strings = other._strings >>> #ifdef ASSERT >>> _defunct = false; >>> #endif >>> >>>> The change of semantics of free() does make me concerned whether >>>> existing uses of it now have their assumptions invalidated? It isn't >>>> clear to me why you would want to free() something but retain >>>> validity - >>>> more of a clear()/reset() operation. But then I don't understand the >>>> significance of comment versus non-comment with regards to validity ?? >>> >>> I see your concern about free(). To make that clearer, I added >>> explicitly next to the declaration of free the fact that it invalidates >>> the buffer. >>> >>> My change was initially due to closed code in JDK-8087333 (an RFE >>> concurrently being reviewed). Extending the meaning of _valid had >>> allowed the closed code to be cleaner and more robust, catching errors >>> in the handling on non-comment strings (see below) but this may no >>> longer be necessary. I'll look for an alternate solution if needed (for >>> instance adding a new clear() method; thanks for the suggestion). >>> >>> Reverting free() in the current webrev means I'll also remove from >>> CodeStrings::assign the >>> >>> + if (!is_null()) { >>> + // The assignment replaces the old content. >>> + // Delete old CodeStrings, invalidating it if there are >>> non-comment >>> + // strings. >>> + free(); >>> + check_valid(); // else the container may reference freed strings >>> + } >>> >>> and add back the >>> >>> - assert(is_null(), "Cannot assign onto non-empty CodeStrings"); >>> >>> FYI, some information on the comment versus non-comment. >>> >>> Non-comment strings in CodeStrings are (currently) used only in for >>> debug functionalities (verify_oop, unimplemented, untested, ...) but >>> they are necessary to correctly report errors. If deleted, the VM may >>> crash when trying to print a debug message. Since CodeStrings are >>> embedded into a CodeBlob container, marking the CodeStrings invalid >>> when >>> freed allowed to detect that the CodeBlob was no longer valid. On the >>> other hand, a comment string is something which is not necessary for >>> correct execution. It is only used when dumping the code. >>> >>> Removing a comment from a CodeStrings has no impact on the execution of >>> the Java application... and freeing them was the most efficient way to >>> handle them for JDK-8087333. My change allowed to detect as a side >>> effect of the free whether we had safely deleted only comments or >>> whether there was a non-comment string that had not been properly >>> handled. As stated above, I'll look for an alternative to provide the >>> same robustness without impacting the existing methods, avoiding all >>> risks. >>> >>> Regards, >>> >>> Bertrand. >>> >>>> >>>> Thanks, >>>> David >>>> >>>>> In non product mode, CodeStrings allows to associate a linked list of >>>>> strings to a CodeBuffer, CodeBlob or Stub. In addition, with >>>>> ASSERTS, it >>>>> defines a boolean asserting whether the list of strings are valid. >>>> >>>> >>>> >>>>> Here are the issues addressed by this CR: >>>>> >>>>> - The old code mentioned the fact that CodeStrings was not always >>>>> correctly initialized. This is addressed by the fix, allowing >>>>> check_valid to be added at a few locations where it could currently >>>>> failed due to uninitialized values (like at the beginning of >>>>> CodeStrings::free). This also makes the code more robust against >>>>> future >>>>> versions of CodeStrings. >>>>> >>>>> - As a minor extension, it is now possible for platform dependent >>>>> code >>>>> to modify the comment separator used by print_block_comment, which >>>>> was >>>>> hard coded to " ;; ". >>>>> >>>>> - As another minor extension, related to the validity assertions, >>>>> freeing a code string no longer necessarily marks it (and hence its >>>>> Stub/CodeBlob/CodeBuffer) as invalid. If CodeStrings contains only >>>>> comment, removing them does not change the validity of the >>>>> CodeStrings. >>>>> For similar reason, assignment over a non null CodeStrings is now >>>>> valid >>>>> when we can safely free the old string. >>>>> >>>>> The modified code passes JPRT. It was also validated in fastdebug >>>>> mode >>>>> with the vm.compiler.testlist to check that the validity assertion >>>>> were >>>>> not triggered. One of our closed extensions also validated >>>>> advanced use >>>>> of CodeStrings::assign (included cases where the target of the >>>>> assignment was not free). >>>>> >>>>> Best regards, >>>>> >>>>> Bertrand. >>>>> >>> >>> > > From coleen.phillimore at oracle.com Wed Jun 24 11:34:19 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 24 Jun 2015 07:34:19 -0400 Subject: RFR (XS): 8078399: Deprecate -Xoss, -Xsqnopause, -Xoptimize and -Xboundthreads options in JDK 9 In-Reply-To: <558A88DB.3000504@oracle.com> References: <5589367F.1040800@oracle.com> <558955EA.6020807@oracle.com> <558958FC.4020704@oracle.com> <55899B32.8080707@oracle.com> <558A88DB.3000504@oracle.com> Message-ID: <558A95BB.7000704@oracle.com> Dmitry, Yes, I like this version better also. Thanks, Coleen On 6/24/15 6:39 AM, Dmitry Dmitriev wrote: > Hello Coleen, > > Thank you for review! I address David comments and put updated webrev: > http://cr.openjdk.java.net/~ddmitriev/8078399/webrev.01/ > > > Regards, > Dmitry > > On 23.06.2015 20:45, Coleen Phillimore wrote: >> >> Dmitry, This code looks good to me. Thank you for doing this. >> >> I think you can't add them to the array >> >> static ObsoleteFlag obsolete_jvm_flags[] = { >> >> because it's only XX flags that this parses. >> >> Coleen >> >> On 6/23/15 9:02 AM, Dmitry Dmitriev wrote: >>> Hello David, >>> >>> Please, see my comments inline. >>> >>> On 23.06.2015 15:49, David Holmes wrote: >>>> Hi Dmitry, >>>> >>>> On 23/06/2015 8:35 PM, Dmitry Dmitriev wrote: >>>>> Hello, >>>>> >>>>> Please review this small fix which deprecate -Xoss, -Xsqnopause, >>>>> -Xoptimize and -Xboundthreads options in JDK 9. Also, I need a >>>>> sponsor >>>>> for this fix, who can push it. >>>> >>>> I can sponsor this for you. But first ... >>> Thank you! >>>> >>>>> Currently HotSpot silently ignore these 4 options. Here are >>>>> description >>>>> of these options: >>>>> "-Xoss", "-Xsqnopause", "-Xoptimize" - EVM option leaved for >>>>> compatibility. From Java 2 SDK for Solaris Developer's Guide: >>>>> "Prior to >>>>> version 1.3.0, the production releases of the Java 2 SDK for the >>>>> Solaris >>>>> Operating Environment shipped with a virtual-machine implementation >>>>> known as the Exact VM (EVM). Beginning with version 1.3.0, the >>>>> Exact VM >>>>> is replaced by the Java HotSpot VM.". So, from Java 1.4 EVM is not >>>>> used >>>>> as VM for JDK on Solaris and these very old flags just silently >>>>> ignored >>>>> by HotSpot. >>>>> "-Xboundthreads" - was used to bind user level threads to kernel >>>>> threads >>>>> on Solaris in case when new thread library is not available. But >>>>> old T1 >>>>> libthread has been removed from Solaris in release 10. JDK9 requires >>>>> Solaris 10u9 or higher. So, this flag become useless. >>>>> >>>>> All these options are deprecated, i.e. following warning is >>>>> printed when >>>>> option is specified: "Java HotSpot(TM) 64-Bit Server VM warning: >>>>> Option >>>>> -Xoss was deprecated in version 9.0 and will likely be removed in a >>>>> future release.". In next major release all these options can be >>>>> removed. >>>>> >>>>> Webrev: http://cr.openjdk.java.net/~ddmitriev/8078399/webrev.00/ >>>>> >>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8078399 >>>>> Tested: JPRT >>>> >>>> Can you not add these options to the set of obsolete_flags ? (and >>>> delete the code that references them of course) >>> Unfortunately, I not understand what set of obsolete flags you mean. >>> Do you mean os::obsolete_option method or obsolete_jvm_flags table? >>> Since obsolete_jvm_flags is developed for "XX:" options I not see >>> how it easily can be done. In case of os::obsolete_option methods >>> then I will need to add these options to all implementations. >>> Probably, I not understand you correctly. >>> >>> Thanks, >>> Dmitry >>> >>>> >>>> Thanks, >>>> David >>>> >>>>> Thanks, >>>>> Dmitry >>> >> > From david.holmes at oracle.com Wed Jun 24 11:49:01 2015 From: david.holmes at oracle.com (David Holmes) Date: Wed, 24 Jun 2015 21:49:01 +1000 Subject: RFR (XS): 8078399: Deprecate -Xoss, -Xsqnopause, -Xoptimize and -Xboundthreads options in JDK 9 In-Reply-To: <558A881D.4010304@oracle.com> References: <5589367F.1040800@oracle.com> <558955EA.6020807@oracle.com> <558958FC.4020704@oracle.com> <558A3130.1050303@oracle.com> <558A881D.4010304@oracle.com> Message-ID: <558A992D.1030100@oracle.com> Hi Dmitry, On 24/06/2015 8:36 PM, Dmitry Dmitriev wrote: > Hello David, > > I update code and now print similar message and use JVM_Version. Thank you! > > Webrev.01: http://cr.openjdk.java.net/~ddmitriev/8078399/webrev.01/ > > > Now warning message looks like this: > Java HotSpot(TM) 64-Bit Server VM warning: ignoring option -Xoss; > support was removed in 9.0 > > This message have small difference with "-XX" options: "-XX" option > strip "-XX:", but I print full optionString. But I can remove "-X" and > just print option name(e.g. "oss") by passing "option->optionString + 2" > to the warning function. What you think about that? I actually prefer to see -Xoss versus oss. :) This looks good to me. We'll let Coleen take a second look and I'll push it in my morning. Thanks, David > Thank you, > Dmitry > > > On 24.06.2015 7:25, David Holmes wrote: >> Hi Dmitry, >> >> On 23/06/2015 11:02 PM, Dmitry Dmitriev wrote: >>> Hello David, >>> >>> Please, see my comments inline. >>> >>> On 23.06.2015 15:49, David Holmes wrote: >>>> Hi Dmitry, >>>> >>>> On 23/06/2015 8:35 PM, Dmitry Dmitriev wrote: >>>>> Hello, >>>>> >>>>> Please review this small fix which deprecate -Xoss, -Xsqnopause, >>>>> -Xoptimize and -Xboundthreads options in JDK 9. Also, I need a sponsor >>>>> for this fix, who can push it. >>>> >>>> I can sponsor this for you. But first ... >>> Thank you! >>>> >>>>> Currently HotSpot silently ignore these 4 options. Here are >>>>> description >>>>> of these options: >>>>> "-Xoss", "-Xsqnopause", "-Xoptimize" - EVM option leaved for >>>>> compatibility. From Java 2 SDK for Solaris Developer's Guide: >>>>> "Prior to >>>>> version 1.3.0, the production releases of the Java 2 SDK for the >>>>> Solaris >>>>> Operating Environment shipped with a virtual-machine implementation >>>>> known as the Exact VM (EVM). Beginning with version 1.3.0, the >>>>> Exact VM >>>>> is replaced by the Java HotSpot VM.". So, from Java 1.4 EVM is not >>>>> used >>>>> as VM for JDK on Solaris and these very old flags just silently >>>>> ignored >>>>> by HotSpot. >>>>> "-Xboundthreads" - was used to bind user level threads to kernel >>>>> threads >>>>> on Solaris in case when new thread library is not available. But >>>>> old T1 >>>>> libthread has been removed from Solaris in release 10. JDK9 requires >>>>> Solaris 10u9 or higher. So, this flag become useless. >>>>> >>>>> All these options are deprecated, i.e. following warning is printed >>>>> when >>>>> option is specified: "Java HotSpot(TM) 64-Bit Server VM warning: >>>>> Option >>>>> -Xoss was deprecated in version 9.0 and will likely be removed in a >>>>> future release.". In next major release all these options can be >>>>> removed. >>>>> >>>>> Webrev: http://cr.openjdk.java.net/~ddmitriev/8078399/webrev.00/ >>>>> >>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8078399 >>>>> Tested: JPRT >>>> >>>> Can you not add these options to the set of obsolete_flags ? (and >>>> delete the code that references them of course) >>> Unfortunately, I not understand what set of obsolete flags you mean. Do >>> you mean os::obsolete_option method or obsolete_jvm_flags table? Since >>> obsolete_jvm_flags is developed for "XX:" options I not see how it >>> easily can be done. In case of os::obsolete_option methods then I will >>> need to add these options to all implementations. Probably, I not >>> understand you correctly. >> >> It was the obsolete_jvm_flags table I meant - sorry about the typo. >> Pity it doesn't support -X options. :( >> >> My only suggestion here is to at least use the same warning message as >> would be seen for obsolete -XX flags (something I should have >> suggested when reviewing the CCC request): >> >> warning("ignoring option %s; support was removed in %s", >> stripped_argname, version); >> >> ref: >> >> > java -XX:+UseOldInlining -version >> Java HotSpot(TM) Server VM warning: ignoring option UseOldInlining; >> support was removed in 9.0 >> >> vs >> >> > java -Xoss -version >> Java HotSpot(TM) Server VM warning: Option -Xoss was deprecated in >> version 9.0 and will likely be removed in a future release. >> >> >> and if you use an actual JVM_Version then this won't need to be >> updated when the new version string comes in. :) >> >> Thanks, >> David >> >>> Thanks, >>> Dmitry >>> >>>> >>>> Thanks, >>>> David >>>> >>>>> Thanks, >>>>> Dmitry >>> > From david.holmes at oracle.com Wed Jun 24 11:51:35 2015 From: david.holmes at oracle.com (David Holmes) Date: Wed, 24 Jun 2015 21:51:35 +1000 Subject: RFR [S] 8081406: cleanup and minor extensions of the debugging facilities in CodeStrings In-Reply-To: <558A7C6A.8070502@oracle.com> References: <55674A24.4050501@oracle.com> <5580D094.8060803@oracle.com> <558154D4.8090405@oracle.com> <55824988.2030109@oracle.com> <558A7C6A.8070502@oracle.com> Message-ID: <558A99C7.4040006@oracle.com> Still seems fine to me. Thanks, David On 24/06/2015 7:46 PM, Bertrand Delsart wrote: > Hi all, > > To avoid further delays since this is a pre-requisite for the closed > part of 8087333, I've removed the two private accessors I had added: > set_null() and invalidate(). > > They are no longer necessary after the cleanup suggested by David and > their potential added value is currently not worth the concerns around > their proper use :-) > > Updated webrev: > > http://cr.openjdk.java.net/~bdelsart/8081406/webrev.02/ > > Incremental diff: > > diff --git a/src/share/vm/asm/codeBuffer.hpp > b/src/share/vm/asm/codeBuffer.hpp > --- a/src/share/vm/asm/codeBuffer.hpp > +++ b/src/share/vm/asm/codeBuffer.hpp > @@ -264,21 +264,6 @@ > #endif > } > > - void set_null() { > -#ifndef PRODUCT > - _strings = NULL; > -#endif > - } > - > - void invalidate() { > -#ifndef PRODUCT > - assert(is_null(), "Should not invalidate non-empty CodeStrings"); > -#ifdef ASSERT > - _defunct = true; > -#endif > -#endif > - } > - > public: > CodeStrings() { > #ifndef PRODUCT > > Regards, > > Bertrand. > > > On 18/06/2015 06:31, David Holmes wrote: >> On 17/06/2015 9:07 PM, Bertrand Delsart wrote: >>> Thanks David, >>> >>> Updated webrev. See below my inlined comments for additional >>> explanations on the changes. >>> >>> http://cr.openjdk.java.net/~bdelsart/8081406/webrev.01/ >>> >>> This is a subset of the previous changes: >>> - free was reverted to its initial definition but its behavior >>> is now clearly documented (e.g. the fact that it must invalidate >>> the object since this was David's concern) >> >> Okay. I guess there's no point discussing things no longer changed, so >> as long as this works you. >> >>> - assign is nearly reverted too but still ensures _defunct is set >> >> Yep - sorry I got my _defunct comment completely backwards. Doh. >> >> Looks good. >> >> Thanks, >> David >> >> >>> Regards, >>> >>> Bertrand. >>> >>> On 17/06/2015 03:42, David Holmes wrote: >>>> Hi Bertrand, >>>> >>>> On 29/05/2015 3:02 AM, Bertrand Delsart wrote: >>>>> Hi all, >>>>> >>>>> Small RFR to address minor issues in debug mode with CodeStrings >>>> >>>> Not something I'm familiar with so I may be missing some things here. >>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8081406 >>>>> http://cr.openjdk.java.net/~bdelsart/8081406/webrev.00/ >>>>> >>>>> The change does not impact the product mode. >>>> >>>> So the initialization of CodeBlob::_strings and >>>> CodeBuffer::_code_strings does happen in product mode as well, but the >>>> resulting CodeStrings object does nothing. Suggests to me that >>>> *_strings >>>> should be a non-product field only (but that's an aside to this set of >>>> changes). >>>> >>>> src/share/vm/asm/codeBuffer.hpp >>>> >>>> The ifdef style in this file is quite awful IMO but the changes are >>>> consistent with it. >>>> >>>> 308 // FREE strings; invalidate if contains non comment strings. >>>> >>>> if -> if it >>> >>> OK. >>> >>> [ Will in fact just be "invalidate this" due to your other feedback ] >>> >>>> >>>> --- >>>> >>>> src/share/vm/asm/codeBuffer.cpp >>>> >>>> 1105 *this = other; // copy all fields (including _defunct when it >>>> exists) >>>> >>>> I can see the need to free() the existing CodeStrings if present, but >>>> otherwise why does the original logic need to change from: >>>> >>>> _strings = other._strings; >>>> _other.set_null_and_invalidate(); >>>> >>>> to the somewhat cryptic: >>>> >>>> *this = other; >>>> other.set_null_and_invalidate(); >>>> >>>> I'm not even certain what that assignment will do. It's also not clear >>>> why _defunct needs to be copied over rather than just being set to true >>>> (as _other can't have _defunct==false as we already called >>>> check_valid() ). >>> >>> First, the fields declared in CodeStrings depends on several ifdefs >>> (ASSERT and PRODUCT). "*this=" is a way to avoid the "awful ifdef style" >>> :-) >>> >>> In addition, this is slightly more robust IMHO. For instance, it makes >>> the assignment copy independent of the internals of CodeStrings. In >>> particular, _defunct would have to be set to false, not true :-) >>> >>> Now, I did check that this had not lead to issue in JPRT and with other >>> test in debug mode, including on exotic platforms, but it is impossible >>> to prove that all C++ compilers will handle correctly "*this=" which >>> should just be an assignment copy between two C++ objects (and a NOP in >>> product mode, where the CodeStrings are of size 0). >>> >>> Since this RFR is blocking later pushes, I'll avoid further delays and >>> replace >>> *this = other >>> by : >>> _strings = other._strings >>> #ifdef ASSERT >>> _defunct = false; >>> #endif >>> >>>> The change of semantics of free() does make me concerned whether >>>> existing uses of it now have their assumptions invalidated? It isn't >>>> clear to me why you would want to free() something but retain >>>> validity - >>>> more of a clear()/reset() operation. But then I don't understand the >>>> significance of comment versus non-comment with regards to validity ?? >>> >>> I see your concern about free(). To make that clearer, I added >>> explicitly next to the declaration of free the fact that it invalidates >>> the buffer. >>> >>> My change was initially due to closed code in JDK-8087333 (an RFE >>> concurrently being reviewed). Extending the meaning of _valid had >>> allowed the closed code to be cleaner and more robust, catching errors >>> in the handling on non-comment strings (see below) but this may no >>> longer be necessary. I'll look for an alternate solution if needed (for >>> instance adding a new clear() method; thanks for the suggestion). >>> >>> Reverting free() in the current webrev means I'll also remove from >>> CodeStrings::assign the >>> >>> + if (!is_null()) { >>> + // The assignment replaces the old content. >>> + // Delete old CodeStrings, invalidating it if there are non-comment >>> + // strings. >>> + free(); >>> + check_valid(); // else the container may reference freed strings >>> + } >>> >>> and add back the >>> >>> - assert(is_null(), "Cannot assign onto non-empty CodeStrings"); >>> >>> FYI, some information on the comment versus non-comment. >>> >>> Non-comment strings in CodeStrings are (currently) used only in for >>> debug functionalities (verify_oop, unimplemented, untested, ...) but >>> they are necessary to correctly report errors. If deleted, the VM may >>> crash when trying to print a debug message. Since CodeStrings are >>> embedded into a CodeBlob container, marking the CodeStrings invalid when >>> freed allowed to detect that the CodeBlob was no longer valid. On the >>> other hand, a comment string is something which is not necessary for >>> correct execution. It is only used when dumping the code. >>> >>> Removing a comment from a CodeStrings has no impact on the execution of >>> the Java application... and freeing them was the most efficient way to >>> handle them for JDK-8087333. My change allowed to detect as a side >>> effect of the free whether we had safely deleted only comments or >>> whether there was a non-comment string that had not been properly >>> handled. As stated above, I'll look for an alternative to provide the >>> same robustness without impacting the existing methods, avoiding all >>> risks. >>> >>> Regards, >>> >>> Bertrand. >>> >>>> >>>> Thanks, >>>> David >>>> >>>>> In non product mode, CodeStrings allows to associate a linked list of >>>>> strings to a CodeBuffer, CodeBlob or Stub. In addition, with >>>>> ASSERTS, it >>>>> defines a boolean asserting whether the list of strings are valid. >>>> >>>> >>>> >>>>> Here are the issues addressed by this CR: >>>>> >>>>> - The old code mentioned the fact that CodeStrings was not always >>>>> correctly initialized. This is addressed by the fix, allowing >>>>> check_valid to be added at a few locations where it could currently >>>>> failed due to uninitialized values (like at the beginning of >>>>> CodeStrings::free). This also makes the code more robust against >>>>> future >>>>> versions of CodeStrings. >>>>> >>>>> - As a minor extension, it is now possible for platform dependent code >>>>> to modify the comment separator used by print_block_comment, which was >>>>> hard coded to " ;; ". >>>>> >>>>> - As another minor extension, related to the validity assertions, >>>>> freeing a code string no longer necessarily marks it (and hence its >>>>> Stub/CodeBlob/CodeBuffer) as invalid. If CodeStrings contains only >>>>> comment, removing them does not change the validity of the >>>>> CodeStrings. >>>>> For similar reason, assignment over a non null CodeStrings is now >>>>> valid >>>>> when we can safely free the old string. >>>>> >>>>> The modified code passes JPRT. It was also validated in fastdebug mode >>>>> with the vm.compiler.testlist to check that the validity assertion >>>>> were >>>>> not triggered. One of our closed extensions also validated advanced >>>>> use >>>>> of CodeStrings::assign (included cases where the target of the >>>>> assignment was not free). >>>>> >>>>> Best regards, >>>>> >>>>> Bertrand. >>>>> >>> >>> > > From david.holmes at oracle.com Wed Jun 24 11:53:48 2015 From: david.holmes at oracle.com (David Holmes) Date: Wed, 24 Jun 2015 21:53:48 +1000 Subject: RFR (XS): 8078399: Deprecate -Xoss, -Xsqnopause, -Xoptimize and -Xboundthreads options in JDK 9 In-Reply-To: <558A992D.1030100@oracle.com> References: <5589367F.1040800@oracle.com> <558955EA.6020807@oracle.com> <558958FC.4020704@oracle.com> <558A3130.1050303@oracle.com> <558A881D.4010304@oracle.com> <558A992D.1030100@oracle.com> Message-ID: <558A9A4C.3090302@oracle.com> On 24/06/2015 9:49 PM, David Holmes wrote: > Hi Dmitry, > > On 24/06/2015 8:36 PM, Dmitry Dmitriev wrote: >> Hello David, >> >> I update code and now print similar message and use JVM_Version. Thank >> you! >> >> Webrev.01: http://cr.openjdk.java.net/~ddmitriev/8078399/webrev.01/ >> >> >> Now warning message looks like this: >> Java HotSpot(TM) 64-Bit Server VM warning: ignoring option -Xoss; >> support was removed in 9.0 >> >> This message have small difference with "-XX" options: "-XX" option >> strip "-XX:", but I print full optionString. But I can remove "-X" and >> just print option name(e.g. "oss") by passing "option->optionString + 2" >> to the warning function. What you think about that? > > I actually prefer to see -Xoss versus oss. :) > > This looks good to me. We'll let Coleen take a second look and I'll > push it in my morning. Ah I see she was looking at the same time :) Cheers, David > Thanks, > David > >> Thank you, >> Dmitry >> >> >> On 24.06.2015 7:25, David Holmes wrote: >>> Hi Dmitry, >>> >>> On 23/06/2015 11:02 PM, Dmitry Dmitriev wrote: >>>> Hello David, >>>> >>>> Please, see my comments inline. >>>> >>>> On 23.06.2015 15:49, David Holmes wrote: >>>>> Hi Dmitry, >>>>> >>>>> On 23/06/2015 8:35 PM, Dmitry Dmitriev wrote: >>>>>> Hello, >>>>>> >>>>>> Please review this small fix which deprecate -Xoss, -Xsqnopause, >>>>>> -Xoptimize and -Xboundthreads options in JDK 9. Also, I need a >>>>>> sponsor >>>>>> for this fix, who can push it. >>>>> >>>>> I can sponsor this for you. But first ... >>>> Thank you! >>>>> >>>>>> Currently HotSpot silently ignore these 4 options. Here are >>>>>> description >>>>>> of these options: >>>>>> "-Xoss", "-Xsqnopause", "-Xoptimize" - EVM option leaved for >>>>>> compatibility. From Java 2 SDK for Solaris Developer's Guide: >>>>>> "Prior to >>>>>> version 1.3.0, the production releases of the Java 2 SDK for the >>>>>> Solaris >>>>>> Operating Environment shipped with a virtual-machine implementation >>>>>> known as the Exact VM (EVM). Beginning with version 1.3.0, the >>>>>> Exact VM >>>>>> is replaced by the Java HotSpot VM.". So, from Java 1.4 EVM is not >>>>>> used >>>>>> as VM for JDK on Solaris and these very old flags just silently >>>>>> ignored >>>>>> by HotSpot. >>>>>> "-Xboundthreads" - was used to bind user level threads to kernel >>>>>> threads >>>>>> on Solaris in case when new thread library is not available. But >>>>>> old T1 >>>>>> libthread has been removed from Solaris in release 10. JDK9 requires >>>>>> Solaris 10u9 or higher. So, this flag become useless. >>>>>> >>>>>> All these options are deprecated, i.e. following warning is printed >>>>>> when >>>>>> option is specified: "Java HotSpot(TM) 64-Bit Server VM warning: >>>>>> Option >>>>>> -Xoss was deprecated in version 9.0 and will likely be removed in a >>>>>> future release.". In next major release all these options can be >>>>>> removed. >>>>>> >>>>>> Webrev: http://cr.openjdk.java.net/~ddmitriev/8078399/webrev.00/ >>>>>> >>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8078399 >>>>>> Tested: JPRT >>>>> >>>>> Can you not add these options to the set of obsolete_flags ? (and >>>>> delete the code that references them of course) >>>> Unfortunately, I not understand what set of obsolete flags you mean. Do >>>> you mean os::obsolete_option method or obsolete_jvm_flags table? Since >>>> obsolete_jvm_flags is developed for "XX:" options I not see how it >>>> easily can be done. In case of os::obsolete_option methods then I will >>>> need to add these options to all implementations. Probably, I not >>>> understand you correctly. >>> >>> It was the obsolete_jvm_flags table I meant - sorry about the typo. >>> Pity it doesn't support -X options. :( >>> >>> My only suggestion here is to at least use the same warning message as >>> would be seen for obsolete -XX flags (something I should have >>> suggested when reviewing the CCC request): >>> >>> warning("ignoring option %s; support was removed in %s", >>> stripped_argname, version); >>> >>> ref: >>> >>> > java -XX:+UseOldInlining -version >>> Java HotSpot(TM) Server VM warning: ignoring option UseOldInlining; >>> support was removed in 9.0 >>> >>> vs >>> >>> > java -Xoss -version >>> Java HotSpot(TM) Server VM warning: Option -Xoss was deprecated in >>> version 9.0 and will likely be removed in a future release. >>> >>> >>> and if you use an actual JVM_Version then this won't need to be >>> updated when the new version string comes in. :) >>> >>> Thanks, >>> David >>> >>>> Thanks, >>>> Dmitry >>>> >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>>> Thanks, >>>>>> Dmitry >>>> >> From dmitry.dmitriev at oracle.com Wed Jun 24 12:07:24 2015 From: dmitry.dmitriev at oracle.com (Dmitry Dmitriev) Date: Wed, 24 Jun 2015 15:07:24 +0300 Subject: RFR (XS): 8129394: [TESTBUG] runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java failed with double option Message-ID: <558A9D7C.6000507@oracle.com> Hello, Please review this small fix(2 lines changed) for recently added Command Line Option Validation tests. The problem was found in test framework code for double options. String.format("%f") was used to format double value and it depends on current locale. Thus, on some locales the resulting string with double value looks like: 0,999 (with comma) and JVM reports an error when trying to parse double command line option with such value. In this fix I explicitly add Locale.US to the String.format: String.format(Locale.US, "%f", value); Webrev: http://cr.openjdk.java.net/~ddmitriev/8129394/webrev.00/ JBS: https://bugs.openjdk.java.net/browse/JDK-8129394 Tested: locally ran with different locale - pass with the fix and fail without fix, JPRT. Thanks, Dmitry From bertrand.delsart at oracle.com Wed Jun 24 12:10:50 2015 From: bertrand.delsart at oracle.com (Bertrand Delsart) Date: Wed, 24 Jun 2015 14:10:50 +0200 Subject: RFR [S] 8081406: cleanup and minor extensions of the debugging facilities in CodeStrings In-Reply-To: <558A9295.4010909@oracle.com> References: <55674A24.4050501@oracle.com> <5580D094.8060803@oracle.com> <558154D4.8090405@oracle.com> <55824988.2030109@oracle.com> <558A7C6A.8070502@oracle.com> <558A9295.4010909@oracle.com> Message-ID: <558A9E4A.7070702@oracle.com> You're welcome. Thanks again Coleen and David. Bertrand. On 24/06/2015 13:20, Coleen Phillimore wrote: > Bertrand, This looks good. Thank you for removing the extra functions. > > Coleen > > On 6/24/15 5:46 AM, Bertrand Delsart wrote: >> Hi all, >> >> To avoid further delays since this is a pre-requisite for the closed >> part of 8087333, I've removed the two private accessors I had added: >> set_null() and invalidate(). >> >> They are no longer necessary after the cleanup suggested by David and >> their potential added value is currently not worth the concerns around >> their proper use :-) >> >> Updated webrev: >> >> http://cr.openjdk.java.net/~bdelsart/8081406/webrev.02/ >> >> Incremental diff: >> >> diff --git a/src/share/vm/asm/codeBuffer.hpp >> b/src/share/vm/asm/codeBuffer.hpp >> --- a/src/share/vm/asm/codeBuffer.hpp >> +++ b/src/share/vm/asm/codeBuffer.hpp >> @@ -264,21 +264,6 @@ >> #endif >> } >> >> - void set_null() { >> -#ifndef PRODUCT >> - _strings = NULL; >> -#endif >> - } >> - >> - void invalidate() { >> -#ifndef PRODUCT >> - assert(is_null(), "Should not invalidate non-empty CodeStrings"); >> -#ifdef ASSERT >> - _defunct = true; >> -#endif >> -#endif >> - } >> - >> public: >> CodeStrings() { >> #ifndef PRODUCT >> >> Regards, >> >> Bertrand. >> >> >> On 18/06/2015 06:31, David Holmes wrote: >>> On 17/06/2015 9:07 PM, Bertrand Delsart wrote: >>>> Thanks David, >>>> >>>> Updated webrev. See below my inlined comments for additional >>>> explanations on the changes. >>>> >>>> http://cr.openjdk.java.net/~bdelsart/8081406/webrev.01/ >>>> >>>> This is a subset of the previous changes: >>>> - free was reverted to its initial definition but its behavior >>>> is now clearly documented (e.g. the fact that it must invalidate >>>> the object since this was David's concern) >>> >>> Okay. I guess there's no point discussing things no longer changed, so >>> as long as this works you. >>> >>>> - assign is nearly reverted too but still ensures _defunct is set >>> >>> Yep - sorry I got my _defunct comment completely backwards. Doh. >>> >>> Looks good. >>> >>> Thanks, >>> David >>> >>> >>>> Regards, >>>> >>>> Bertrand. >>>> >>>> On 17/06/2015 03:42, David Holmes wrote: >>>>> Hi Bertrand, >>>>> >>>>> On 29/05/2015 3:02 AM, Bertrand Delsart wrote: >>>>>> Hi all, >>>>>> >>>>>> Small RFR to address minor issues in debug mode with CodeStrings >>>>> >>>>> Not something I'm familiar with so I may be missing some things here. >>>>> >>>>>> https://bugs.openjdk.java.net/browse/JDK-8081406 >>>>>> http://cr.openjdk.java.net/~bdelsart/8081406/webrev.00/ >>>>>> >>>>>> The change does not impact the product mode. >>>>> >>>>> So the initialization of CodeBlob::_strings and >>>>> CodeBuffer::_code_strings does happen in product mode as well, but the >>>>> resulting CodeStrings object does nothing. Suggests to me that >>>>> *_strings >>>>> should be a non-product field only (but that's an aside to this set of >>>>> changes). >>>>> >>>>> src/share/vm/asm/codeBuffer.hpp >>>>> >>>>> The ifdef style in this file is quite awful IMO but the changes are >>>>> consistent with it. >>>>> >>>>> 308 // FREE strings; invalidate if contains non comment strings. >>>>> >>>>> if -> if it >>>> >>>> OK. >>>> >>>> [ Will in fact just be "invalidate this" due to your other feedback ] >>>> >>>>> >>>>> --- >>>>> >>>>> src/share/vm/asm/codeBuffer.cpp >>>>> >>>>> 1105 *this = other; // copy all fields (including _defunct when it >>>>> exists) >>>>> >>>>> I can see the need to free() the existing CodeStrings if present, but >>>>> otherwise why does the original logic need to change from: >>>>> >>>>> _strings = other._strings; >>>>> _other.set_null_and_invalidate(); >>>>> >>>>> to the somewhat cryptic: >>>>> >>>>> *this = other; >>>>> other.set_null_and_invalidate(); >>>>> >>>>> I'm not even certain what that assignment will do. It's also not clear >>>>> why _defunct needs to be copied over rather than just being set to >>>>> true >>>>> (as _other can't have _defunct==false as we already called >>>>> check_valid() ). >>>> >>>> First, the fields declared in CodeStrings depends on several ifdefs >>>> (ASSERT and PRODUCT). "*this=" is a way to avoid the "awful ifdef >>>> style" >>>> :-) >>>> >>>> In addition, this is slightly more robust IMHO. For instance, it makes >>>> the assignment copy independent of the internals of CodeStrings. In >>>> particular, _defunct would have to be set to false, not true :-) >>>> >>>> Now, I did check that this had not lead to issue in JPRT and with other >>>> test in debug mode, including on exotic platforms, but it is impossible >>>> to prove that all C++ compilers will handle correctly "*this=" which >>>> should just be an assignment copy between two C++ objects (and a NOP in >>>> product mode, where the CodeStrings are of size 0). >>>> >>>> Since this RFR is blocking later pushes, I'll avoid further delays and >>>> replace >>>> *this = other >>>> by : >>>> _strings = other._strings >>>> #ifdef ASSERT >>>> _defunct = false; >>>> #endif >>>> >>>>> The change of semantics of free() does make me concerned whether >>>>> existing uses of it now have their assumptions invalidated? It isn't >>>>> clear to me why you would want to free() something but retain >>>>> validity - >>>>> more of a clear()/reset() operation. But then I don't understand the >>>>> significance of comment versus non-comment with regards to validity ?? >>>> >>>> I see your concern about free(). To make that clearer, I added >>>> explicitly next to the declaration of free the fact that it invalidates >>>> the buffer. >>>> >>>> My change was initially due to closed code in JDK-8087333 (an RFE >>>> concurrently being reviewed). Extending the meaning of _valid had >>>> allowed the closed code to be cleaner and more robust, catching errors >>>> in the handling on non-comment strings (see below) but this may no >>>> longer be necessary. I'll look for an alternate solution if needed (for >>>> instance adding a new clear() method; thanks for the suggestion). >>>> >>>> Reverting free() in the current webrev means I'll also remove from >>>> CodeStrings::assign the >>>> >>>> + if (!is_null()) { >>>> + // The assignment replaces the old content. >>>> + // Delete old CodeStrings, invalidating it if there are >>>> non-comment >>>> + // strings. >>>> + free(); >>>> + check_valid(); // else the container may reference freed strings >>>> + } >>>> >>>> and add back the >>>> >>>> - assert(is_null(), "Cannot assign onto non-empty CodeStrings"); >>>> >>>> FYI, some information on the comment versus non-comment. >>>> >>>> Non-comment strings in CodeStrings are (currently) used only in for >>>> debug functionalities (verify_oop, unimplemented, untested, ...) but >>>> they are necessary to correctly report errors. If deleted, the VM may >>>> crash when trying to print a debug message. Since CodeStrings are >>>> embedded into a CodeBlob container, marking the CodeStrings invalid >>>> when >>>> freed allowed to detect that the CodeBlob was no longer valid. On the >>>> other hand, a comment string is something which is not necessary for >>>> correct execution. It is only used when dumping the code. >>>> >>>> Removing a comment from a CodeStrings has no impact on the execution of >>>> the Java application... and freeing them was the most efficient way to >>>> handle them for JDK-8087333. My change allowed to detect as a side >>>> effect of the free whether we had safely deleted only comments or >>>> whether there was a non-comment string that had not been properly >>>> handled. As stated above, I'll look for an alternative to provide the >>>> same robustness without impacting the existing methods, avoiding all >>>> risks. >>>> >>>> Regards, >>>> >>>> Bertrand. >>>> >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>>> In non product mode, CodeStrings allows to associate a linked list of >>>>>> strings to a CodeBuffer, CodeBlob or Stub. In addition, with >>>>>> ASSERTS, it >>>>>> defines a boolean asserting whether the list of strings are valid. >>>>> >>>>> >>>>> >>>>>> Here are the issues addressed by this CR: >>>>>> >>>>>> - The old code mentioned the fact that CodeStrings was not always >>>>>> correctly initialized. This is addressed by the fix, allowing >>>>>> check_valid to be added at a few locations where it could currently >>>>>> failed due to uninitialized values (like at the beginning of >>>>>> CodeStrings::free). This also makes the code more robust against >>>>>> future >>>>>> versions of CodeStrings. >>>>>> >>>>>> - As a minor extension, it is now possible for platform dependent >>>>>> code >>>>>> to modify the comment separator used by print_block_comment, which >>>>>> was >>>>>> hard coded to " ;; ". >>>>>> >>>>>> - As another minor extension, related to the validity assertions, >>>>>> freeing a code string no longer necessarily marks it (and hence its >>>>>> Stub/CodeBlob/CodeBuffer) as invalid. If CodeStrings contains only >>>>>> comment, removing them does not change the validity of the >>>>>> CodeStrings. >>>>>> For similar reason, assignment over a non null CodeStrings is now >>>>>> valid >>>>>> when we can safely free the old string. >>>>>> >>>>>> The modified code passes JPRT. It was also validated in fastdebug >>>>>> mode >>>>>> with the vm.compiler.testlist to check that the validity assertion >>>>>> were >>>>>> not triggered. One of our closed extensions also validated >>>>>> advanced use >>>>>> of CodeStrings::assign (included cases where the target of the >>>>>> assignment was not free). >>>>>> >>>>>> Best regards, >>>>>> >>>>>> Bertrand. >>>>>> >>>> >>>> >> >> > -- Bertrand Delsart, Grenoble Engineering Center Oracle, 180 av. de l'Europe, ZIRST de Montbonnot 38330 Montbonnot Saint Martin, FRANCE bertrand.delsart at oracle.com Phone : +33 4 76 18 81 23 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From david.holmes at oracle.com Wed Jun 24 12:10:50 2015 From: david.holmes at oracle.com (David Holmes) Date: Wed, 24 Jun 2015 22:10:50 +1000 Subject: RFR: 8087322: Implement a Semaphore utility class In-Reply-To: <558A8D78.5000209@oracle.com> References: <557AF8E4.9040804@oracle.com> <557F3582.6060401@oracle.com> <5581B597.5080900@oracle.com> <55836FF2.6070604@oracle.com> <55881B78.3040909@oracle.com> <558A8D78.5000209@oracle.com> Message-ID: <558A9E4A.50304@oracle.com> Hi Stefan, On 24/06/2015 8:59 PM, Stefan Karlsson wrote: > Hi all, > > Updated webrev: > http://cr.openjdk.java.net/~stefank/8087322/webrev.04 This looks good to me. > This patch: > > - Gets rid of the public inheritance between Semaphore class and the > [OS]Semaphore classes. > > - Semaphore is now a wrapper around the [OS]Semaphore implementation, > and only expose a limited API (signal, wait). The OS-specific extensions > to the semaphore API is only exposed and implemented in the > [OS]Semaphore classes. > > - Changed back to use a guarantee in the constructor of the > [OS]Semaphore classes. > > - Added more asserts. > > There are a few pre-existing bugs in the OSX implementation, but it > would be good to handle those as separate RFEs. Agreed. Thanks for all your work and perseverance on this. David > Thanks, > StefanK > > On 2015-06-22 16:28, Stefan Karlsson wrote: >> Hi David, >> >> Updated webrevs: >> http://cr.openjdk.java.net/~stefank/8087322/webrev.03.delta >> http://cr.openjdk.java.net/~stefank/8087322/webrev.03 >> >> Comments inlined: >> >> On 2015-06-19 03:27, David Holmes wrote: >>> Hi Stefan, >>> >>> Sorry for the delay ... >>> >>> On 18/06/2015 3:59 AM, Stefan Karlsson wrote: >>>> Hi again, >>>> >>>> Here's a version that gets rid of the max parameter: >>> >>> Great! This is looking really good! >> >> Thanks. >> >>> >>>> http://cr.openjdk.java.net/~stefank/8087322/webrev.02.delta >>>> http://cr.openjdk.java.net/~stefank/8087322/webrev.02 >>>> >>>> The patch also contains a few minor cleanups and removes the redundant >>>> BsdSemaphore::trywait(), which is already defined in PosixSemaphore. >>> >>> The interaction with the sr_semaphore complicates things. If we push >>> its API up to being the Semaphore API then we have to implement >>> unused functionality on Windows (and perhaps AIX?). If instead we >>> subclass Semaphore to extend the API then we have to duplicate some >>> of the code, even across POSIX systems. :( Unfortunate but I don't >>> see a better approach than what you have chosen (and the Apple vs >>> other-BSD also complicates things). >>> >>> One thing I am tempted to clean up a little more is the timedwait >>> call. PosixSemaphore timedwait takes a timespec to pass to the >>> underlying sem_timedwait. But the primary API is timed_wait(long >>> secs, int nsecs) which each PosixSemaphore subclass has to add, and >>> each then has to perform the "unpackTime" mechanics (which in itself >>> is something screaming to be cleaned up). What if PosixSemaphore >>> defined: >>> >>> class PosixSemaphore : public Semaphore { >>> public: >>> PosixSemaphore(uint value = 0) : Semaphore(value) {} >>> >>> bool trywait(); >>> bool timedwait(unsigned int sec, int nsec); >>> >>> protected: >>> virtual void rel_to_abs_timespec(struct timespec* ts, unsigned int >>> sec, int nsec) = 0; >>> }; >>> >>> then: >>> >>> bool os::PosixSemaphore::timedwait(unsigned int sec, int nsec) { >>> struct timespec ts; >>> rel_to_abs_timespec(&ts, sec nsecs); >>> while (true) { >>> int result = sem_timedwait(&_semaphore, &ts); >>> ... >>> } >>> } >>> >>> and then just define the rel_to_abs_timespec functions for BSD, linux >>> and Solaris subclasses. ? >> >> I did something similar while prototyping alternative implementations >> of this. I named the function to PosixSemaphore::create_timespec, but >> I can change that name if you want to. >> >>> --- >>> >>> The sr_semaphore appears to be being initialized by C++ static >>> initialization, which is a concern for me, primarily because >>> Semaphore construction requires allocation support (it's a CHeapObj) >>> and utilizes NMT. I get very nervous when NMT gets involved prior to >>> VM initialization. Can we make sr_semaphore a pointer instead and >>> initialize it in one of the os::init methods? >> >> The current code doesn't use the CHeapObj new operator, so NMT isn't >> involved here. I'd prefer if this could be changed as a separate RFE. >> >>> >>> --- >>> >>> A few specific comments ... >>> >>> src/os/posix/vm/os_posix.cpp >>> >>> Two nits that I know have been copied from the existing code: >>> >>> 1061 while (1) { >>> >>> I prefer while (true) >>> >>> 1069 } else { >>> 1070 return false; >>> 1071 } >>> >>> This is returning false when an error has occurred. At a minimum >>> there should be an assert(false, "...") so that we detect this in >>> debug builds. >> >> Done. >> >>> >>> --- >>> >>> src/share/vm/utilities/semaphore.hpp >>> >>> Can we not implement this: >>> >>> 53 void signal(); >>> 54 void signal(uint count); >>> >>> as simply: >>> >>> void signal(uint count = 1); >>> >>> ? >> >> Done. >> >>> --- >>> >>> src/share/vm/utilities/semaphore.cpp: >>> >>> The logic in test_semaphore_many isn't quite right. For example if >>> you call it with value=0, max=2, increment=1, then you will end up >>> performing two signals() but only one wait(). >> >> Fixed. >> >> Thanks, >> StefanK >> >>> >>> Thanks, >>> David >>> ----- >>> >>> >>>> Thanks, >>>> StefanK >>>> >>>> On 2015-06-15 22:28, Stefan Karlsson wrote: >>>>> Hi again, >>>>> >>>>> I've hopefully addressed some of Kim's and David's concerns with the >>>>> following version: >>>>> >>>>> http://cr.openjdk.java.net/~stefank/8087322/webrev.01.delta/ >>>>> http://cr.openjdk.java.net/~stefank/8087322/webrev.01/ >>>>> >>>>> Changes in the current version of the patch: >>>>> >>>>> - Created a POSIX version that is used by Linux and Solaris (and maybe >>>>> AIX?). >>>>> >>>>> - Use asserts instead of guarantees. (I've got offline feedback that >>>>> others preferred at least some of the guarantees.) >>>>> >>>>> - Print the errno value and the errno string in the posix version >>>>> >>>>> - Removed trywait and timedwait from the Semaphore class and added >>>>> that functionality in platform-specific semaphore classes. This gets >>>>> rid of the Unimplemented() functions in os_windows.cpp. >>>>> >>>>> - I removed the IMPLEMENTS_SEMAPHORE_CLASS define. >>>>> >>>>> Some comments about the current patch: >>>>> >>>>> - I have not removed the 'max' parameter, since I haven't yet figured >>>>> out what the max value should be used for windows. >>>>> >>>>> - OS X doesn't implement unamed POSIX semaphores, so I have to go >>>>> through hoops to compile out the POXIS version when building on OS X. >>>>> >>>>> - I had to add -lrt to get the patch to link on Solaris. >>>>> >>>>> Tested with JPRT, >>>>> >>>>> Thanks, >>>>> StefanK >>>>> >>>>> On 2015-06-12 17:21, Stefan Karlsson wrote: >>>>>> Hi all, >>>>>> >>>>>> Please review this patch to create a Semaphore utility class. I need >>>>>> this class to implementing faster GC thread synchronization [1]. >>>>>> >>>>>> http://cr.openjdk.java.net/~stefank/8087322/webrev.00/ >>>>>> https://bugs.openjdk.java.net/browse/JDK-8087322 >>>>>> >>>>>> Some of our platforms already implement a Semaphore class, but those >>>>>> classes are hidden inside os_.cpp. I've moved the class >>>>>> declaration to semaphore.hpp, but the implementation is left in the >>>>>> os_.hpp. I considered creating semaphore_.cpp files, but I >>>>>> ended up having to restructure too much code and I wanted to focus on >>>>>> the feature in [1] instead. Should I create a RFE to move the >>>>>> semaphore implementations? >>>>>> >>>>>> There seems to be another opportunity to cleanup the code. If we take >>>>>> os_linux.cpp, as an example, the code uses both the existing >>>>>> Semaphore class and the global ::sem_wait and ::sem_post functions. >>>>>> We might want to consider unifying that code. >>>>>> >>>>>> Since HotSpot is built on platforms that I don't have access to and >>>>>> can't test, I've added the IMPLEMENTS_SEMAPHORE_CLASS define. So, >>>>>> that I can detect if the the current platform implements the >>>>>> Semaphore class, and choose what synchronization primitive to use by >>>>>> the GC. >>>>>> >>>>>> The os_bsd.cpp file has support for "non-apple BSD", but I've only >>>>>> tested this patch with OS X. >>>>>> >>>>>> This patch has been tested in JPRT and our nightly testing together >>>>>> with the patches in [1]. The patch also contains a few unit tests in >>>>>> semaphore.cpp. >>>>>> >>>>>> Thanks, >>>>>> StefanK >>>>>> >>>>>> [1] >>>>>> http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2015-June/013829.html >>>>>> >>>>>> >>>>> >>>> >> > From stefan.karlsson at oracle.com Wed Jun 24 12:17:43 2015 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Wed, 24 Jun 2015 14:17:43 +0200 Subject: RFR: 8087322: Implement a Semaphore utility class In-Reply-To: <558A9E4A.50304@oracle.com> References: <557AF8E4.9040804@oracle.com> <557F3582.6060401@oracle.com> <5581B597.5080900@oracle.com> <55836FF2.6070604@oracle.com> <55881B78.3040909@oracle.com> <558A8D78.5000209@oracle.com> <558A9E4A.50304@oracle.com> Message-ID: <558A9FE7.7090801@oracle.com> On 2015-06-24 14:10, David Holmes wrote: > Hi Stefan, > > On 24/06/2015 8:59 PM, Stefan Karlsson wrote: >> Hi all, >> >> Updated webrev: >> http://cr.openjdk.java.net/~stefank/8087322/webrev.04 > > This looks good to me. Thanks for reviewing! StefanK > >> This patch: >> >> - Gets rid of the public inheritance between Semaphore class and the >> [OS]Semaphore classes. >> >> - Semaphore is now a wrapper around the [OS]Semaphore implementation, >> and only expose a limited API (signal, wait). The OS-specific extensions >> to the semaphore API is only exposed and implemented in the >> [OS]Semaphore classes. >> >> - Changed back to use a guarantee in the constructor of the >> [OS]Semaphore classes. >> >> - Added more asserts. >> >> There are a few pre-existing bugs in the OSX implementation, but it >> would be good to handle those as separate RFEs. > > Agreed. > > Thanks for all your work and perseverance on this. > > David > >> Thanks, >> StefanK >> >> On 2015-06-22 16:28, Stefan Karlsson wrote: >>> Hi David, >>> >>> Updated webrevs: >>> http://cr.openjdk.java.net/~stefank/8087322/webrev.03.delta >>> http://cr.openjdk.java.net/~stefank/8087322/webrev.03 >>> >>> Comments inlined: >>> >>> On 2015-06-19 03:27, David Holmes wrote: >>>> Hi Stefan, >>>> >>>> Sorry for the delay ... >>>> >>>> On 18/06/2015 3:59 AM, Stefan Karlsson wrote: >>>>> Hi again, >>>>> >>>>> Here's a version that gets rid of the max parameter: >>>> >>>> Great! This is looking really good! >>> >>> Thanks. >>> >>>> >>>>> http://cr.openjdk.java.net/~stefank/8087322/webrev.02.delta >>>>> http://cr.openjdk.java.net/~stefank/8087322/webrev.02 >>>>> >>>>> The patch also contains a few minor cleanups and removes the >>>>> redundant >>>>> BsdSemaphore::trywait(), which is already defined in PosixSemaphore. >>>> >>>> The interaction with the sr_semaphore complicates things. If we push >>>> its API up to being the Semaphore API then we have to implement >>>> unused functionality on Windows (and perhaps AIX?). If instead we >>>> subclass Semaphore to extend the API then we have to duplicate some >>>> of the code, even across POSIX systems. :( Unfortunate but I don't >>>> see a better approach than what you have chosen (and the Apple vs >>>> other-BSD also complicates things). >>>> >>>> One thing I am tempted to clean up a little more is the timedwait >>>> call. PosixSemaphore timedwait takes a timespec to pass to the >>>> underlying sem_timedwait. But the primary API is timed_wait(long >>>> secs, int nsecs) which each PosixSemaphore subclass has to add, and >>>> each then has to perform the "unpackTime" mechanics (which in itself >>>> is something screaming to be cleaned up). What if PosixSemaphore >>>> defined: >>>> >>>> class PosixSemaphore : public Semaphore { >>>> public: >>>> PosixSemaphore(uint value = 0) : Semaphore(value) {} >>>> >>>> bool trywait(); >>>> bool timedwait(unsigned int sec, int nsec); >>>> >>>> protected: >>>> virtual void rel_to_abs_timespec(struct timespec* ts, unsigned int >>>> sec, int nsec) = 0; >>>> }; >>>> >>>> then: >>>> >>>> bool os::PosixSemaphore::timedwait(unsigned int sec, int nsec) { >>>> struct timespec ts; >>>> rel_to_abs_timespec(&ts, sec nsecs); >>>> while (true) { >>>> int result = sem_timedwait(&_semaphore, &ts); >>>> ... >>>> } >>>> } >>>> >>>> and then just define the rel_to_abs_timespec functions for BSD, linux >>>> and Solaris subclasses. ? >>> >>> I did something similar while prototyping alternative implementations >>> of this. I named the function to PosixSemaphore::create_timespec, but >>> I can change that name if you want to. >>> >>>> --- >>>> >>>> The sr_semaphore appears to be being initialized by C++ static >>>> initialization, which is a concern for me, primarily because >>>> Semaphore construction requires allocation support (it's a CHeapObj) >>>> and utilizes NMT. I get very nervous when NMT gets involved prior to >>>> VM initialization. Can we make sr_semaphore a pointer instead and >>>> initialize it in one of the os::init methods? >>> >>> The current code doesn't use the CHeapObj new operator, so NMT isn't >>> involved here. I'd prefer if this could be changed as a separate RFE. >>> >>>> >>>> --- >>>> >>>> A few specific comments ... >>>> >>>> src/os/posix/vm/os_posix.cpp >>>> >>>> Two nits that I know have been copied from the existing code: >>>> >>>> 1061 while (1) { >>>> >>>> I prefer while (true) >>>> >>>> 1069 } else { >>>> 1070 return false; >>>> 1071 } >>>> >>>> This is returning false when an error has occurred. At a minimum >>>> there should be an assert(false, "...") so that we detect this in >>>> debug builds. >>> >>> Done. >>> >>>> >>>> --- >>>> >>>> src/share/vm/utilities/semaphore.hpp >>>> >>>> Can we not implement this: >>>> >>>> 53 void signal(); >>>> 54 void signal(uint count); >>>> >>>> as simply: >>>> >>>> void signal(uint count = 1); >>>> >>>> ? >>> >>> Done. >>> >>>> --- >>>> >>>> src/share/vm/utilities/semaphore.cpp: >>>> >>>> The logic in test_semaphore_many isn't quite right. For example if >>>> you call it with value=0, max=2, increment=1, then you will end up >>>> performing two signals() but only one wait(). >>> >>> Fixed. >>> >>> Thanks, >>> StefanK >>> >>>> >>>> Thanks, >>>> David >>>> ----- >>>> >>>> >>>>> Thanks, >>>>> StefanK >>>>> >>>>> On 2015-06-15 22:28, Stefan Karlsson wrote: >>>>>> Hi again, >>>>>> >>>>>> I've hopefully addressed some of Kim's and David's concerns with the >>>>>> following version: >>>>>> >>>>>> http://cr.openjdk.java.net/~stefank/8087322/webrev.01.delta/ >>>>>> http://cr.openjdk.java.net/~stefank/8087322/webrev.01/ >>>>>> >>>>>> Changes in the current version of the patch: >>>>>> >>>>>> - Created a POSIX version that is used by Linux and Solaris (and >>>>>> maybe >>>>>> AIX?). >>>>>> >>>>>> - Use asserts instead of guarantees. (I've got offline feedback that >>>>>> others preferred at least some of the guarantees.) >>>>>> >>>>>> - Print the errno value and the errno string in the posix version >>>>>> >>>>>> - Removed trywait and timedwait from the Semaphore class and added >>>>>> that functionality in platform-specific semaphore classes. This gets >>>>>> rid of the Unimplemented() functions in os_windows.cpp. >>>>>> >>>>>> - I removed the IMPLEMENTS_SEMAPHORE_CLASS define. >>>>>> >>>>>> Some comments about the current patch: >>>>>> >>>>>> - I have not removed the 'max' parameter, since I haven't yet >>>>>> figured >>>>>> out what the max value should be used for windows. >>>>>> >>>>>> - OS X doesn't implement unamed POSIX semaphores, so I have to go >>>>>> through hoops to compile out the POXIS version when building on >>>>>> OS X. >>>>>> >>>>>> - I had to add -lrt to get the patch to link on Solaris. >>>>>> >>>>>> Tested with JPRT, >>>>>> >>>>>> Thanks, >>>>>> StefanK >>>>>> >>>>>> On 2015-06-12 17:21, Stefan Karlsson wrote: >>>>>>> Hi all, >>>>>>> >>>>>>> Please review this patch to create a Semaphore utility class. I >>>>>>> need >>>>>>> this class to implementing faster GC thread synchronization [1]. >>>>>>> >>>>>>> http://cr.openjdk.java.net/~stefank/8087322/webrev.00/ >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8087322 >>>>>>> >>>>>>> Some of our platforms already implement a Semaphore class, but >>>>>>> those >>>>>>> classes are hidden inside os_.cpp. I've moved the class >>>>>>> declaration to semaphore.hpp, but the implementation is left in the >>>>>>> os_.hpp. I considered creating semaphore_.cpp files, but I >>>>>>> ended up having to restructure too much code and I wanted to >>>>>>> focus on >>>>>>> the feature in [1] instead. Should I create a RFE to move the >>>>>>> semaphore implementations? >>>>>>> >>>>>>> There seems to be another opportunity to cleanup the code. If we >>>>>>> take >>>>>>> os_linux.cpp, as an example, the code uses both the existing >>>>>>> Semaphore class and the global ::sem_wait and ::sem_post functions. >>>>>>> We might want to consider unifying that code. >>>>>>> >>>>>>> Since HotSpot is built on platforms that I don't have access to and >>>>>>> can't test, I've added the IMPLEMENTS_SEMAPHORE_CLASS define. So, >>>>>>> that I can detect if the the current platform implements the >>>>>>> Semaphore class, and choose what synchronization primitive to >>>>>>> use by >>>>>>> the GC. >>>>>>> >>>>>>> The os_bsd.cpp file has support for "non-apple BSD", but I've only >>>>>>> tested this patch with OS X. >>>>>>> >>>>>>> This patch has been tested in JPRT and our nightly testing together >>>>>>> with the patches in [1]. The patch also contains a few unit >>>>>>> tests in >>>>>>> semaphore.cpp. >>>>>>> >>>>>>> Thanks, >>>>>>> StefanK >>>>>>> >>>>>>> [1] >>>>>>> http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2015-June/013829.html >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>> >> From bill.pittore at oracle.com Wed Jun 24 15:50:22 2015 From: bill.pittore at oracle.com (bill pittore) Date: Wed, 24 Jun 2015 11:50:22 -0400 Subject: Need a volunteer to push C++11 macro fix to jdk9/hs-rt Message-ID: <558AD1BE.6020605@oracle.com> This is bug 8081202 which fixes "C++11 requires a space between literal and identifier" There are two export files here: /export/users/bpittore/jdk9-macro-2/8081202.hotspot.export /export/users/bpittore/jdk9-macro-2/8081202.hotspot.closed.export The parent repo is jdk9/hs-rt. I made some new changes to two files during the merge of the files from the command line range checking changeset. Diffs are below. Thanks! bill --- old/src/share/vm/runtime/globals.cpp 2015-06-24 11:23:48.142216822 -0400 +++ new/src/share/vm/runtime/globals.cpp 2015-06-24 11:23:47.514180257 -0400 @@ -1240,7 +1240,7 @@ size_ranges += sizeof(CommandLineFlagRange*); } } - fprintf(stderr, "Size of %d ranges: "SIZE_FORMAT" bytes\n", + fprintf(stderr, "Size of %d ranges: " SIZE_FORMAT " bytes\n", CommandLineFlagRangeList::length(), size_ranges); } { @@ -1270,7 +1270,7 @@ size_constraints += sizeof(CommandLineFlagConstraint*); } } - fprintf(stderr, "Size of %d constraints: "SIZE_FORMAT" bytes\n", + fprintf(stderr, "Size of %d constraints: " SIZE_FORMAT " bytes\n", CommandLineFlagConstraintList::length(), size_constraints); } #endif // PRINT_RANGES_AND_CONSTRAINTS_SIZES --- old/src/share/vm/runtime/commandLineFlagRangeList.cpp 2015-06-24 11:23:50.034326981 -0400 +++ new/src/share/vm/runtime/commandLineFlagRangeList.cpp 2015-06-24 11:23:49.462293677 -0400 @@ -84,7 +84,7 @@ } void print(outputStream* st) { - st->print("[ "INTX_FORMAT_W(-25)" ... "INTX_FORMAT_W(25)" ]", _min, _max); + st->print("[ " INTX_FORMAT_W(-25) " ... " INTX_FORMAT_W(25) " ]", _min, _max); } }; @@ -140,7 +140,7 @@ } void print(outputStream* st) { - st->print("[ "UINTX_FORMAT_W(-25)" ... "UINTX_FORMAT_W(25)" ]", _min, _max); + st->print("[ " UINTX_FORMAT_W(-25) " ... " UINTX_FORMAT_W(25) " ]", _min, _max); } }; @@ -196,7 +196,7 @@ } void print(outputStream* st) { - st->print("[ "SIZE_FORMAT_W(-25)" ... "SIZE_FORMAT_W(25)" ]", _min, _max); + st->print("[ " SIZE_FORMAT_W(-25) " ... " SIZE_FORMAT_W(25) " ]", _min, _max); } }; From daniel.daugherty at oracle.com Wed Jun 24 15:57:02 2015 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 24 Jun 2015 09:57:02 -0600 Subject: RFR(S): 8129757: ppc/aarch: Fix passing thread to runtime after "8073165: Contended Locking fast exit bucket." In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CFFED31@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CFFED31@DEWDFEMB12A.global.corp.sap> Message-ID: <558AD34E.8070703@oracle.com> On 6/24/15 1:40 AM, Lindenmaier, Goetz wrote: > Hi, > > Change 8073165 added a new argument to complete_monitor_unlocking_C(): the current thread. Moving this value into the argument registers before the runtime call issued in the native wrapper was missing on ppc and aarch. > > Please review this change: > http://cr.openjdk.java.net/~goetz/webrevs/8129757-unlock/webrev-01/ src/cpu/aarch64/vm/sharedRuntime_aarch64.cpp L2132 rt_call(masm, CAST_FROM_FN_PTR(address, SharedRuntime::complete_monitor_unlocking_C), 3, 0, 1); nit: It would nice if there was comment like above L2132: // Arguments are (oop obj, BasicLock* lock, JavaThread* thread). src/cpu/ppc/vm/sharedRuntime_ppc.cpp No comments. Thumbs up. Dan > > Edward Nevill already had a look at the aarch changes and tested them. > > Best regards, > Goetz. From thomas.schatzl at oracle.com Wed Jun 24 16:00:27 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Wed, 24 Jun 2015 18:00:27 +0200 Subject: RFR (XXS): 8129604: Incorrect GPL header in README file causes RE script to produce wrong output Message-ID: <1435161627.2512.309.camel@oracle.com> Hi again, another one (I hope the last) of the changes that fix the GPL headers, this time for a README file. The mentioned RE script does not like GPL headers starting with a "#" or "*" in non-source code files. This changes simply removes the "#" at the start of the affected file. CR (confidential, sorry): https://bugs.openjdk.java.net/browse/JDK-8129604 Webrev: http://cr.openjdk.java.net/~tschatzl/8129604/webrev/ The same patch also needs to go into 8u60, but applies cleanly. Thanks, Thomas From thomas.schatzl at oracle.com Wed Jun 24 16:03:03 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Wed, 24 Jun 2015 18:03:03 +0200 Subject: RFR (XXS): 8129602: Incorrect GPL header causes RE script to create wrong output In-Reply-To: <558A9190.4030601@oracle.com> References: <1435136626.2512.15.camel@oracle.com> <558A7EEB.9040305@oracle.com> <558A7F4D.2000406@oracle.com> <558A9190.4030601@oracle.com> Message-ID: <1435161783.2512.311.camel@oracle.com> Hi Stefan, David, Coleen, On Wed, 2015-06-24 at 07:16 -0400, Coleen Phillimore wrote: > Thomas, > > This looks good (in case you haven't already pushed it). I think you > fixed your removal of the extra blank lines in the final > http://cr.openjdk.java.net/~tschatzl/8129602/webrev.8u60/hotspot.patch Yes. > patch. I'm sorry I didn't address all of these issues when I did the > one assigned to me. David pointed the other bugs out to me after I'd > started my JPRT job. > > Now we know something will catch missing , at the end of copyright years. :) Thanks for the reviews. Note that there is another one of those up for review, maybe if you had a second... Thanks, Thomas From coleen.phillimore at oracle.com Wed Jun 24 16:04:22 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 24 Jun 2015 12:04:22 -0400 Subject: RFR (XXS): 8129604: Incorrect GPL header in README file causes RE script to produce wrong output In-Reply-To: <1435161627.2512.309.camel@oracle.com> References: <1435161627.2512.309.camel@oracle.com> Message-ID: <558AD506.6040506@oracle.com> This is good. Thank you for taking care of these. Coleen On 6/24/15 12:00 PM, Thomas Schatzl wrote: > Hi again, > > another one (I hope the last) of the changes that fix the GPL headers, > this time for a README file. The mentioned RE script does not like GPL > headers starting with a "#" or "*" in non-source code files. > > This changes simply removes the "#" at the start of the affected file. > > CR (confidential, sorry): > https://bugs.openjdk.java.net/browse/JDK-8129604 > > Webrev: > http://cr.openjdk.java.net/~tschatzl/8129604/webrev/ > > The same patch also needs to go into 8u60, but applies cleanly. > > Thanks, > Thomas > > From coleen.phillimore at oracle.com Wed Jun 24 16:34:46 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 24 Jun 2015 12:34:46 -0400 Subject: Need a volunteer to push C++11 macro fix to jdk9/hs-rt In-Reply-To: <558AD1BE.6020605@oracle.com> References: <558AD1BE.6020605@oracle.com> Message-ID: <558ADC26.2090605@oracle.com> I'll push it for you, Bill. Coleen On 6/24/15 11:50 AM, bill pittore wrote: > This is bug 8081202 which fixes "C++11 requires a space between > literal and identifier" > > There are two export files here: > /export/users/bpittore/jdk9-macro-2/8081202.hotspot.export > /export/users/bpittore/jdk9-macro-2/8081202.hotspot.closed.export > > The parent repo is jdk9/hs-rt. > > I made some new changes to two files during the merge of the files > from the command line range checking changeset. Diffs are below. > > Thanks! > > bill > > --- old/src/share/vm/runtime/globals.cpp 2015-06-24 11:23:48.142216822 > -0400 > +++ new/src/share/vm/runtime/globals.cpp 2015-06-24 11:23:47.514180257 > -0400 > @@ -1240,7 +1240,7 @@ > size_ranges += sizeof(CommandLineFlagRange*); > } > } > - fprintf(stderr, "Size of %d ranges: "SIZE_FORMAT" bytes\n", > + fprintf(stderr, "Size of %d ranges: " SIZE_FORMAT " bytes\n", > CommandLineFlagRangeList::length(), size_ranges); > } > { > @@ -1270,7 +1270,7 @@ > size_constraints += sizeof(CommandLineFlagConstraint*); > } > } > - fprintf(stderr, "Size of %d constraints: "SIZE_FORMAT" bytes\n", > + fprintf(stderr, "Size of %d constraints: " SIZE_FORMAT " bytes\n", > CommandLineFlagConstraintList::length(), size_constraints); > } > #endif // PRINT_RANGES_AND_CONSTRAINTS_SIZES > --- old/src/share/vm/runtime/commandLineFlagRangeList.cpp 2015-06-24 > 11:23:50.034326981 -0400 > +++ new/src/share/vm/runtime/commandLineFlagRangeList.cpp 2015-06-24 > 11:23:49.462293677 -0400 > @@ -84,7 +84,7 @@ > } > > void print(outputStream* st) { > - st->print("[ "INTX_FORMAT_W(-25)" ... "INTX_FORMAT_W(25)" ]", > _min, _max); > + st->print("[ " INTX_FORMAT_W(-25) " ... " INTX_FORMAT_W(25) " ]", > _min, _max); > } > }; > > @@ -140,7 +140,7 @@ > } > > void print(outputStream* st) { > - st->print("[ "UINTX_FORMAT_W(-25)" ... "UINTX_FORMAT_W(25)" ]", > _min, _max); > + st->print("[ " UINTX_FORMAT_W(-25) " ... " UINTX_FORMAT_W(25) " > ]", _min, _max); > } > }; > > @@ -196,7 +196,7 @@ > } > > void print(outputStream* st) { > - st->print("[ "SIZE_FORMAT_W(-25)" ... "SIZE_FORMAT_W(25)" ]", > _min, _max); > + st->print("[ " SIZE_FORMAT_W(-25) " ... " SIZE_FORMAT_W(25) " ]", > _min, _max); > } > }; From bill.pittore at oracle.com Wed Jun 24 16:40:57 2015 From: bill.pittore at oracle.com (bill pittore) Date: Wed, 24 Jun 2015 12:40:57 -0400 Subject: Need a volunteer to push C++11 macro fix to jdk9/hs-rt In-Reply-To: <558ADC26.2090605@oracle.com> References: <558AD1BE.6020605@oracle.com> <558ADC26.2090605@oracle.com> Message-ID: <558ADD99.9090303@oracle.com> Thanks Coleen. Let me know if there are any issues with the push since this does touch lots of files. bill On 6/24/2015 12:34 PM, Coleen Phillimore wrote: > > I'll push it for you, Bill. > Coleen > > > On 6/24/15 11:50 AM, bill pittore wrote: >> This is bug 8081202 which fixes "C++11 requires a space between >> literal and identifier" >> >> There are two export files here: >> /export/users/bpittore/jdk9-macro-2/8081202.hotspot.export >> /export/users/bpittore/jdk9-macro-2/8081202.hotspot.closed.export >> >> The parent repo is jdk9/hs-rt. >> >> I made some new changes to two files during the merge of the files >> from the command line range checking changeset. Diffs are below. >> >> Thanks! >> >> bill >> >> --- old/src/share/vm/runtime/globals.cpp 2015-06-24 >> 11:23:48.142216822 -0400 >> +++ new/src/share/vm/runtime/globals.cpp 2015-06-24 >> 11:23:47.514180257 -0400 >> @@ -1240,7 +1240,7 @@ >> size_ranges += sizeof(CommandLineFlagRange*); >> } >> } >> - fprintf(stderr, "Size of %d ranges: "SIZE_FORMAT" bytes\n", >> + fprintf(stderr, "Size of %d ranges: " SIZE_FORMAT " bytes\n", >> CommandLineFlagRangeList::length(), size_ranges); >> } >> { >> @@ -1270,7 +1270,7 @@ >> size_constraints += sizeof(CommandLineFlagConstraint*); >> } >> } >> - fprintf(stderr, "Size of %d constraints: "SIZE_FORMAT" bytes\n", >> + fprintf(stderr, "Size of %d constraints: " SIZE_FORMAT " bytes\n", >> CommandLineFlagConstraintList::length(), size_constraints); >> } >> #endif // PRINT_RANGES_AND_CONSTRAINTS_SIZES >> --- old/src/share/vm/runtime/commandLineFlagRangeList.cpp 2015-06-24 >> 11:23:50.034326981 -0400 >> +++ new/src/share/vm/runtime/commandLineFlagRangeList.cpp 2015-06-24 >> 11:23:49.462293677 -0400 >> @@ -84,7 +84,7 @@ >> } >> >> void print(outputStream* st) { >> - st->print("[ "INTX_FORMAT_W(-25)" ... "INTX_FORMAT_W(25)" ]", >> _min, _max); >> + st->print("[ " INTX_FORMAT_W(-25) " ... " INTX_FORMAT_W(25) " >> ]", _min, _max); >> } >> }; >> >> @@ -140,7 +140,7 @@ >> } >> >> void print(outputStream* st) { >> - st->print("[ "UINTX_FORMAT_W(-25)" ... "UINTX_FORMAT_W(25)" ]", >> _min, _max); >> + st->print("[ " UINTX_FORMAT_W(-25) " ... " UINTX_FORMAT_W(25) " >> ]", _min, _max); >> } >> }; >> >> @@ -196,7 +196,7 @@ >> } >> >> void print(outputStream* st) { >> - st->print("[ "SIZE_FORMAT_W(-25)" ... "SIZE_FORMAT_W(25)" ]", >> _min, _max); >> + st->print("[ " SIZE_FORMAT_W(-25) " ... " SIZE_FORMAT_W(25) " >> ]", _min, _max); >> } >> }; > From kim.barrett at oracle.com Wed Jun 24 20:28:39 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 24 Jun 2015 16:28:39 -0400 Subject: RFR: 8087322: Implement a Semaphore utility class In-Reply-To: <558A8D78.5000209@oracle.com> References: <557AF8E4.9040804@oracle.com> <557F3582.6060401@oracle.com> <5581B597.5080900@oracle.com> <55836FF2.6070604@oracle.com> <55881B78.3040909@oracle.com> <558A8D78.5000209@oracle.com> Message-ID: On Jun 24, 2015, at 6:59 AM, Stefan Karlsson wrote: > > Hi all, > > Updated webrev: > http://cr.openjdk.java.net/~stefank/8087322/webrev.04 Structurally fine. (Stefan would be rightly annoyed with me if I said otherwise after all the offline discussions we've had.) There's some nastiness that results from pre-existing problems in the os_xxx.cpp files, but cleaning that up is another collection of tasks. A few easy bugs, some stylistic comments that can be accepted or declined, but nothing requiring large amounts of rework. ------------------------------------------------------------------------------ src/os/bsd/vm/os_bsd.cpp 1971 OSXSemaphore::OSXSemaphore(uint value) : _semaphore(0) { I think that initializer for _semaphore isn't right. _semaphore is a (OSX) semaphore_t. I think that initializer only accidentally compiles at all. ------------------------------------------------------------------------------ src/os/bsd/vm/semaphore_bsd.hpp 28 #include "memory/allocation.hpp" 29 30 #include 31 32 #ifndef __APPLE__ 33 # include "semaphore_posix.hpp" 34 #else 35 // OS X doesn't support unamed POSIX semaphores, so the implementation in os_posix.cpp can't be used. 36 37 class OSXSemaphore : public CHeapObj{ This only needs "memory/allocation.hpp" in the Apple case. This doesn't need in the non-Apple case. In the Apple case, I think the correct include is rather than . I'm not sure why is working at all. ------------------------------------------------------------------------------ src/os/posix/vm/os_posix.cpp 1021 #define check_with_errno(check_type, cond, msg) \ 1022 do { \ 1023 int err = errno; \ 1024 check_type(cond, err_msg("%s; error='%s' (errno=%d)", msg, strerror(err), err)); \ 1025 } while (false) 1026 1027 #define assert_with_errno(cond, msg) check_with_errno(assert, cond, msg) 1028 #define guarantee_with_errno(cond, msg) check_with_errno(guarantee, cond, msg) We already have assert_status in debug.hpp. It might be better to add a corresponding guarantee_status there, and use those here. Also, these macros are only used inside the #ifndef __APPLE__ block. And welcome to the dark side. (Higher order macros!) ------------------------------------------------------------------------------ src/os/posix/vm/os_posix.cpp 1053 while ((ret = sem_wait(&_semaphore)) == -1 && errno == EINTR) { I would probably instead use (ret = sem_wait(&_semaphore)) != 0 e.g. while !successful. ------------------------------------------------------------------------------ src/os/posix/vm/os_posix.cpp 1059 bool PosixSemaphore::trywait() { 1060 bool succeeded = sem_trywait(&_semaphore) == 0; 1061 1062 assert_with_errno(succeeded || errno == EAGAIN, "trywait failed"); 1063 1064 return succeeded; 1065 } sem_trywait can also fail with EINTR. ------------------------------------------------------------------------------ src/os/posix/vm/os_posix.cpp 1072 } else if (errno == EINTR) { 1073 continue; 1074 } else if (errno == ETIMEDOUT) { I think ETIMEDOUT should be tested before EINTR. ETIMEDOUT is the more interesting and performance relevant case. ------------------------------------------------------------------------------ src/os/windows/vm/os_windows.cpp 1905 WindowsSemaphore::~WindowsSemaphore() { 1906 if (_semaphore != NULL) { 1907 ::CloseHandle(_semaphore); 1908 } I don't think the NULL check is needed here. ------------------------------------------------------------------------------ src/os/bsd/vm/semaphore_bsd.hpp 56 static jlong currenttime(); This function is an implementation detail of the timedwait function, and could be a file-scoped static near its caller, rather than having external linkage. [The PosixSemaphore class is different in this respect, because there we need to choose between platform-specific definitions of create_timespec that will be in a different file from the reference, so external linkage is required. That situation doesn't apply for OSXSemaphore.] ------------------------------------------------------------------------------ src/os/windows/vm/semaphore_windows.hpp 30 #include I think is sufficient here, and is purportedly smaller. The .cpp file likely needs more, but is already including . Also, it looks like we prefer the lowercase form on Windows, even though the file system is case-insensitive. ------------------------------------------------------------------------------ src/os/windows/vm/semaphore_windows.hpp 43 void signal(uint count = 0); Default count of 0 is inconsistent with corresponding classes for other platforms. ------------------------------------------------------------------------------ src/share/vm/runtime/semaphore.cpp 30 Semaphore::Semaphore(uint value) : _impl(value) {} 31 Semaphore::~Semaphore() {} 32 void Semaphore::signal(uint count) { _impl.signal(count); } 33 void Semaphore::wait() { _impl.wait(); } I'm not sure why these forwarding definitions are out of line in the .cpp file, rather than inline in the header. After all, we've now gone to some trouble to have the wrapped platform-specific implementation class provide at least that set of operations. ------------------------------------------------------------------------------ From gerard.ziemski at oracle.com Wed Jun 24 20:46:57 2015 From: gerard.ziemski at oracle.com (Gerard Ziemski) Date: Wed, 24 Jun 2015 15:46:57 -0500 Subject: Need a volunteer to push C++11 macro fix to jdk9/hs-rt In-Reply-To: <558AD1BE.6020605@oracle.com> References: <558AD1BE.6020605@oracle.com> Message-ID: <558B1741.9070806@oracle.com> Thank you Bill for fixing this. I had this fix in my local repo, but it has more changes, so it's taking me longer and you beat me to it. cheers On 6/24/2015 10:50 AM, bill pittore wrote: > This is bug 8081202 which fixes "C++11 requires a space between > literal and identifier" > > There are two export files here: > /export/users/bpittore/jdk9-macro-2/8081202.hotspot.export > /export/users/bpittore/jdk9-macro-2/8081202.hotspot.closed.export > > The parent repo is jdk9/hs-rt. > > I made some new changes to two files during the merge of the files > from the command line range checking changeset. Diffs are below. > > Thanks! > > bill > > --- old/src/share/vm/runtime/globals.cpp 2015-06-24 11:23:48.142216822 > -0400 > +++ new/src/share/vm/runtime/globals.cpp 2015-06-24 11:23:47.514180257 > -0400 > @@ -1240,7 +1240,7 @@ > size_ranges += sizeof(CommandLineFlagRange*); > } > } > - fprintf(stderr, "Size of %d ranges: "SIZE_FORMAT" bytes\n", > + fprintf(stderr, "Size of %d ranges: " SIZE_FORMAT " bytes\n", > CommandLineFlagRangeList::length(), size_ranges); > } > { > @@ -1270,7 +1270,7 @@ > size_constraints += sizeof(CommandLineFlagConstraint*); > } > } > - fprintf(stderr, "Size of %d constraints: "SIZE_FORMAT" bytes\n", > + fprintf(stderr, "Size of %d constraints: " SIZE_FORMAT " bytes\n", > CommandLineFlagConstraintList::length(), size_constraints); > } > #endif // PRINT_RANGES_AND_CONSTRAINTS_SIZES > --- old/src/share/vm/runtime/commandLineFlagRangeList.cpp 2015-06-24 > 11:23:50.034326981 -0400 > +++ new/src/share/vm/runtime/commandLineFlagRangeList.cpp 2015-06-24 > 11:23:49.462293677 -0400 > @@ -84,7 +84,7 @@ > } > > void print(outputStream* st) { > - st->print("[ "INTX_FORMAT_W(-25)" ... "INTX_FORMAT_W(25)" ]", > _min, _max); > + st->print("[ " INTX_FORMAT_W(-25) " ... " INTX_FORMAT_W(25) " ]", > _min, _max); > } > }; > > @@ -140,7 +140,7 @@ > } > > void print(outputStream* st) { > - st->print("[ "UINTX_FORMAT_W(-25)" ... "UINTX_FORMAT_W(25)" ]", > _min, _max); > + st->print("[ " UINTX_FORMAT_W(-25) " ... " UINTX_FORMAT_W(25) " > ]", _min, _max); > } > }; > > @@ -196,7 +196,7 @@ > } > > void print(outputStream* st) { > - st->print("[ "SIZE_FORMAT_W(-25)" ... "SIZE_FORMAT_W(25)" ]", > _min, _max); > + st->print("[ " SIZE_FORMAT_W(-25) " ... " SIZE_FORMAT_W(25) " ]", > _min, _max); > } > }; > > From bill.pittore at oracle.com Wed Jun 24 21:00:18 2015 From: bill.pittore at oracle.com (bill pittore) Date: Wed, 24 Jun 2015 17:00:18 -0400 Subject: Need a volunteer to push C++11 macro fix to jdk9/hs-rt In-Reply-To: <558B1741.9070806@oracle.com> References: <558AD1BE.6020605@oracle.com> <558B1741.9070806@oracle.com> Message-ID: <558B1A62.2070802@oracle.com> No problem. I'm sure there are a few more I missed since I only built linux and windows with the C++11 standard. bill On 6/24/2015 4:46 PM, Gerard Ziemski wrote: > Thank you Bill for fixing this. > > I had this fix in my local repo, but it has more changes, so it's > taking me longer and you beat me to it. > > > cheers > > On 6/24/2015 10:50 AM, bill pittore wrote: >> This is bug 8081202 which fixes "C++11 requires a space between >> literal and identifier" >> >> There are two export files here: >> /export/users/bpittore/jdk9-macro-2/8081202.hotspot.export >> /export/users/bpittore/jdk9-macro-2/8081202.hotspot.closed.export >> >> The parent repo is jdk9/hs-rt. >> >> I made some new changes to two files during the merge of the files >> from the command line range checking changeset. Diffs are below. >> >> Thanks! >> >> bill >> >> --- old/src/share/vm/runtime/globals.cpp 2015-06-24 >> 11:23:48.142216822 -0400 >> +++ new/src/share/vm/runtime/globals.cpp 2015-06-24 >> 11:23:47.514180257 -0400 >> @@ -1240,7 +1240,7 @@ >> size_ranges += sizeof(CommandLineFlagRange*); >> } >> } >> - fprintf(stderr, "Size of %d ranges: "SIZE_FORMAT" bytes\n", >> + fprintf(stderr, "Size of %d ranges: " SIZE_FORMAT " bytes\n", >> CommandLineFlagRangeList::length(), size_ranges); >> } >> { >> @@ -1270,7 +1270,7 @@ >> size_constraints += sizeof(CommandLineFlagConstraint*); >> } >> } >> - fprintf(stderr, "Size of %d constraints: "SIZE_FORMAT" bytes\n", >> + fprintf(stderr, "Size of %d constraints: " SIZE_FORMAT " bytes\n", >> CommandLineFlagConstraintList::length(), size_constraints); >> } >> #endif // PRINT_RANGES_AND_CONSTRAINTS_SIZES >> --- old/src/share/vm/runtime/commandLineFlagRangeList.cpp 2015-06-24 >> 11:23:50.034326981 -0400 >> +++ new/src/share/vm/runtime/commandLineFlagRangeList.cpp 2015-06-24 >> 11:23:49.462293677 -0400 >> @@ -84,7 +84,7 @@ >> } >> >> void print(outputStream* st) { >> - st->print("[ "INTX_FORMAT_W(-25)" ... "INTX_FORMAT_W(25)" ]", >> _min, _max); >> + st->print("[ " INTX_FORMAT_W(-25) " ... " INTX_FORMAT_W(25) " >> ]", _min, _max); >> } >> }; >> >> @@ -140,7 +140,7 @@ >> } >> >> void print(outputStream* st) { >> - st->print("[ "UINTX_FORMAT_W(-25)" ... "UINTX_FORMAT_W(25)" ]", >> _min, _max); >> + st->print("[ " UINTX_FORMAT_W(-25) " ... " UINTX_FORMAT_W(25) " >> ]", _min, _max); >> } >> }; >> >> @@ -196,7 +196,7 @@ >> } >> >> void print(outputStream* st) { >> - st->print("[ "SIZE_FORMAT_W(-25)" ... "SIZE_FORMAT_W(25)" ]", >> _min, _max); >> + st->print("[ " SIZE_FORMAT_W(-25) " ... " SIZE_FORMAT_W(25) " >> ]", _min, _max); >> } >> }; >> >> > From stefan.karlsson at oracle.com Wed Jun 24 21:31:55 2015 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Wed, 24 Jun 2015 23:31:55 +0200 Subject: RFR: 8087322: Implement a Semaphore utility class In-Reply-To: References: <557AF8E4.9040804@oracle.com> <557F3582.6060401@oracle.com> <5581B597.5080900@oracle.com> <55836FF2.6070604@oracle.com> <55881B78.3040909@oracle.com> <558A8D78.5000209@oracle.com> Message-ID: <558B21CB.1010901@oracle.com> Hi Kim, On 2015-06-24 22:28, Kim Barrett wrote: > On Jun 24, 2015, at 6:59 AM, Stefan Karlsson wrote: >> Hi all, >> >> Updated webrev: >> http://cr.openjdk.java.net/~stefank/8087322/webrev.04 > Structurally fine. (Stefan would be rightly annoyed with me if I said > otherwise after all the offline discussions we've had.) There's some > nastiness that results from pre-existing problems in the os_xxx.cpp > files, but cleaning that up is another collection of tasks. > > A few easy bugs, some stylistic comments that can be accepted or > declined, but nothing requiring large amounts of rework. > > ------------------------------------------------------------------------------ > src/os/bsd/vm/os_bsd.cpp > 1971 OSXSemaphore::OSXSemaphore(uint value) : _semaphore(0) { > > I think that initializer for _semaphore isn't right. _semaphore is a > (OSX) semaphore_t. I think that initializer only accidentally > compiles at all. This is one yet another case of pre-existing code. > > ------------------------------------------------------------------------------ > src/os/bsd/vm/semaphore_bsd.hpp > 28 #include "memory/allocation.hpp" > 29 > 30 #include > 31 > 32 #ifndef __APPLE__ > 33 # include "semaphore_posix.hpp" > 34 #else > 35 // OS X doesn't support unamed POSIX semaphores, so the implementation in os_posix.cpp can't be used. > 36 > 37 class OSXSemaphore : public CHeapObj{ > > This only needs "memory/allocation.hpp" in the Apple case. > > This doesn't need in the non-Apple case. OK. > > In the Apple case, I think the correct include is > rather than . I'm not sure why is working > at all. I'll change it. > > ------------------------------------------------------------------------------ > src/os/posix/vm/os_posix.cpp > 1021 #define check_with_errno(check_type, cond, msg) \ > 1022 do { \ > 1023 int err = errno; \ > 1024 check_type(cond, err_msg("%s; error='%s' (errno=%d)", msg, strerror(err), err)); \ > 1025 } while (false) > 1026 > 1027 #define assert_with_errno(cond, msg) check_with_errno(assert, cond, msg) > 1028 #define guarantee_with_errno(cond, msg) check_with_errno(guarantee, cond, msg) > > We already have assert_status in debug.hpp. It might be better to add > a corresponding guarantee_status there, and use those here. 1) The comment above vmassert_status says: // This version of vmassert is for use with checking return status from // library calls that return actual error values eg. EINVAL, // ENOMEM etc, rather than returning -1 and setting errno. // When the status is not what is expected it is very useful to know // what status was actually returned, so we pass the status variable as // an extra arg and use strerror to convert it to a meaningful string // like "Invalid argument", "out of memory" etc but called library calls actually do return -1 and sets errno. Maybe the comment is too specific? 2) I modeled the error message with this code in mind: 2587 static void warn_fail_commit_memory(char* addr, size_t size, bool exec, 2588 int err) { 2589 warning("INFO: os::commit_memory(" PTR_FORMAT ", " SIZE_FORMAT 2590 ", %d) failed; error='%s' (errno=%d)", addr, size, exec, 2591 strerror(err), err); 2592 } > > Also, these macros are only used inside the #ifndef __APPLE__ block. Yes, but they are not specific to non-__APPLE__ code, so I chooe to put it outside that block. > > And welcome to the dark side. (Higher order macros!) > > ------------------------------------------------------------------------------ > src/os/posix/vm/os_posix.cpp > 1053 while ((ret = sem_wait(&_semaphore)) == -1 && errno == EINTR) { > > I would probably instead use > > (ret = sem_wait(&_semaphore)) != 0 > > e.g. while !successful. Sure. > > ------------------------------------------------------------------------------ > src/os/posix/vm/os_posix.cpp > 1059 bool PosixSemaphore::trywait() { > 1060 bool succeeded = sem_trywait(&_semaphore) == 0; > 1061 > 1062 assert_with_errno(succeeded || errno == EAGAIN, "trywait failed"); > 1063 > 1064 return succeeded; > 1065 } > > sem_trywait can also fail with EINTR. Will fix the assert. > > ------------------------------------------------------------------------------ > src/os/posix/vm/os_posix.cpp > 1072 } else if (errno == EINTR) { > 1073 continue; > 1074 } else if (errno == ETIMEDOUT) { > > I think ETIMEDOUT should be tested before EINTR. ETIMEDOUT is the > more interesting and performance relevant case. This pre-existing code can be fixed as a separate RFE. > > ------------------------------------------------------------------------------ > src/os/windows/vm/os_windows.cpp > 1905 WindowsSemaphore::~WindowsSemaphore() { > 1906 if (_semaphore != NULL) { > 1907 ::CloseHandle(_semaphore); > 1908 } > > I don't think the NULL check is needed here. I'll remove it. > > ------------------------------------------------------------------------------ > src/os/bsd/vm/semaphore_bsd.hpp > 56 static jlong currenttime(); > > This function is an implementation detail of the timedwait function, > and could be a file-scoped static near its caller, rather than having > external linkage. Yes. I put it in the class so that I wouldn't have to create a prefix for currenttime and to make it obvious that only the OSXSemaphore uses that function. > > [The PosixSemaphore class is different in this respect, because there > we need to choose between platform-specific definitions of > create_timespec that will be in a different file from the reference, > so external linkage is required. That situation doesn't apply for > OSXSemaphore.] > > ------------------------------------------------------------------------------ > src/os/windows/vm/semaphore_windows.hpp > 30 #include > > I think is sufficient here, and is purportedly smaller. > The .cpp file likely needs more, but is already including . > Also, it looks like we prefer the lowercase form on Windows, even > though the file system is case-insensitive. I'll fix. > > ------------------------------------------------------------------------------ > src/os/windows/vm/semaphore_windows.hpp > 43 void signal(uint count = 0); > > Default count of 0 is inconsistent with corresponding classes for > other platforms. This is a bug that I thought I had fixed. I'll change it. > > ------------------------------------------------------------------------------ > src/share/vm/runtime/semaphore.cpp > 30 Semaphore::Semaphore(uint value) : _impl(value) {} > 31 Semaphore::~Semaphore() {} > 32 void Semaphore::signal(uint count) { _impl.signal(count); } > 33 void Semaphore::wait() { _impl.wait(); } > > I'm not sure why these forwarding definitions are out of line in the > .cpp file, rather than inline in the header. After all, we've now > gone to some trouble to have the wrapped platform-specific > implementation class provide at least that set of operations. Because I don't think they are performance critical. Another reason is that one of my prototypes forward declared SemaphoreImpl in semaphore.hpp and only included the platform specific semaphore_xxx.hpp files in the semaphore.cpp file. But sure, I can inline them in the .hpp file. Thanks, StefanK > > ------------------------------------------------------------------------------ > From david.holmes at oracle.com Wed Jun 24 21:43:28 2015 From: david.holmes at oracle.com (David Holmes) Date: Thu, 25 Jun 2015 07:43:28 +1000 Subject: RFR (XS): 8129394: [TESTBUG] runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java failed with double option In-Reply-To: <558A9D7C.6000507@oracle.com> References: <558A9D7C.6000507@oracle.com> Message-ID: <558B2480.2090108@oracle.com> Hi Dmitry, On 24/06/2015 10:07 PM, Dmitry Dmitriev wrote: > Hello, > > Please review this small fix(2 lines changed) for recently added Command > Line Option Validation tests. > > The problem was found in test framework code for double options. > String.format("%f") was used to format double value and it depends on > current locale. Thus, on some locales the resulting string with double > value looks like: 0,999 (with comma) and JVM reports an error when > trying to parse double command line option with such value. In this fix > I explicitly add Locale.US to the String.format: > String.format(Locale.US, "%f", value); > > Webrev: http://cr.openjdk.java.net/~ddmitriev/8129394/webrev.00/ > > JBS: https://bugs.openjdk.java.net/browse/JDK-8129394 > Tested: locally ran with different locale - pass with the fix and fail > without fix, JPRT. Looks good. As this is a trivial test fix a single Review suffices. I will push this with your other change. David > Thanks, > Dmitry From kim.barrett at oracle.com Wed Jun 24 22:36:02 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 24 Jun 2015 18:36:02 -0400 Subject: RFR: 8087322: Implement a Semaphore utility class In-Reply-To: <558B21CB.1010901@oracle.com> References: <557AF8E4.9040804@oracle.com> <557F3582.6060401@oracle.com> <5581B597.5080900@oracle.com> <55836FF2.6070604@oracle.com> <55881B78.3040909@oracle.com> <558A8D78.5000209@oracle.com> <558B21CB.1010901@oracle.com> Message-ID: On Jun 24, 2015, at 5:31 PM, Stefan Karlsson wrote: > >> We already have assert_status in debug.hpp. It might be better to add >> a corresponding guarantee_status there, and use those here. >> > > 1) The comment above vmassert_status says: > // This version of vmassert is for use with checking return status from > // library calls that return actual error values eg. EINVAL, > // ENOMEM etc, rather than returning -1 and setting errno. > // When the status is not what is expected it is very useful to know > // what status was actually returned, so we pass the status variable as > // an extra arg and use strerror to convert it to a meaningful string > // like "Invalid argument", "out of memory" etc > > but called library calls actually do return -1 and sets errno. Maybe the comment is too specific? The comment seems to be wrong, since the status that gets passed to strerror is one of the macro arguments. So one could write something like: assert_status(ret == 0, errno, ?sem_post?); Maybe the macro had a different form at some point in the distant past? Or maybe there was some other macro (now gone) that provided strerror-based error reporting that was always unconditionally based on errno? From david.holmes at oracle.com Wed Jun 24 22:39:50 2015 From: david.holmes at oracle.com (David Holmes) Date: Thu, 25 Jun 2015 08:39:50 +1000 Subject: RFR: 8087322: Implement a Semaphore utility class In-Reply-To: <558B21CB.1010901@oracle.com> References: <557AF8E4.9040804@oracle.com> <557F3582.6060401@oracle.com> <5581B597.5080900@oracle.com> <55836FF2.6070604@oracle.com> <55881B78.3040909@oracle.com> <558A8D78.5000209@oracle.com> <558B21CB.1010901@oracle.com> Message-ID: <558B31B6.80002@oracle.com> A few follow ups on some comments ... On 25/06/2015 7:31 AM, Stefan Karlsson wrote: > Hi Kim, > > On 2015-06-24 22:28, Kim Barrett wrote: >> On Jun 24, 2015, at 6:59 AM, Stefan Karlsson wrote: >>> Hi all, >>> >>> Updated webrev: >>> http://cr.openjdk.java.net/~stefank/8087322/webrev.04 >> Structurally fine. (Stefan would be rightly annoyed with me if I said >> otherwise after all the offline discussions we've had.) There's some >> nastiness that results from pre-existing problems in the os_xxx.cpp >> files, but cleaning that up is another collection of tasks. >> >> A few easy bugs, some stylistic comments that can be accepted or >> declined, but nothing requiring large amounts of rework. >> >> ------------------------------------------------------------------------------ >> src/os/bsd/vm/os_bsd.cpp >> 1971 OSXSemaphore::OSXSemaphore(uint value) : _semaphore(0) { >> >> I think that initializer for _semaphore isn't right. _semaphore is a >> (OSX) semaphore_t. I think that initializer only accidentally >> compiles at all. > > This is one yet another case of pre-existing code. > >> >> ------------------------------------------------------------------------------ >> src/os/bsd/vm/semaphore_bsd.hpp >> 28 #include "memory/allocation.hpp" >> 29 >> 30 #include >> 31 >> 32 #ifndef __APPLE__ >> 33 # include "semaphore_posix.hpp" >> 34 #else >> 35 // OS X doesn't support unamed POSIX semaphores, so the implementation in os_posix.cpp can't be used. >> 36 >> 37 class OSXSemaphore : public CHeapObj{ >> >> This only needs "memory/allocation.hpp" in the Apple case. >> >> This doesn't need in the non-Apple case. > > OK. > >> >> In the Apple case, I think the correct include is >> rather than . I'm not sure why is working >> at all. > > I'll change it. 113 #ifdef __APPLE__ 114 #include // semaphore_* API No need for semaphore.h apparently. > >> >> ------------------------------------------------------------------------------ >> src/os/posix/vm/os_posix.cpp >> 1021 #define check_with_errno(check_type, cond, msg) \ >> 1022 do { \ >> 1023 int err = errno; \ >> 1024 check_type(cond, err_msg("%s; error='%s' (errno=%d)", msg, strerror(err), err)); \ >> 1025 } while (false) >> 1026 >> 1027 #define assert_with_errno(cond, msg) check_with_errno(assert, cond, msg) >> 1028 #define guarantee_with_errno(cond, msg) check_with_errno(guarantee, cond, msg) >> >> We already have assert_status in debug.hpp. It might be better to add >> a corresponding guarantee_status there, and use those here. > > 1) The comment above vmassert_status says: > > // This version of vmassert is for use with checking return status from > // library calls that return actual error values eg. EINVAL, > // ENOMEM etc, rather than returning -1 and setting errno. > // When the status is not what is expected it is very useful to know > // what status was actually returned, so we pass the status variable as > // an extra arg and use strerror to convert it to a meaningful string > // like "Invalid argument", "out of memory" etc > > > but called library calls actually do return -1 and sets errno. Maybe the > comment is too specific? No the comment is as I intended when I wrote it :) This was for those POSIX library calls that don't set errno and return -1, but which return an error code directly: eg the pthread_* family of functions for POSIX Where did you see another form of library call using it? It is possible some misuse has crept in. > 2) I modeled the error message with this code in mind: > > 2587 static void warn_fail_commit_memory(char* addr, size_t size, bool exec, > 2588 int err) { > 2589 warning("INFO: os::commit_memory(" PTR_FORMAT ", " SIZE_FORMAT > 2590 ", %d) failed; error='%s' (errno=%d)", addr, size, exec, > 2591 strerror(err), err); > 2592 } > >> >> Also, these macros are only used inside the #ifndef __APPLE__ block. > > Yes, but they are not specific to non-__APPLE__ code, so I chooe to put > it outside that block. > >> >> And welcome to the dark side. (Higher order macros!) >> >> ------------------------------------------------------------------------------ >> src/os/posix/vm/os_posix.cpp >> 1053 while ((ret = sem_wait(&_semaphore)) == -1 && errno == EINTR) { >> >> I would probably instead use >> >> (ret = sem_wait(&_semaphore)) != 0 >> >> e.g. while !successful. > > Sure. > >> >> ------------------------------------------------------------------------------ >> src/os/posix/vm/os_posix.cpp >> 1059 bool PosixSemaphore::trywait() { >> 1060 bool succeeded = sem_trywait(&_semaphore) == 0; >> 1061 >> 1062 assert_with_errno(succeeded || errno == EAGAIN, "trywait failed"); >> 1063 >> 1064 return succeeded; >> 1065 } >> >> sem_trywait can also fail with EINTR. > > Will fix the assert. trywait can't fail with EINTR as it does not block - so nothing can be interrupted. >> >> ------------------------------------------------------------------------------ >> src/os/posix/vm/os_posix.cpp >> 1072 } else if (errno == EINTR) { >> 1073 continue; >> 1074 } else if (errno == ETIMEDOUT) { >> >> I think ETIMEDOUT should be tested before EINTR. ETIMEDOUT is the >> more interesting and performance relevant case. > > This pre-existing code can be fixed as a separate RFE. > >> >> ------------------------------------------------------------------------------ >> src/os/windows/vm/os_windows.cpp >> 1905 WindowsSemaphore::~WindowsSemaphore() { >> 1906 if (_semaphore != NULL) { >> 1907 ::CloseHandle(_semaphore); >> 1908 } >> >> I don't think the NULL check is needed here. > > I'll remove it. Not clear to me that we don't need it, and we do perform null checks elsewhere in the windows code. >> >> ------------------------------------------------------------------------------ >> src/os/bsd/vm/semaphore_bsd.hpp >> 56 static jlong currenttime(); >> >> This function is an implementation detail of the timedwait function, >> and could be a file-scoped static near its caller, rather than having >> external linkage. > > Yes. I put it in the class so that I wouldn't have to create a prefix > for currenttime and to make it obvious that only the OSXSemaphore uses > that function. > >> >> [The PosixSemaphore class is different in this respect, because there >> we need to choose between platform-specific definitions of >> create_timespec that will be in a different file from the reference, >> so external linkage is required. That situation doesn't apply for >> OSXSemaphore.] >> >> ------------------------------------------------------------------------------ >> src/os/windows/vm/semaphore_windows.hpp >> 30 #include >> >> I think is sufficient here, and is purportedly smaller. >> The .cpp file likely needs more, but is already including . >> Also, it looks like we prefer the lowercase form on Windows, even >> though the file system is case-insensitive. > > I'll fix. > >> >> ------------------------------------------------------------------------------ >> src/os/windows/vm/semaphore_windows.hpp >> 43 void signal(uint count = 0); >> >> Default count of 0 is inconsistent with corresponding classes for >> other platforms. > > This is a bug that I thought I had fixed. I'll change it. Oops - missed that! Thanks, David >> >> ------------------------------------------------------------------------------ >> src/share/vm/runtime/semaphore.cpp >> 30 Semaphore::Semaphore(uint value) : _impl(value) {} >> 31 Semaphore::~Semaphore() {} >> 32 void Semaphore::signal(uint count) { _impl.signal(count); } >> 33 void Semaphore::wait() { _impl.wait(); } >> >> I'm not sure why these forwarding definitions are out of line in the >> .cpp file, rather than inline in the header. After all, we've now >> gone to some trouble to have the wrapped platform-specific >> implementation class provide at least that set of operations. > > Because I don't think they are performance critical. Another reason is > that one of my prototypes forward declared SemaphoreImpl in > semaphore.hpp and only included the platform specific semaphore_xxx.hpp > files in the semaphore.cpp file. > > But sure, I can inline them in the .hpp file. > > Thanks, > StefanK >> >> ------------------------------------------------------------------------------ >> > From kim.barrett at oracle.com Wed Jun 24 22:46:55 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 24 Jun 2015 18:46:55 -0400 Subject: RFR: 8087322: Implement a Semaphore utility class In-Reply-To: <558B31B6.80002@oracle.com> References: <557AF8E4.9040804@oracle.com> <557F3582.6060401@oracle.com> <5581B597.5080900@oracle.com> <55836FF2.6070604@oracle.com> <55881B78.3040909@oracle.com> <558A8D78.5000209@oracle.com> <558B21CB.1010901@oracle.com> <558B31B6.80002@oracle.com> Message-ID: <82FD5DE9-176A-4999-8E80-208B7311E731@oracle.com> On Jun 24, 2015, at 6:39 PM, David Holmes wrote: > >> 1) The comment above vmassert_status says: >> >> // This version of vmassert is for use with checking return status from >> // library calls that return actual error values eg. EINVAL, >> // ENOMEM etc, rather than returning -1 and setting errno. >> // When the status is not what is expected it is very useful to know >> // what status was actually returned, so we pass the status variable as >> // an extra arg and use strerror to convert it to a meaningful string >> // like "Invalid argument", "out of memory" etc >> >> >> but called library calls actually do return -1 and sets errno. Maybe the >> comment is too specific? > > No the comment is as I intended when I wrote it :) This was for those POSIX library calls that don't set errno and return -1, but which return an error code directly: eg the pthread_* family of functions for POSIX > > Where did you see another form of library call using it? It is possible some misuse has crept in. Oh, good, we actually have original intent available. Would you consider it a misuse to do assert_status(ret == 0, errno, ); From kim.barrett at oracle.com Wed Jun 24 23:07:10 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 24 Jun 2015 19:07:10 -0400 Subject: RFR: 8087322: Implement a Semaphore utility class In-Reply-To: <558B31B6.80002@oracle.com> References: <557AF8E4.9040804@oracle.com> <557F3582.6060401@oracle.com> <5581B597.5080900@oracle.com> <55836FF2.6070604@oracle.com> <55881B78.3040909@oracle.com> <558A8D78.5000209@oracle.com> <558B21CB.1010901@oracle.com> <558B31B6.80002@oracle.com> Message-ID: <0AE53977-AF81-481E-B8BD-C8ADBEB6250E@oracle.com> On Jun 24, 2015, at 6:39 PM, David Holmes wrote: > >>> sem_trywait can also fail with EINTR. >> >> Will fix the assert. > > trywait can't fail with EINTR as it does not block - so nothing can be interrupted. When dealing with standards like POSIX, I generally try to listen as closely as I can to what the standard says, rather than trusting my intuition about how something "ought" to work. Compiler and library authors are known for driving trucks through holes in one's intuition, and then saying nyah, nyah to complaints. So when POSIX says sem_trywait can return an error of EINTR and my intuition says "no way", *I* still include the check. YMMV. >>> src/os/windows/vm/os_windows.cpp >>> 1905 WindowsSemaphore::~WindowsSemaphore() { >>> 1906 if (_semaphore != NULL) { >>> 1907 ::CloseHandle(_semaphore); >>> 1908 } >>> >>> I don't think the NULL check is needed here. >> >> I'll remove it. > > Not clear to me that we don't need it, and we do perform null checks elsewhere in the windows code. We already have a NULL check in the constructor, and terminate if that fails. From david.holmes at oracle.com Wed Jun 24 23:32:24 2015 From: david.holmes at oracle.com (David Holmes) Date: Thu, 25 Jun 2015 09:32:24 +1000 Subject: RFR: 8087322: Implement a Semaphore utility class In-Reply-To: <0AE53977-AF81-481E-B8BD-C8ADBEB6250E@oracle.com> References: <557AF8E4.9040804@oracle.com> <557F3582.6060401@oracle.com> <5581B597.5080900@oracle.com> <55836FF2.6070604@oracle.com> <55881B78.3040909@oracle.com> <558A8D78.5000209@oracle.com> <558B21CB.1010901@oracle.com> <558B31B6.80002@oracle.com> <0AE53977-AF81-481E-B8BD-C8ADBEB6250E@oracle.com> Message-ID: <558B3E08.5020109@oracle.com> On 25/06/2015 9:07 AM, Kim Barrett wrote: > On Jun 24, 2015, at 6:39 PM, David Holmes wrote: >> >>>> sem_trywait can also fail with EINTR. >>> >>> Will fix the assert. >> >> trywait can't fail with EINTR as it does not block - so nothing can be interrupted. > > When dealing with standards like POSIX, I generally try to listen as > closely as I can to what the standard says, rather than trusting my > intuition about how something "ought" to work. Compiler and library > authors are known for driving trucks through holes in one's intuition, > and then saying nyah, nyah to complaints. > > So when POSIX says sem_trywait can return an error of EINTR and my > intuition says "no way", *I* still include the check. YMMV. The POSIX spec is somewhat inconsistent on the matter: http://pubs.opengroup.org/onlinepubs/9699919799/functions/sem_trywait.html It states explicitly: "The sem_wait() function is interruptible by the delivery of a signal." Nothing about trywait - which makes sense as trywait never actually waits - but also says in the ERRORS section that trywait may fail if interrupted by a signal. So yes we should check for EINTR on the trywait - and retry I guess? >>>> src/os/windows/vm/os_windows.cpp >>>> 1905 WindowsSemaphore::~WindowsSemaphore() { >>>> 1906 if (_semaphore != NULL) { >>>> 1907 ::CloseHandle(_semaphore); >>>> 1908 } >>>> >>>> I don't think the NULL check is needed here. >>> >>> I'll remove it. >> >> Not clear to me that we don't need it, and we do perform null checks elsewhere in the windows code. > > We already have a NULL check in the constructor, and terminate if that fails. Yes my mistake. Thanks, David From david.holmes at oracle.com Wed Jun 24 23:44:04 2015 From: david.holmes at oracle.com (David Holmes) Date: Thu, 25 Jun 2015 09:44:04 +1000 Subject: RFR: 8087322: Implement a Semaphore utility class In-Reply-To: <82FD5DE9-176A-4999-8E80-208B7311E731@oracle.com> References: <557AF8E4.9040804@oracle.com> <557F3582.6060401@oracle.com> <5581B597.5080900@oracle.com> <55836FF2.6070604@oracle.com> <55881B78.3040909@oracle.com> <558A8D78.5000209@oracle.com> <558B21CB.1010901@oracle.com> <558B31B6.80002@oracle.com> <82FD5DE9-176A-4999-8E80-208B7311E731@oracle.com> Message-ID: <558B40C4.2010408@oracle.com> On 25/06/2015 8:46 AM, Kim Barrett wrote: > On Jun 24, 2015, at 6:39 PM, David Holmes wrote: >> >>> 1) The comment above vmassert_status says: >>> >>> // This version of vmassert is for use with checking return status from >>> // library calls that return actual error values eg. EINVAL, >>> // ENOMEM etc, rather than returning -1 and setting errno. >>> // When the status is not what is expected it is very useful to know >>> // what status was actually returned, so we pass the status variable as >>> // an extra arg and use strerror to convert it to a meaningful string >>> // like "Invalid argument", "out of memory" etc >>> >>> >>> but called library calls actually do return -1 and sets errno. Maybe the >>> comment is too specific? >> >> No the comment is as I intended when I wrote it :) This was for those POSIX library calls that don't set errno and return -1, but which return an error code directly: eg the pthread_* family of functions for POSIX >> >> Where did you see another form of library call using it? It is possible some misuse has crept in. > > Oh, good, we actually have original intent available. > > Would you consider it a misuse to do > > assert_status(ret == 0, errno, ); That works, but it wasn't the intended use case :) And of course you have to be sure that when the macro expands there are no intervening calls that will potentially modify errno - which there aren't in this case. But if we're going to start using it this way then the comment block needs updating to clarify the two different use-cases. David From dean.long at oracle.com Wed Jun 24 23:49:23 2015 From: dean.long at oracle.com (Dean Long) Date: Wed, 24 Jun 2015 16:49:23 -0700 Subject: RFR: 8087322: Implement a Semaphore utility class In-Reply-To: <558B3E08.5020109@oracle.com> References: <557AF8E4.9040804@oracle.com> <557F3582.6060401@oracle.com> <5581B597.5080900@oracle.com> <55836FF2.6070604@oracle.com> <55881B78.3040909@oracle.com> <558A8D78.5000209@oracle.com> <558B21CB.1010901@oracle.com> <558B31B6.80002@oracle.com> <0AE53977-AF81-481E-B8BD-C8ADBEB6250E@oracle.com> <558B3E08.5020109@oracle.com> Message-ID: <558B4203.3010507@oracle.com> On 6/24/2015 4:32 PM, David Holmes wrote: > On 25/06/2015 9:07 AM, Kim Barrett wrote: >> On Jun 24, 2015, at 6:39 PM, David Holmes >> wrote: >>> >>>>> sem_trywait can also fail with EINTR. >>>> >>>> Will fix the assert. >>> >>> trywait can't fail with EINTR as it does not block - so nothing can >>> be interrupted. >> >> When dealing with standards like POSIX, I generally try to listen as >> closely as I can to what the standard says, rather than trusting my >> intuition about how something "ought" to work. Compiler and library >> authors are known for driving trucks through holes in one's intuition, >> and then saying nyah, nyah to complaints. >> >> So when POSIX says sem_trywait can return an error of EINTR and my >> intuition says "no way", *I* still include the check. YMMV. > > The POSIX spec is somewhat inconsistent on the matter: > > http://pubs.opengroup.org/onlinepubs/9699919799/functions/sem_trywait.html > > > It states explicitly: > > "The sem_wait() function is interruptible by the delivery of a signal." > > Nothing about trywait - which makes sense as trywait never actually > waits - but also says in the ERRORS section that trywait may fail if > interrupted by a signal. > > So yes we should check for EINTR on the trywait - and retry I guess? Retry doesn't sound necessary for trywait, and an unbounded number of retries sounds bad. I would think one attempt is enough. dl From bengt.rutisson at oracle.com Thu Jun 25 06:48:13 2015 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Thu, 25 Jun 2015 08:48:13 +0200 Subject: RFR (XXS): 8129604: Incorrect GPL header in README file causes RE script to produce wrong output In-Reply-To: <1435161627.2512.309.camel@oracle.com> References: <1435161627.2512.309.camel@oracle.com> Message-ID: <558BA42D.5060404@oracle.com> Hi Thomas, On 2015-06-24 18:00, Thomas Schatzl wrote: > Hi again, > > another one (I hope the last) of the changes that fix the GPL headers, > this time for a README file. The mentioned RE script does not like GPL > headers starting with a "#" or "*" in non-source code files. > > This changes simply removes the "#" at the start of the affected file. > > CR (confidential, sorry): > https://bugs.openjdk.java.net/browse/JDK-8129604 > > Webrev: > http://cr.openjdk.java.net/~tschatzl/8129604/webrev/ > > The same patch also needs to go into 8u60, but applies cleanly. Looks good. Thanks for taking care of the copyright issues! Bengt > > Thanks, > Thomas > > From thomas.schatzl at oracle.com Thu Jun 25 08:20:29 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Thu, 25 Jun 2015 10:20:29 +0200 Subject: RFR (XXS): 8129604: Incorrect GPL header in README file causes RE script to produce wrong output In-Reply-To: <558BA42D.5060404@oracle.com> References: <1435161627.2512.309.camel@oracle.com> <558BA42D.5060404@oracle.com> Message-ID: <1435220429.2431.23.camel@oracle.com> Hi Bengt, Coleen, On Thu, 2015-06-25 at 08:48 +0200, Bengt Rutisson wrote: > Hi Thomas, > > On 2015-06-24 18:00, Thomas Schatzl wrote: > > Hi again, > > > > another one (I hope the last) of the changes that fix the GPL headers, > > this time for a README file. The mentioned RE script does not like GPL > > headers starting with a "#" or "*" in non-source code files. > > > > This changes simply removes the "#" at the start of the affected file. > > > > CR (confidential, sorry): > > https://bugs.openjdk.java.net/browse/JDK-8129604 > > > > Webrev: > > http://cr.openjdk.java.net/~tschatzl/8129604/webrev/ > > > > The same patch also needs to go into 8u60, but applies cleanly. > > Looks good. Thanks for taking care of the copyright issues! thanks for the reviews. Thomas From zoltan.majo at oracle.com Thu Jun 25 11:49:17 2015 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Thu, 25 Jun 2015 13:49:17 +0200 Subject: [9] RFR(M): 8076112: Add @HotSpotIntrinsicCandidate annotation to indicate methods for which Java Runtime has intrinsics Message-ID: <558BEABD.7090907@oracle.com> Hi, please review the patch for JDK-8076112. Bug: https://bugs.openjdk.java.net/browse/JDK-8076112 Problem: There is need to indicate Java methods that are potentially intrinsified by JVM. Solution: Mark intrinsified methods with the jdk.internal.HotSpotIntrinsicCandidate annotation. Add checks that are omitted by VM-level intrinsics to the library code. Add a new diagnostic flag, CheckIntrinsics. If CheckIntrinsics is enabled, the VM performs the following checks when a class C is loaded: - all intrinsics defined by the VM for class C are present in the loaded class file and are marked; - an intrinsic is defined by the VM for all marked methods of C. If a mismatch is detected, the following is done: - a fastdebug VM prints a warning and then exits; - a product VM prints a warning and unmarked are not intrinsified. Webrev: - top: http://cr.openjdk.java.net/~zmajo/8076112/top/webrev.05/ - jdk: http://cr.openjdk.java.net/~zmajo/8076112/jdk/webrev.05/ - hotspot: http://cr.openjdk.java.net/~zmajo/8076112/hotspot/webrev.05/ Testing: - JPRT run with the 'hotspot' testset, all tests pass; - all JTREG hotspot tests, all tests pass that pass with a VM version that does not include the patch; all tests were run with -XX:+CheckIntrinsics. Thank you and best regards, Zoltan From dmitry.dmitriev at oracle.com Thu Jun 25 12:17:30 2015 From: dmitry.dmitriev at oracle.com (Dmitry Dmitriev) Date: Thu, 25 Jun 2015 15:17:30 +0300 Subject: IgnoreUnrecognizedVMOptions and badly specified options Message-ID: <558BF15A.6030702@oracle.com> Hello, Working with JVM command line options I noticed that "IgnoreUnrecognizedVMOptions" option allow to hide options with bad values. "IgnoreUnrecognizedVMOptions" allow to ignore unrecognized options, but it also allow to ignore improperly specified VM Options which are processed in general way, i.e. "-XX:" options processed by Arguments::process_argument function(hotspot/src/share/vm/runtime/arguments.cpp module). I will be very appreciated if someone can describe this behavior or state that this is intentional. Example for numeric and boolean options: 1) Bad numeric option with and without "-XX:+IgnoreUnrecongnizedVMOptions" java -XX:MaxRAMFraction=-1 -version Improperly specified VM option 'MaxRAMFraction=-1' Error: Could not create the Java Virtual Machine. Error: A fatal exception has occurred. Program will exit. java -XX:MaxRAMFraction=-1 -XX:+IgnoreUnrecognizedVMOptions -version java version "1.8.0_40" Java(TM) SE Runtime Environment (build 1.8.0_40-b26) Java HotSpot(TM) 64-Bit Server VM (build 25.40-b25, mixed mode) 2) Bad boolean option with and without "-XX:+IgnoreUnrecongnizedVMOptions" java -XX:UseG1GC -version Missing +/- setting for VM option 'UseG1GC' Error: Could not create the Java Virtual Machine. Error: A fatal exception has occurred. Program will exit. java -XX:UseG1GC -XX:+IgnoreUnrecognizedVMOptions -version java version "1.8.0_40" Java(TM) SE Runtime Environment (build 1.8.0_40-b26) Java HotSpot(TM) 64-Bit Server VM (build 25.40-b25, mixed mode) So, as we see when "-XX:+IgnoreUnrecongnizedVMOptions" is used, bad "-XX:MaxRAMFraction=-1" and "-XX:UseG1GC" are ignored. I don't know is this behavior intentional or not, but HotSpot works in that way. So, can someone tell me this is intentional? Or this behavior is wrong? Thank you, Dmitry From vladimir.kozlov at oracle.com Thu Jun 25 14:45:47 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 25 Jun 2015 07:45:47 -0700 Subject: IgnoreUnrecognizedVMOptions and badly specified options In-Reply-To: <558BF15A.6030702@oracle.com> References: <558BF15A.6030702@oracle.com> Message-ID: <558C141B.9080006@oracle.com> It is not intentional but difficult to implement. It was added to allow specify options which are not defined in running VM. For example when C2 option is specified but Client VM (which has only C1) is run. We can do more smarter things here, I agree, by trying to verify options before ignoring it. But it will not help with misspelled options, I think. Regards, Vladimir On 6/25/15 5:17 AM, Dmitry Dmitriev wrote: > Hello, > > Working with JVM command line options I noticed that "IgnoreUnrecognizedVMOptions" option allow to hide options with bad > values. "IgnoreUnrecognizedVMOptions" allow to ignore unrecognized options, but it also allow to ignore improperly > specified VM Options which are processed in general way, i.e. "-XX:" options processed by Arguments::process_argument > function(hotspot/src/share/vm/runtime/arguments.cpp module). > > I will be very appreciated if someone can describe this behavior or state that this is intentional. > > Example for numeric and boolean options: > 1) Bad numeric option with and without "-XX:+IgnoreUnrecongnizedVMOptions" > java -XX:MaxRAMFraction=-1 -version > Improperly specified VM option 'MaxRAMFraction=-1' > Error: Could not create the Java Virtual Machine. > Error: A fatal exception has occurred. Program will exit. > > java -XX:MaxRAMFraction=-1 -XX:+IgnoreUnrecognizedVMOptions -version > java version "1.8.0_40" > Java(TM) SE Runtime Environment (build 1.8.0_40-b26) > Java HotSpot(TM) 64-Bit Server VM (build 25.40-b25, mixed mode) > > 2) Bad boolean option with and without "-XX:+IgnoreUnrecongnizedVMOptions" > java -XX:UseG1GC -version > Missing +/- setting for VM option 'UseG1GC' > Error: Could not create the Java Virtual Machine. > Error: A fatal exception has occurred. Program will exit. > > java -XX:UseG1GC -XX:+IgnoreUnrecognizedVMOptions -version > java version "1.8.0_40" > Java(TM) SE Runtime Environment (build 1.8.0_40-b26) > Java HotSpot(TM) 64-Bit Server VM (build 25.40-b25, mixed mode) > > So, as we see when "-XX:+IgnoreUnrecongnizedVMOptions" is used, bad "-XX:MaxRAMFraction=-1" and "-XX:UseG1GC" are > ignored. I don't know is this behavior intentional or not, but HotSpot works in that way. > > So, can someone tell me this is intentional? Or this behavior is wrong? > > Thank you, > Dmitry > > From stefan.karlsson at oracle.com Thu Jun 25 16:42:49 2015 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Thu, 25 Jun 2015 18:42:49 +0200 Subject: RFR: 8087322: Implement a Semaphore utility class In-Reply-To: <558B21CB.1010901@oracle.com> References: <557AF8E4.9040804@oracle.com> <557F3582.6060401@oracle.com> <5581B597.5080900@oracle.com> <55836FF2.6070604@oracle.com> <55881B78.3040909@oracle.com> <558A8D78.5000209@oracle.com> <558B21CB.1010901@oracle.com> Message-ID: <558C2F89.3070908@oracle.com> Hi all, Updated webrev: http://cr.openjdk.java.net/~stefank/8087322/webrev.05.delta http://cr.openjdk.java.net/~stefank/8087322/webrev.05 - Removed unnecessary and incorrect initialization of _semaphore - Fixed includes - Loop around sem_trywait if EINTR is reported - Removed unnecessary NULL check on windows - Fixed the default value for signal(uint count), on windows. - Moved Sempahore implementation from semaphore.cpp to semaphore.hpp I skipped implementing some of the suggestions that were not essential for this patch or that we haven't reached an agreement on. It doesn't mean that I don't think we should do some of the cleanups. If we could get the structural changes in place (and bug fixes), then we can fix some of the details as follow-up RFEs. Thanks, StefanK On 2015-06-24 23:31, Stefan Karlsson wrote: > Hi Kim, > > On 2015-06-24 22:28, Kim Barrett wrote: >> On Jun 24, 2015, at 6:59 AM, Stefan Karlsson >> wrote: >>> Hi all, >>> >>> Updated webrev: >>> http://cr.openjdk.java.net/~stefank/8087322/webrev.04 >> Structurally fine. (Stefan would be rightly annoyed with me if I said >> otherwise after all the offline discussions we've had.) There's some >> nastiness that results from pre-existing problems in the os_xxx.cpp >> files, but cleaning that up is another collection of tasks. >> >> A few easy bugs, some stylistic comments that can be accepted or >> declined, but nothing requiring large amounts of rework. >> >> ------------------------------------------------------------------------------ >> >> src/os/bsd/vm/os_bsd.cpp >> 1971 OSXSemaphore::OSXSemaphore(uint value) : _semaphore(0) { >> >> I think that initializer for _semaphore isn't right. _semaphore is a >> (OSX) semaphore_t. I think that initializer only accidentally >> compiles at all. > > This is one yet another case of pre-existing code. > >> >> ------------------------------------------------------------------------------ >> >> src/os/bsd/vm/semaphore_bsd.hpp >> 28 #include "memory/allocation.hpp" >> 29 >> 30 #include >> 31 >> 32 #ifndef __APPLE__ >> 33 # include "semaphore_posix.hpp" >> 34 #else >> 35 // OS X doesn't support unamed POSIX semaphores, so the >> implementation in os_posix.cpp can't be used. >> 36 >> 37 class OSXSemaphore : public CHeapObj{ >> >> This only needs "memory/allocation.hpp" in the Apple case. >> >> This doesn't need in the non-Apple case. > > OK. > >> >> In the Apple case, I think the correct include is >> rather than . I'm not sure why is working >> at all. > > I'll change it. > >> >> ------------------------------------------------------------------------------ >> >> src/os/posix/vm/os_posix.cpp >> 1021 #define check_with_errno(check_type, cond, >> msg) \ >> 1022 do { \ >> 1023 int err = errno; \ >> 1024 check_type(cond, err_msg("%s; error='%s' (errno=%d)", msg, >> strerror(err), err)); \ >> 1025 } while (false) >> 1026 >> 1027 #define assert_with_errno(cond, msg) check_with_errno(assert, >> cond, msg) >> 1028 #define guarantee_with_errno(cond, msg) >> check_with_errno(guarantee, cond, msg) >> >> We already have assert_status in debug.hpp. It might be better to add >> a corresponding guarantee_status there, and use those here. > > 1) The comment above vmassert_status says: > > // This version of vmassert is for use with checking return status from > // library calls that return actual error values eg. EINVAL, > // ENOMEM etc, rather than returning -1 and setting errno. > // When the status is not what is expected it is very useful to know > // what status was actually returned, so we pass the status variable as > // an extra arg and use strerror to convert it to a meaningful string > // like "Invalid argument", "out of memory" etc > > > but called library calls actually do return -1 and sets errno. Maybe > the comment is too specific? > > 2) I modeled the error message with this code in mind: > > 2587 static void warn_fail_commit_memory(char* addr, size_t size, bool > exec, > 2588 int err) { > 2589 warning("INFO: os::commit_memory(" PTR_FORMAT ", " SIZE_FORMAT > 2590 ", %d) failed; error='%s' (errno=%d)", addr, size, exec, > 2591 strerror(err), err); > 2592 } > >> >> Also, these macros are only used inside the #ifndef __APPLE__ block. > > Yes, but they are not specific to non-__APPLE__ code, so I chooe to > put it outside that block. > >> >> And welcome to the dark side. (Higher order macros!) >> >> ------------------------------------------------------------------------------ >> >> src/os/posix/vm/os_posix.cpp >> 1053 while ((ret = sem_wait(&_semaphore)) == -1 && errno == EINTR) { >> >> I would probably instead use >> >> (ret = sem_wait(&_semaphore)) != 0 >> >> e.g. while !successful. > > Sure. > >> >> ------------------------------------------------------------------------------ >> >> src/os/posix/vm/os_posix.cpp >> 1059 bool PosixSemaphore::trywait() { >> 1060 bool succeeded = sem_trywait(&_semaphore) == 0; >> 1061 >> 1062 assert_with_errno(succeeded || errno == EAGAIN, "trywait >> failed"); >> 1063 >> 1064 return succeeded; >> 1065 } >> >> sem_trywait can also fail with EINTR. > > Will fix the assert. > >> >> ------------------------------------------------------------------------------ >> >> src/os/posix/vm/os_posix.cpp >> 1072 } else if (errno == EINTR) { >> 1073 continue; >> 1074 } else if (errno == ETIMEDOUT) { >> >> I think ETIMEDOUT should be tested before EINTR. ETIMEDOUT is the >> more interesting and performance relevant case. > > This pre-existing code can be fixed as a separate RFE. > >> >> ------------------------------------------------------------------------------ >> >> src/os/windows/vm/os_windows.cpp >> 1905 WindowsSemaphore::~WindowsSemaphore() { >> 1906 if (_semaphore != NULL) { >> 1907 ::CloseHandle(_semaphore); >> 1908 } >> >> I don't think the NULL check is needed here. > > I'll remove it. > >> >> ------------------------------------------------------------------------------ >> >> src/os/bsd/vm/semaphore_bsd.hpp >> 56 static jlong currenttime(); >> >> This function is an implementation detail of the timedwait function, >> and could be a file-scoped static near its caller, rather than having >> external linkage. > > Yes. I put it in the class so that I wouldn't have to create a prefix > for currenttime and to make it obvious that only the OSXSemaphore uses > that function. > >> >> [The PosixSemaphore class is different in this respect, because there >> we need to choose between platform-specific definitions of >> create_timespec that will be in a different file from the reference, >> so external linkage is required. That situation doesn't apply for >> OSXSemaphore.] >> >> ------------------------------------------------------------------------------ >> >> src/os/windows/vm/semaphore_windows.hpp >> 30 #include >> >> I think is sufficient here, and is purportedly smaller. >> The .cpp file likely needs more, but is already including . >> Also, it looks like we prefer the lowercase form on Windows, even >> though the file system is case-insensitive. > > I'll fix. > >> >> ------------------------------------------------------------------------------ >> >> src/os/windows/vm/semaphore_windows.hpp >> 43 void signal(uint count = 0); >> >> Default count of 0 is inconsistent with corresponding classes for >> other platforms. > > This is a bug that I thought I had fixed. I'll change it. > >> >> ------------------------------------------------------------------------------ >> >> src/share/vm/runtime/semaphore.cpp >> 30 Semaphore::Semaphore(uint value) : _impl(value) {} >> 31 Semaphore::~Semaphore() {} >> 32 void Semaphore::signal(uint count) { _impl.signal(count); } >> 33 void Semaphore::wait() { _impl.wait(); } >> >> I'm not sure why these forwarding definitions are out of line in the >> .cpp file, rather than inline in the header. After all, we've now >> gone to some trouble to have the wrapped platform-specific >> implementation class provide at least that set of operations. > > Because I don't think they are performance critical. Another reason is > that one of my prototypes forward declared SemaphoreImpl in > semaphore.hpp and only included the platform specific > semaphore_xxx.hpp files in the semaphore.cpp file. > > But sure, I can inline them in the .hpp file. > > Thanks, > StefanK >> >> ------------------------------------------------------------------------------ >> >> > From dmitry.dmitriev at oracle.com Thu Jun 25 17:00:07 2015 From: dmitry.dmitriev at oracle.com (Dmitry Dmitriev) Date: Thu, 25 Jun 2015 20:00:07 +0300 Subject: IgnoreUnrecognizedVMOptions and badly specified options In-Reply-To: <558C141B.9080006@oracle.com> References: <558BF15A.6030702@oracle.com> <558C141B.9080006@oracle.com> Message-ID: <558C3397.80001@oracle.com> Hello Vladimir, Thank you for explanation. I just was bit confused about valid VM options but which improperly specified. I look at the Arguments::process_argument function in src/share/vm/runtime/arguments.cpp module and noticed one thing: 817 bool Arguments::process_argument(const char* arg, 818 jboolean ignore_unrecognized, Flag::Flags origin) { 819 820 JDK_Version since = JDK_Version(); 821 822 if (parse_argument(arg, origin) || ignore_unrecognized) { 823 return true; 824 } ... 850 // For locked flags, report a custom error message if available. 851 // Otherwise, report the standard unrecognized VM option. 852 Flag* found_flag = Flag::find_flag((const char*)argname, arg_len, true, true); 853 if (found_flag != NULL) { 854 char locked_message_buf[BUFLEN]; 855 found_flag->get_locked_message(locked_message_buf, BUFLEN); 856 if (strlen(locked_message_buf) == 0) { 857 if (found_flag->is_bool() && !has_plus_minus) { 858 jio_fprintf(defaultStream::error_stream(), 859 "Missing +/- setting for VM option '%s'\n", argname); 860 } else if (!found_flag->is_bool() && has_plus_minus) { 861 jio_fprintf(defaultStream::error_stream(), 862 "Unexpected +/- setting in VM option '%s'\n", argname); 863 } else { 864 jio_fprintf(defaultStream::error_stream(), 865 "Improperly specified VM option '%s'\n", argname); 866 } 867 } else { 868 jio_fprintf(defaultStream::error_stream(), "%s", locked_message_buf); 869 } 870 } else { 871 jio_fprintf(defaultStream::error_stream(), 872 "Unrecognized VM option '%s'\n", argname); 873 Flag* fuzzy_matched = Flag::fuzzy_match((const char*)argname, arg_len, true); 874 if (fuzzy_matched != NULL) { 875 jio_fprintf(defaultStream::error_stream(), 876 "Did you mean '%s%s%s'? ", 877 (fuzzy_matched->is_bool()) ? "(+/-)" : "", 878 fuzzy_matched->_name, 879 (fuzzy_matched->is_bool()) ? "" : "="); 880 } 881 } 882 883 // allow for commandline "commenting out" options like -XX:#+Verbose 884 return arg[0] == '#'; 885 } If "-XX:+IgnoreUnrecongnizedVMOptions" is specified, then "ignore_unrecognized" will be true and "if" statement on line 822 will always be true. I just think that a better place to check "ignore_unrecognized" is on "else" branch on line 867(for locked flags) and on "else" branch on line 870(where we actually found unrecognized option). If "ignore_unrecognized" is true, then return true in this case, otherwise execute code in these "else" branches. It's my thoughts about that. In this case improperly specified options will be catched(lines 857-866). Thanks, Dmitry On 25.06.2015 17:45, Vladimir Kozlov wrote: > It is not intentional but difficult to implement. > It was added to allow specify options which are not defined in running > VM. > For example when C2 option is specified but Client VM (which has only > C1) is run. > We can do more smarter things here, I agree, by trying to verify > options before ignoring it. > But it will not help with misspelled options, I think. > > Regards, > Vladimir > > On 6/25/15 5:17 AM, Dmitry Dmitriev wrote: >> Hello, >> >> Working with JVM command line options I noticed that >> "IgnoreUnrecognizedVMOptions" option allow to hide options with bad >> values. "IgnoreUnrecognizedVMOptions" allow to ignore unrecognized >> options, but it also allow to ignore improperly >> specified VM Options which are processed in general way, i.e. "-XX:" >> options processed by Arguments::process_argument >> function(hotspot/src/share/vm/runtime/arguments.cpp module). >> >> I will be very appreciated if someone can describe this behavior or >> state that this is intentional. >> >> Example for numeric and boolean options: >> 1) Bad numeric option with and without >> "-XX:+IgnoreUnrecongnizedVMOptions" >> java -XX:MaxRAMFraction=-1 -version >> Improperly specified VM option 'MaxRAMFraction=-1' >> Error: Could not create the Java Virtual Machine. >> Error: A fatal exception has occurred. Program will exit. >> >> java -XX:MaxRAMFraction=-1 -XX:+IgnoreUnrecognizedVMOptions -version >> java version "1.8.0_40" >> Java(TM) SE Runtime Environment (build 1.8.0_40-b26) >> Java HotSpot(TM) 64-Bit Server VM (build 25.40-b25, mixed mode) >> >> 2) Bad boolean option with and without >> "-XX:+IgnoreUnrecongnizedVMOptions" >> java -XX:UseG1GC -version >> Missing +/- setting for VM option 'UseG1GC' >> Error: Could not create the Java Virtual Machine. >> Error: A fatal exception has occurred. Program will exit. >> >> java -XX:UseG1GC -XX:+IgnoreUnrecognizedVMOptions -version >> java version "1.8.0_40" >> Java(TM) SE Runtime Environment (build 1.8.0_40-b26) >> Java HotSpot(TM) 64-Bit Server VM (build 25.40-b25, mixed mode) >> >> So, as we see when "-XX:+IgnoreUnrecongnizedVMOptions" is used, bad >> "-XX:MaxRAMFraction=-1" and "-XX:UseG1GC" are >> ignored. I don't know is this behavior intentional or not, but >> HotSpot works in that way. >> >> So, can someone tell me this is intentional? Or this behavior is wrong? >> >> Thank you, >> Dmitry >> >> From dmitry.dmitriev at oracle.com Thu Jun 25 17:04:34 2015 From: dmitry.dmitriev at oracle.com (Dmitry Dmitriev) Date: Thu, 25 Jun 2015 20:04:34 +0300 Subject: IgnoreUnrecognizedVMOptions and badly specified options In-Reply-To: <558C3397.80001@oracle.com> References: <558BF15A.6030702@oracle.com> <558C141B.9080006@oracle.com> <558C3397.80001@oracle.com> Message-ID: <558C34A2.8010105@oracle.com> Sorry about bad code paste(and repeate my thoughts after code): 817 bool Arguments::process_argument(const char* arg, 818 jboolean ignore_unrecognized, Flag::Flags origin) { 819 820 JDK_Version since = JDK_Version(); 821 822 if (parse_argument(arg, origin) || ignore_unrecognized) { 823 return true; 824 } ... 850 // For locked flags, report a custom error message if available. 851 // Otherwise, report the standard unrecognized VM option. 852 Flag* found_flag = Flag::find_flag((const char*)argname, arg_len, true, true); 853 if (found_flag != NULL) { 854 char locked_message_buf[BUFLEN]; 855 found_flag->get_locked_message(locked_message_buf, BUFLEN); 856 if (strlen(locked_message_buf) == 0) { 857 if (found_flag->is_bool() && !has_plus_minus) { 858 jio_fprintf(defaultStream::error_stream(), 859 "Missing +/- setting for VM option '%s'\n", argname); 860 } else if (!found_flag->is_bool() && has_plus_minus) { 861 jio_fprintf(defaultStream::error_stream(), 862 "Unexpected +/- setting in VM option '%s'\n", argname); 863 } else { 864 jio_fprintf(defaultStream::error_stream(), 865 "Improperly specified VM option '%s'\n", argname); 866 } 867 } else { 868 jio_fprintf(defaultStream::error_stream(), "%s", locked_message_buf); 869 } 870 } else { 871 jio_fprintf(defaultStream::error_stream(), 872 "Unrecognized VM option '%s'\n", argname); 873 Flag* fuzzy_matched = Flag::fuzzy_match((const char*)argname, arg_len, true); 874 if (fuzzy_matched != NULL) { 875 jio_fprintf(defaultStream::error_stream(), 876 "Did you mean '%s%s%s'? ", 877 (fuzzy_matched->is_bool()) ? "(+/-)" : "", 878 fuzzy_matched->_name, 879 (fuzzy_matched->is_bool()) ? "" : "="); 880 } 881 } 882 883 // allow for commandline "commenting out" options like -XX:#+Verbose 884 return arg[0] == '#'; 885 } If "-XX:+IgnoreUnrecongnizedVMOptions" is specified, then "ignore_unrecognized" will be true and "if" statement on line 822 will always be true. I just think that a better place to check "ignore_unrecognized" is on "else" branch on line 867(for locked flags) and on "else" branch on line 870(where we actually found unrecognized option). If "ignore_unrecognized" is true, then return true in this case, otherwise execute code in these "else" branches. It's my thoughts about that. In this case improperly specified options will be catched(lines 857-866). Thanks, Dmitry On 25.06.2015 20:00, Dmitry Dmitriev wrote: > Hello Vladimir, > > Thank you for explanation. I just was bit confused about valid VM > options but which improperly specified. > I look at the Arguments::process_argument function in > src/share/vm/runtime/arguments.cpp module and noticed one thing: > > 817 bool Arguments::process_argument(const char* arg, 818 jboolean > ignore_unrecognized, Flag::Flags origin) { 819 820 JDK_Version since = > JDK_Version(); 821 822 if (parse_argument(arg, origin) || > ignore_unrecognized) { 823 return true; 824 } ... 850 // For locked > flags, report a custom error message if available. 851 // Otherwise, > report the standard unrecognized VM option. 852 Flag* found_flag = > Flag::find_flag((const char*)argname, arg_len, true, true); 853 if > (found_flag != NULL) { 854 char locked_message_buf[BUFLEN]; 855 > found_flag->get_locked_message(locked_message_buf, BUFLEN); 856 if > (strlen(locked_message_buf) == 0) { 857 if (found_flag->is_bool() && > !has_plus_minus) { 858 jio_fprintf(defaultStream::error_stream(), 859 > "Missing +/- setting for VM option '%s'\n", argname); 860 } else if > (!found_flag->is_bool() && has_plus_minus) { 861 > jio_fprintf(defaultStream::error_stream(), 862 "Unexpected +/- setting > in VM option '%s'\n", argname); 863 } else { 864 > jio_fprintf(defaultStream::error_stream(), 865 "Improperly specified > VM option '%s'\n", argname); 866 } 867 } else { 868 > jio_fprintf(defaultStream::error_stream(), "%s", locked_message_buf); > 869 } 870 } else { 871 jio_fprintf(defaultStream::error_stream(), 872 > "Unrecognized VM option '%s'\n", argname); 873 Flag* fuzzy_matched = > Flag::fuzzy_match((const char*)argname, arg_len, true); 874 if > (fuzzy_matched != NULL) { 875 > jio_fprintf(defaultStream::error_stream(), 876 "Did you mean '%s%s%s'? > ", 877 (fuzzy_matched->is_bool()) ? "(+/-)" : "", 878 > fuzzy_matched->_name, 879 (fuzzy_matched->is_bool()) ? "" : > "="); 880 } 881 } 882 883 // allow for commandline "commenting > out" options like -XX:#+Verbose 884 return arg[0] == '#'; 885 } > > If "-XX:+IgnoreUnrecongnizedVMOptions" is specified, then > "ignore_unrecognized" will be true and "if" statement on line 822 will > always be true. > I just think that a better place to check "ignore_unrecognized" is on > "else" branch on line 867(for locked flags) and on "else" branch on > line 870(where we actually found unrecognized option). If > "ignore_unrecognized" is true, then return true in this case, > otherwise execute code in these "else" branches. It's my thoughts > about that. In this case improperly specified options will be > catched(lines 857-866). > > Thanks, > Dmitry > > > On 25.06.2015 17:45, Vladimir Kozlov wrote: >> It is not intentional but difficult to implement. >> It was added to allow specify options which are not defined in >> running VM. >> For example when C2 option is specified but Client VM (which has only >> C1) is run. >> We can do more smarter things here, I agree, by trying to verify >> options before ignoring it. >> But it will not help with misspelled options, I think. >> >> Regards, >> Vladimir >> >> On 6/25/15 5:17 AM, Dmitry Dmitriev wrote: >>> Hello, >>> >>> Working with JVM command line options I noticed that >>> "IgnoreUnrecognizedVMOptions" option allow to hide options with bad >>> values. "IgnoreUnrecognizedVMOptions" allow to ignore unrecognized >>> options, but it also allow to ignore improperly >>> specified VM Options which are processed in general way, i.e. "-XX:" >>> options processed by Arguments::process_argument >>> function(hotspot/src/share/vm/runtime/arguments.cpp module). >>> >>> I will be very appreciated if someone can describe this behavior or >>> state that this is intentional. >>> >>> Example for numeric and boolean options: >>> 1) Bad numeric option with and without >>> "-XX:+IgnoreUnrecongnizedVMOptions" >>> java -XX:MaxRAMFraction=-1 -version >>> Improperly specified VM option 'MaxRAMFraction=-1' >>> Error: Could not create the Java Virtual Machine. >>> Error: A fatal exception has occurred. Program will exit. >>> >>> java -XX:MaxRAMFraction=-1 -XX:+IgnoreUnrecognizedVMOptions -version >>> java version "1.8.0_40" >>> Java(TM) SE Runtime Environment (build 1.8.0_40-b26) >>> Java HotSpot(TM) 64-Bit Server VM (build 25.40-b25, mixed mode) >>> >>> 2) Bad boolean option with and without >>> "-XX:+IgnoreUnrecongnizedVMOptions" >>> java -XX:UseG1GC -version >>> Missing +/- setting for VM option 'UseG1GC' >>> Error: Could not create the Java Virtual Machine. >>> Error: A fatal exception has occurred. Program will exit. >>> >>> java -XX:UseG1GC -XX:+IgnoreUnrecognizedVMOptions -version >>> java version "1.8.0_40" >>> Java(TM) SE Runtime Environment (build 1.8.0_40-b26) >>> Java HotSpot(TM) 64-Bit Server VM (build 25.40-b25, mixed mode) >>> >>> So, as we see when "-XX:+IgnoreUnrecongnizedVMOptions" is used, bad >>> "-XX:MaxRAMFraction=-1" and "-XX:UseG1GC" are >>> ignored. I don't know is this behavior intentional or not, but >>> HotSpot works in that way. >>> >>> So, can someone tell me this is intentional? Or this behavior is wrong? >>> >>> Thank you, >>> Dmitry >>> >>> > From vladimir.kozlov at oracle.com Thu Jun 25 17:06:04 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 25 Jun 2015 10:06:04 -0700 Subject: IgnoreUnrecognizedVMOptions and badly specified options In-Reply-To: <558C3397.80001@oracle.com> References: <558BF15A.6030702@oracle.com> <558C141B.9080006@oracle.com> <558C3397.80001@oracle.com> Message-ID: <558C34FC.803@oracle.com> File bug on runtime (who handles flags verification this days?) with your suggestion. Thanks, Vladimir On 6/25/15 10:00 AM, Dmitry Dmitriev wrote: > Hello Vladimir, > > Thank you for explanation. I just was bit confused about valid VM options but which improperly specified. > I look at the Arguments::process_argument function in src/share/vm/runtime/arguments.cpp module and noticed one thing: > > 817 bool Arguments::process_argument(const char* arg, > 818 jboolean ignore_unrecognized, Flag::Flags origin) { > 819 > 820 JDK_Version since = JDK_Version(); > 821 > 822 if (parse_argument(arg, origin) || ignore_unrecognized) { > 823 return true; > 824 } > ... > 850 // For locked flags, report a custom error message if available. > 851 // Otherwise, report the standard unrecognized VM option. > 852 Flag* found_flag = Flag::find_flag((const char*)argname, arg_len, true, true); > 853 if (found_flag != NULL) { > 854 char locked_message_buf[BUFLEN]; > 855 found_flag->get_locked_message(locked_message_buf, BUFLEN); > 856 if (strlen(locked_message_buf) == 0) { > 857 if (found_flag->is_bool() && !has_plus_minus) { > 858 jio_fprintf(defaultStream::error_stream(), > 859 "Missing +/- setting for VM option '%s'\n", argname); > 860 } else if (!found_flag->is_bool() && has_plus_minus) { > 861 jio_fprintf(defaultStream::error_stream(), > 862 "Unexpected +/- setting in VM option '%s'\n", argname); > 863 } else { > 864 jio_fprintf(defaultStream::error_stream(), > 865 "Improperly specified VM option '%s'\n", argname); > 866 } > 867 } else { > 868 jio_fprintf(defaultStream::error_stream(), "%s", locked_message_buf); > 869 } > 870 } else { > 871 jio_fprintf(defaultStream::error_stream(), > 872 "Unrecognized VM option '%s'\n", argname); > 873 Flag* fuzzy_matched = Flag::fuzzy_match((const char*)argname, arg_len, true); > 874 if (fuzzy_matched != NULL) { > 875 jio_fprintf(defaultStream::error_stream(), > 876 "Did you mean '%s%s%s'? ", > 877 (fuzzy_matched->is_bool()) ? "(+/-)" : "", > 878 fuzzy_matched->_name, > 879 (fuzzy_matched->is_bool()) ? "" : "="); > 880 } > 881 } > 882 > 883 // allow for commandline "commenting out" options like -XX:#+Verbose > 884 return arg[0] == '#'; > 885 } > > If "-XX:+IgnoreUnrecongnizedVMOptions" is specified, then "ignore_unrecognized" will be true and "if" statement on line > 822 will always be true. > I just think that a better place to check "ignore_unrecognized" is on "else" branch on line 867(for locked flags) and on > "else" branch on line 870(where we actually found unrecognized option). If "ignore_unrecognized" is true, then return > true in this case, otherwise execute code in these "else" branches. It's my thoughts about that. In this case improperly > specified options will be catched(lines 857-866). > > Thanks, > Dmitry > > > On 25.06.2015 17:45, Vladimir Kozlov wrote: >> It is not intentional but difficult to implement. >> It was added to allow specify options which are not defined in running VM. >> For example when C2 option is specified but Client VM (which has only C1) is run. >> We can do more smarter things here, I agree, by trying to verify options before ignoring it. >> But it will not help with misspelled options, I think. >> >> Regards, >> Vladimir >> >> On 6/25/15 5:17 AM, Dmitry Dmitriev wrote: >>> Hello, >>> >>> Working with JVM command line options I noticed that "IgnoreUnrecognizedVMOptions" option allow to hide options with bad >>> values. "IgnoreUnrecognizedVMOptions" allow to ignore unrecognized options, but it also allow to ignore improperly >>> specified VM Options which are processed in general way, i.e. "-XX:" options processed by Arguments::process_argument >>> function(hotspot/src/share/vm/runtime/arguments.cpp module). >>> >>> I will be very appreciated if someone can describe this behavior or state that this is intentional. >>> >>> Example for numeric and boolean options: >>> 1) Bad numeric option with and without "-XX:+IgnoreUnrecongnizedVMOptions" >>> java -XX:MaxRAMFraction=-1 -version >>> Improperly specified VM option 'MaxRAMFraction=-1' >>> Error: Could not create the Java Virtual Machine. >>> Error: A fatal exception has occurred. Program will exit. >>> >>> java -XX:MaxRAMFraction=-1 -XX:+IgnoreUnrecognizedVMOptions -version >>> java version "1.8.0_40" >>> Java(TM) SE Runtime Environment (build 1.8.0_40-b26) >>> Java HotSpot(TM) 64-Bit Server VM (build 25.40-b25, mixed mode) >>> >>> 2) Bad boolean option with and without "-XX:+IgnoreUnrecongnizedVMOptions" >>> java -XX:UseG1GC -version >>> Missing +/- setting for VM option 'UseG1GC' >>> Error: Could not create the Java Virtual Machine. >>> Error: A fatal exception has occurred. Program will exit. >>> >>> java -XX:UseG1GC -XX:+IgnoreUnrecognizedVMOptions -version >>> java version "1.8.0_40" >>> Java(TM) SE Runtime Environment (build 1.8.0_40-b26) >>> Java HotSpot(TM) 64-Bit Server VM (build 25.40-b25, mixed mode) >>> >>> So, as we see when "-XX:+IgnoreUnrecongnizedVMOptions" is used, bad "-XX:MaxRAMFraction=-1" and "-XX:UseG1GC" are >>> ignored. I don't know is this behavior intentional or not, but HotSpot works in that way. >>> >>> So, can someone tell me this is intentional? Or this behavior is wrong? >>> >>> Thank you, >>> Dmitry >>> >>> > From kim.barrett at oracle.com Thu Jun 25 17:07:43 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 25 Jun 2015 13:07:43 -0400 Subject: RFR: 8087322: Implement a Semaphore utility class In-Reply-To: <558C2F89.3070908@oracle.com> References: <557AF8E4.9040804@oracle.com> <557F3582.6060401@oracle.com> <5581B597.5080900@oracle.com> <55836FF2.6070604@oracle.com> <55881B78.3040909@oracle.com> <558A8D78.5000209@oracle.com> <558B21CB.1010901@oracle.com> <558C2F89.3070908@oracle.com> Message-ID: <062DD278-F371-4BB0-B0BD-4D0E887B8C40@oracle.com> On Jun 25, 2015, at 12:42 PM, Stefan Karlsson wrote: > > Hi all, > > Updated webrev: > http://cr.openjdk.java.net/~stefank/8087322/webrev.05.delta > http://cr.openjdk.java.net/~stefank/8087322/webrev.05 One minor thing that I unfortunately forgot to include in previous comments: I think Semaphore::_impl should be private, not protected. I don?t need a new webrev if you want to fix that. Looks good otherwise. From daniel.daugherty at oracle.com Thu Jun 25 17:09:48 2015 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 25 Jun 2015 11:09:48 -0600 Subject: IgnoreUnrecognizedVMOptions and badly specified options In-Reply-To: <558C34FC.803@oracle.com> References: <558BF15A.6030702@oracle.com> <558C141B.9080006@oracle.com> <558C3397.80001@oracle.com> <558C34FC.803@oracle.com> Message-ID: <558C35DC.5060002@oracle.com> I'm pretty sure that bug was filed this morning: JDK-8129855 -XX:+IgnoreUnrecognizedVMOptions hides improperly specified VM options. https://bugs.openjdk.java.net/browse/JDK-8129855 Michail was reading your mind... Dan On 6/25/15 11:06 AM, Vladimir Kozlov wrote: > File bug on runtime (who handles flags verification this days?) with > your suggestion. > > Thanks, > Vladimir > > On 6/25/15 10:00 AM, Dmitry Dmitriev wrote: >> Hello Vladimir, >> >> Thank you for explanation. I just was bit confused about valid VM >> options but which improperly specified. >> I look at the Arguments::process_argument function in >> src/share/vm/runtime/arguments.cpp module and noticed one thing: >> >> 817 bool Arguments::process_argument(const char* arg, >> 818 jboolean ignore_unrecognized, Flag::Flags origin) { >> 819 >> 820 JDK_Version since = JDK_Version(); >> 821 >> 822 if (parse_argument(arg, origin) || ignore_unrecognized) { >> 823 return true; >> 824 } >> ... >> 850 // For locked flags, report a custom error message if available. >> 851 // Otherwise, report the standard unrecognized VM option. >> 852 Flag* found_flag = Flag::find_flag((const char*)argname, >> arg_len, true, true); >> 853 if (found_flag != NULL) { >> 854 char locked_message_buf[BUFLEN]; >> 855 found_flag->get_locked_message(locked_message_buf, BUFLEN); >> 856 if (strlen(locked_message_buf) == 0) { >> 857 if (found_flag->is_bool() && !has_plus_minus) { >> 858 jio_fprintf(defaultStream::error_stream(), >> 859 "Missing +/- setting for VM option '%s'\n", argname); >> 860 } else if (!found_flag->is_bool() && has_plus_minus) { >> 861 jio_fprintf(defaultStream::error_stream(), >> 862 "Unexpected +/- setting in VM option '%s'\n", argname); >> 863 } else { >> 864 jio_fprintf(defaultStream::error_stream(), >> 865 "Improperly specified VM option '%s'\n", argname); >> 866 } >> 867 } else { >> 868 jio_fprintf(defaultStream::error_stream(), "%s", >> locked_message_buf); >> 869 } >> 870 } else { >> 871 jio_fprintf(defaultStream::error_stream(), >> 872 "Unrecognized VM option '%s'\n", argname); >> 873 Flag* fuzzy_matched = Flag::fuzzy_match((const >> char*)argname, arg_len, true); >> 874 if (fuzzy_matched != NULL) { >> 875 jio_fprintf(defaultStream::error_stream(), >> 876 "Did you mean '%s%s%s'? ", >> 877 (fuzzy_matched->is_bool()) ? "(+/-)" : "", >> 878 fuzzy_matched->_name, >> 879 (fuzzy_matched->is_bool()) ? "" : "="); >> 880 } >> 881 } >> 882 >> 883 // allow for commandline "commenting out" options like >> -XX:#+Verbose >> 884 return arg[0] == '#'; >> 885 } >> >> If "-XX:+IgnoreUnrecongnizedVMOptions" is specified, then >> "ignore_unrecognized" will be true and "if" statement on line >> 822 will always be true. >> I just think that a better place to check "ignore_unrecognized" is on >> "else" branch on line 867(for locked flags) and on >> "else" branch on line 870(where we actually found unrecognized >> option). If "ignore_unrecognized" is true, then return >> true in this case, otherwise execute code in these "else" branches. >> It's my thoughts about that. In this case improperly >> specified options will be catched(lines 857-866). >> >> Thanks, >> Dmitry >> >> >> On 25.06.2015 17:45, Vladimir Kozlov wrote: >>> It is not intentional but difficult to implement. >>> It was added to allow specify options which are not defined in >>> running VM. >>> For example when C2 option is specified but Client VM (which has >>> only C1) is run. >>> We can do more smarter things here, I agree, by trying to verify >>> options before ignoring it. >>> But it will not help with misspelled options, I think. >>> >>> Regards, >>> Vladimir >>> >>> On 6/25/15 5:17 AM, Dmitry Dmitriev wrote: >>>> Hello, >>>> >>>> Working with JVM command line options I noticed that >>>> "IgnoreUnrecognizedVMOptions" option allow to hide options with bad >>>> values. "IgnoreUnrecognizedVMOptions" allow to ignore unrecognized >>>> options, but it also allow to ignore improperly >>>> specified VM Options which are processed in general way, i.e. >>>> "-XX:" options processed by Arguments::process_argument >>>> function(hotspot/src/share/vm/runtime/arguments.cpp module). >>>> >>>> I will be very appreciated if someone can describe this behavior or >>>> state that this is intentional. >>>> >>>> Example for numeric and boolean options: >>>> 1) Bad numeric option with and without >>>> "-XX:+IgnoreUnrecongnizedVMOptions" >>>> java -XX:MaxRAMFraction=-1 -version >>>> Improperly specified VM option 'MaxRAMFraction=-1' >>>> Error: Could not create the Java Virtual Machine. >>>> Error: A fatal exception has occurred. Program will exit. >>>> >>>> java -XX:MaxRAMFraction=-1 -XX:+IgnoreUnrecognizedVMOptions -version >>>> java version "1.8.0_40" >>>> Java(TM) SE Runtime Environment (build 1.8.0_40-b26) >>>> Java HotSpot(TM) 64-Bit Server VM (build 25.40-b25, mixed mode) >>>> >>>> 2) Bad boolean option with and without >>>> "-XX:+IgnoreUnrecongnizedVMOptions" >>>> java -XX:UseG1GC -version >>>> Missing +/- setting for VM option 'UseG1GC' >>>> Error: Could not create the Java Virtual Machine. >>>> Error: A fatal exception has occurred. Program will exit. >>>> >>>> java -XX:UseG1GC -XX:+IgnoreUnrecognizedVMOptions -version >>>> java version "1.8.0_40" >>>> Java(TM) SE Runtime Environment (build 1.8.0_40-b26) >>>> Java HotSpot(TM) 64-Bit Server VM (build 25.40-b25, mixed mode) >>>> >>>> So, as we see when "-XX:+IgnoreUnrecongnizedVMOptions" is used, bad >>>> "-XX:MaxRAMFraction=-1" and "-XX:UseG1GC" are >>>> ignored. I don't know is this behavior intentional or not, but >>>> HotSpot works in that way. >>>> >>>> So, can someone tell me this is intentional? Or this behavior is >>>> wrong? >>>> >>>> Thank you, >>>> Dmitry >>>> >>>> >> From staffan.friberg at oracle.com Thu Jun 25 17:10:51 2015 From: staffan.friberg at oracle.com (Staffan Friberg) Date: Thu, 25 Jun 2015 10:10:51 -0700 Subject: JEP 248: Make G1 the Default Garbage Collector In-Reply-To: References: <20150428220211.4355960845@eggemoggin.niobe.net> <55423444.7040009@beckwithclan.com> <4391D841-07CD-4A37-8092-DABBA3C3A627@gmail.com> <20150604150835.278728@eggemoggin.niobe.net> <55719229.3060806@oracle.com> Message-ID: <558C361B.5040301@oracle.com> Hi, As JEP 248 moved to target, we would like to expand on the testing we have done. We want to ask the community to help us make sure we get the best data points. These data points will be used to evaluate if there are critical issues for G1 that can not be addressed in JDK 9 time frame. Switching to G1 as the default GC in JDK 9 will in the end come down to a judgment call with the data collected at the decision time. We would like to get your feedback on all experiences, good, neutral and bad. Usually bad experiences is what generates blogs and emails, the other data points are not always easy to get. * **Metrics* The following we see as the key metrics to gather data around to determine the impact of the switch. Not all metrics will be interesting for every application, but a default collector needs to behave well in them as a whole. * *Startup Time *- VM Initialization o G1 is a more complex GC than Parallel GC and requires a bit more infrastructure to be configured to enable concurrent marking and mixed collections. o This is most critical for short lived applications (such as simple command line tools or build tools), where the execution time is largely impacted by the time it takes to initialize the VM. o *Goal:* The VM initialization time must not have a major impact the run time of short running applications * *Throughput* - Code Performance o The pure application performance should not be too adversely affected by which GC is used. o Due to the heavier write barriers used in G1 there may be a performance impact. But the impact varies for different applications. o *Goal:* The performance is good enough so the general recommendation does not end up being to set the Parallel GC as part of application launch scripts. * *Footprint *- Total Memory Usage o G1 is a more complex GC than Parallel GC and requires a bit more infrastructure to be configured to enable concurrent marking and mixed collections. o This also ties into the Ergonomics metric below in that the Ergonomics need to keep the memory usage balanced by not expanding the heap too aggressively. o *Goal*: The total memory usage of the Java process must be kept reasonable. * *Ergonomics *- GC Behavior and Pauses o A default GC need to be able to handle a reasonably large set of different types of applications Out-Of-The-Box without extensive tuning. + A user should be able to just run their Java application, potentially just setting the heap size and pause time goal, and have it behave well. + The GC needs to be able size the heap and its sub components using dynamic ergonomics. o The default GC needs to be able to avoid long costly Full collections by using Ergonomics to self tune depending on the workload. o *Goal*: The GC Ergonomics must be able to handle common applications without causing performance overhead or Full GCs *Applications* We are focusing on general Java applications, and not on applications that are very dependent on extreme GC tuning. Applications not considered a target for this switch includes applications requiring low latency with milliseconds, micro or no-pause requirements, nor very large heap applications that use multiple of 10s or 100s of GB of heap. The focus is on applications that are normally not tuned, either because there has never been a need to do so or they are used by people not accustomed to GC tuning. * *Unaffected Applications* o Client VM Application: The Client VM will continue to use the Serial Collector, and applications such as Applets and regular Java applications using the 32bit JRE on Windows with only the client VM would not be affected. o "Tuned Applications": Any application that specifically sets the GC will not be impacted by this change. * *Affected Applications* o Command Line Tools + Command line tools are often batch type jobs and are often fairly short running, so the GC pauses are of less concern as long as the execution is finished as soon as possible. Example tools are the Java Compiler, Scala Compiler, Maven and Gradle. The key metrics are Startup Time and Ergonomics to make sure the tool starts fast and that the GC can quickly adapt to the behavior of the application. For semi long running compilations the Throughput will become a factor as well. o UI Applications + UI applications often don't set a specific GC, they might tune the heap size depending on the requirements of the application. End users of UI:s most likely don't know how to tune the VM, or the fact that the application is written in Java. As an example NetBeans by default only increases the minimum heap size as the only GC related tuning and let the ergonomics handle the rest. As a data point here, Java Mission Control is configured to run with G1 without issues so far. For most desktop UI application pure throughput is less critical. What tends to most noticeable is stalls due to GC pauses, so Ergonomics is probably the most important metric, together with Footprint as you do not want you application to use up all the memory on you desktop/laptop. o Applications using the Default GC + This is the area where we need the most help. We have internal workloads and benchmarks we can run, but that set will always be infinitely small compared to what is used across the Java community. This is also the reason why we enable this early to expand the amount of testing and feedback we are able to get. For these applications all the metrics apply, but their importance will vary from workload to workload. We would like to encourage and collaborate on further community polls and surveys on this matter, to gain more valuable insights on questions such as: * Do you specify GC on the command line? * Are you tuning GC, but do not specify UseParallelGC since it was the default anyway? * Do you specify the minimum and/or maximum heap size and nursery size * Is this a distributed end-user application or a server application? Regards, Staffan and Jenny Java SE Performance On 06/05/2015 10:11 AM, Ben Evans wrote: > Hi, > > I like the plan, but this statement is really quite bullish, > especially (IMO) on the available evidence. > > G1 was always marketed as the replacement for CMS. In field experience > so far, that hasn't happened, and I feel that we are glossing over the > fact that we are now thinking of G1 as a replacement for Parallel. > > Certainly none of the testing I've done has been about Parallel -> G1 > - it's all been CMS vs G1. I will be happy to start working with > clients to try to cover the Parallel vs G1 space, but that hasn't > happened up until now. > > Neither do I think we should be under any illusions that a very large > number of installs are going to be affected. > > It may not be all that representative, but here are the results of a > quick community straw poll I ran over the last couple of days: > > A single question: "Which Garbage Collector Does Your Application Use? > " yielded these results: > > Concurrent Mark & Sweep (CMS) > 23.94% > 85 > ? > Garbage First (G1GC) > 10.70% > 38 > ? > Parallel (because I explicitly set it) > 5.07% > 18 > ? > Default (this actually gives you Parallel) > 39.15% > 139 > ? > I Don't Know > 21.13% > 75 > > Total: 355 > > The clear, stand-out winner is Default, with ~40% of installs using > this, and therefore being exposed to the proposed change. That makes > me very nervous. > > So, whilst I'm not saying we shouldn't do this, and I know that > community members, including Kirk, myself & the other jClarity folks > will help to get some better data, I'd argue that we're still a long > way from being certain that we're ready for this change. > > Thanks, > > Ben > > > On Fri, Jun 5, 2015 at 1:12 PM, Stefan Johansson > wrote: >> On 2015-06-05 00:08, mark.reinhold at oracle.com wrote: >>> 2015/6/4 6:44 -0700, charlie.hunt at oracle.com: >>>> Wanted to come back to this thread, continue the dialog, reiterate the >>>> objective, (try to) summarize the concerns and put forth a potential >>>> plan for this JEP going forward. >>>> >>>> Intent: Use G1 GC as the default collector chosen by the JVM when no >>>> GC is explicitly set at the JVM command line. >>>> >>>> ... >>> Charlie -- thanks for the excellent summary of this wide-ranging >>> discussion! >>> >>>> ... >>>> >>>> Suggested plan for moving forward: >>>> - Make G1 the default collector in JDK 9, continue to evaluate G1 and >>>> enhance G1 in JDK 9 >>>> - Mitigate risk by reverting back to Parallel GC before JDK 9 goes >>>> ?Generally Available? (Sept 22, 2016 [1]) if warranted by continuing >>>> to monitor observations and experiences with G1 in both JDK 9 >>>> pre-releases and latest JDK 8 update releases >>>> - Address enhancing ergonomics for selecting a default GC as a >>>> separate JEP if future observations suggests its needed >>> I think this is a fine plan. >>> >>> Stefan -- To move forward with JEP 248, could you please revise the >>> second item in the "Risks and Assumptions" section to note that there >>> is some concern that G1 might not be ready to become the default, that >>> making it the default now will allow us to get more feedback on it, and >>> that if it proves to be not ready then we'll revert the default to the >>> Parallel GC in time for JDK 9 GA? >> Mark, I've extended second item as follows: >> - G1 is seen as a robust and well-tested collector. It is not expected >> to have stability problems, but becoming the default collector will >> increase its visibility and may reveal previously-unknown issues. If >> a critical issue is found that can't be addressed in the JDK 9 time >> frame, we will revert back to use Parallel GC as the default for the >> JDK 9 GA. >> >> Thanks, >> Stefan >> >> >>> Ben -- Can you live with this plan? >>> >>> - Mark >> > > From dmitry.dmitriev at oracle.com Thu Jun 25 17:13:50 2015 From: dmitry.dmitriev at oracle.com (Dmitry Dmitriev) Date: Thu, 25 Jun 2015 20:13:50 +0300 Subject: IgnoreUnrecognizedVMOptions and badly specified options In-Reply-To: <558C35DC.5060002@oracle.com> References: <558BF15A.6030702@oracle.com> <558C141B.9080006@oracle.com> <558C3397.80001@oracle.com> <558C34FC.803@oracle.com> <558C35DC.5060002@oracle.com> Message-ID: <558C36CE.6090606@oracle.com> Thank you Dan! The bug states about changed behaviour but it relates to the current implementation of IgnoreUnrecongnizedVMOptions flag and I think it can be fixed by this RFR. On 25.06.2015 20:09, Daniel D. Daugherty wrote: > I'm pretty sure that bug was filed this morning: > > JDK-8129855 -XX:+IgnoreUnrecognizedVMOptions hides improperly > specified VM options. > https://bugs.openjdk.java.net/browse/JDK-8129855 > > Michail was reading your mind... No magic here, we discuss this topic today :) I am become curious about that behaviour, since this code exit for a long time. Regards, Dmitry > > Dan > > > On 6/25/15 11:06 AM, Vladimir Kozlov wrote: >> File bug on runtime (who handles flags verification this days?) with >> your suggestion. >> >> Thanks, >> Vladimir >> >> On 6/25/15 10:00 AM, Dmitry Dmitriev wrote: >>> Hello Vladimir, >>> >>> Thank you for explanation. I just was bit confused about valid VM >>> options but which improperly specified. >>> I look at the Arguments::process_argument function in >>> src/share/vm/runtime/arguments.cpp module and noticed one thing: >>> >>> 817 bool Arguments::process_argument(const char* arg, >>> 818 jboolean ignore_unrecognized, Flag::Flags origin) { >>> 819 >>> 820 JDK_Version since = JDK_Version(); >>> 821 >>> 822 if (parse_argument(arg, origin) || ignore_unrecognized) { >>> 823 return true; >>> 824 } >>> ... >>> 850 // For locked flags, report a custom error message if >>> available. >>> 851 // Otherwise, report the standard unrecognized VM option. >>> 852 Flag* found_flag = Flag::find_flag((const char*)argname, >>> arg_len, true, true); >>> 853 if (found_flag != NULL) { >>> 854 char locked_message_buf[BUFLEN]; >>> 855 found_flag->get_locked_message(locked_message_buf, BUFLEN); >>> 856 if (strlen(locked_message_buf) == 0) { >>> 857 if (found_flag->is_bool() && !has_plus_minus) { >>> 858 jio_fprintf(defaultStream::error_stream(), >>> 859 "Missing +/- setting for VM option '%s'\n", argname); >>> 860 } else if (!found_flag->is_bool() && has_plus_minus) { >>> 861 jio_fprintf(defaultStream::error_stream(), >>> 862 "Unexpected +/- setting in VM option '%s'\n", argname); >>> 863 } else { >>> 864 jio_fprintf(defaultStream::error_stream(), >>> 865 "Improperly specified VM option '%s'\n", argname); >>> 866 } >>> 867 } else { >>> 868 jio_fprintf(defaultStream::error_stream(), "%s", >>> locked_message_buf); >>> 869 } >>> 870 } else { >>> 871 jio_fprintf(defaultStream::error_stream(), >>> 872 "Unrecognized VM option '%s'\n", argname); >>> 873 Flag* fuzzy_matched = Flag::fuzzy_match((const >>> char*)argname, arg_len, true); >>> 874 if (fuzzy_matched != NULL) { >>> 875 jio_fprintf(defaultStream::error_stream(), >>> 876 "Did you mean '%s%s%s'? ", >>> 877 (fuzzy_matched->is_bool()) ? "(+/-)" : "", >>> 878 fuzzy_matched->_name, >>> 879 (fuzzy_matched->is_bool()) ? "" : "="); >>> 880 } >>> 881 } >>> 882 >>> 883 // allow for commandline "commenting out" options like >>> -XX:#+Verbose >>> 884 return arg[0] == '#'; >>> 885 } >>> >>> If "-XX:+IgnoreUnrecongnizedVMOptions" is specified, then >>> "ignore_unrecognized" will be true and "if" statement on line >>> 822 will always be true. >>> I just think that a better place to check "ignore_unrecognized" is >>> on "else" branch on line 867(for locked flags) and on >>> "else" branch on line 870(where we actually found unrecognized >>> option). If "ignore_unrecognized" is true, then return >>> true in this case, otherwise execute code in these "else" branches. >>> It's my thoughts about that. In this case improperly >>> specified options will be catched(lines 857-866). >>> >>> Thanks, >>> Dmitry >>> >>> >>> On 25.06.2015 17:45, Vladimir Kozlov wrote: >>>> It is not intentional but difficult to implement. >>>> It was added to allow specify options which are not defined in >>>> running VM. >>>> For example when C2 option is specified but Client VM (which has >>>> only C1) is run. >>>> We can do more smarter things here, I agree, by trying to verify >>>> options before ignoring it. >>>> But it will not help with misspelled options, I think. >>>> >>>> Regards, >>>> Vladimir >>>> >>>> On 6/25/15 5:17 AM, Dmitry Dmitriev wrote: >>>>> Hello, >>>>> >>>>> Working with JVM command line options I noticed that >>>>> "IgnoreUnrecognizedVMOptions" option allow to hide options with bad >>>>> values. "IgnoreUnrecognizedVMOptions" allow to ignore unrecognized >>>>> options, but it also allow to ignore improperly >>>>> specified VM Options which are processed in general way, i.e. >>>>> "-XX:" options processed by Arguments::process_argument >>>>> function(hotspot/src/share/vm/runtime/arguments.cpp module). >>>>> >>>>> I will be very appreciated if someone can describe this behavior >>>>> or state that this is intentional. >>>>> >>>>> Example for numeric and boolean options: >>>>> 1) Bad numeric option with and without >>>>> "-XX:+IgnoreUnrecongnizedVMOptions" >>>>> java -XX:MaxRAMFraction=-1 -version >>>>> Improperly specified VM option 'MaxRAMFraction=-1' >>>>> Error: Could not create the Java Virtual Machine. >>>>> Error: A fatal exception has occurred. Program will exit. >>>>> >>>>> java -XX:MaxRAMFraction=-1 -XX:+IgnoreUnrecognizedVMOptions -version >>>>> java version "1.8.0_40" >>>>> Java(TM) SE Runtime Environment (build 1.8.0_40-b26) >>>>> Java HotSpot(TM) 64-Bit Server VM (build 25.40-b25, mixed mode) >>>>> >>>>> 2) Bad boolean option with and without >>>>> "-XX:+IgnoreUnrecongnizedVMOptions" >>>>> java -XX:UseG1GC -version >>>>> Missing +/- setting for VM option 'UseG1GC' >>>>> Error: Could not create the Java Virtual Machine. >>>>> Error: A fatal exception has occurred. Program will exit. >>>>> >>>>> java -XX:UseG1GC -XX:+IgnoreUnrecognizedVMOptions -version >>>>> java version "1.8.0_40" >>>>> Java(TM) SE Runtime Environment (build 1.8.0_40-b26) >>>>> Java HotSpot(TM) 64-Bit Server VM (build 25.40-b25, mixed mode) >>>>> >>>>> So, as we see when "-XX:+IgnoreUnrecongnizedVMOptions" is used, >>>>> bad "-XX:MaxRAMFraction=-1" and "-XX:UseG1GC" are >>>>> ignored. I don't know is this behavior intentional or not, but >>>>> HotSpot works in that way. >>>>> >>>>> So, can someone tell me this is intentional? Or this behavior is >>>>> wrong? >>>>> >>>>> Thank you, >>>>> Dmitry >>>>> >>>>> >>> > From gerard.ziemski at oracle.com Thu Jun 25 17:19:08 2015 From: gerard.ziemski at oracle.com (Gerard Ziemski) Date: Thu, 25 Jun 2015 12:19:08 -0500 Subject: IgnoreUnrecognizedVMOptions and badly specified options In-Reply-To: <558C35DC.5060002@oracle.com> References: <558BF15A.6030702@oracle.com> <558C141B.9080006@oracle.com> <558C3397.80001@oracle.com> <558C34FC.803@oracle.com> <558C35DC.5060002@oracle.com> Message-ID: <558C380C.5050102@oracle.com> I will be happy to take a look. cheers On 6/25/2015 12:09 PM, Daniel D. Daugherty wrote: > I'm pretty sure that bug was filed this morning: > > JDK-8129855 -XX:+IgnoreUnrecognizedVMOptions hides improperly > specified VM options. > https://bugs.openjdk.java.net/browse/JDK-8129855 > > Michail was reading your mind... > > Dan > > > On 6/25/15 11:06 AM, Vladimir Kozlov wrote: >> File bug on runtime (who handles flags verification this days?) with >> your suggestion. >> >> Thanks, >> Vladimir >> >> On 6/25/15 10:00 AM, Dmitry Dmitriev wrote: >>> Hello Vladimir, >>> >>> Thank you for explanation. I just was bit confused about valid VM >>> options but which improperly specified. >>> I look at the Arguments::process_argument function in >>> src/share/vm/runtime/arguments.cpp module and noticed one thing: >>> >>> 817 bool Arguments::process_argument(const char* arg, >>> 818 jboolean ignore_unrecognized, Flag::Flags origin) { >>> 819 >>> 820 JDK_Version since = JDK_Version(); >>> 821 >>> 822 if (parse_argument(arg, origin) || ignore_unrecognized) { >>> 823 return true; >>> 824 } >>> ... >>> 850 // For locked flags, report a custom error message if >>> available. >>> 851 // Otherwise, report the standard unrecognized VM option. >>> 852 Flag* found_flag = Flag::find_flag((const char*)argname, >>> arg_len, true, true); >>> 853 if (found_flag != NULL) { >>> 854 char locked_message_buf[BUFLEN]; >>> 855 found_flag->get_locked_message(locked_message_buf, BUFLEN); >>> 856 if (strlen(locked_message_buf) == 0) { >>> 857 if (found_flag->is_bool() && !has_plus_minus) { >>> 858 jio_fprintf(defaultStream::error_stream(), >>> 859 "Missing +/- setting for VM option '%s'\n", argname); >>> 860 } else if (!found_flag->is_bool() && has_plus_minus) { >>> 861 jio_fprintf(defaultStream::error_stream(), >>> 862 "Unexpected +/- setting in VM option '%s'\n", argname); >>> 863 } else { >>> 864 jio_fprintf(defaultStream::error_stream(), >>> 865 "Improperly specified VM option '%s'\n", argname); >>> 866 } >>> 867 } else { >>> 868 jio_fprintf(defaultStream::error_stream(), "%s", >>> locked_message_buf); >>> 869 } >>> 870 } else { >>> 871 jio_fprintf(defaultStream::error_stream(), >>> 872 "Unrecognized VM option '%s'\n", argname); >>> 873 Flag* fuzzy_matched = Flag::fuzzy_match((const >>> char*)argname, arg_len, true); >>> 874 if (fuzzy_matched != NULL) { >>> 875 jio_fprintf(defaultStream::error_stream(), >>> 876 "Did you mean '%s%s%s'? ", >>> 877 (fuzzy_matched->is_bool()) ? "(+/-)" : "", >>> 878 fuzzy_matched->_name, >>> 879 (fuzzy_matched->is_bool()) ? "" : "="); >>> 880 } >>> 881 } >>> 882 >>> 883 // allow for commandline "commenting out" options like >>> -XX:#+Verbose >>> 884 return arg[0] == '#'; >>> 885 } >>> >>> If "-XX:+IgnoreUnrecongnizedVMOptions" is specified, then >>> "ignore_unrecognized" will be true and "if" statement on line >>> 822 will always be true. >>> I just think that a better place to check "ignore_unrecognized" is >>> on "else" branch on line 867(for locked flags) and on >>> "else" branch on line 870(where we actually found unrecognized >>> option). If "ignore_unrecognized" is true, then return >>> true in this case, otherwise execute code in these "else" branches. >>> It's my thoughts about that. In this case improperly >>> specified options will be catched(lines 857-866). >>> >>> Thanks, >>> Dmitry >>> >>> >>> On 25.06.2015 17:45, Vladimir Kozlov wrote: >>>> It is not intentional but difficult to implement. >>>> It was added to allow specify options which are not defined in >>>> running VM. >>>> For example when C2 option is specified but Client VM (which has >>>> only C1) is run. >>>> We can do more smarter things here, I agree, by trying to verify >>>> options before ignoring it. >>>> But it will not help with misspelled options, I think. >>>> >>>> Regards, >>>> Vladimir >>>> >>>> On 6/25/15 5:17 AM, Dmitry Dmitriev wrote: >>>>> Hello, >>>>> >>>>> Working with JVM command line options I noticed that >>>>> "IgnoreUnrecognizedVMOptions" option allow to hide options with bad >>>>> values. "IgnoreUnrecognizedVMOptions" allow to ignore unrecognized >>>>> options, but it also allow to ignore improperly >>>>> specified VM Options which are processed in general way, i.e. >>>>> "-XX:" options processed by Arguments::process_argument >>>>> function(hotspot/src/share/vm/runtime/arguments.cpp module). >>>>> >>>>> I will be very appreciated if someone can describe this behavior >>>>> or state that this is intentional. >>>>> >>>>> Example for numeric and boolean options: >>>>> 1) Bad numeric option with and without >>>>> "-XX:+IgnoreUnrecongnizedVMOptions" >>>>> java -XX:MaxRAMFraction=-1 -version >>>>> Improperly specified VM option 'MaxRAMFraction=-1' >>>>> Error: Could not create the Java Virtual Machine. >>>>> Error: A fatal exception has occurred. Program will exit. >>>>> >>>>> java -XX:MaxRAMFraction=-1 -XX:+IgnoreUnrecognizedVMOptions -version >>>>> java version "1.8.0_40" >>>>> Java(TM) SE Runtime Environment (build 1.8.0_40-b26) >>>>> Java HotSpot(TM) 64-Bit Server VM (build 25.40-b25, mixed mode) >>>>> >>>>> 2) Bad boolean option with and without >>>>> "-XX:+IgnoreUnrecongnizedVMOptions" >>>>> java -XX:UseG1GC -version >>>>> Missing +/- setting for VM option 'UseG1GC' >>>>> Error: Could not create the Java Virtual Machine. >>>>> Error: A fatal exception has occurred. Program will exit. >>>>> >>>>> java -XX:UseG1GC -XX:+IgnoreUnrecognizedVMOptions -version >>>>> java version "1.8.0_40" >>>>> Java(TM) SE Runtime Environment (build 1.8.0_40-b26) >>>>> Java HotSpot(TM) 64-Bit Server VM (build 25.40-b25, mixed mode) >>>>> >>>>> So, as we see when "-XX:+IgnoreUnrecongnizedVMOptions" is used, >>>>> bad "-XX:MaxRAMFraction=-1" and "-XX:UseG1GC" are >>>>> ignored. I don't know is this behavior intentional or not, but >>>>> HotSpot works in that way. >>>>> >>>>> So, can someone tell me this is intentional? Or this behavior is >>>>> wrong? >>>>> >>>>> Thank you, >>>>> Dmitry >>>>> >>>>> >>> > > From stefan.karlsson at oracle.com Thu Jun 25 17:24:50 2015 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Thu, 25 Jun 2015 19:24:50 +0200 Subject: RFR: 8087322: Implement a Semaphore utility class In-Reply-To: <062DD278-F371-4BB0-B0BD-4D0E887B8C40@oracle.com> References: <557AF8E4.9040804@oracle.com> <557F3582.6060401@oracle.com> <5581B597.5080900@oracle.com> <55836FF2.6070604@oracle.com> <55881B78.3040909@oracle.com> <558A8D78.5000209@oracle.com> <558B21CB.1010901@oracle.com> <558C2F89.3070908@oracle.com> <062DD278-F371-4BB0-B0BD-4D0E887B8C40@oracle.com> Message-ID: <558C3962.4030501@oracle.com> On 2015-06-25 19:07, Kim Barrett wrote: > On Jun 25, 2015, at 12:42 PM, Stefan Karlsson wrote: >> Hi all, >> >> Updated webrev: >> http://cr.openjdk.java.net/~stefank/8087322/webrev.05.delta >> http://cr.openjdk.java.net/~stefank/8087322/webrev.05 > One minor thing that I unfortunately forgot to include in previous comments: > > I think Semaphore::_impl should be private, not protected. I agree. > I don?t need a new webrev if you want to fix that. > > Looks good otherwise. Great. Thanks for reviewing! StefanK > From aph at redhat.com Thu Jun 25 17:44:20 2015 From: aph at redhat.com (Andrew Haley) Date: Thu, 25 Jun 2015 18:44:20 +0100 Subject: Debugging HotSpot on Solaris Message-ID: <558C3DF4.6060902@redhat.com> What do y'all do? GDB can't grok the DWARF which the SunStudio compiler emits, so that's out. I can't figure out how to persuade the solarisstudio GUI debugger to run the java binary. I'm really not tempted to learn dbx. I'm sure there must be a way, but it's not obvious. Andrew. From gerard.ziemski at oracle.com Thu Jun 25 17:54:11 2015 From: gerard.ziemski at oracle.com (Gerard Ziemski) Date: Thu, 25 Jun 2015 12:54:11 -0500 Subject: RFR (S): 8112746 Followup to JEP 245: Validate JVM Command-Line Flag Arguments Message-ID: <558C4043.4050103@oracle.com> hi all, Please review this followup to my recent JEP 245 checkin. It addresses the issues raised by Coleen, Dmitry and Kim during webrev. You can seehttps://bugs.openjdk.java.net/browse/JDK-8112746 for details, but the most important change here is that we only check constraint if the range check passes first. To quickly recap: I changed that part of the code when David pointed out that I had to modify 2 tests in a way that looked like a regression - I removed some test cases. However, Kim, later pointed out that the original code had the advantage of having constraints guaranteed that the flag values were within ranges. I checked in the code with ranges and constraints being checked both regardless of each other, but this followup restores the original behavior (and simplifies the code), where we first check ranges and only check constraints if range passes. The 2 tests (ObjectAlignment.java and Options.java) seem to loose some test cases, but those paths are still tested (though with different values), so we in fact do not loose anything from test coverage point of view. The change passes JPRT (hotspot) and RBT (vm.quick.testlist) References: webrev:http://cr.openjdk.java.net/~gziemski/8112746_rev0/ this issue:https://bugs.openjdk.java.net/browse/JDK-8112746 JEP 245:https://bugs.openjdk.java.net/browse/JDK-8059557 hg stat: src/share/vm/gc/g1/g1_globals.hpp | 4 +- src/share/vm/runtime/commandLineFlagConstraintsCompiler.cpp | 2 +- src/share/vm/runtime/commandLineFlagConstraintsGC.cpp | 55 ++-- src/share/vm/runtime/commandLineFlagRangeList.cpp | 58 ++--- src/share/vm/runtime/globals.cpp | 129 ++++++----- src/share/vm/runtime/globals.hpp | 17 +- test/runtime/CompressedOops/ObjectAlignment.java | 3 +- test/runtime/contended/Options.java | 2 - 8 files changed, 129 insertions(+), 141 deletions(-) From christian.thalinger at oracle.com Thu Jun 25 18:05:08 2015 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 25 Jun 2015 11:05:08 -0700 Subject: Debugging HotSpot on Solaris In-Reply-To: <558C3DF4.6060902@redhat.com> References: <558C3DF4.6060902@redhat.com> Message-ID: dbx. > On Jun 25, 2015, at 10:44 AM, Andrew Haley wrote: > > What do y'all do? GDB can't grok the DWARF which the SunStudio > compiler emits, so that's out. I can't figure out how to persuade the > solarisstudio GUI debugger to run the java binary. I'm really not > tempted to learn dbx. > > I'm sure there must be a way, but it's not obvious. > > Andrew. > From karen.kinnear at oracle.com Thu Jun 25 18:57:14 2015 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Thu, 25 Jun 2015 14:57:14 -0400 Subject: Debugging HotSpot on Solaris In-Reply-To: References: <558C3DF4.6060902@redhat.com> Message-ID: <2FAF33FB-5840-4EFE-83E8-D143B0464FBA@oracle.com> Years ago Coleen found this is dbx help FAQ: mapping from gdb to dbx : hth, Karen (A.1) Gdb does ; how do I do it in dbx? The following table list approximately equivalent dbx commands for some common gdb commands: GDB DBX for more information === === ==================== break stop at `help stop' break stop in `help stop' break * stopi at `help stopi' break ... if stop ... -if `help event specification' cond stop ... -if `help event specification' tbreak stop ... -temp `help event specification' watch stop [slow] `help event specification' watch stop modify & [fast] `help event watchpoint' catch intercept `help intercept' info break status `help status' info watch status `help status' clear clear `help clear' clear delete `help delete' delete delete all `help delete' disable handler -disable all `help handler' disable handler -disable `help handler' enable handler -enable all `help handler' enable handler -enable `help handler' ignore handler -count `help handler' commands when ... { ; } `help when' backtrace where `help where' frame frame `help frame' info reg print $ `help registers' finish step up `help step' signal cont sig `help cont' jump cont at `help cont' set = assign = `help assign' x/ x / `help examine' disassem dis `help dis' shell sh [if needed] `help sh' info func funcs `help funcs' ptype whatis -t `help whatis' define function `help ksh syntax' handle stop sig `help event specification' info signals status; catch `help status', `help catch' attach debug - `help debug' attach debug `help debug' file [unnecessary] exec debug `help debug' core debug `help debug' set editing on set -o emacs `help editing' set language language `help language' set prompt PS1= `help ksh PS1' set history size HISTSIZE= `help ksh HISTSIZE' set print object on dbxenv output_dynamic_type on `help c++ dynamic' show commands history `help history' dir pathmap `help pathmap' show dir pathmap `help pathmap' info line listi `help listi' info source file `help file' info sources files; modules `help files', `help modules' forw search `help search' rev bsearch `help bsearch' -------------------------------------------------------------------------------- On Jun 25, 2015, at 2:05 PM, Christian Thalinger wrote: > dbx. > >> On Jun 25, 2015, at 10:44 AM, Andrew Haley wrote: >> >> What do y'all do? GDB can't grok the DWARF which the SunStudio >> compiler emits, so that's out. I can't figure out how to persuade the >> solarisstudio GUI debugger to run the java binary. I'm really not >> tempted to learn dbx. >> >> I'm sure there must be a way, but it's not obvious. >> >> Andrew. >> > From dmitry.dmitriev at oracle.com Thu Jun 25 21:30:41 2015 From: dmitry.dmitriev at oracle.com (Dmitry Dmitriev) Date: Fri, 26 Jun 2015 00:30:41 +0300 Subject: RFR (S): 8112746 Followup to JEP 245: Validate JVM Command-Line Flag Arguments In-Reply-To: <558C4043.4050103@oracle.com> References: <558C4043.4050103@oracle.com> Message-ID: <558C7301.6020702@oracle.com> Hi Gerard, It seems that recently added space(https://bugs.openjdk.java.net/browse/JDK-8081202) between macro and double quotes is disappear in several files. I.e. must be: " INTX_FORMAT " instead of "INTX_FORMAT" Files where space is disappear: 1) src/share/vm/runtime/commandLineFlagConstraintsCompiler.cpp All changes in file. 2) src/share/vm/runtime/commandLineFlagConstraintsGC.cpp All changes in file. 3) src/share/vm/runtime/commandLineFlagRangeList.cpp On lines 81(3 times), 131(3 times), 156(3 times) and 181(3 times). Thanks, Dmitry On 25.06.2015 20:54, Gerard Ziemski wrote: > hi all, > > Please review this followup to my recent JEP 245 checkin. It addresses the issues raised by Coleen, Dmitry and Kim during webrev. > > You can seehttps://bugs.openjdk.java.net/browse/JDK-8112746 for details, but the most important change here is that we only check constraint if the range check passes first. > > To quickly recap: I changed that part of the code when David pointed out that I had to modify 2 tests in a way that looked like a regression - I removed some test cases. However, Kim, later pointed out that the original code had the advantage of having constraints guaranteed that the flag values were within ranges. > > I checked in the code with ranges and constraints being checked both regardless of each other, but this followup restores the original behavior (and simplifies the code), where we first check ranges and only check constraints if range passes. > > The 2 tests (ObjectAlignment.java and Options.java) seem to loose some test cases, but those paths are still tested (though with different values), so we in fact do not loose anything from test coverage point of view. > > The change passes JPRT (hotspot) and RBT (vm.quick.testlist) > > > References: > > webrev:http://cr.openjdk.java.net/~gziemski/8112746_rev0/ > this issue:https://bugs.openjdk.java.net/browse/JDK-8112746 > JEP 245:https://bugs.openjdk.java.net/browse/JDK-8059557 > > > hg stat: > src/share/vm/gc/g1/g1_globals.hpp | 4 +- > src/share/vm/runtime/commandLineFlagConstraintsCompiler.cpp | 2 +- > src/share/vm/runtime/commandLineFlagConstraintsGC.cpp | 55 ++-- > src/share/vm/runtime/commandLineFlagRangeList.cpp | 58 ++--- > src/share/vm/runtime/globals.cpp | 129 ++++++----- > src/share/vm/runtime/globals.hpp | 17 +- > test/runtime/CompressedOops/ObjectAlignment.java | 3 +- > test/runtime/contended/Options.java | 2 - > 8 files changed, 129 insertions(+), 141 deletions(-) > From dean.long at oracle.com Thu Jun 25 21:35:32 2015 From: dean.long at oracle.com (Dean Long) Date: Thu, 25 Jun 2015 14:35:32 -0700 Subject: RFR: 8087322: Implement a Semaphore utility class In-Reply-To: <558C2F89.3070908@oracle.com> References: <557AF8E4.9040804@oracle.com> <557F3582.6060401@oracle.com> <5581B597.5080900@oracle.com> <55836FF2.6070604@oracle.com> <55881B78.3040909@oracle.com> <558A8D78.5000209@oracle.com> <558B21CB.1010901@oracle.com> <558C2F89.3070908@oracle.com> Message-ID: <558C7424.1060002@oracle.com> On 6/25/2015 9:42 AM, Stefan Karlsson wrote: > Hi all, > > Updated webrev: > http://cr.openjdk.java.net/~stefank/8087322/webrev.05.delta > http://cr.openjdk.java.net/~stefank/8087322/webrev.05 > > - Removed unnecessary and incorrect initialization of _semaphore > > - Fixed includes > > - Loop around sem_trywait if EINTR is reported > How about this instead? 1061 bool PosixSemaphore::trywait() { 1062 int ret = sem_trywait(&_semaphore); 1068 assert_with_errno(ret == 0 || (errno == EAGAIN || errno == EINTR), "trywait failed"); dl > - Removed unnecessary NULL check on windows > > - Fixed the default value for signal(uint count), on windows. > > - Moved Sempahore implementation from semaphore.cpp to semaphore.hpp > > I skipped implementing some of the suggestions that were not essential > for this patch or that we haven't reached an agreement on. It doesn't > mean that I don't think we should do some of the cleanups. If we could > get the structural changes in place (and bug fixes), then we can fix > some of the details as follow-up RFEs. > > Thanks, > StefanK > > On 2015-06-24 23:31, Stefan Karlsson wrote: >> Hi Kim, >> >> On 2015-06-24 22:28, Kim Barrett wrote: >>> On Jun 24, 2015, at 6:59 AM, Stefan Karlsson >>> wrote: >>>> Hi all, >>>> >>>> Updated webrev: >>>> http://cr.openjdk.java.net/~stefank/8087322/webrev.04 >>> Structurally fine. (Stefan would be rightly annoyed with me if I said >>> otherwise after all the offline discussions we've had.) There's some >>> nastiness that results from pre-existing problems in the os_xxx.cpp >>> files, but cleaning that up is another collection of tasks. >>> >>> A few easy bugs, some stylistic comments that can be accepted or >>> declined, but nothing requiring large amounts of rework. >>> >>> ------------------------------------------------------------------------------ >>> >>> src/os/bsd/vm/os_bsd.cpp >>> 1971 OSXSemaphore::OSXSemaphore(uint value) : _semaphore(0) { >>> >>> I think that initializer for _semaphore isn't right. _semaphore is a >>> (OSX) semaphore_t. I think that initializer only accidentally >>> compiles at all. >> >> This is one yet another case of pre-existing code. >> >>> >>> ------------------------------------------------------------------------------ >>> >>> src/os/bsd/vm/semaphore_bsd.hpp >>> 28 #include "memory/allocation.hpp" >>> 29 >>> 30 #include >>> 31 >>> 32 #ifndef __APPLE__ >>> 33 # include "semaphore_posix.hpp" >>> 34 #else >>> 35 // OS X doesn't support unamed POSIX semaphores, so the >>> implementation in os_posix.cpp can't be used. >>> 36 >>> 37 class OSXSemaphore : public CHeapObj{ >>> >>> This only needs "memory/allocation.hpp" in the Apple case. >>> >>> This doesn't need in the non-Apple case. >> >> OK. >> >>> >>> In the Apple case, I think the correct include is >>> rather than . I'm not sure why is working >>> at all. >> >> I'll change it. >> >>> >>> ------------------------------------------------------------------------------ >>> >>> src/os/posix/vm/os_posix.cpp >>> 1021 #define check_with_errno(check_type, cond, >>> msg) \ >>> 1022 do { \ >>> 1023 int err = errno; \ >>> 1024 check_type(cond, err_msg("%s; error='%s' (errno=%d)", msg, >>> strerror(err), err)); \ >>> 1025 } while (false) >>> 1026 >>> 1027 #define assert_with_errno(cond, msg) check_with_errno(assert, >>> cond, msg) >>> 1028 #define guarantee_with_errno(cond, msg) >>> check_with_errno(guarantee, cond, msg) >>> >>> We already have assert_status in debug.hpp. It might be better to add >>> a corresponding guarantee_status there, and use those here. >> >> 1) The comment above vmassert_status says: >> >> // This version of vmassert is for use with checking return status from >> // library calls that return actual error values eg. EINVAL, >> // ENOMEM etc, rather than returning -1 and setting errno. >> // When the status is not what is expected it is very useful to know >> // what status was actually returned, so we pass the status variable as >> // an extra arg and use strerror to convert it to a meaningful string >> // like "Invalid argument", "out of memory" etc >> >> >> but called library calls actually do return -1 and sets errno. Maybe >> the comment is too specific? >> >> 2) I modeled the error message with this code in mind: >> >> 2587 static void warn_fail_commit_memory(char* addr, size_t size, >> bool exec, >> 2588 int err) { >> 2589 warning("INFO: os::commit_memory(" PTR_FORMAT ", " SIZE_FORMAT >> 2590 ", %d) failed; error='%s' (errno=%d)", addr, size, exec, >> 2591 strerror(err), err); >> 2592 } >> >>> >>> Also, these macros are only used inside the #ifndef __APPLE__ block. >> >> Yes, but they are not specific to non-__APPLE__ code, so I chooe to >> put it outside that block. >> >>> >>> And welcome to the dark side. (Higher order macros!) >>> >>> ------------------------------------------------------------------------------ >>> >>> src/os/posix/vm/os_posix.cpp >>> 1053 while ((ret = sem_wait(&_semaphore)) == -1 && errno == EINTR) { >>> >>> I would probably instead use >>> >>> (ret = sem_wait(&_semaphore)) != 0 >>> >>> e.g. while !successful. >> >> Sure. >> >>> >>> ------------------------------------------------------------------------------ >>> >>> src/os/posix/vm/os_posix.cpp >>> 1059 bool PosixSemaphore::trywait() { >>> 1060 bool succeeded = sem_trywait(&_semaphore) == 0; >>> 1061 >>> 1062 assert_with_errno(succeeded || errno == EAGAIN, "trywait >>> failed"); >>> 1063 >>> 1064 return succeeded; >>> 1065 } >>> >>> sem_trywait can also fail with EINTR. >> >> Will fix the assert. >> >>> >>> ------------------------------------------------------------------------------ >>> >>> src/os/posix/vm/os_posix.cpp >>> 1072 } else if (errno == EINTR) { >>> 1073 continue; >>> 1074 } else if (errno == ETIMEDOUT) { >>> >>> I think ETIMEDOUT should be tested before EINTR. ETIMEDOUT is the >>> more interesting and performance relevant case. >> >> This pre-existing code can be fixed as a separate RFE. >> >>> >>> ------------------------------------------------------------------------------ >>> >>> src/os/windows/vm/os_windows.cpp >>> 1905 WindowsSemaphore::~WindowsSemaphore() { >>> 1906 if (_semaphore != NULL) { >>> 1907 ::CloseHandle(_semaphore); >>> 1908 } >>> >>> I don't think the NULL check is needed here. >> >> I'll remove it. >> >>> >>> ------------------------------------------------------------------------------ >>> >>> src/os/bsd/vm/semaphore_bsd.hpp >>> 56 static jlong currenttime(); >>> >>> This function is an implementation detail of the timedwait function, >>> and could be a file-scoped static near its caller, rather than having >>> external linkage. >> >> Yes. I put it in the class so that I wouldn't have to create a prefix >> for currenttime and to make it obvious that only the OSXSemaphore >> uses that function. >> >>> >>> [The PosixSemaphore class is different in this respect, because there >>> we need to choose between platform-specific definitions of >>> create_timespec that will be in a different file from the reference, >>> so external linkage is required. That situation doesn't apply for >>> OSXSemaphore.] >>> >>> ------------------------------------------------------------------------------ >>> >>> src/os/windows/vm/semaphore_windows.hpp >>> 30 #include >>> >>> I think is sufficient here, and is purportedly smaller. >>> The .cpp file likely needs more, but is already including . >>> Also, it looks like we prefer the lowercase form on Windows, even >>> though the file system is case-insensitive. >> >> I'll fix. >> >>> >>> ------------------------------------------------------------------------------ >>> >>> src/os/windows/vm/semaphore_windows.hpp >>> 43 void signal(uint count = 0); >>> >>> Default count of 0 is inconsistent with corresponding classes for >>> other platforms. >> >> This is a bug that I thought I had fixed. I'll change it. >> >>> >>> ------------------------------------------------------------------------------ >>> >>> src/share/vm/runtime/semaphore.cpp >>> 30 Semaphore::Semaphore(uint value) : _impl(value) {} >>> 31 Semaphore::~Semaphore() {} >>> 32 void Semaphore::signal(uint count) { _impl.signal(count); } >>> 33 void Semaphore::wait() { _impl.wait(); } >>> >>> I'm not sure why these forwarding definitions are out of line in the >>> .cpp file, rather than inline in the header. After all, we've now >>> gone to some trouble to have the wrapped platform-specific >>> implementation class provide at least that set of operations. >> >> Because I don't think they are performance critical. Another reason >> is that one of my prototypes forward declared SemaphoreImpl in >> semaphore.hpp and only included the platform specific >> semaphore_xxx.hpp files in the semaphore.cpp file. >> >> But sure, I can inline them in the .hpp file. >> >> Thanks, >> StefanK >>> >>> ------------------------------------------------------------------------------ >>> >>> >> > From gerard.ziemski at oracle.com Thu Jun 25 21:35:40 2015 From: gerard.ziemski at oracle.com (Gerard Ziemski) Date: Thu, 25 Jun 2015 16:35:40 -0500 Subject: RFR (S): 8112746 Followup to JEP 245: Validate JVM Command-Line Flag Arguments In-Reply-To: <558C7301.6020702@oracle.com> References: <558C4043.4050103@oracle.com> <558C7301.6020702@oracle.com> Message-ID: <558C742C.20509@oracle.com> Hmm, I fixed those white spaces at least three times now. I wonder if XCode does something funky... Thank you Dmitry. I will look into this. cheers On 6/25/2015 4:30 PM, Dmitry Dmitriev wrote: > Hi Gerard, > > It seems that recently added > space(https://bugs.openjdk.java.net/browse/JDK-8081202) between macro > and double quotes is disappear in several files. I.e. must be: " > INTX_FORMAT " instead of "INTX_FORMAT" > Files where space is disappear: > 1) src/share/vm/runtime/commandLineFlagConstraintsCompiler.cpp > All changes in file. > > 2) src/share/vm/runtime/commandLineFlagConstraintsGC.cpp > All changes in file. > > 3) src/share/vm/runtime/commandLineFlagRangeList.cpp > On lines 81(3 times), 131(3 times), 156(3 times) and 181(3 times). > > Thanks, > Dmitry > > On 25.06.2015 20:54, Gerard Ziemski wrote: >> hi all, >> >> Please review this followup to my recent JEP 245 checkin. It addresses the issues raised by Coleen, Dmitry and Kim during webrev. >> >> You can seehttps://bugs.openjdk.java.net/browse/JDK-8112746 for details, but the most important change here is that we only check constraint if the range check passes first. >> >> To quickly recap: I changed that part of the code when David pointed out that I had to modify 2 tests in a way that looked like a regression - I removed some test cases. However, Kim, later pointed out that the original code had the advantage of having constraints guaranteed that the flag values were within ranges. >> >> I checked in the code with ranges and constraints being checked both regardless of each other, but this followup restores the original behavior (and simplifies the code), where we first check ranges and only check constraints if range passes. >> >> The 2 tests (ObjectAlignment.java and Options.java) seem to loose some test cases, but those paths are still tested (though with different values), so we in fact do not loose anything from test coverage point of view. >> >> The change passes JPRT (hotspot) and RBT (vm.quick.testlist) >> >> >> References: >> >> webrev:http://cr.openjdk.java.net/~gziemski/8112746_rev0/ >> this issue:https://bugs.openjdk.java.net/browse/JDK-8112746 >> JEP 245:https://bugs.openjdk.java.net/browse/JDK-8059557 >> >> >> hg stat: >> src/share/vm/gc/g1/g1_globals.hpp | 4 +- >> src/share/vm/runtime/commandLineFlagConstraintsCompiler.cpp | 2 +- >> src/share/vm/runtime/commandLineFlagConstraintsGC.cpp | 55 ++-- >> src/share/vm/runtime/commandLineFlagRangeList.cpp | 58 ++--- >> src/share/vm/runtime/globals.cpp | 129 ++++++----- >> src/share/vm/runtime/globals.hpp | 17 +- >> test/runtime/CompressedOops/ObjectAlignment.java | 3 +- >> test/runtime/contended/Options.java | 2 - >> 8 files changed, 129 insertions(+), 141 deletions(-) >> > From gerard.ziemski at oracle.com Thu Jun 25 21:52:27 2015 From: gerard.ziemski at oracle.com (Gerard Ziemski) Date: Thu, 25 Jun 2015 16:52:27 -0500 Subject: RFR (S): 8112746 Followup to JEP 245: Validate JVM Command-Line Flag Arguments In-Reply-To: <558C742C.20509@oracle.com> References: <558C4043.4050103@oracle.com> <558C7301.6020702@oracle.com> <558C742C.20509@oracle.com> Message-ID: <558C781B.5050400@oracle.com> Nope, that was just me - I got the fix exactly the opposite of what it should be. I will rev up. On 6/25/2015 4:35 PM, Gerard Ziemski wrote: > Hmm, I fixed those white spaces at least three times now. I wonder if > XCode does something funky... > > Thank you Dmitry. I will look into this. > > > cheers > > On 6/25/2015 4:30 PM, Dmitry Dmitriev wrote: >> Hi Gerard, >> >> It seems that recently added >> space(https://bugs.openjdk.java.net/browse/JDK-8081202) between macro >> and double quotes is disappear in several files. I.e. must be: " >> INTX_FORMAT " instead of "INTX_FORMAT" >> Files where space is disappear: >> 1) src/share/vm/runtime/commandLineFlagConstraintsCompiler.cpp >> All changes in file. >> >> 2) src/share/vm/runtime/commandLineFlagConstraintsGC.cpp >> All changes in file. >> >> 3) src/share/vm/runtime/commandLineFlagRangeList.cpp >> On lines 81(3 times), 131(3 times), 156(3 times) and 181(3 times). >> >> Thanks, >> Dmitry >> >> On 25.06.2015 20:54, Gerard Ziemski wrote: >>> hi all, >>> >>> Please review this followup to my recent JEP 245 checkin. It >>> addresses the issues raised by Coleen, Dmitry and Kim during webrev. >>> >>> You can seehttps://bugs.openjdk.java.net/browse/JDK-8112746 for >>> details, but the most important change here is that we only check >>> constraint if the range check passes first. >>> >>> To quickly recap: I changed that part of the code when David pointed >>> out that I had to modify 2 tests in a way that looked like a >>> regression - I removed some test cases. However, Kim, later pointed >>> out that the original code had the advantage of having constraints >>> guaranteed that the flag values were within ranges. >>> >>> I checked in the code with ranges and constraints being checked both >>> regardless of each other, but this followup restores the original >>> behavior (and simplifies the code), where we first check ranges and >>> only check constraints if range passes. >>> >>> The 2 tests (ObjectAlignment.java and Options.java) seem to loose >>> some test cases, but those paths are still tested (though with >>> different values), so we in fact do not loose anything from test >>> coverage point of view. >>> >>> The change passes JPRT (hotspot) and RBT (vm.quick.testlist) >>> >>> >>> References: >>> >>> webrev:http://cr.openjdk.java.net/~gziemski/8112746_rev0/ >>> this issue:https://bugs.openjdk.java.net/browse/JDK-8112746 >>> JEP 245:https://bugs.openjdk.java.net/browse/JDK-8059557 >>> >>> >>> hg stat: >>> src/share/vm/gc/g1/g1_globals.hpp | 4 +- >>> src/share/vm/runtime/commandLineFlagConstraintsCompiler.cpp | 2 +- >>> src/share/vm/runtime/commandLineFlagConstraintsGC.cpp | 55 ++-- >>> src/share/vm/runtime/commandLineFlagRangeList.cpp | 58 ++--- >>> src/share/vm/runtime/globals.cpp | 129 ++++++----- >>> src/share/vm/runtime/globals.hpp | 17 +- >>> test/runtime/CompressedOops/ObjectAlignment.java | 3 +- >>> test/runtime/contended/Options.java | 2 - >>> 8 files changed, 129 insertions(+), 141 deletions(-) >>> >> > > > From gerard.ziemski at oracle.com Thu Jun 25 21:58:38 2015 From: gerard.ziemski at oracle.com (Gerard Ziemski) Date: Thu, 25 Jun 2015 16:58:38 -0500 Subject: Rev1 RFR (S): 8112746 Followup to JEP 245: Validate JVM Command-Line Flag Arguments Message-ID: <558C798E.6040307@oracle.com> hi all, This webrev gets the macro and quotes fix right. Please review this followup to my recent JEP 245 checkin. It addresses the issues raised by Coleen, Dmitry and Kim during webrev. You can see https://bugs.openjdk.java.net/browse/JDK-8112746 for details, but the most important change here is that we only check constraint if the range check passes first. To quickly recap: I changed that part of the code when David pointed out that I had to modify 2 tests in a way that looked like a regression - I removed some test cases. However, Kim, later pointed out that the original code had the advantage of having constraints guaranteed that the flag values were within ranges. I checked in the code with ranges and constraints being checked both regardless of each other, but this followup restores the original behavior (and simplifies the code), where we first check ranges and only check constraints if range passes. The 2 tests (ObjectAlignment.java and Options.java) seem to loose some test cases, but those paths are still tested (though with different values), so we in fact do not loose anything from test coverage point of view. The change passes JPRT (hotspot) and RBT (vm.quick.testlist) References: webrev:http://cr.openjdk.java.net/~gziemski/8112746_rev1 this issue:https://bugs.openjdk.java.net/browse/JDK-8112746 JEP 245:https://bugs.openjdk.java.net/browse/JDK-8059557 hg stat: # hg_stat src/share/vm/gc/g1/g1_globals.hpp | 4 +- src/share/vm/runtime/commandLineFlagConstraintsGC.cpp | 5 +- src/share/vm/runtime/commandLineFlagRangeList.cpp | 58 ++++------ src/share/vm/runtime/globals.cpp | 129 +++++++++++++---------- src/share/vm/runtime/globals.hpp | 17 +-- test/runtime/CompressedOops/ObjectAlignment.java | 3 +- test/runtime/contended/Options.java | 2 - 7 files changed, 103 insertions(+), 115 deletions(-) From david.holmes at oracle.com Fri Jun 26 05:39:33 2015 From: david.holmes at oracle.com (David Holmes) Date: Fri, 26 Jun 2015 15:39:33 +1000 Subject: IgnoreUnrecognizedVMOptions and badly specified options In-Reply-To: <558C36CE.6090606@oracle.com> References: <558BF15A.6030702@oracle.com> <558C141B.9080006@oracle.com> <558C3397.80001@oracle.com> <558C34FC.803@oracle.com> <558C35DC.5060002@oracle.com> <558C36CE.6090606@oracle.com> Message-ID: <558CE595.2050604@oracle.com> On 26/06/2015 3:13 AM, Dmitry Dmitriev wrote: > Thank you Dan! The bug states about changed behaviour but it relates to > the current implementation of IgnoreUnrecongnizedVMOptions flag and I > think it can be fixed by this RFR. As I added to the/a bug report I think we need a very clear spec on how all these aspects of option checking should interact - what should be ignored by IgnoreUnrecognizedVMOptions? Is a badly formed option "unrecognized"? A flow chart covering all the possibilities and the precedence would make it a lot easier to validate the code. Cheers, David > On 25.06.2015 20:09, Daniel D. Daugherty wrote: >> I'm pretty sure that bug was filed this morning: >> >> JDK-8129855 -XX:+IgnoreUnrecognizedVMOptions hides improperly >> specified VM options. >> https://bugs.openjdk.java.net/browse/JDK-8129855 >> >> Michail was reading your mind... > No magic here, we discuss this topic today :) I am become curious about > that behaviour, since this code exit for a long time. > > Regards, > Dmitry > >> >> Dan >> >> >> On 6/25/15 11:06 AM, Vladimir Kozlov wrote: >>> File bug on runtime (who handles flags verification this days?) with >>> your suggestion. >>> >>> Thanks, >>> Vladimir >>> >>> On 6/25/15 10:00 AM, Dmitry Dmitriev wrote: >>>> Hello Vladimir, >>>> >>>> Thank you for explanation. I just was bit confused about valid VM >>>> options but which improperly specified. >>>> I look at the Arguments::process_argument function in >>>> src/share/vm/runtime/arguments.cpp module and noticed one thing: >>>> >>>> 817 bool Arguments::process_argument(const char* arg, >>>> 818 jboolean ignore_unrecognized, Flag::Flags origin) { >>>> 819 >>>> 820 JDK_Version since = JDK_Version(); >>>> 821 >>>> 822 if (parse_argument(arg, origin) || ignore_unrecognized) { >>>> 823 return true; >>>> 824 } >>>> ... >>>> 850 // For locked flags, report a custom error message if >>>> available. >>>> 851 // Otherwise, report the standard unrecognized VM option. >>>> 852 Flag* found_flag = Flag::find_flag((const char*)argname, >>>> arg_len, true, true); >>>> 853 if (found_flag != NULL) { >>>> 854 char locked_message_buf[BUFLEN]; >>>> 855 found_flag->get_locked_message(locked_message_buf, BUFLEN); >>>> 856 if (strlen(locked_message_buf) == 0) { >>>> 857 if (found_flag->is_bool() && !has_plus_minus) { >>>> 858 jio_fprintf(defaultStream::error_stream(), >>>> 859 "Missing +/- setting for VM option '%s'\n", argname); >>>> 860 } else if (!found_flag->is_bool() && has_plus_minus) { >>>> 861 jio_fprintf(defaultStream::error_stream(), >>>> 862 "Unexpected +/- setting in VM option '%s'\n", argname); >>>> 863 } else { >>>> 864 jio_fprintf(defaultStream::error_stream(), >>>> 865 "Improperly specified VM option '%s'\n", argname); >>>> 866 } >>>> 867 } else { >>>> 868 jio_fprintf(defaultStream::error_stream(), "%s", >>>> locked_message_buf); >>>> 869 } >>>> 870 } else { >>>> 871 jio_fprintf(defaultStream::error_stream(), >>>> 872 "Unrecognized VM option '%s'\n", argname); >>>> 873 Flag* fuzzy_matched = Flag::fuzzy_match((const >>>> char*)argname, arg_len, true); >>>> 874 if (fuzzy_matched != NULL) { >>>> 875 jio_fprintf(defaultStream::error_stream(), >>>> 876 "Did you mean '%s%s%s'? ", >>>> 877 (fuzzy_matched->is_bool()) ? "(+/-)" : "", >>>> 878 fuzzy_matched->_name, >>>> 879 (fuzzy_matched->is_bool()) ? "" : "="); >>>> 880 } >>>> 881 } >>>> 882 >>>> 883 // allow for commandline "commenting out" options like >>>> -XX:#+Verbose >>>> 884 return arg[0] == '#'; >>>> 885 } >>>> >>>> If "-XX:+IgnoreUnrecongnizedVMOptions" is specified, then >>>> "ignore_unrecognized" will be true and "if" statement on line >>>> 822 will always be true. >>>> I just think that a better place to check "ignore_unrecognized" is >>>> on "else" branch on line 867(for locked flags) and on >>>> "else" branch on line 870(where we actually found unrecognized >>>> option). If "ignore_unrecognized" is true, then return >>>> true in this case, otherwise execute code in these "else" branches. >>>> It's my thoughts about that. In this case improperly >>>> specified options will be catched(lines 857-866). >>>> >>>> Thanks, >>>> Dmitry >>>> >>>> >>>> On 25.06.2015 17:45, Vladimir Kozlov wrote: >>>>> It is not intentional but difficult to implement. >>>>> It was added to allow specify options which are not defined in >>>>> running VM. >>>>> For example when C2 option is specified but Client VM (which has >>>>> only C1) is run. >>>>> We can do more smarter things here, I agree, by trying to verify >>>>> options before ignoring it. >>>>> But it will not help with misspelled options, I think. >>>>> >>>>> Regards, >>>>> Vladimir >>>>> >>>>> On 6/25/15 5:17 AM, Dmitry Dmitriev wrote: >>>>>> Hello, >>>>>> >>>>>> Working with JVM command line options I noticed that >>>>>> "IgnoreUnrecognizedVMOptions" option allow to hide options with bad >>>>>> values. "IgnoreUnrecognizedVMOptions" allow to ignore unrecognized >>>>>> options, but it also allow to ignore improperly >>>>>> specified VM Options which are processed in general way, i.e. >>>>>> "-XX:" options processed by Arguments::process_argument >>>>>> function(hotspot/src/share/vm/runtime/arguments.cpp module). >>>>>> >>>>>> I will be very appreciated if someone can describe this behavior >>>>>> or state that this is intentional. >>>>>> >>>>>> Example for numeric and boolean options: >>>>>> 1) Bad numeric option with and without >>>>>> "-XX:+IgnoreUnrecongnizedVMOptions" >>>>>> java -XX:MaxRAMFraction=-1 -version >>>>>> Improperly specified VM option 'MaxRAMFraction=-1' >>>>>> Error: Could not create the Java Virtual Machine. >>>>>> Error: A fatal exception has occurred. Program will exit. >>>>>> >>>>>> java -XX:MaxRAMFraction=-1 -XX:+IgnoreUnrecognizedVMOptions -version >>>>>> java version "1.8.0_40" >>>>>> Java(TM) SE Runtime Environment (build 1.8.0_40-b26) >>>>>> Java HotSpot(TM) 64-Bit Server VM (build 25.40-b25, mixed mode) >>>>>> >>>>>> 2) Bad boolean option with and without >>>>>> "-XX:+IgnoreUnrecongnizedVMOptions" >>>>>> java -XX:UseG1GC -version >>>>>> Missing +/- setting for VM option 'UseG1GC' >>>>>> Error: Could not create the Java Virtual Machine. >>>>>> Error: A fatal exception has occurred. Program will exit. >>>>>> >>>>>> java -XX:UseG1GC -XX:+IgnoreUnrecognizedVMOptions -version >>>>>> java version "1.8.0_40" >>>>>> Java(TM) SE Runtime Environment (build 1.8.0_40-b26) >>>>>> Java HotSpot(TM) 64-Bit Server VM (build 25.40-b25, mixed mode) >>>>>> >>>>>> So, as we see when "-XX:+IgnoreUnrecongnizedVMOptions" is used, >>>>>> bad "-XX:MaxRAMFraction=-1" and "-XX:UseG1GC" are >>>>>> ignored. I don't know is this behavior intentional or not, but >>>>>> HotSpot works in that way. >>>>>> >>>>>> So, can someone tell me this is intentional? Or this behavior is >>>>>> wrong? >>>>>> >>>>>> Thank you, >>>>>> Dmitry >>>>>> >>>>>> >>>> >> > From bengt.rutisson at oracle.com Fri Jun 26 06:00:56 2015 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Fri, 26 Jun 2015 08:00:56 +0200 Subject: IgnoreUnrecognizedVMOptions and badly specified options In-Reply-To: <558CE595.2050604@oracle.com> References: <558BF15A.6030702@oracle.com> <558C141B.9080006@oracle.com> <558C3397.80001@oracle.com> <558C34FC.803@oracle.com> <558C35DC.5060002@oracle.com> <558C36CE.6090606@oracle.com> <558CE595.2050604@oracle.com> Message-ID: <558CEA98.1070501@oracle.com> Hi all, Just one more thought if we are thinking about making changes to the IgnoreUnrecognizedVMOptions flag. I am not a big fan of this flag since I think it just goes to show that we don't have enough control over our testing. As I understand it the main reason for the introduction of this flag was that when compressed oops was implemented we had no way of controlling which tests were run on 32 bit platforms (where the UseCompressedOops flag is not available) or o 64 bit platforms. I think it is unfortunate that we don't have better control of our testing. But one way of at least increasing the control would be to make IgnoreUnrecognizedVMOptions more specific. I would suggest that we change it to take a named argument that should be ignored. Something like: -XX:IgnoreUnrecognizedVMOption=UseCompressedOops That way it would not hide other issues in our testing. As it is now we run a lot of our testing with IgnoreUnrecognizedVMOptions which means that we don't find tests that need to be updated when we for example remove a command line option. Maybe it is a side track, but I wanted to mention it in this discussion. Bengt On 2015-06-26 07:39, David Holmes wrote: > On 26/06/2015 3:13 AM, Dmitry Dmitriev wrote: >> Thank you Dan! The bug states about changed behaviour but it relates to >> the current implementation of IgnoreUnrecongnizedVMOptions flag and I >> think it can be fixed by this RFR. > > As I added to the/a bug report I think we need a very clear spec on > how all these aspects of option checking should interact - what should > be ignored by IgnoreUnrecognizedVMOptions? Is a badly formed option > "unrecognized"? A flow chart covering all the possibilities and the > precedence would make it a lot easier to validate the code. > > Cheers, > David > >> On 25.06.2015 20:09, Daniel D. Daugherty wrote: >>> I'm pretty sure that bug was filed this morning: >>> >>> JDK-8129855 -XX:+IgnoreUnrecognizedVMOptions hides improperly >>> specified VM options. >>> https://bugs.openjdk.java.net/browse/JDK-8129855 >>> >>> Michail was reading your mind... >> No magic here, we discuss this topic today :) I am become curious about >> that behaviour, since this code exit for a long time. >> >> Regards, >> Dmitry >> >>> >>> Dan >>> >>> >>> On 6/25/15 11:06 AM, Vladimir Kozlov wrote: >>>> File bug on runtime (who handles flags verification this days?) with >>>> your suggestion. >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 6/25/15 10:00 AM, Dmitry Dmitriev wrote: >>>>> Hello Vladimir, >>>>> >>>>> Thank you for explanation. I just was bit confused about valid VM >>>>> options but which improperly specified. >>>>> I look at the Arguments::process_argument function in >>>>> src/share/vm/runtime/arguments.cpp module and noticed one thing: >>>>> >>>>> 817 bool Arguments::process_argument(const char* arg, >>>>> 818 jboolean ignore_unrecognized, Flag::Flags origin) { >>>>> 819 >>>>> 820 JDK_Version since = JDK_Version(); >>>>> 821 >>>>> 822 if (parse_argument(arg, origin) || ignore_unrecognized) { >>>>> 823 return true; >>>>> 824 } >>>>> ... >>>>> 850 // For locked flags, report a custom error message if >>>>> available. >>>>> 851 // Otherwise, report the standard unrecognized VM option. >>>>> 852 Flag* found_flag = Flag::find_flag((const char*)argname, >>>>> arg_len, true, true); >>>>> 853 if (found_flag != NULL) { >>>>> 854 char locked_message_buf[BUFLEN]; >>>>> 855 found_flag->get_locked_message(locked_message_buf, BUFLEN); >>>>> 856 if (strlen(locked_message_buf) == 0) { >>>>> 857 if (found_flag->is_bool() && !has_plus_minus) { >>>>> 858 jio_fprintf(defaultStream::error_stream(), >>>>> 859 "Missing +/- setting for VM option '%s'\n", argname); >>>>> 860 } else if (!found_flag->is_bool() && has_plus_minus) { >>>>> 861 jio_fprintf(defaultStream::error_stream(), >>>>> 862 "Unexpected +/- setting in VM option '%s'\n", >>>>> argname); >>>>> 863 } else { >>>>> 864 jio_fprintf(defaultStream::error_stream(), >>>>> 865 "Improperly specified VM option '%s'\n", argname); >>>>> 866 } >>>>> 867 } else { >>>>> 868 jio_fprintf(defaultStream::error_stream(), "%s", >>>>> locked_message_buf); >>>>> 869 } >>>>> 870 } else { >>>>> 871 jio_fprintf(defaultStream::error_stream(), >>>>> 872 "Unrecognized VM option '%s'\n", argname); >>>>> 873 Flag* fuzzy_matched = Flag::fuzzy_match((const >>>>> char*)argname, arg_len, true); >>>>> 874 if (fuzzy_matched != NULL) { >>>>> 875 jio_fprintf(defaultStream::error_stream(), >>>>> 876 "Did you mean '%s%s%s'? ", >>>>> 877 (fuzzy_matched->is_bool()) ? "(+/-)" : "", >>>>> 878 fuzzy_matched->_name, >>>>> 879 (fuzzy_matched->is_bool()) ? "" : >>>>> "="); >>>>> 880 } >>>>> 881 } >>>>> 882 >>>>> 883 // allow for commandline "commenting out" options like >>>>> -XX:#+Verbose >>>>> 884 return arg[0] == '#'; >>>>> 885 } >>>>> >>>>> If "-XX:+IgnoreUnrecongnizedVMOptions" is specified, then >>>>> "ignore_unrecognized" will be true and "if" statement on line >>>>> 822 will always be true. >>>>> I just think that a better place to check "ignore_unrecognized" is >>>>> on "else" branch on line 867(for locked flags) and on >>>>> "else" branch on line 870(where we actually found unrecognized >>>>> option). If "ignore_unrecognized" is true, then return >>>>> true in this case, otherwise execute code in these "else" branches. >>>>> It's my thoughts about that. In this case improperly >>>>> specified options will be catched(lines 857-866). >>>>> >>>>> Thanks, >>>>> Dmitry >>>>> >>>>> >>>>> On 25.06.2015 17:45, Vladimir Kozlov wrote: >>>>>> It is not intentional but difficult to implement. >>>>>> It was added to allow specify options which are not defined in >>>>>> running VM. >>>>>> For example when C2 option is specified but Client VM (which has >>>>>> only C1) is run. >>>>>> We can do more smarter things here, I agree, by trying to verify >>>>>> options before ignoring it. >>>>>> But it will not help with misspelled options, I think. >>>>>> >>>>>> Regards, >>>>>> Vladimir >>>>>> >>>>>> On 6/25/15 5:17 AM, Dmitry Dmitriev wrote: >>>>>>> Hello, >>>>>>> >>>>>>> Working with JVM command line options I noticed that >>>>>>> "IgnoreUnrecognizedVMOptions" option allow to hide options with bad >>>>>>> values. "IgnoreUnrecognizedVMOptions" allow to ignore unrecognized >>>>>>> options, but it also allow to ignore improperly >>>>>>> specified VM Options which are processed in general way, i.e. >>>>>>> "-XX:" options processed by Arguments::process_argument >>>>>>> function(hotspot/src/share/vm/runtime/arguments.cpp module). >>>>>>> >>>>>>> I will be very appreciated if someone can describe this behavior >>>>>>> or state that this is intentional. >>>>>>> >>>>>>> Example for numeric and boolean options: >>>>>>> 1) Bad numeric option with and without >>>>>>> "-XX:+IgnoreUnrecongnizedVMOptions" >>>>>>> java -XX:MaxRAMFraction=-1 -version >>>>>>> Improperly specified VM option 'MaxRAMFraction=-1' >>>>>>> Error: Could not create the Java Virtual Machine. >>>>>>> Error: A fatal exception has occurred. Program will exit. >>>>>>> >>>>>>> java -XX:MaxRAMFraction=-1 -XX:+IgnoreUnrecognizedVMOptions >>>>>>> -version >>>>>>> java version "1.8.0_40" >>>>>>> Java(TM) SE Runtime Environment (build 1.8.0_40-b26) >>>>>>> Java HotSpot(TM) 64-Bit Server VM (build 25.40-b25, mixed mode) >>>>>>> >>>>>>> 2) Bad boolean option with and without >>>>>>> "-XX:+IgnoreUnrecongnizedVMOptions" >>>>>>> java -XX:UseG1GC -version >>>>>>> Missing +/- setting for VM option 'UseG1GC' >>>>>>> Error: Could not create the Java Virtual Machine. >>>>>>> Error: A fatal exception has occurred. Program will exit. >>>>>>> >>>>>>> java -XX:UseG1GC -XX:+IgnoreUnrecognizedVMOptions -version >>>>>>> java version "1.8.0_40" >>>>>>> Java(TM) SE Runtime Environment (build 1.8.0_40-b26) >>>>>>> Java HotSpot(TM) 64-Bit Server VM (build 25.40-b25, mixed mode) >>>>>>> >>>>>>> So, as we see when "-XX:+IgnoreUnrecongnizedVMOptions" is used, >>>>>>> bad "-XX:MaxRAMFraction=-1" and "-XX:UseG1GC" are >>>>>>> ignored. I don't know is this behavior intentional or not, but >>>>>>> HotSpot works in that way. >>>>>>> >>>>>>> So, can someone tell me this is intentional? Or this behavior is >>>>>>> wrong? >>>>>>> >>>>>>> Thank you, >>>>>>> Dmitry >>>>>>> >>>>>>> >>>>> >>> >> From david.holmes at oracle.com Fri Jun 26 06:48:55 2015 From: david.holmes at oracle.com (David Holmes) Date: Fri, 26 Jun 2015 16:48:55 +1000 Subject: RFR: 8087322: Implement a Semaphore utility class In-Reply-To: <558C7424.1060002@oracle.com> References: <557AF8E4.9040804@oracle.com> <557F3582.6060401@oracle.com> <5581B597.5080900@oracle.com> <55836FF2.6070604@oracle.com> <55881B78.3040909@oracle.com> <558A8D78.5000209@oracle.com> <558B21CB.1010901@oracle.com> <558C2F89.3070908@oracle.com> <558C7424.1060002@oracle.com> Message-ID: <558CF5D7.6090906@oracle.com> Hi Dean, On 26/06/2015 7:35 AM, Dean Long wrote: > On 6/25/2015 9:42 AM, Stefan Karlsson wrote: >> Hi all, >> >> Updated webrev: >> http://cr.openjdk.java.net/~stefank/8087322/webrev.05.delta >> http://cr.openjdk.java.net/~stefank/8087322/webrev.05 >> >> - Removed unnecessary and incorrect initialization of _semaphore >> >> - Fixed includes >> >> - Loop around sem_trywait if EINTR is reported >> > > How about this instead? > > 1061 bool PosixSemaphore::trywait() { > 1062 int ret = sem_trywait(&_semaphore); > 1068 assert_with_errno(ret == 0 || (errno == EAGAIN || errno == > EINTR), "trywait failed"); That amounts to a spurious failure, suggesting the semaphore was not available when in fact it may have been. The retry is semantically better. Cheers, David > > dl > >> - Removed unnecessary NULL check on windows >> >> - Fixed the default value for signal(uint count), on windows. >> >> - Moved Sempahore implementation from semaphore.cpp to semaphore.hpp >> >> I skipped implementing some of the suggestions that were not essential >> for this patch or that we haven't reached an agreement on. It doesn't >> mean that I don't think we should do some of the cleanups. If we could >> get the structural changes in place (and bug fixes), then we can fix >> some of the details as follow-up RFEs. >> >> Thanks, >> StefanK >> >> On 2015-06-24 23:31, Stefan Karlsson wrote: >>> Hi Kim, >>> >>> On 2015-06-24 22:28, Kim Barrett wrote: >>>> On Jun 24, 2015, at 6:59 AM, Stefan Karlsson >>>> wrote: >>>>> Hi all, >>>>> >>>>> Updated webrev: >>>>> http://cr.openjdk.java.net/~stefank/8087322/webrev.04 >>>> Structurally fine. (Stefan would be rightly annoyed with me if I said >>>> otherwise after all the offline discussions we've had.) There's some >>>> nastiness that results from pre-existing problems in the os_xxx.cpp >>>> files, but cleaning that up is another collection of tasks. >>>> >>>> A few easy bugs, some stylistic comments that can be accepted or >>>> declined, but nothing requiring large amounts of rework. >>>> >>>> ------------------------------------------------------------------------------ >>>> >>>> src/os/bsd/vm/os_bsd.cpp >>>> 1971 OSXSemaphore::OSXSemaphore(uint value) : _semaphore(0) { >>>> >>>> I think that initializer for _semaphore isn't right. _semaphore is a >>>> (OSX) semaphore_t. I think that initializer only accidentally >>>> compiles at all. >>> >>> This is one yet another case of pre-existing code. >>> >>>> >>>> ------------------------------------------------------------------------------ >>>> >>>> src/os/bsd/vm/semaphore_bsd.hpp >>>> 28 #include "memory/allocation.hpp" >>>> 29 >>>> 30 #include >>>> 31 >>>> 32 #ifndef __APPLE__ >>>> 33 # include "semaphore_posix.hpp" >>>> 34 #else >>>> 35 // OS X doesn't support unamed POSIX semaphores, so the >>>> implementation in os_posix.cpp can't be used. >>>> 36 >>>> 37 class OSXSemaphore : public CHeapObj{ >>>> >>>> This only needs "memory/allocation.hpp" in the Apple case. >>>> >>>> This doesn't need in the non-Apple case. >>> >>> OK. >>> >>>> >>>> In the Apple case, I think the correct include is >>>> rather than . I'm not sure why is working >>>> at all. >>> >>> I'll change it. >>> >>>> >>>> ------------------------------------------------------------------------------ >>>> >>>> src/os/posix/vm/os_posix.cpp >>>> 1021 #define check_with_errno(check_type, cond, >>>> msg) \ >>>> 1022 do { \ >>>> 1023 int err = errno; \ >>>> 1024 check_type(cond, err_msg("%s; error='%s' (errno=%d)", msg, >>>> strerror(err), err)); \ >>>> 1025 } while (false) >>>> 1026 >>>> 1027 #define assert_with_errno(cond, msg) check_with_errno(assert, >>>> cond, msg) >>>> 1028 #define guarantee_with_errno(cond, msg) >>>> check_with_errno(guarantee, cond, msg) >>>> >>>> We already have assert_status in debug.hpp. It might be better to add >>>> a corresponding guarantee_status there, and use those here. >>> >>> 1) The comment above vmassert_status says: >>> >>> // This version of vmassert is for use with checking return status from >>> // library calls that return actual error values eg. EINVAL, >>> // ENOMEM etc, rather than returning -1 and setting errno. >>> // When the status is not what is expected it is very useful to know >>> // what status was actually returned, so we pass the status variable as >>> // an extra arg and use strerror to convert it to a meaningful string >>> // like "Invalid argument", "out of memory" etc >>> >>> >>> but called library calls actually do return -1 and sets errno. Maybe >>> the comment is too specific? >>> >>> 2) I modeled the error message with this code in mind: >>> >>> 2587 static void warn_fail_commit_memory(char* addr, size_t size, >>> bool exec, >>> 2588 int err) { >>> 2589 warning("INFO: os::commit_memory(" PTR_FORMAT ", " SIZE_FORMAT >>> 2590 ", %d) failed; error='%s' (errno=%d)", addr, size, exec, >>> 2591 strerror(err), err); >>> 2592 } >>> >>>> >>>> Also, these macros are only used inside the #ifndef __APPLE__ block. >>> >>> Yes, but they are not specific to non-__APPLE__ code, so I chooe to >>> put it outside that block. >>> >>>> >>>> And welcome to the dark side. (Higher order macros!) >>>> >>>> ------------------------------------------------------------------------------ >>>> >>>> src/os/posix/vm/os_posix.cpp >>>> 1053 while ((ret = sem_wait(&_semaphore)) == -1 && errno == EINTR) { >>>> >>>> I would probably instead use >>>> >>>> (ret = sem_wait(&_semaphore)) != 0 >>>> >>>> e.g. while !successful. >>> >>> Sure. >>> >>>> >>>> ------------------------------------------------------------------------------ >>>> >>>> src/os/posix/vm/os_posix.cpp >>>> 1059 bool PosixSemaphore::trywait() { >>>> 1060 bool succeeded = sem_trywait(&_semaphore) == 0; >>>> 1061 >>>> 1062 assert_with_errno(succeeded || errno == EAGAIN, "trywait >>>> failed"); >>>> 1063 >>>> 1064 return succeeded; >>>> 1065 } >>>> >>>> sem_trywait can also fail with EINTR. >>> >>> Will fix the assert. >>> >>>> >>>> ------------------------------------------------------------------------------ >>>> >>>> src/os/posix/vm/os_posix.cpp >>>> 1072 } else if (errno == EINTR) { >>>> 1073 continue; >>>> 1074 } else if (errno == ETIMEDOUT) { >>>> >>>> I think ETIMEDOUT should be tested before EINTR. ETIMEDOUT is the >>>> more interesting and performance relevant case. >>> >>> This pre-existing code can be fixed as a separate RFE. >>> >>>> >>>> ------------------------------------------------------------------------------ >>>> >>>> src/os/windows/vm/os_windows.cpp >>>> 1905 WindowsSemaphore::~WindowsSemaphore() { >>>> 1906 if (_semaphore != NULL) { >>>> 1907 ::CloseHandle(_semaphore); >>>> 1908 } >>>> >>>> I don't think the NULL check is needed here. >>> >>> I'll remove it. >>> >>>> >>>> ------------------------------------------------------------------------------ >>>> >>>> src/os/bsd/vm/semaphore_bsd.hpp >>>> 56 static jlong currenttime(); >>>> >>>> This function is an implementation detail of the timedwait function, >>>> and could be a file-scoped static near its caller, rather than having >>>> external linkage. >>> >>> Yes. I put it in the class so that I wouldn't have to create a prefix >>> for currenttime and to make it obvious that only the OSXSemaphore >>> uses that function. >>> >>>> >>>> [The PosixSemaphore class is different in this respect, because there >>>> we need to choose between platform-specific definitions of >>>> create_timespec that will be in a different file from the reference, >>>> so external linkage is required. That situation doesn't apply for >>>> OSXSemaphore.] >>>> >>>> ------------------------------------------------------------------------------ >>>> >>>> src/os/windows/vm/semaphore_windows.hpp >>>> 30 #include >>>> >>>> I think is sufficient here, and is purportedly smaller. >>>> The .cpp file likely needs more, but is already including . >>>> Also, it looks like we prefer the lowercase form on Windows, even >>>> though the file system is case-insensitive. >>> >>> I'll fix. >>> >>>> >>>> ------------------------------------------------------------------------------ >>>> >>>> src/os/windows/vm/semaphore_windows.hpp >>>> 43 void signal(uint count = 0); >>>> >>>> Default count of 0 is inconsistent with corresponding classes for >>>> other platforms. >>> >>> This is a bug that I thought I had fixed. I'll change it. >>> >>>> >>>> ------------------------------------------------------------------------------ >>>> >>>> src/share/vm/runtime/semaphore.cpp >>>> 30 Semaphore::Semaphore(uint value) : _impl(value) {} >>>> 31 Semaphore::~Semaphore() {} >>>> 32 void Semaphore::signal(uint count) { _impl.signal(count); } >>>> 33 void Semaphore::wait() { _impl.wait(); } >>>> >>>> I'm not sure why these forwarding definitions are out of line in the >>>> .cpp file, rather than inline in the header. After all, we've now >>>> gone to some trouble to have the wrapped platform-specific >>>> implementation class provide at least that set of operations. >>> >>> Because I don't think they are performance critical. Another reason >>> is that one of my prototypes forward declared SemaphoreImpl in >>> semaphore.hpp and only included the platform specific >>> semaphore_xxx.hpp files in the semaphore.cpp file. >>> >>> But sure, I can inline them in the .hpp file. >>> >>> Thanks, >>> StefanK >>>> >>>> ------------------------------------------------------------------------------ >>>> >>>> >>> >> > From david.holmes at oracle.com Fri Jun 26 06:51:34 2015 From: david.holmes at oracle.com (David Holmes) Date: Fri, 26 Jun 2015 16:51:34 +1000 Subject: RFR: 8087322: Implement a Semaphore utility class In-Reply-To: <558C2F89.3070908@oracle.com> References: <557AF8E4.9040804@oracle.com> <557F3582.6060401@oracle.com> <5581B597.5080900@oracle.com> <55836FF2.6070604@oracle.com> <55881B78.3040909@oracle.com> <558A8D78.5000209@oracle.com> <558B21CB.1010901@oracle.com> <558C2F89.3070908@oracle.com> Message-ID: <558CF676.1010801@oracle.com> Looks good to me - no further comments. Thanks, David On 26/06/2015 2:42 AM, Stefan Karlsson wrote: > Hi all, > > Updated webrev: > http://cr.openjdk.java.net/~stefank/8087322/webrev.05.delta > http://cr.openjdk.java.net/~stefank/8087322/webrev.05 > > - Removed unnecessary and incorrect initialization of _semaphore > > - Fixed includes > > - Loop around sem_trywait if EINTR is reported > > - Removed unnecessary NULL check on windows > > - Fixed the default value for signal(uint count), on windows. > > - Moved Sempahore implementation from semaphore.cpp to semaphore.hpp > > I skipped implementing some of the suggestions that were not essential > for this patch or that we haven't reached an agreement on. It doesn't > mean that I don't think we should do some of the cleanups. If we could > get the structural changes in place (and bug fixes), then we can fix > some of the details as follow-up RFEs. > > Thanks, > StefanK > > On 2015-06-24 23:31, Stefan Karlsson wrote: >> Hi Kim, >> >> On 2015-06-24 22:28, Kim Barrett wrote: >>> On Jun 24, 2015, at 6:59 AM, Stefan Karlsson >>> wrote: >>>> Hi all, >>>> >>>> Updated webrev: >>>> http://cr.openjdk.java.net/~stefank/8087322/webrev.04 >>> Structurally fine. (Stefan would be rightly annoyed with me if I said >>> otherwise after all the offline discussions we've had.) There's some >>> nastiness that results from pre-existing problems in the os_xxx.cpp >>> files, but cleaning that up is another collection of tasks. >>> >>> A few easy bugs, some stylistic comments that can be accepted or >>> declined, but nothing requiring large amounts of rework. >>> >>> ------------------------------------------------------------------------------ >>> >>> src/os/bsd/vm/os_bsd.cpp >>> 1971 OSXSemaphore::OSXSemaphore(uint value) : _semaphore(0) { >>> >>> I think that initializer for _semaphore isn't right. _semaphore is a >>> (OSX) semaphore_t. I think that initializer only accidentally >>> compiles at all. >> >> This is one yet another case of pre-existing code. >> >>> >>> ------------------------------------------------------------------------------ >>> >>> src/os/bsd/vm/semaphore_bsd.hpp >>> 28 #include "memory/allocation.hpp" >>> 29 >>> 30 #include >>> 31 >>> 32 #ifndef __APPLE__ >>> 33 # include "semaphore_posix.hpp" >>> 34 #else >>> 35 // OS X doesn't support unamed POSIX semaphores, so the >>> implementation in os_posix.cpp can't be used. >>> 36 >>> 37 class OSXSemaphore : public CHeapObj{ >>> >>> This only needs "memory/allocation.hpp" in the Apple case. >>> >>> This doesn't need in the non-Apple case. >> >> OK. >> >>> >>> In the Apple case, I think the correct include is >>> rather than . I'm not sure why is working >>> at all. >> >> I'll change it. >> >>> >>> ------------------------------------------------------------------------------ >>> >>> src/os/posix/vm/os_posix.cpp >>> 1021 #define check_with_errno(check_type, cond, >>> msg) \ >>> 1022 do { \ >>> 1023 int err = errno; \ >>> 1024 check_type(cond, err_msg("%s; error='%s' (errno=%d)", msg, >>> strerror(err), err)); \ >>> 1025 } while (false) >>> 1026 >>> 1027 #define assert_with_errno(cond, msg) check_with_errno(assert, >>> cond, msg) >>> 1028 #define guarantee_with_errno(cond, msg) >>> check_with_errno(guarantee, cond, msg) >>> >>> We already have assert_status in debug.hpp. It might be better to add >>> a corresponding guarantee_status there, and use those here. >> >> 1) The comment above vmassert_status says: >> >> // This version of vmassert is for use with checking return status from >> // library calls that return actual error values eg. EINVAL, >> // ENOMEM etc, rather than returning -1 and setting errno. >> // When the status is not what is expected it is very useful to know >> // what status was actually returned, so we pass the status variable as >> // an extra arg and use strerror to convert it to a meaningful string >> // like "Invalid argument", "out of memory" etc >> >> >> but called library calls actually do return -1 and sets errno. Maybe >> the comment is too specific? >> >> 2) I modeled the error message with this code in mind: >> >> 2587 static void warn_fail_commit_memory(char* addr, size_t size, bool >> exec, >> 2588 int err) { >> 2589 warning("INFO: os::commit_memory(" PTR_FORMAT ", " SIZE_FORMAT >> 2590 ", %d) failed; error='%s' (errno=%d)", addr, size, exec, >> 2591 strerror(err), err); >> 2592 } >> >>> >>> Also, these macros are only used inside the #ifndef __APPLE__ block. >> >> Yes, but they are not specific to non-__APPLE__ code, so I chooe to >> put it outside that block. >> >>> >>> And welcome to the dark side. (Higher order macros!) >>> >>> ------------------------------------------------------------------------------ >>> >>> src/os/posix/vm/os_posix.cpp >>> 1053 while ((ret = sem_wait(&_semaphore)) == -1 && errno == EINTR) { >>> >>> I would probably instead use >>> >>> (ret = sem_wait(&_semaphore)) != 0 >>> >>> e.g. while !successful. >> >> Sure. >> >>> >>> ------------------------------------------------------------------------------ >>> >>> src/os/posix/vm/os_posix.cpp >>> 1059 bool PosixSemaphore::trywait() { >>> 1060 bool succeeded = sem_trywait(&_semaphore) == 0; >>> 1061 >>> 1062 assert_with_errno(succeeded || errno == EAGAIN, "trywait >>> failed"); >>> 1063 >>> 1064 return succeeded; >>> 1065 } >>> >>> sem_trywait can also fail with EINTR. >> >> Will fix the assert. >> >>> >>> ------------------------------------------------------------------------------ >>> >>> src/os/posix/vm/os_posix.cpp >>> 1072 } else if (errno == EINTR) { >>> 1073 continue; >>> 1074 } else if (errno == ETIMEDOUT) { >>> >>> I think ETIMEDOUT should be tested before EINTR. ETIMEDOUT is the >>> more interesting and performance relevant case. >> >> This pre-existing code can be fixed as a separate RFE. >> >>> >>> ------------------------------------------------------------------------------ >>> >>> src/os/windows/vm/os_windows.cpp >>> 1905 WindowsSemaphore::~WindowsSemaphore() { >>> 1906 if (_semaphore != NULL) { >>> 1907 ::CloseHandle(_semaphore); >>> 1908 } >>> >>> I don't think the NULL check is needed here. >> >> I'll remove it. >> >>> >>> ------------------------------------------------------------------------------ >>> >>> src/os/bsd/vm/semaphore_bsd.hpp >>> 56 static jlong currenttime(); >>> >>> This function is an implementation detail of the timedwait function, >>> and could be a file-scoped static near its caller, rather than having >>> external linkage. >> >> Yes. I put it in the class so that I wouldn't have to create a prefix >> for currenttime and to make it obvious that only the OSXSemaphore uses >> that function. >> >>> >>> [The PosixSemaphore class is different in this respect, because there >>> we need to choose between platform-specific definitions of >>> create_timespec that will be in a different file from the reference, >>> so external linkage is required. That situation doesn't apply for >>> OSXSemaphore.] >>> >>> ------------------------------------------------------------------------------ >>> >>> src/os/windows/vm/semaphore_windows.hpp >>> 30 #include >>> >>> I think is sufficient here, and is purportedly smaller. >>> The .cpp file likely needs more, but is already including . >>> Also, it looks like we prefer the lowercase form on Windows, even >>> though the file system is case-insensitive. >> >> I'll fix. >> >>> >>> ------------------------------------------------------------------------------ >>> >>> src/os/windows/vm/semaphore_windows.hpp >>> 43 void signal(uint count = 0); >>> >>> Default count of 0 is inconsistent with corresponding classes for >>> other platforms. >> >> This is a bug that I thought I had fixed. I'll change it. >> >>> >>> ------------------------------------------------------------------------------ >>> >>> src/share/vm/runtime/semaphore.cpp >>> 30 Semaphore::Semaphore(uint value) : _impl(value) {} >>> 31 Semaphore::~Semaphore() {} >>> 32 void Semaphore::signal(uint count) { _impl.signal(count); } >>> 33 void Semaphore::wait() { _impl.wait(); } >>> >>> I'm not sure why these forwarding definitions are out of line in the >>> .cpp file, rather than inline in the header. After all, we've now >>> gone to some trouble to have the wrapped platform-specific >>> implementation class provide at least that set of operations. >> >> Because I don't think they are performance critical. Another reason is >> that one of my prototypes forward declared SemaphoreImpl in >> semaphore.hpp and only included the platform specific >> semaphore_xxx.hpp files in the semaphore.cpp file. >> >> But sure, I can inline them in the .hpp file. >> >> Thanks, >> StefanK >>> >>> ------------------------------------------------------------------------------ >>> >>> >> > From dean.long at oracle.com Fri Jun 26 08:06:00 2015 From: dean.long at oracle.com (Dean Long) Date: Fri, 26 Jun 2015 01:06:00 -0700 Subject: RFR: 8087322: Implement a Semaphore utility class In-Reply-To: <558CF5D7.6090906@oracle.com> References: <557AF8E4.9040804@oracle.com> <557F3582.6060401@oracle.com> <5581B597.5080900@oracle.com> <55836FF2.6070604@oracle.com> <55881B78.3040909@oracle.com> <558A8D78.5000209@oracle.com> <558B21CB.1010901@oracle.com> <558C2F89.3070908@oracle.com> <558C7424.1060002@oracle.com> <558CF5D7.6090906@oracle.com> Message-ID: <558D07E8.9020509@oracle.com> On 6/25/2015 11:48 PM, David Holmes wrote: > Hi Dean, > > On 26/06/2015 7:35 AM, Dean Long wrote: >> On 6/25/2015 9:42 AM, Stefan Karlsson wrote: >>> Hi all, >>> >>> Updated webrev: >>> http://cr.openjdk.java.net/~stefank/8087322/webrev.05.delta >>> http://cr.openjdk.java.net/~stefank/8087322/webrev.05 >>> >>> - Removed unnecessary and incorrect initialization of _semaphore >>> >>> - Fixed includes >>> >>> - Loop around sem_trywait if EINTR is reported >>> >> >> How about this instead? >> >> 1061 bool PosixSemaphore::trywait() { >> 1062 int ret = sem_trywait(&_semaphore); >> 1068 assert_with_errno(ret == 0 || (errno == EAGAIN || errno == >> EINTR), "trywait failed"); > > That amounts to a spurious failure, suggesting the semaphore was not > available when in fact it may have been. The retry is semantically > better. > OK. I see that we already have uses like this: assert (!sr_semaphore .trywait (),"invalid semaphore state"); where we can't tolerate a spurious failure. dl > Cheers, > David > >> >> dl >> >>> - Removed unnecessary NULL check on windows >>> >>> - Fixed the default value for signal(uint count), on windows. >>> >>> - Moved Sempahore implementation from semaphore.cpp to semaphore.hpp >>> >>> I skipped implementing some of the suggestions that were not essential >>> for this patch or that we haven't reached an agreement on. It doesn't >>> mean that I don't think we should do some of the cleanups. If we could >>> get the structural changes in place (and bug fixes), then we can fix >>> some of the details as follow-up RFEs. >>> >>> Thanks, >>> StefanK >>> >>> On 2015-06-24 23:31, Stefan Karlsson wrote: >>>> Hi Kim, >>>> >>>> On 2015-06-24 22:28, Kim Barrett wrote: >>>>> On Jun 24, 2015, at 6:59 AM, Stefan Karlsson >>>>> wrote: >>>>>> Hi all, >>>>>> >>>>>> Updated webrev: >>>>>> http://cr.openjdk.java.net/~stefank/8087322/webrev.04 >>>>> Structurally fine. (Stefan would be rightly annoyed with me if I >>>>> said >>>>> otherwise after all the offline discussions we've had.) There's some >>>>> nastiness that results from pre-existing problems in the os_xxx.cpp >>>>> files, but cleaning that up is another collection of tasks. >>>>> >>>>> A few easy bugs, some stylistic comments that can be accepted or >>>>> declined, but nothing requiring large amounts of rework. >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> >>>>> >>>>> src/os/bsd/vm/os_bsd.cpp >>>>> 1971 OSXSemaphore::OSXSemaphore(uint value) : _semaphore(0) { >>>>> >>>>> I think that initializer for _semaphore isn't right. _semaphore is a >>>>> (OSX) semaphore_t. I think that initializer only accidentally >>>>> compiles at all. >>>> >>>> This is one yet another case of pre-existing code. >>>> >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> >>>>> >>>>> src/os/bsd/vm/semaphore_bsd.hpp >>>>> 28 #include "memory/allocation.hpp" >>>>> 29 >>>>> 30 #include >>>>> 31 >>>>> 32 #ifndef __APPLE__ >>>>> 33 # include "semaphore_posix.hpp" >>>>> 34 #else >>>>> 35 // OS X doesn't support unamed POSIX semaphores, so the >>>>> implementation in os_posix.cpp can't be used. >>>>> 36 >>>>> 37 class OSXSemaphore : public CHeapObj{ >>>>> >>>>> This only needs "memory/allocation.hpp" in the Apple case. >>>>> >>>>> This doesn't need in the non-Apple case. >>>> >>>> OK. >>>> >>>>> >>>>> In the Apple case, I think the correct include is >>>>> rather than . I'm not sure why is working >>>>> at all. >>>> >>>> I'll change it. >>>> >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> >>>>> >>>>> src/os/posix/vm/os_posix.cpp >>>>> 1021 #define check_with_errno(check_type, cond, >>>>> msg) \ >>>>> 1022 do { \ >>>>> 1023 int err = errno; \ >>>>> 1024 check_type(cond, err_msg("%s; error='%s' (errno=%d)", msg, >>>>> strerror(err), err)); \ >>>>> 1025 } while (false) >>>>> 1026 >>>>> 1027 #define assert_with_errno(cond, msg) check_with_errno(assert, >>>>> cond, msg) >>>>> 1028 #define guarantee_with_errno(cond, msg) >>>>> check_with_errno(guarantee, cond, msg) >>>>> >>>>> We already have assert_status in debug.hpp. It might be better to >>>>> add >>>>> a corresponding guarantee_status there, and use those here. >>>> >>>> 1) The comment above vmassert_status says: >>>> >>>> // This version of vmassert is for use with checking return status >>>> from >>>> // library calls that return actual error values eg. EINVAL, >>>> // ENOMEM etc, rather than returning -1 and setting errno. >>>> // When the status is not what is expected it is very useful to know >>>> // what status was actually returned, so we pass the status >>>> variable as >>>> // an extra arg and use strerror to convert it to a meaningful string >>>> // like "Invalid argument", "out of memory" etc >>>> >>>> >>>> but called library calls actually do return -1 and sets errno. Maybe >>>> the comment is too specific? >>>> >>>> 2) I modeled the error message with this code in mind: >>>> >>>> 2587 static void warn_fail_commit_memory(char* addr, size_t size, >>>> bool exec, >>>> 2588 int err) { >>>> 2589 warning("INFO: os::commit_memory(" PTR_FORMAT ", " SIZE_FORMAT >>>> 2590 ", %d) failed; error='%s' (errno=%d)", addr, size, >>>> exec, >>>> 2591 strerror(err), err); >>>> 2592 } >>>> >>>>> >>>>> Also, these macros are only used inside the #ifndef __APPLE__ block. >>>> >>>> Yes, but they are not specific to non-__APPLE__ code, so I chooe to >>>> put it outside that block. >>>> >>>>> >>>>> And welcome to the dark side. (Higher order macros!) >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> >>>>> >>>>> src/os/posix/vm/os_posix.cpp >>>>> 1053 while ((ret = sem_wait(&_semaphore)) == -1 && errno == >>>>> EINTR) { >>>>> >>>>> I would probably instead use >>>>> >>>>> (ret = sem_wait(&_semaphore)) != 0 >>>>> >>>>> e.g. while !successful. >>>> >>>> Sure. >>>> >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> >>>>> >>>>> src/os/posix/vm/os_posix.cpp >>>>> 1059 bool PosixSemaphore::trywait() { >>>>> 1060 bool succeeded = sem_trywait(&_semaphore) == 0; >>>>> 1061 >>>>> 1062 assert_with_errno(succeeded || errno == EAGAIN, "trywait >>>>> failed"); >>>>> 1063 >>>>> 1064 return succeeded; >>>>> 1065 } >>>>> >>>>> sem_trywait can also fail with EINTR. >>>> >>>> Will fix the assert. >>>> >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> >>>>> >>>>> src/os/posix/vm/os_posix.cpp >>>>> 1072 } else if (errno == EINTR) { >>>>> 1073 continue; >>>>> 1074 } else if (errno == ETIMEDOUT) { >>>>> >>>>> I think ETIMEDOUT should be tested before EINTR. ETIMEDOUT is the >>>>> more interesting and performance relevant case. >>>> >>>> This pre-existing code can be fixed as a separate RFE. >>>> >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> >>>>> >>>>> src/os/windows/vm/os_windows.cpp >>>>> 1905 WindowsSemaphore::~WindowsSemaphore() { >>>>> 1906 if (_semaphore != NULL) { >>>>> 1907 ::CloseHandle(_semaphore); >>>>> 1908 } >>>>> >>>>> I don't think the NULL check is needed here. >>>> >>>> I'll remove it. >>>> >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> >>>>> >>>>> src/os/bsd/vm/semaphore_bsd.hpp >>>>> 56 static jlong currenttime(); >>>>> >>>>> This function is an implementation detail of the timedwait function, >>>>> and could be a file-scoped static near its caller, rather than having >>>>> external linkage. >>>> >>>> Yes. I put it in the class so that I wouldn't have to create a prefix >>>> for currenttime and to make it obvious that only the OSXSemaphore >>>> uses that function. >>>> >>>>> >>>>> [The PosixSemaphore class is different in this respect, because there >>>>> we need to choose between platform-specific definitions of >>>>> create_timespec that will be in a different file from the reference, >>>>> so external linkage is required. That situation doesn't apply for >>>>> OSXSemaphore.] >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> >>>>> >>>>> src/os/windows/vm/semaphore_windows.hpp >>>>> 30 #include >>>>> >>>>> I think is sufficient here, and is purportedly smaller. >>>>> The .cpp file likely needs more, but is already including >>>>> . >>>>> Also, it looks like we prefer the lowercase form on Windows, even >>>>> though the file system is case-insensitive. >>>> >>>> I'll fix. >>>> >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> >>>>> >>>>> src/os/windows/vm/semaphore_windows.hpp >>>>> 43 void signal(uint count = 0); >>>>> >>>>> Default count of 0 is inconsistent with corresponding classes for >>>>> other platforms. >>>> >>>> This is a bug that I thought I had fixed. I'll change it. >>>> >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> >>>>> >>>>> src/share/vm/runtime/semaphore.cpp >>>>> 30 Semaphore::Semaphore(uint value) : _impl(value) {} >>>>> 31 Semaphore::~Semaphore() {} >>>>> 32 void Semaphore::signal(uint count) { _impl.signal(count); } >>>>> 33 void Semaphore::wait() { _impl.wait(); } >>>>> >>>>> I'm not sure why these forwarding definitions are out of line in the >>>>> .cpp file, rather than inline in the header. After all, we've now >>>>> gone to some trouble to have the wrapped platform-specific >>>>> implementation class provide at least that set of operations. >>>> >>>> Because I don't think they are performance critical. Another reason >>>> is that one of my prototypes forward declared SemaphoreImpl in >>>> semaphore.hpp and only included the platform specific >>>> semaphore_xxx.hpp files in the semaphore.cpp file. >>>> >>>> But sure, I can inline them in the .hpp file. >>>> >>>> Thanks, >>>> StefanK >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> >>>>> >>>>> >>>> >>> >> From dean.long at oracle.com Fri Jun 26 08:10:33 2015 From: dean.long at oracle.com (Dean Long) Date: Fri, 26 Jun 2015 01:10:33 -0700 Subject: RFR: 8087322: Implement a Semaphore utility class In-Reply-To: <558D07E8.9020509@oracle.com> References: <557AF8E4.9040804@oracle.com> <557F3582.6060401@oracle.com> <5581B597.5080900@oracle.com> <55836FF2.6070604@oracle.com> <55881B78.3040909@oracle.com> <558A8D78.5000209@oracle.com> <558B21CB.1010901@oracle.com> <558C2F89.3070908@oracle.com> <558C7424.1060002@oracle.com> <558CF5D7.6090906@oracle.com> <558D07E8.9020509@oracle.com> Message-ID: <558D08F9.2060008@oracle.com> On 6/26/2015 1:06 AM, Dean Long wrote: > On 6/25/2015 11:48 PM, David Holmes wrote: >> Hi Dean, >> >> On 26/06/2015 7:35 AM, Dean Long wrote: >>> On 6/25/2015 9:42 AM, Stefan Karlsson wrote: >>>> Hi all, >>>> >>>> Updated webrev: >>>> http://cr.openjdk.java.net/~stefank/8087322/webrev.05.delta >>>> http://cr.openjdk.java.net/~stefank/8087322/webrev.05 >>>> >>>> - Removed unnecessary and incorrect initialization of _semaphore >>>> >>>> - Fixed includes >>>> >>>> - Loop around sem_trywait if EINTR is reported >>>> >>> >>> How about this instead? >>> >>> 1061 bool PosixSemaphore::trywait() { >>> 1062 int ret = sem_trywait(&_semaphore); >>> 1068 assert_with_errno(ret == 0 || (errno == EAGAIN || errno == >>> EINTR), "trywait failed"); >> >> That amounts to a spurious failure, suggesting the semaphore was not >> available when in fact it may have been. The retry is semantically >> better. >> > > OK. I see that we already have uses like this: > > assert > (!sr_semaphore > .trywait > (),"invalid > semaphore state"); > Oops. Didn't mean to include opengrok markups. Should have been: assert(!sr_semaphore.trywait(), "invalid semaphore state"); dl > where we can't tolerate a spurious failure. > > dl > >> Cheers, >> David >> >>> >>> dl >>> >>>> - Removed unnecessary NULL check on windows >>>> >>>> - Fixed the default value for signal(uint count), on windows. >>>> >>>> - Moved Sempahore implementation from semaphore.cpp to semaphore.hpp >>>> >>>> I skipped implementing some of the suggestions that were not essential >>>> for this patch or that we haven't reached an agreement on. It doesn't >>>> mean that I don't think we should do some of the cleanups. If we could >>>> get the structural changes in place (and bug fixes), then we can fix >>>> some of the details as follow-up RFEs. >>>> >>>> Thanks, >>>> StefanK >>>> >>>> On 2015-06-24 23:31, Stefan Karlsson wrote: >>>>> Hi Kim, >>>>> >>>>> On 2015-06-24 22:28, Kim Barrett wrote: >>>>>> On Jun 24, 2015, at 6:59 AM, Stefan Karlsson >>>>>> wrote: >>>>>>> Hi all, >>>>>>> >>>>>>> Updated webrev: >>>>>>> http://cr.openjdk.java.net/~stefank/8087322/webrev.04 >>>>>> Structurally fine. (Stefan would be rightly annoyed with me if I >>>>>> said >>>>>> otherwise after all the offline discussions we've had.) There's some >>>>>> nastiness that results from pre-existing problems in the os_xxx.cpp >>>>>> files, but cleaning that up is another collection of tasks. >>>>>> >>>>>> A few easy bugs, some stylistic comments that can be accepted or >>>>>> declined, but nothing requiring large amounts of rework. >>>>>> >>>>>> ------------------------------------------------------------------------------ >>>>>> >>>>>> >>>>>> src/os/bsd/vm/os_bsd.cpp >>>>>> 1971 OSXSemaphore::OSXSemaphore(uint value) : _semaphore(0) { >>>>>> >>>>>> I think that initializer for _semaphore isn't right. _semaphore is a >>>>>> (OSX) semaphore_t. I think that initializer only accidentally >>>>>> compiles at all. >>>>> >>>>> This is one yet another case of pre-existing code. >>>>> >>>>>> >>>>>> ------------------------------------------------------------------------------ >>>>>> >>>>>> >>>>>> src/os/bsd/vm/semaphore_bsd.hpp >>>>>> 28 #include "memory/allocation.hpp" >>>>>> 29 >>>>>> 30 #include >>>>>> 31 >>>>>> 32 #ifndef __APPLE__ >>>>>> 33 # include "semaphore_posix.hpp" >>>>>> 34 #else >>>>>> 35 // OS X doesn't support unamed POSIX semaphores, so the >>>>>> implementation in os_posix.cpp can't be used. >>>>>> 36 >>>>>> 37 class OSXSemaphore : public CHeapObj{ >>>>>> >>>>>> This only needs "memory/allocation.hpp" in the Apple case. >>>>>> >>>>>> This doesn't need in the non-Apple case. >>>>> >>>>> OK. >>>>> >>>>>> >>>>>> In the Apple case, I think the correct include is >>>>>> rather than . I'm not sure why is >>>>>> working >>>>>> at all. >>>>> >>>>> I'll change it. >>>>> >>>>>> >>>>>> ------------------------------------------------------------------------------ >>>>>> >>>>>> >>>>>> src/os/posix/vm/os_posix.cpp >>>>>> 1021 #define check_with_errno(check_type, cond, >>>>>> msg) \ >>>>>> 1022 do { \ >>>>>> 1023 int err = errno; \ >>>>>> 1024 check_type(cond, err_msg("%s; error='%s' (errno=%d)", msg, >>>>>> strerror(err), err)); \ >>>>>> 1025 } while (false) >>>>>> 1026 >>>>>> 1027 #define assert_with_errno(cond, msg) check_with_errno(assert, >>>>>> cond, msg) >>>>>> 1028 #define guarantee_with_errno(cond, msg) >>>>>> check_with_errno(guarantee, cond, msg) >>>>>> >>>>>> We already have assert_status in debug.hpp. It might be better >>>>>> to add >>>>>> a corresponding guarantee_status there, and use those here. >>>>> >>>>> 1) The comment above vmassert_status says: >>>>> >>>>> // This version of vmassert is for use with checking return status >>>>> from >>>>> // library calls that return actual error values eg. EINVAL, >>>>> // ENOMEM etc, rather than returning -1 and setting errno. >>>>> // When the status is not what is expected it is very useful to know >>>>> // what status was actually returned, so we pass the status >>>>> variable as >>>>> // an extra arg and use strerror to convert it to a meaningful string >>>>> // like "Invalid argument", "out of memory" etc >>>>> >>>>> >>>>> but called library calls actually do return -1 and sets errno. Maybe >>>>> the comment is too specific? >>>>> >>>>> 2) I modeled the error message with this code in mind: >>>>> >>>>> 2587 static void warn_fail_commit_memory(char* addr, size_t size, >>>>> bool exec, >>>>> 2588 int err) { >>>>> 2589 warning("INFO: os::commit_memory(" PTR_FORMAT ", " SIZE_FORMAT >>>>> 2590 ", %d) failed; error='%s' (errno=%d)", addr, size, >>>>> exec, >>>>> 2591 strerror(err), err); >>>>> 2592 } >>>>> >>>>>> >>>>>> Also, these macros are only used inside the #ifndef __APPLE__ block. >>>>> >>>>> Yes, but they are not specific to non-__APPLE__ code, so I chooe to >>>>> put it outside that block. >>>>> >>>>>> >>>>>> And welcome to the dark side. (Higher order macros!) >>>>>> >>>>>> ------------------------------------------------------------------------------ >>>>>> >>>>>> >>>>>> src/os/posix/vm/os_posix.cpp >>>>>> 1053 while ((ret = sem_wait(&_semaphore)) == -1 && errno == >>>>>> EINTR) { >>>>>> >>>>>> I would probably instead use >>>>>> >>>>>> (ret = sem_wait(&_semaphore)) != 0 >>>>>> >>>>>> e.g. while !successful. >>>>> >>>>> Sure. >>>>> >>>>>> >>>>>> ------------------------------------------------------------------------------ >>>>>> >>>>>> >>>>>> src/os/posix/vm/os_posix.cpp >>>>>> 1059 bool PosixSemaphore::trywait() { >>>>>> 1060 bool succeeded = sem_trywait(&_semaphore) == 0; >>>>>> 1061 >>>>>> 1062 assert_with_errno(succeeded || errno == EAGAIN, "trywait >>>>>> failed"); >>>>>> 1063 >>>>>> 1064 return succeeded; >>>>>> 1065 } >>>>>> >>>>>> sem_trywait can also fail with EINTR. >>>>> >>>>> Will fix the assert. >>>>> >>>>>> >>>>>> ------------------------------------------------------------------------------ >>>>>> >>>>>> >>>>>> src/os/posix/vm/os_posix.cpp >>>>>> 1072 } else if (errno == EINTR) { >>>>>> 1073 continue; >>>>>> 1074 } else if (errno == ETIMEDOUT) { >>>>>> >>>>>> I think ETIMEDOUT should be tested before EINTR. ETIMEDOUT is the >>>>>> more interesting and performance relevant case. >>>>> >>>>> This pre-existing code can be fixed as a separate RFE. >>>>> >>>>>> >>>>>> ------------------------------------------------------------------------------ >>>>>> >>>>>> >>>>>> src/os/windows/vm/os_windows.cpp >>>>>> 1905 WindowsSemaphore::~WindowsSemaphore() { >>>>>> 1906 if (_semaphore != NULL) { >>>>>> 1907 ::CloseHandle(_semaphore); >>>>>> 1908 } >>>>>> >>>>>> I don't think the NULL check is needed here. >>>>> >>>>> I'll remove it. >>>>> >>>>>> >>>>>> ------------------------------------------------------------------------------ >>>>>> >>>>>> >>>>>> src/os/bsd/vm/semaphore_bsd.hpp >>>>>> 56 static jlong currenttime(); >>>>>> >>>>>> This function is an implementation detail of the timedwait function, >>>>>> and could be a file-scoped static near its caller, rather than >>>>>> having >>>>>> external linkage. >>>>> >>>>> Yes. I put it in the class so that I wouldn't have to create a prefix >>>>> for currenttime and to make it obvious that only the OSXSemaphore >>>>> uses that function. >>>>> >>>>>> >>>>>> [The PosixSemaphore class is different in this respect, because >>>>>> there >>>>>> we need to choose between platform-specific definitions of >>>>>> create_timespec that will be in a different file from the reference, >>>>>> so external linkage is required. That situation doesn't apply for >>>>>> OSXSemaphore.] >>>>>> >>>>>> ------------------------------------------------------------------------------ >>>>>> >>>>>> >>>>>> src/os/windows/vm/semaphore_windows.hpp >>>>>> 30 #include >>>>>> >>>>>> I think is sufficient here, and is purportedly smaller. >>>>>> The .cpp file likely needs more, but is already including >>>>>> . >>>>>> Also, it looks like we prefer the lowercase form on Windows, even >>>>>> though the file system is case-insensitive. >>>>> >>>>> I'll fix. >>>>> >>>>>> >>>>>> ------------------------------------------------------------------------------ >>>>>> >>>>>> >>>>>> src/os/windows/vm/semaphore_windows.hpp >>>>>> 43 void signal(uint count = 0); >>>>>> >>>>>> Default count of 0 is inconsistent with corresponding classes for >>>>>> other platforms. >>>>> >>>>> This is a bug that I thought I had fixed. I'll change it. >>>>> >>>>>> >>>>>> ------------------------------------------------------------------------------ >>>>>> >>>>>> >>>>>> src/share/vm/runtime/semaphore.cpp >>>>>> 30 Semaphore::Semaphore(uint value) : _impl(value) {} >>>>>> 31 Semaphore::~Semaphore() {} >>>>>> 32 void Semaphore::signal(uint count) { _impl.signal(count); } >>>>>> 33 void Semaphore::wait() { _impl.wait(); } >>>>>> >>>>>> I'm not sure why these forwarding definitions are out of line in the >>>>>> .cpp file, rather than inline in the header. After all, we've now >>>>>> gone to some trouble to have the wrapped platform-specific >>>>>> implementation class provide at least that set of operations. >>>>> >>>>> Because I don't think they are performance critical. Another reason >>>>> is that one of my prototypes forward declared SemaphoreImpl in >>>>> semaphore.hpp and only included the platform specific >>>>> semaphore_xxx.hpp files in the semaphore.cpp file. >>>>> >>>>> But sure, I can inline them in the .hpp file. >>>>> >>>>> Thanks, >>>>> StefanK >>>>>> >>>>>> ------------------------------------------------------------------------------ >>>>>> >>>>>> >>>>>> >>>>> >>>> >>> > From stefan.karlsson at oracle.com Fri Jun 26 08:30:53 2015 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Fri, 26 Jun 2015 10:30:53 +0200 Subject: RFR: 8087322: Implement a Semaphore utility class In-Reply-To: <558CF676.1010801@oracle.com> References: <557AF8E4.9040804@oracle.com> <557F3582.6060401@oracle.com> <5581B597.5080900@oracle.com> <55836FF2.6070604@oracle.com> <55881B78.3040909@oracle.com> <558A8D78.5000209@oracle.com> <558B21CB.1010901@oracle.com> <558C2F89.3070908@oracle.com> <558CF676.1010801@oracle.com> Message-ID: <558D0DBD.70208@oracle.com> Hi David, On 2015-06-26 08:51, David Holmes wrote: > Looks good to me - no further comments. Thanks for reviewing! StefanK > > Thanks, > David > > On 26/06/2015 2:42 AM, Stefan Karlsson wrote: >> Hi all, >> >> Updated webrev: >> http://cr.openjdk.java.net/~stefank/8087322/webrev.05.delta >> http://cr.openjdk.java.net/~stefank/8087322/webrev.05 >> >> - Removed unnecessary and incorrect initialization of _semaphore >> >> - Fixed includes >> >> - Loop around sem_trywait if EINTR is reported >> >> - Removed unnecessary NULL check on windows >> >> - Fixed the default value for signal(uint count), on windows. >> >> - Moved Sempahore implementation from semaphore.cpp to semaphore.hpp >> >> I skipped implementing some of the suggestions that were not essential >> for this patch or that we haven't reached an agreement on. It doesn't >> mean that I don't think we should do some of the cleanups. If we could >> get the structural changes in place (and bug fixes), then we can fix >> some of the details as follow-up RFEs. >> >> Thanks, >> StefanK >> >> On 2015-06-24 23:31, Stefan Karlsson wrote: >>> Hi Kim, >>> >>> On 2015-06-24 22:28, Kim Barrett wrote: >>>> On Jun 24, 2015, at 6:59 AM, Stefan Karlsson >>>> wrote: >>>>> Hi all, >>>>> >>>>> Updated webrev: >>>>> http://cr.openjdk.java.net/~stefank/8087322/webrev.04 >>>> Structurally fine. (Stefan would be rightly annoyed with me if I said >>>> otherwise after all the offline discussions we've had.) There's some >>>> nastiness that results from pre-existing problems in the os_xxx.cpp >>>> files, but cleaning that up is another collection of tasks. >>>> >>>> A few easy bugs, some stylistic comments that can be accepted or >>>> declined, but nothing requiring large amounts of rework. >>>> >>>> ------------------------------------------------------------------------------ >>>> >>>> >>>> src/os/bsd/vm/os_bsd.cpp >>>> 1971 OSXSemaphore::OSXSemaphore(uint value) : _semaphore(0) { >>>> >>>> I think that initializer for _semaphore isn't right. _semaphore is a >>>> (OSX) semaphore_t. I think that initializer only accidentally >>>> compiles at all. >>> >>> This is one yet another case of pre-existing code. >>> >>>> >>>> ------------------------------------------------------------------------------ >>>> >>>> >>>> src/os/bsd/vm/semaphore_bsd.hpp >>>> 28 #include "memory/allocation.hpp" >>>> 29 >>>> 30 #include >>>> 31 >>>> 32 #ifndef __APPLE__ >>>> 33 # include "semaphore_posix.hpp" >>>> 34 #else >>>> 35 // OS X doesn't support unamed POSIX semaphores, so the >>>> implementation in os_posix.cpp can't be used. >>>> 36 >>>> 37 class OSXSemaphore : public CHeapObj{ >>>> >>>> This only needs "memory/allocation.hpp" in the Apple case. >>>> >>>> This doesn't need in the non-Apple case. >>> >>> OK. >>> >>>> >>>> In the Apple case, I think the correct include is >>>> rather than . I'm not sure why is working >>>> at all. >>> >>> I'll change it. >>> >>>> >>>> ------------------------------------------------------------------------------ >>>> >>>> >>>> src/os/posix/vm/os_posix.cpp >>>> 1021 #define check_with_errno(check_type, cond, >>>> msg) \ >>>> 1022 do { \ >>>> 1023 int err = errno; \ >>>> 1024 check_type(cond, err_msg("%s; error='%s' (errno=%d)", msg, >>>> strerror(err), err)); \ >>>> 1025 } while (false) >>>> 1026 >>>> 1027 #define assert_with_errno(cond, msg) check_with_errno(assert, >>>> cond, msg) >>>> 1028 #define guarantee_with_errno(cond, msg) >>>> check_with_errno(guarantee, cond, msg) >>>> >>>> We already have assert_status in debug.hpp. It might be better to add >>>> a corresponding guarantee_status there, and use those here. >>> >>> 1) The comment above vmassert_status says: >>> >>> // This version of vmassert is for use with checking return status from >>> // library calls that return actual error values eg. EINVAL, >>> // ENOMEM etc, rather than returning -1 and setting errno. >>> // When the status is not what is expected it is very useful to know >>> // what status was actually returned, so we pass the status variable as >>> // an extra arg and use strerror to convert it to a meaningful string >>> // like "Invalid argument", "out of memory" etc >>> >>> >>> but called library calls actually do return -1 and sets errno. Maybe >>> the comment is too specific? >>> >>> 2) I modeled the error message with this code in mind: >>> >>> 2587 static void warn_fail_commit_memory(char* addr, size_t size, bool >>> exec, >>> 2588 int err) { >>> 2589 warning("INFO: os::commit_memory(" PTR_FORMAT ", " SIZE_FORMAT >>> 2590 ", %d) failed; error='%s' (errno=%d)", addr, size, exec, >>> 2591 strerror(err), err); >>> 2592 } >>> >>>> >>>> Also, these macros are only used inside the #ifndef __APPLE__ block. >>> >>> Yes, but they are not specific to non-__APPLE__ code, so I chooe to >>> put it outside that block. >>> >>>> >>>> And welcome to the dark side. (Higher order macros!) >>>> >>>> ------------------------------------------------------------------------------ >>>> >>>> >>>> src/os/posix/vm/os_posix.cpp >>>> 1053 while ((ret = sem_wait(&_semaphore)) == -1 && errno == EINTR) { >>>> >>>> I would probably instead use >>>> >>>> (ret = sem_wait(&_semaphore)) != 0 >>>> >>>> e.g. while !successful. >>> >>> Sure. >>> >>>> >>>> ------------------------------------------------------------------------------ >>>> >>>> >>>> src/os/posix/vm/os_posix.cpp >>>> 1059 bool PosixSemaphore::trywait() { >>>> 1060 bool succeeded = sem_trywait(&_semaphore) == 0; >>>> 1061 >>>> 1062 assert_with_errno(succeeded || errno == EAGAIN, "trywait >>>> failed"); >>>> 1063 >>>> 1064 return succeeded; >>>> 1065 } >>>> >>>> sem_trywait can also fail with EINTR. >>> >>> Will fix the assert. >>> >>>> >>>> ------------------------------------------------------------------------------ >>>> >>>> >>>> src/os/posix/vm/os_posix.cpp >>>> 1072 } else if (errno == EINTR) { >>>> 1073 continue; >>>> 1074 } else if (errno == ETIMEDOUT) { >>>> >>>> I think ETIMEDOUT should be tested before EINTR. ETIMEDOUT is the >>>> more interesting and performance relevant case. >>> >>> This pre-existing code can be fixed as a separate RFE. >>> >>>> >>>> ------------------------------------------------------------------------------ >>>> >>>> >>>> src/os/windows/vm/os_windows.cpp >>>> 1905 WindowsSemaphore::~WindowsSemaphore() { >>>> 1906 if (_semaphore != NULL) { >>>> 1907 ::CloseHandle(_semaphore); >>>> 1908 } >>>> >>>> I don't think the NULL check is needed here. >>> >>> I'll remove it. >>> >>>> >>>> ------------------------------------------------------------------------------ >>>> >>>> >>>> src/os/bsd/vm/semaphore_bsd.hpp >>>> 56 static jlong currenttime(); >>>> >>>> This function is an implementation detail of the timedwait function, >>>> and could be a file-scoped static near its caller, rather than having >>>> external linkage. >>> >>> Yes. I put it in the class so that I wouldn't have to create a prefix >>> for currenttime and to make it obvious that only the OSXSemaphore uses >>> that function. >>> >>>> >>>> [The PosixSemaphore class is different in this respect, because there >>>> we need to choose between platform-specific definitions of >>>> create_timespec that will be in a different file from the reference, >>>> so external linkage is required. That situation doesn't apply for >>>> OSXSemaphore.] >>>> >>>> ------------------------------------------------------------------------------ >>>> >>>> >>>> src/os/windows/vm/semaphore_windows.hpp >>>> 30 #include >>>> >>>> I think is sufficient here, and is purportedly smaller. >>>> The .cpp file likely needs more, but is already including . >>>> Also, it looks like we prefer the lowercase form on Windows, even >>>> though the file system is case-insensitive. >>> >>> I'll fix. >>> >>>> >>>> ------------------------------------------------------------------------------ >>>> >>>> >>>> src/os/windows/vm/semaphore_windows.hpp >>>> 43 void signal(uint count = 0); >>>> >>>> Default count of 0 is inconsistent with corresponding classes for >>>> other platforms. >>> >>> This is a bug that I thought I had fixed. I'll change it. >>> >>>> >>>> ------------------------------------------------------------------------------ >>>> >>>> >>>> src/share/vm/runtime/semaphore.cpp >>>> 30 Semaphore::Semaphore(uint value) : _impl(value) {} >>>> 31 Semaphore::~Semaphore() {} >>>> 32 void Semaphore::signal(uint count) { _impl.signal(count); } >>>> 33 void Semaphore::wait() { _impl.wait(); } >>>> >>>> I'm not sure why these forwarding definitions are out of line in the >>>> .cpp file, rather than inline in the header. After all, we've now >>>> gone to some trouble to have the wrapped platform-specific >>>> implementation class provide at least that set of operations. >>> >>> Because I don't think they are performance critical. Another reason is >>> that one of my prototypes forward declared SemaphoreImpl in >>> semaphore.hpp and only included the platform specific >>> semaphore_xxx.hpp files in the semaphore.cpp file. >>> >>> But sure, I can inline them in the .hpp file. >>> >>> Thanks, >>> StefanK >>>> >>>> ------------------------------------------------------------------------------ >>>> >>>> >>>> >>> >> From Alan.Bateman at oracle.com Fri Jun 26 08:39:30 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 26 Jun 2015 09:39:30 +0100 Subject: [9] RFR(M): 8076112: Add @HotSpotIntrinsicCandidate annotation to indicate methods for which Java Runtime has intrinsics In-Reply-To: <558BEABD.7090907@oracle.com> References: <558BEABD.7090907@oracle.com> Message-ID: <558D0FC2.5060903@oracle.com> On 25/06/2015 12:49, Zolt?n Maj? wrote: > Hi, > > > please review the patch for JDK-8076112. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8076112 > > Problem: There is need to indicate Java methods that are potentially > intrinsified by JVM. > > Solution: Mark intrinsified methods with the > jdk.internal.HotSpotIntrinsicCandidate annotation. Add checks that are > omitted by VM-level intrinsics to the library code. Add a new > diagnostic flag, CheckIntrinsics. If CheckIntrinsics is enabled, the > VM performs the following checks when a class C is loaded: > - all intrinsics defined by the VM for class C are present in the > loaded class file and are marked; > - an intrinsic is defined by the VM for all marked methods of C. > > If a mismatch is detected, the following is done: > - a fastdebug VM prints a warning and then exits; > - a product VM prints a warning and unmarked are not intrinsified. > > Webrev: > - top: http://cr.openjdk.java.net/~zmajo/8076112/top/webrev.05/ > - jdk: http://cr.openjdk.java.net/~zmajo/8076112/jdk/webrev.05/ > - hotspot: http://cr.openjdk.java.net/~zmajo/8076112/hotspot/webrev.05/ I skimmed through the webrev and don't see any significant issues. One thing to double check is that you are are keeping things locally consistent. One example is the convention in many areas to use implFoo rather than fooImpl. Also in some areas then native methods then you'll see foo0 called from foo. I'm just mentioning it because it requires coordination to rename these methods. You might also want to do a quick pass over to ensure other consistency. I see a few places where 8 spec indent is used, that could be just tabs of course. -Alan From stefan.karlsson at oracle.com Fri Jun 26 08:59:28 2015 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Fri, 26 Jun 2015 10:59:28 +0200 Subject: IgnoreUnrecognizedVMOptions and badly specified options In-Reply-To: <558CEA98.1070501@oracle.com> References: <558BF15A.6030702@oracle.com> <558C141B.9080006@oracle.com> <558C3397.80001@oracle.com> <558C34FC.803@oracle.com> <558C35DC.5060002@oracle.com> <558C36CE.6090606@oracle.com> <558CE595.2050604@oracle.com> <558CEA98.1070501@oracle.com> Message-ID: <558D1470.5030206@oracle.com> On 2015-06-26 08:00, Bengt Rutisson wrote: > > Hi all, > > Just one more thought if we are thinking about making changes to the > IgnoreUnrecognizedVMOptions flag. > > I am not a big fan of this flag since I think it just goes to show > that we don't have enough control over our testing. As I understand it > the main reason for the introduction of this flag was that when > compressed oops was implemented we had no way of controlling which > tests were run on 32 bit platforms (where the UseCompressedOops flag > is not available) or o 64 bit platforms. > > I think it is unfortunate that we don't have better control of our > testing. But one way of at least increasing the control would be to > make IgnoreUnrecognizedVMOptions more specific. I would suggest that > we change it to take a named argument that should be ignored. > > Something like: > > -XX:IgnoreUnrecognizedVMOption=UseCompressedOops > > That way it would not hide other issues in our testing. As it is now > we run a lot of our testing with IgnoreUnrecognizedVMOptions which > means that we don't find tests that need to be updated when we for > example remove a command line option. > > Maybe it is a side track, but I wanted to mention it in this discussion. Yes, I've also suggested this a couple of times. Maybe it's time to create an RFE? StefanK > > Bengt > > > On 2015-06-26 07:39, David Holmes wrote: >> On 26/06/2015 3:13 AM, Dmitry Dmitriev wrote: >>> Thank you Dan! The bug states about changed behaviour but it relates to >>> the current implementation of IgnoreUnrecongnizedVMOptions flag and I >>> think it can be fixed by this RFR. >> >> As I added to the/a bug report I think we need a very clear spec on >> how all these aspects of option checking should interact - what >> should be ignored by IgnoreUnrecognizedVMOptions? Is a badly formed >> option "unrecognized"? A flow chart covering all the possibilities >> and the precedence would make it a lot easier to validate the code. >> >> Cheers, >> David >> >>> On 25.06.2015 20:09, Daniel D. Daugherty wrote: >>>> I'm pretty sure that bug was filed this morning: >>>> >>>> JDK-8129855 -XX:+IgnoreUnrecognizedVMOptions hides improperly >>>> specified VM options. >>>> https://bugs.openjdk.java.net/browse/JDK-8129855 >>>> >>>> Michail was reading your mind... >>> No magic here, we discuss this topic today :) I am become curious about >>> that behaviour, since this code exit for a long time. >>> >>> Regards, >>> Dmitry >>> >>>> >>>> Dan >>>> >>>> >>>> On 6/25/15 11:06 AM, Vladimir Kozlov wrote: >>>>> File bug on runtime (who handles flags verification this days?) with >>>>> your suggestion. >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> On 6/25/15 10:00 AM, Dmitry Dmitriev wrote: >>>>>> Hello Vladimir, >>>>>> >>>>>> Thank you for explanation. I just was bit confused about valid VM >>>>>> options but which improperly specified. >>>>>> I look at the Arguments::process_argument function in >>>>>> src/share/vm/runtime/arguments.cpp module and noticed one thing: >>>>>> >>>>>> 817 bool Arguments::process_argument(const char* arg, >>>>>> 818 jboolean ignore_unrecognized, Flag::Flags origin) { >>>>>> 819 >>>>>> 820 JDK_Version since = JDK_Version(); >>>>>> 821 >>>>>> 822 if (parse_argument(arg, origin) || ignore_unrecognized) { >>>>>> 823 return true; >>>>>> 824 } >>>>>> ... >>>>>> 850 // For locked flags, report a custom error message if >>>>>> available. >>>>>> 851 // Otherwise, report the standard unrecognized VM option. >>>>>> 852 Flag* found_flag = Flag::find_flag((const char*)argname, >>>>>> arg_len, true, true); >>>>>> 853 if (found_flag != NULL) { >>>>>> 854 char locked_message_buf[BUFLEN]; >>>>>> 855 found_flag->get_locked_message(locked_message_buf, BUFLEN); >>>>>> 856 if (strlen(locked_message_buf) == 0) { >>>>>> 857 if (found_flag->is_bool() && !has_plus_minus) { >>>>>> 858 jio_fprintf(defaultStream::error_stream(), >>>>>> 859 "Missing +/- setting for VM option '%s'\n", >>>>>> argname); >>>>>> 860 } else if (!found_flag->is_bool() && has_plus_minus) { >>>>>> 861 jio_fprintf(defaultStream::error_stream(), >>>>>> 862 "Unexpected +/- setting in VM option '%s'\n", >>>>>> argname); >>>>>> 863 } else { >>>>>> 864 jio_fprintf(defaultStream::error_stream(), >>>>>> 865 "Improperly specified VM option '%s'\n", argname); >>>>>> 866 } >>>>>> 867 } else { >>>>>> 868 jio_fprintf(defaultStream::error_stream(), "%s", >>>>>> locked_message_buf); >>>>>> 869 } >>>>>> 870 } else { >>>>>> 871 jio_fprintf(defaultStream::error_stream(), >>>>>> 872 "Unrecognized VM option '%s'\n", argname); >>>>>> 873 Flag* fuzzy_matched = Flag::fuzzy_match((const >>>>>> char*)argname, arg_len, true); >>>>>> 874 if (fuzzy_matched != NULL) { >>>>>> 875 jio_fprintf(defaultStream::error_stream(), >>>>>> 876 "Did you mean '%s%s%s'? ", >>>>>> 877 (fuzzy_matched->is_bool()) ? "(+/-)" : "", >>>>>> 878 fuzzy_matched->_name, >>>>>> 879 (fuzzy_matched->is_bool()) ? "" : >>>>>> "="); >>>>>> 880 } >>>>>> 881 } >>>>>> 882 >>>>>> 883 // allow for commandline "commenting out" options like >>>>>> -XX:#+Verbose >>>>>> 884 return arg[0] == '#'; >>>>>> 885 } >>>>>> >>>>>> If "-XX:+IgnoreUnrecongnizedVMOptions" is specified, then >>>>>> "ignore_unrecognized" will be true and "if" statement on line >>>>>> 822 will always be true. >>>>>> I just think that a better place to check "ignore_unrecognized" is >>>>>> on "else" branch on line 867(for locked flags) and on >>>>>> "else" branch on line 870(where we actually found unrecognized >>>>>> option). If "ignore_unrecognized" is true, then return >>>>>> true in this case, otherwise execute code in these "else" branches. >>>>>> It's my thoughts about that. In this case improperly >>>>>> specified options will be catched(lines 857-866). >>>>>> >>>>>> Thanks, >>>>>> Dmitry >>>>>> >>>>>> >>>>>> On 25.06.2015 17:45, Vladimir Kozlov wrote: >>>>>>> It is not intentional but difficult to implement. >>>>>>> It was added to allow specify options which are not defined in >>>>>>> running VM. >>>>>>> For example when C2 option is specified but Client VM (which has >>>>>>> only C1) is run. >>>>>>> We can do more smarter things here, I agree, by trying to verify >>>>>>> options before ignoring it. >>>>>>> But it will not help with misspelled options, I think. >>>>>>> >>>>>>> Regards, >>>>>>> Vladimir >>>>>>> >>>>>>> On 6/25/15 5:17 AM, Dmitry Dmitriev wrote: >>>>>>>> Hello, >>>>>>>> >>>>>>>> Working with JVM command line options I noticed that >>>>>>>> "IgnoreUnrecognizedVMOptions" option allow to hide options with >>>>>>>> bad >>>>>>>> values. "IgnoreUnrecognizedVMOptions" allow to ignore unrecognized >>>>>>>> options, but it also allow to ignore improperly >>>>>>>> specified VM Options which are processed in general way, i.e. >>>>>>>> "-XX:" options processed by Arguments::process_argument >>>>>>>> function(hotspot/src/share/vm/runtime/arguments.cpp module). >>>>>>>> >>>>>>>> I will be very appreciated if someone can describe this behavior >>>>>>>> or state that this is intentional. >>>>>>>> >>>>>>>> Example for numeric and boolean options: >>>>>>>> 1) Bad numeric option with and without >>>>>>>> "-XX:+IgnoreUnrecongnizedVMOptions" >>>>>>>> java -XX:MaxRAMFraction=-1 -version >>>>>>>> Improperly specified VM option 'MaxRAMFraction=-1' >>>>>>>> Error: Could not create the Java Virtual Machine. >>>>>>>> Error: A fatal exception has occurred. Program will exit. >>>>>>>> >>>>>>>> java -XX:MaxRAMFraction=-1 -XX:+IgnoreUnrecognizedVMOptions >>>>>>>> -version >>>>>>>> java version "1.8.0_40" >>>>>>>> Java(TM) SE Runtime Environment (build 1.8.0_40-b26) >>>>>>>> Java HotSpot(TM) 64-Bit Server VM (build 25.40-b25, mixed mode) >>>>>>>> >>>>>>>> 2) Bad boolean option with and without >>>>>>>> "-XX:+IgnoreUnrecongnizedVMOptions" >>>>>>>> java -XX:UseG1GC -version >>>>>>>> Missing +/- setting for VM option 'UseG1GC' >>>>>>>> Error: Could not create the Java Virtual Machine. >>>>>>>> Error: A fatal exception has occurred. Program will exit. >>>>>>>> >>>>>>>> java -XX:UseG1GC -XX:+IgnoreUnrecognizedVMOptions -version >>>>>>>> java version "1.8.0_40" >>>>>>>> Java(TM) SE Runtime Environment (build 1.8.0_40-b26) >>>>>>>> Java HotSpot(TM) 64-Bit Server VM (build 25.40-b25, mixed mode) >>>>>>>> >>>>>>>> So, as we see when "-XX:+IgnoreUnrecongnizedVMOptions" is used, >>>>>>>> bad "-XX:MaxRAMFraction=-1" and "-XX:UseG1GC" are >>>>>>>> ignored. I don't know is this behavior intentional or not, but >>>>>>>> HotSpot works in that way. >>>>>>>> >>>>>>>> So, can someone tell me this is intentional? Or this behavior is >>>>>>>> wrong? >>>>>>>> >>>>>>>> Thank you, >>>>>>>> Dmitry >>>>>>>> >>>>>>>> >>>>>> >>>> >>> > From volker.simonis at gmail.com Fri Jun 26 09:09:49 2015 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 26 Jun 2015 11:09:49 +0200 Subject: [TESTBUG]: Syntax error in test description of jdk8u-dev/.../JcmdWithNMTDisabled.java ? Message-ID: Hi, after I've upgraded to the latest and greatest version of JTreg (168:055251d38f29 "minor naming cleanup in Agent") I get an error when executing the hotspot test: runtime/NMT/JcmdWithNMTDisabled.java from the jdk8u-dev (notice that the same test from the jdk9 forest runs just fine because it was already refactored). I think this is because of the strange tag syntax the test uses: /* * @test * @key nmt jcmd * @summary Verify that jcmd correctly reports that NMT is not enabled * @library /testlibrary * First run without enabling NMT * @run main/othervm JcmdWithNMTDisabled * Then run with explicitly disabling NMT, should not be any difference * @run main/othervm -XX:NativeMemoryTracking=off JcmdWithNMTDisabled */ The problem is that the comment line "First run without enabling NMT" will be appended to the "@library" tag like this: @library /testlibrary First run without enabling NMT yielding in strange class paths during execution which contain "/First:/run:/without:...". But apparently this doesn't confuse older version of JTreg too much because the test succeeded nevertheless. However with the newest JTreg version the test badly fails with the error: test result: Error. Test Class Exception: Can't find library: First Notice that "First" is the first word of the comment line "First run without enabling NMT" in the tag description. So is this indeed an error in the test description of JcmdWithNMTDisabled.java and should it be fixed by removing the two lines: * @library /testlibrary - * First run without enabling NMT * @run main/othervm JcmdWithNMTDisabled - * Then run with explicitly disabling NMT, should not be any difference * @run main/othervm -XX:NativeMemoryTracking=off JcmdWithNMTDisabled from the test description to make it runnable with newer JTreg versions as well? Regards, Volker From david.holmes at oracle.com Fri Jun 26 11:53:46 2015 From: david.holmes at oracle.com (David Holmes) Date: Fri, 26 Jun 2015 21:53:46 +1000 Subject: [TESTBUG]: Syntax error in test description of jdk8u-dev/.../JcmdWithNMTDisabled.java ? In-Reply-To: References: Message-ID: <558D3D4A.9090701@oracle.com> Hi Volker, Known issue: https://bugs.openjdk.java.net/browse/JDK-8098541 (not public sorry) but mis-processed in my opinion so I'm trying to get it re-addressed. It's amazing how many people had no idea that tags spanned multiple lines, and that there was no commenting mechanism. :( David On 26/06/2015 7:09 PM, Volker Simonis wrote: > Hi, > > after I've upgraded to the latest and greatest version of JTreg > (168:055251d38f29 "minor naming cleanup in Agent") I get an error when > executing the hotspot test: > > runtime/NMT/JcmdWithNMTDisabled.java > > from the jdk8u-dev (notice that the same test from the jdk9 forest > runs just fine because it was already refactored). > > I think this is because of the strange tag syntax the test uses: > > /* > * @test > * @key nmt jcmd > * @summary Verify that jcmd correctly reports that NMT is not enabled > * @library /testlibrary > * First run without enabling NMT > * @run main/othervm JcmdWithNMTDisabled > * Then run with explicitly disabling NMT, should not be any difference > * @run main/othervm -XX:NativeMemoryTracking=off JcmdWithNMTDisabled > */ > > The problem is that the comment line "First run without enabling NMT" > will be appended to the "@library" tag like this: > > @library /testlibrary First run without enabling NMT > > yielding in strange class paths during execution which contain > "/First:/run:/without:...". But apparently this > doesn't confuse older version of JTreg too much because the test > succeeded nevertheless. > > However with the newest JTreg version the test badly fails with the error: > > test result: Error. Test Class Exception: Can't find library: First > > Notice that "First" is the first word of the comment line "First run > without enabling NMT" in the tag description. > > So is this indeed an error in the test description of > JcmdWithNMTDisabled.java and should it be fixed by removing the two > lines: > > * @library /testlibrary > - * First run without enabling NMT > * @run main/othervm JcmdWithNMTDisabled > - * Then run with explicitly disabling NMT, should not be any difference > * @run main/othervm -XX:NativeMemoryTracking=off JcmdWithNMTDisabled > > from the test description to make it runnable with newer JTreg versions as well? > > Regards, > Volker > From volker.simonis at gmail.com Fri Jun 26 12:33:17 2015 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 26 Jun 2015 14:33:17 +0200 Subject: [TESTBUG]: Syntax error in test description of jdk8u-dev/.../JcmdWithNMTDisabled.java ? In-Reply-To: <558D3D4A.9090701@oracle.com> References: <558D3D4A.9090701@oracle.com> Message-ID: Thanks David, It's also amazing that this actually did run with older versions of jtreg without producing an error (altough it produced a lot of useless, empty directories - on for each word in the 'comment' lines :) So I assume somebody is taking care of this issue. Regards, Volker On Fri, Jun 26, 2015 at 1:53 PM, David Holmes wrote: > Hi Volker, > > Known issue: > > https://bugs.openjdk.java.net/browse/JDK-8098541 (not public sorry) > > but mis-processed in my opinion so I'm trying to get it re-addressed. > > It's amazing how many people had no idea that tags spanned multiple lines, > and that there was no commenting mechanism. :( > > David > > > On 26/06/2015 7:09 PM, Volker Simonis wrote: >> >> Hi, >> >> after I've upgraded to the latest and greatest version of JTreg >> (168:055251d38f29 "minor naming cleanup in Agent") I get an error when >> executing the hotspot test: >> >> runtime/NMT/JcmdWithNMTDisabled.java >> >> from the jdk8u-dev (notice that the same test from the jdk9 forest >> runs just fine because it was already refactored). >> >> I think this is because of the strange tag syntax the test uses: >> >> /* >> * @test >> * @key nmt jcmd >> * @summary Verify that jcmd correctly reports that NMT is not enabled >> * @library /testlibrary >> * First run without enabling NMT >> * @run main/othervm JcmdWithNMTDisabled >> * Then run with explicitly disabling NMT, should not be any difference >> * @run main/othervm -XX:NativeMemoryTracking=off JcmdWithNMTDisabled >> */ >> >> The problem is that the comment line "First run without enabling NMT" >> will be appended to the "@library" tag like this: >> >> @library /testlibrary First run without enabling NMT >> >> yielding in strange class paths during execution which contain >> "/First:/run:/without:...". But apparently this >> doesn't confuse older version of JTreg too much because the test >> succeeded nevertheless. >> >> However with the newest JTreg version the test badly fails with the error: >> >> test result: Error. Test Class Exception: Can't find library: First >> >> Notice that "First" is the first word of the comment line "First run >> without enabling NMT" in the tag description. >> >> So is this indeed an error in the test description of >> JcmdWithNMTDisabled.java and should it be fixed by removing the two >> lines: >> >> * @library /testlibrary >> - * First run without enabling NMT >> * @run main/othervm JcmdWithNMTDisabled >> - * Then run with explicitly disabling NMT, should not be any difference >> * @run main/othervm -XX:NativeMemoryTracking=off JcmdWithNMTDisabled >> >> from the test description to make it runnable with newer JTreg versions as >> well? >> >> Regards, >> Volker >> > From david.holmes at oracle.com Fri Jun 26 12:38:26 2015 From: david.holmes at oracle.com (David Holmes) Date: Fri, 26 Jun 2015 22:38:26 +1000 Subject: [TESTBUG]: Syntax error in test description of jdk8u-dev/.../JcmdWithNMTDisabled.java ? In-Reply-To: References: <558D3D4A.9090701@oracle.com> Message-ID: <558D47C2.2010407@oracle.com> On 26/06/2015 10:33 PM, Volker Simonis wrote: > Thanks David, > > It's also amazing that this actually did run with older versions of > jtreg without producing an error (altough it produced a lot of > useless, empty directories - on for each word in the 'comment' lines > :) > > So I assume somebody is taking care of this issue. I hope so. Unfortunately the timing is bad. jdk8u/hs-dev is now closed for 8u60 changes as the final snapshot has been taken before 8u60 hits RDP2. That means this change must either quickly zip in via jdk8u/dev before RDP2, or it will either miss 8u60 or else require special approval (which is unlikely as it isn't a P1 or P2 issue). David > Regards, > Volker > > > On Fri, Jun 26, 2015 at 1:53 PM, David Holmes wrote: >> Hi Volker, >> >> Known issue: >> >> https://bugs.openjdk.java.net/browse/JDK-8098541 (not public sorry) >> >> but mis-processed in my opinion so I'm trying to get it re-addressed. >> >> It's amazing how many people had no idea that tags spanned multiple lines, >> and that there was no commenting mechanism. :( >> >> David >> >> >> On 26/06/2015 7:09 PM, Volker Simonis wrote: >>> >>> Hi, >>> >>> after I've upgraded to the latest and greatest version of JTreg >>> (168:055251d38f29 "minor naming cleanup in Agent") I get an error when >>> executing the hotspot test: >>> >>> runtime/NMT/JcmdWithNMTDisabled.java >>> >>> from the jdk8u-dev (notice that the same test from the jdk9 forest >>> runs just fine because it was already refactored). >>> >>> I think this is because of the strange tag syntax the test uses: >>> >>> /* >>> * @test >>> * @key nmt jcmd >>> * @summary Verify that jcmd correctly reports that NMT is not enabled >>> * @library /testlibrary >>> * First run without enabling NMT >>> * @run main/othervm JcmdWithNMTDisabled >>> * Then run with explicitly disabling NMT, should not be any difference >>> * @run main/othervm -XX:NativeMemoryTracking=off JcmdWithNMTDisabled >>> */ >>> >>> The problem is that the comment line "First run without enabling NMT" >>> will be appended to the "@library" tag like this: >>> >>> @library /testlibrary First run without enabling NMT >>> >>> yielding in strange class paths during execution which contain >>> "/First:/run:/without:...". But apparently this >>> doesn't confuse older version of JTreg too much because the test >>> succeeded nevertheless. >>> >>> However with the newest JTreg version the test badly fails with the error: >>> >>> test result: Error. Test Class Exception: Can't find library: First >>> >>> Notice that "First" is the first word of the comment line "First run >>> without enabling NMT" in the tag description. >>> >>> So is this indeed an error in the test description of >>> JcmdWithNMTDisabled.java and should it be fixed by removing the two >>> lines: >>> >>> * @library /testlibrary >>> - * First run without enabling NMT >>> * @run main/othervm JcmdWithNMTDisabled >>> - * Then run with explicitly disabling NMT, should not be any difference >>> * @run main/othervm -XX:NativeMemoryTracking=off JcmdWithNMTDisabled >>> >>> from the test description to make it runnable with newer JTreg versions as >>> well? >>> >>> Regards, >>> Volker >>> >> From vladimir.kozlov at oracle.com Fri Jun 26 15:24:26 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 26 Jun 2015 08:24:26 -0700 Subject: IgnoreUnrecognizedVMOptions and badly specified options In-Reply-To: <558D1470.5030206@oracle.com> References: <558BF15A.6030702@oracle.com> <558C141B.9080006@oracle.com> <558C3397.80001@oracle.com> <558C34FC.803@oracle.com> <558C35DC.5060002@oracle.com> <558C36CE.6090606@oracle.com> <558CE595.2050604@oracle.com> <558CEA98.1070501@oracle.com> <558D1470.5030206@oracle.com> Message-ID: <558D6EAA.1060202@oracle.com> I agree with this suggestion. Make it ccstrlist so we can specify list of flags. But then the name should be different - "Unrecognized" is misleading in such case I think. Thanks, Vladimir On 6/26/15 1:59 AM, Stefan Karlsson wrote: > On 2015-06-26 08:00, Bengt Rutisson wrote: >> >> Hi all, >> >> Just one more thought if we are thinking about making changes to the >> IgnoreUnrecognizedVMOptions flag. >> >> I am not a big fan of this flag since I think it just goes to show >> that we don't have enough control over our testing. As I understand it >> the main reason for the introduction of this flag was that when >> compressed oops was implemented we had no way of controlling which >> tests were run on 32 bit platforms (where the UseCompressedOops flag >> is not available) or o 64 bit platforms. >> >> I think it is unfortunate that we don't have better control of our >> testing. But one way of at least increasing the control would be to >> make IgnoreUnrecognizedVMOptions more specific. I would suggest that >> we change it to take a named argument that should be ignored. >> >> Something like: >> >> -XX:IgnoreUnrecognizedVMOption=UseCompressedOops >> >> That way it would not hide other issues in our testing. As it is now >> we run a lot of our testing with IgnoreUnrecognizedVMOptions which >> means that we don't find tests that need to be updated when we for >> example remove a command line option. >> >> Maybe it is a side track, but I wanted to mention it in this discussion. > > Yes, I've also suggested this a couple of times. Maybe it's time to > create an RFE? > > StefanK > >> >> Bengt >> >> >> On 2015-06-26 07:39, David Holmes wrote: >>> On 26/06/2015 3:13 AM, Dmitry Dmitriev wrote: >>>> Thank you Dan! The bug states about changed behaviour but it relates to >>>> the current implementation of IgnoreUnrecongnizedVMOptions flag and I >>>> think it can be fixed by this RFR. >>> >>> As I added to the/a bug report I think we need a very clear spec on >>> how all these aspects of option checking should interact - what >>> should be ignored by IgnoreUnrecognizedVMOptions? Is a badly formed >>> option "unrecognized"? A flow chart covering all the possibilities >>> and the precedence would make it a lot easier to validate the code. >>> >>> Cheers, >>> David >>> >>>> On 25.06.2015 20:09, Daniel D. Daugherty wrote: >>>>> I'm pretty sure that bug was filed this morning: >>>>> >>>>> JDK-8129855 -XX:+IgnoreUnrecognizedVMOptions hides improperly >>>>> specified VM options. >>>>> https://bugs.openjdk.java.net/browse/JDK-8129855 >>>>> >>>>> Michail was reading your mind... >>>> No magic here, we discuss this topic today :) I am become curious about >>>> that behaviour, since this code exit for a long time. >>>> >>>> Regards, >>>> Dmitry >>>> >>>>> >>>>> Dan >>>>> >>>>> >>>>> On 6/25/15 11:06 AM, Vladimir Kozlov wrote: >>>>>> File bug on runtime (who handles flags verification this days?) with >>>>>> your suggestion. >>>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>> On 6/25/15 10:00 AM, Dmitry Dmitriev wrote: >>>>>>> Hello Vladimir, >>>>>>> >>>>>>> Thank you for explanation. I just was bit confused about valid VM >>>>>>> options but which improperly specified. >>>>>>> I look at the Arguments::process_argument function in >>>>>>> src/share/vm/runtime/arguments.cpp module and noticed one thing: >>>>>>> >>>>>>> 817 bool Arguments::process_argument(const char* arg, >>>>>>> 818 jboolean ignore_unrecognized, Flag::Flags origin) { >>>>>>> 819 >>>>>>> 820 JDK_Version since = JDK_Version(); >>>>>>> 821 >>>>>>> 822 if (parse_argument(arg, origin) || ignore_unrecognized) { >>>>>>> 823 return true; >>>>>>> 824 } >>>>>>> ... >>>>>>> 850 // For locked flags, report a custom error message if >>>>>>> available. >>>>>>> 851 // Otherwise, report the standard unrecognized VM option. >>>>>>> 852 Flag* found_flag = Flag::find_flag((const char*)argname, >>>>>>> arg_len, true, true); >>>>>>> 853 if (found_flag != NULL) { >>>>>>> 854 char locked_message_buf[BUFLEN]; >>>>>>> 855 found_flag->get_locked_message(locked_message_buf, BUFLEN); >>>>>>> 856 if (strlen(locked_message_buf) == 0) { >>>>>>> 857 if (found_flag->is_bool() && !has_plus_minus) { >>>>>>> 858 jio_fprintf(defaultStream::error_stream(), >>>>>>> 859 "Missing +/- setting for VM option '%s'\n", >>>>>>> argname); >>>>>>> 860 } else if (!found_flag->is_bool() && has_plus_minus) { >>>>>>> 861 jio_fprintf(defaultStream::error_stream(), >>>>>>> 862 "Unexpected +/- setting in VM option '%s'\n", >>>>>>> argname); >>>>>>> 863 } else { >>>>>>> 864 jio_fprintf(defaultStream::error_stream(), >>>>>>> 865 "Improperly specified VM option '%s'\n", argname); >>>>>>> 866 } >>>>>>> 867 } else { >>>>>>> 868 jio_fprintf(defaultStream::error_stream(), "%s", >>>>>>> locked_message_buf); >>>>>>> 869 } >>>>>>> 870 } else { >>>>>>> 871 jio_fprintf(defaultStream::error_stream(), >>>>>>> 872 "Unrecognized VM option '%s'\n", argname); >>>>>>> 873 Flag* fuzzy_matched = Flag::fuzzy_match((const >>>>>>> char*)argname, arg_len, true); >>>>>>> 874 if (fuzzy_matched != NULL) { >>>>>>> 875 jio_fprintf(defaultStream::error_stream(), >>>>>>> 876 "Did you mean '%s%s%s'? ", >>>>>>> 877 (fuzzy_matched->is_bool()) ? "(+/-)" : "", >>>>>>> 878 fuzzy_matched->_name, >>>>>>> 879 (fuzzy_matched->is_bool()) ? "" : >>>>>>> "="); >>>>>>> 880 } >>>>>>> 881 } >>>>>>> 882 >>>>>>> 883 // allow for commandline "commenting out" options like >>>>>>> -XX:#+Verbose >>>>>>> 884 return arg[0] == '#'; >>>>>>> 885 } >>>>>>> >>>>>>> If "-XX:+IgnoreUnrecongnizedVMOptions" is specified, then >>>>>>> "ignore_unrecognized" will be true and "if" statement on line >>>>>>> 822 will always be true. >>>>>>> I just think that a better place to check "ignore_unrecognized" is >>>>>>> on "else" branch on line 867(for locked flags) and on >>>>>>> "else" branch on line 870(where we actually found unrecognized >>>>>>> option). If "ignore_unrecognized" is true, then return >>>>>>> true in this case, otherwise execute code in these "else" branches. >>>>>>> It's my thoughts about that. In this case improperly >>>>>>> specified options will be catched(lines 857-866). >>>>>>> >>>>>>> Thanks, >>>>>>> Dmitry >>>>>>> >>>>>>> >>>>>>> On 25.06.2015 17:45, Vladimir Kozlov wrote: >>>>>>>> It is not intentional but difficult to implement. >>>>>>>> It was added to allow specify options which are not defined in >>>>>>>> running VM. >>>>>>>> For example when C2 option is specified but Client VM (which has >>>>>>>> only C1) is run. >>>>>>>> We can do more smarter things here, I agree, by trying to verify >>>>>>>> options before ignoring it. >>>>>>>> But it will not help with misspelled options, I think. >>>>>>>> >>>>>>>> Regards, >>>>>>>> Vladimir >>>>>>>> >>>>>>>> On 6/25/15 5:17 AM, Dmitry Dmitriev wrote: >>>>>>>>> Hello, >>>>>>>>> >>>>>>>>> Working with JVM command line options I noticed that >>>>>>>>> "IgnoreUnrecognizedVMOptions" option allow to hide options with >>>>>>>>> bad >>>>>>>>> values. "IgnoreUnrecognizedVMOptions" allow to ignore unrecognized >>>>>>>>> options, but it also allow to ignore improperly >>>>>>>>> specified VM Options which are processed in general way, i.e. >>>>>>>>> "-XX:" options processed by Arguments::process_argument >>>>>>>>> function(hotspot/src/share/vm/runtime/arguments.cpp module). >>>>>>>>> >>>>>>>>> I will be very appreciated if someone can describe this behavior >>>>>>>>> or state that this is intentional. >>>>>>>>> >>>>>>>>> Example for numeric and boolean options: >>>>>>>>> 1) Bad numeric option with and without >>>>>>>>> "-XX:+IgnoreUnrecongnizedVMOptions" >>>>>>>>> java -XX:MaxRAMFraction=-1 -version >>>>>>>>> Improperly specified VM option 'MaxRAMFraction=-1' >>>>>>>>> Error: Could not create the Java Virtual Machine. >>>>>>>>> Error: A fatal exception has occurred. Program will exit. >>>>>>>>> >>>>>>>>> java -XX:MaxRAMFraction=-1 -XX:+IgnoreUnrecognizedVMOptions >>>>>>>>> -version >>>>>>>>> java version "1.8.0_40" >>>>>>>>> Java(TM) SE Runtime Environment (build 1.8.0_40-b26) >>>>>>>>> Java HotSpot(TM) 64-Bit Server VM (build 25.40-b25, mixed mode) >>>>>>>>> >>>>>>>>> 2) Bad boolean option with and without >>>>>>>>> "-XX:+IgnoreUnrecongnizedVMOptions" >>>>>>>>> java -XX:UseG1GC -version >>>>>>>>> Missing +/- setting for VM option 'UseG1GC' >>>>>>>>> Error: Could not create the Java Virtual Machine. >>>>>>>>> Error: A fatal exception has occurred. Program will exit. >>>>>>>>> >>>>>>>>> java -XX:UseG1GC -XX:+IgnoreUnrecognizedVMOptions -version >>>>>>>>> java version "1.8.0_40" >>>>>>>>> Java(TM) SE Runtime Environment (build 1.8.0_40-b26) >>>>>>>>> Java HotSpot(TM) 64-Bit Server VM (build 25.40-b25, mixed mode) >>>>>>>>> >>>>>>>>> So, as we see when "-XX:+IgnoreUnrecongnizedVMOptions" is used, >>>>>>>>> bad "-XX:MaxRAMFraction=-1" and "-XX:UseG1GC" are >>>>>>>>> ignored. I don't know is this behavior intentional or not, but >>>>>>>>> HotSpot works in that way. >>>>>>>>> >>>>>>>>> So, can someone tell me this is intentional? Or this behavior is >>>>>>>>> wrong? >>>>>>>>> >>>>>>>>> Thank you, >>>>>>>>> Dmitry >>>>>>>>> >>>>>>>>> >>>>>>> >>>>> >>>> >> > From zoltan.majo at oracle.com Fri Jun 26 15:43:12 2015 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Fri, 26 Jun 2015 17:43:12 +0200 Subject: [9] RFR(M): 8076112: Add @HotSpotIntrinsicCandidate annotation to indicate methods for which Java Runtime has intrinsics In-Reply-To: <558D0FC2.5060903@oracle.com> References: <558BEABD.7090907@oracle.com> <558D0FC2.5060903@oracle.com> Message-ID: <558D7310.60807@oracle.com> Hi Alan, thank you for the review! Please see my answers/comments below. On 06/26/2015 10:39 AM, Alan Bateman wrote: > On 25/06/2015 12:49, Zolt?n Maj? wrote: >> Hi, >> >> >> please review the patch for JDK-8076112. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8076112 >> >> Problem: There is need to indicate Java methods that are potentially >> intrinsified by JVM. >> >> Solution: Mark intrinsified methods with the >> jdk.internal.HotSpotIntrinsicCandidate annotation. Add checks that >> are omitted by VM-level intrinsics to the library code. Add a new >> diagnostic flag, CheckIntrinsics. If CheckIntrinsics is enabled, the >> VM performs the following checks when a class C is loaded: >> - all intrinsics defined by the VM for class C are present in the >> loaded class file and are marked; >> - an intrinsic is defined by the VM for all marked methods of C. >> >> If a mismatch is detected, the following is done: >> - a fastdebug VM prints a warning and then exits; >> - a product VM prints a warning and unmarked are not intrinsified. >> >> Webrev: >> - top: http://cr.openjdk.java.net/~zmajo/8076112/top/webrev.05/ >> - jdk: http://cr.openjdk.java.net/~zmajo/8076112/jdk/webrev.05/ >> - hotspot: http://cr.openjdk.java.net/~zmajo/8076112/hotspot/webrev.05/ > > I skimmed through the webrev and don't see any significant issues. > > One thing to double check is that you are are keeping things locally > consistent. One example is the convention in many areas to use implFoo > rather than fooImpl. Also in some areas then native methods then > you'll see foo0 called from foo. I'm just mentioning it because it > requires coordination to rename these methods. I changed the naming of most intrinsified methods from fooImpl to implFoo. In four cases the wrapper of the intrinsified method is already called implFoo. So I decided to use the convention for native methods in those cases and renamed the intrinsic to implFoo0. The four methods are: sun/security/provider/SHA.implCompress0 sun/security/provider/SHA2.implCompress0 sun/security/provider/SHA5.implCompress0 sun/security/provider/implCompressMultiBlock0 > You might also want to do a quick pass over to ensure other > consistency. I see a few places where 8 spec indent is used, that > could be just tabs of course. I updated the indentation as well. Here is the updated webrev: - top: http://cr.openjdk.java.net/~zmajo/8076112/top/webrev.06/ - jdk: http://cr.openjdk.java.net/~zmajo/8076112/jdk/webrev.06/ - hotspot: http://cr.openjdk.java.net/~zmajo/8076112/hotspot/webrev.06/ Thank you and best regards, Zoltan > > -Alan > > > > From alejandro.murillo at oracle.com Fri Jun 26 16:05:32 2015 From: alejandro.murillo at oracle.com (Alejandro E Murillo) Date: Fri, 26 Jun 2015 10:05:32 -0600 Subject: Hotspot changes for 8u60 and jdk8u/hs-dev Message-ID: <558D784C.2090802@oracle.com> I just submitted PIT for the last snapshot of jdk8u/hs-dev for jdk8u60 before 8u60 enters RDP2 ([1]). PLEASE do not push anything to that repo until further notice. Once jdk8u60-b22 is promoted next week, I will synch jdk8u/hs-dev with jdk8u/jdk8u and associate it with a new 8u release, following suit to what what will be done for jdk8u/jdk8u[-dev] (see [2]) Going forward any hotspot change destined for 8u60 will be subject to the Phase 2 stabilization process [1]. Those 8u60 approved HOTSPOT related changes should be pushed to jdk8u/hs-dev as usual and I will extract them from there, on a need basis, and will get them to the 8u60 stabilization repos. I will keep an eye on approved RDP2 changes but send me a heads up email when you have pushed one of such changes Thanks [1] http://openjdk.java.net/projects/jdk8u/phase2/phase2-process.html [2] http://mail.openjdk.java.net/pipermail/jdk8u-dev/2015-June/003929.html -- Alejandro From gerard.ziemski at oracle.com Fri Jun 26 16:16:40 2015 From: gerard.ziemski at oracle.com (Gerard Ziemski) Date: Fri, 26 Jun 2015 11:16:40 -0500 Subject: Rev1 RFR (S): 8112746 Followup to JEP 245: Validate JVM Command-Line Flag Arguments In-Reply-To: <558C798E.6040307@oracle.com> References: <558C798E.6040307@oracle.com> Message-ID: <558D7AE8.9090504@oracle.com> I will be updating up my webrev to Rev2 soon, that changes constraint functions to take flags' arguments by value, not a pointer, as it is currently implemented. I originally thought we could automatically adjust flag values as needed when the range/constraint was invalidated, but that was deemed outside the JEP-245, however, I forgot to fix constraint functions parameters. cheers On 6/25/2015 4:58 PM, Gerard Ziemski wrote: > hi all, > > This webrev gets the macro and quotes fix right. > > Please review this followup to my recent JEP 245 checkin. It addresses > the issues raised by Coleen, Dmitry and Kim during webrev. > > You can see https://bugs.openjdk.java.net/browse/JDK-8112746 for > details, but the most important change here is that we only check > constraint if the range check passes first. > > To quickly recap: I changed that part of the code when David pointed > out that I had to modify 2 tests in a way that looked like a > regression - I removed some test cases. However, Kim, later pointed > out that the original code had the advantage of having constraints > guaranteed that the flag values were within ranges. > > I checked in the code with ranges and constraints being checked both > regardless of each other, but this followup restores the original > behavior (and simplifies the code), where we first check ranges and > only check constraints if range passes. > > The 2 tests (ObjectAlignment.java and Options.java) seem to loose some > test cases, but those paths are still tested (though with different > values), so we in fact do not loose anything from test coverage point > of view. > > The change passes JPRT (hotspot) and RBT (vm.quick.testlist) > > > References: > > webrev:http://cr.openjdk.java.net/~gziemski/8112746_rev1 > this issue:https://bugs.openjdk.java.net/browse/JDK-8112746 > JEP 245:https://bugs.openjdk.java.net/browse/JDK-8059557 > > > hg stat: > > # hg_stat > src/share/vm/gc/g1/g1_globals.hpp | 4 +- > src/share/vm/runtime/commandLineFlagConstraintsGC.cpp | 5 +- > src/share/vm/runtime/commandLineFlagRangeList.cpp | 58 ++++------ > src/share/vm/runtime/globals.cpp | 129 > +++++++++++++---------- > src/share/vm/runtime/globals.hpp | 17 +-- > test/runtime/CompressedOops/ObjectAlignment.java | 3 +- > test/runtime/contended/Options.java | 2 - > 7 files changed, 103 insertions(+), 115 deletions(-) > > > > > > > From alexander.vorobyev at oracle.com Fri Jun 26 13:31:28 2015 From: alexander.vorobyev at oracle.com (alexander vorobyev) Date: Fri, 26 Jun 2015 16:31:28 +0300 Subject: [8u65] Request for approval: backport of JDK-8007890 In-Reply-To: <542E8041.1010101@oracle.com> References: <542E8041.1010101@oracle.com> Message-ID: <558D5430.7040209@oracle.com> Hi All, I would like to backport fix for JDK-8007890 to 8u65. Bug id:https://bugs.openjdk.java.net/browse/JDK-8007890 Webrev:http://cr.openjdk.java.net/~ctornqvi/webrev/8007890/webrev.00/ Changeset:http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/e865e9584e0e Review thread for original fix:http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2014-March/011228.html testing: jprt Thanks, Alexander From james.cheng at oracle.com Fri Jun 26 17:23:08 2015 From: james.cheng at oracle.com (james cheng) Date: Fri, 26 Jun 2015 10:23:08 -0700 Subject: [9] RFR(M): 8076112: Add @HotSpotIntrinsicCandidate annotation to indicate methods for which Java Runtime has intrinsics In-Reply-To: <558D7310.60807@oracle.com> References: <558BEABD.7090907@oracle.com> <558D0FC2.5060903@oracle.com> <558D7310.60807@oracle.com> Message-ID: <558D8A7C.8020807@oracle.com> Hi Zolt?n, I am not a reviewer. Just saw some typos in code comments: > Here is the updated webrev: > - top: http://cr.openjdk.java.net/~zmajo/8076112/top/webrev.06/ > - jdk: http://cr.openjdk.java.net/~zmajo/8076112/jdk/webrev.06/ in SHA*.java, 'implCompressImpl', "as parameter the method" > - hotspot: http://cr.openjdk.java.net/~zmajo/8076112/hotspot/webrev.06/ in vmSymbols.hpp.html, 649 // ... e.g.,, 650&651 [ one of the closing parentheses seems superfluous] 673 // ... approriate ... Thanks, -James From aph at redhat.com Sat Jun 27 08:05:34 2015 From: aph at redhat.com (Andrew Haley) Date: Sat, 27 Jun 2015 09:05:34 +0100 Subject: [9] RFR(M): 8076112: Add @HotSpotIntrinsicCandidate annotation to indicate methods for which Java Runtime has intrinsics In-Reply-To: <558BEABD.7090907@oracle.com> References: <558BEABD.7090907@oracle.com> Message-ID: <558E594E.7080906@redhat.com> On 25/06/15 12:49, Zolt?n Maj? wrote: > Problem: There is need to indicate Java methods that are potentially > intrinsified by JVM. It's a great idea but is it a good name? HotSpot is not the only Java VM. Do we expect people from to come along and add J9IntrinsicCandidate, CACAOIntrinsicCandidate, and so on? Andrew. From david.holmes at oracle.com Sat Jun 27 22:10:19 2015 From: david.holmes at oracle.com (David Holmes) Date: Sun, 28 Jun 2015 08:10:19 +1000 Subject: [8u65] Request for approval: backport of JDK-8007890 In-Reply-To: <558D5430.7040209@oracle.com> References: <542E8041.1010101@oracle.com> <558D5430.7040209@oracle.com> Message-ID: <558F1F4B.7040706@oracle.com> Hi Alexander, Why is this targeted to 8u65 and where do you propose to push it? jdk8u/hs-dev is not accepting any changes at the moment. Thanks, David On 26/06/2015 11:31 PM, alexander vorobyev wrote: > > Hi All, > > I would like to backport fix for JDK-8007890 to 8u65. > > Bug id:https://bugs.openjdk.java.net/browse/JDK-8007890 > Webrev:http://cr.openjdk.java.net/~ctornqvi/webrev/8007890/webrev.00/ > > Changeset:http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/e865e9584e0e > Review thread for original > fix:http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2014-March/011228.html > > > testing: jprt > > Thanks, > Alexander > > > From kim.barrett at oracle.com Sun Jun 28 01:16:40 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Sat, 27 Jun 2015 21:16:40 -0400 Subject: GCC 4.8.3+ Does anybody aware of Stack Smashing Protection ? In-Reply-To: <557669D9.704@oracle.com> References: <5571F91D.2020003@oracle.com> <557669D9.704@oracle.com> Message-ID: <0EDC7C31-CB52-40CD-81BC-1A4E9060B7B4@oracle.com> On Jun 9, 2015, at 12:21 AM, David Holmes wrote: > > We initially added -fstack-protector-all (and related settings under): > > https://bugs.openjdk.java.net/browse/JDK-8032045 > > We removed the -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 definitions under 8047952 as they broke fastdebug builds. > > If we were to make the official compiler one that enables this by default then we would have to re-examine its affects on all platforms and the costs involved - and then allow or disable as appropriate. I was reminded by this to finally get around to filing an RFE to (carefully) re-enable _FORTIFY_SOURCE for fastdebug builds: https://bugs.openjdk.java.net/browse/JDK-8130017 From Alan.Bateman at oracle.com Sun Jun 28 19:21:12 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 28 Jun 2015 20:21:12 +0100 Subject: [9] RFR(M): 8076112: Add @HotSpotIntrinsicCandidate annotation to indicate methods for which Java Runtime has intrinsics In-Reply-To: <558D7310.60807@oracle.com> References: <558BEABD.7090907@oracle.com> <558D0FC2.5060903@oracle.com> <558D7310.60807@oracle.com> Message-ID: <55904928.9050909@oracle.com> On 26/06/2015 16:43, Zolt?n Maj? wrote: > > I updated the indentation as well. > > Here is the updated webrev: > - top: http://cr.openjdk.java.net/~zmajo/8076112/top/webrev.06/ > - jdk: http://cr.openjdk.java.net/~zmajo/8076112/jdk/webrev.06/ > - hotspot: http://cr.openjdk.java.net/~zmajo/8076112/hotspot/webrev.06/ > > Thank you and best regards, > Thanks, looks like my comments are addressed so looks good to me. -Alan From goetz.lindenmaier at sap.com Mon Jun 29 08:27:19 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 29 Jun 2015 08:27:19 +0000 Subject: RFR(S): Message-ID: <4295855A5C1DE049A61835A1887419CC2D000AF4@DEWDFEMB12A.global.corp.sap> Hi, We detected some minor, but obviously wrong coding issues we would like to fix. In two places {} are missing after an if, whilst there are two statements that depend on the condition (CHECK macro expands to another statement). In compilerOracle.cpp, a wrong size is passed to jio_snprintf(). Please review this change. I please need a sponsor. http://cr.openjdk.java.net/~goetz/webrevs/8130036_blocks/webrev.01/8130036_blocks-hs-rt.changeset Best regards, Goetz. From goetz.lindenmaier at sap.com Mon Jun 29 08:30:39 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 29 Jun 2015 08:30:39 +0000 Subject: RFR(S): 8130036: Fix problems with imprecise C++ coding. Message-ID: <4295855A5C1DE049A61835A1887419CC2D000B06@DEWDFEMB12A.global.corp.sap> Hi, We detected some minor, but obviously wrong coding issues we would like to fix. In two places {} are missing after an if, whilst there are two statements that depend on the condition (CHECK macro expands to another statement). In compilerOracle.cpp, a wrong size is passed to jio_snprintf(). Please review this change. I please need a sponsor. http://cr.openjdk.java.net/~goetz/webrevs/8130036_blocks/webrev.01/8130036_blocks-hs-rt.changeset Best regards, Goetz. Sorry for the resend, the subject was missing ... From zoltan.majo at oracle.com Mon Jun 29 09:24:16 2015 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Mon, 29 Jun 2015 11:24:16 +0200 Subject: [9] RFR(M): 8076112: Add @HotSpotIntrinsicCandidate annotation to indicate methods for which Java Runtime has intrinsics In-Reply-To: <558D8A7C.8020807@oracle.com> References: <558BEABD.7090907@oracle.com> <558D0FC2.5060903@oracle.com> <558D7310.60807@oracle.com> <558D8A7C.8020807@oracle.com> Message-ID: <55910EC0.609@oracle.com> Hi James, thank you for your feedback! I've implemented the changes you suggested, here is the updated webrev: - top: http://cr.openjdk.java.net/~zmajo/8076112/top/webrev.07/ - jdk: http://cr.openjdk.java.net/~zmajo/8076112/jdk/webrev.07/ - hotspot: http://cr.openjdk.java.net/~zmajo/8076112/hotspot/webrev.07/ Best regards, Zoltan On 06/26/2015 07:23 PM, james cheng wrote: > Hi Zolt?n, > > I am not a reviewer. Just saw some typos in code comments: > >> Here is the updated webrev: >> - top: http://cr.openjdk.java.net/~zmajo/8076112/top/webrev.06/ >> - jdk: http://cr.openjdk.java.net/~zmajo/8076112/jdk/webrev.06/ > > in SHA*.java, 'implCompressImpl', "as parameter the method" > >> - hotspot: http://cr.openjdk.java.net/~zmajo/8076112/hotspot/webrev.06/ > > in vmSymbols.hpp.html, > 649 // ... e.g.,, > 650&651 [ one of the closing parentheses seems > superfluous] > 673 // ... approriate ... > > Thanks, > -James From zoltan.majo at oracle.com Mon Jun 29 09:24:51 2015 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Mon, 29 Jun 2015 11:24:51 +0200 Subject: [9] RFR(M): 8076112: Add @HotSpotIntrinsicCandidate annotation to indicate methods for which Java Runtime has intrinsics In-Reply-To: <55904928.9050909@oracle.com> References: <558BEABD.7090907@oracle.com> <558D0FC2.5060903@oracle.com> <558D7310.60807@oracle.com> <55904928.9050909@oracle.com> Message-ID: <55910EE3.3060800@oracle.com> On 06/28/2015 09:21 PM, Alan Bateman wrote: > > > On 26/06/2015 16:43, Zolt?n Maj? wrote: >> >> I updated the indentation as well. >> >> Here is the updated webrev: >> - top: http://cr.openjdk.java.net/~zmajo/8076112/top/webrev.06/ >> - jdk: http://cr.openjdk.java.net/~zmajo/8076112/jdk/webrev.06/ >> - hotspot: http://cr.openjdk.java.net/~zmajo/8076112/hotspot/webrev.06/ >> >> Thank you and best regards, >> > Thanks, looks like my comments are addressed so looks good to me. Thank you, Alan! Best regards, Zoltan > > -Alan > From david.holmes at oracle.com Mon Jun 29 09:26:00 2015 From: david.holmes at oracle.com (David Holmes) Date: Mon, 29 Jun 2015 19:26:00 +1000 Subject: RFR(S): 8130036: Fix problems with imprecise C++ coding. In-Reply-To: <4295855A5C1DE049A61835A1887419CC2D000B06@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2D000B06@DEWDFEMB12A.global.corp.sap> Message-ID: <55910F28.2050400@oracle.com> Hi Goetz, Good catches! If no-one steps in overnight I'll take care of this in my morning. Thanks, David On 29/06/2015 6:30 PM, Lindenmaier, Goetz wrote: > Hi, > > > > We detected some minor, but obviously wrong coding issues we would like to fix. > > > > In two places {} are missing after an if, whilst there are two statements that depend > > on the condition (CHECK macro expands to another statement). > > > > In compilerOracle.cpp, a wrong size is passed to jio_snprintf(). > > > > Please review this change. I please need a sponsor. > > http://cr.openjdk.java.net/~goetz/webrevs/8130036_blocks/webrev.01/8130036_blocks-hs-rt.changeset > > > > Best regards, > > Goetz. > > Sorry for the resend, the subject was missing ... > From zoltan.majo at oracle.com Mon Jun 29 09:41:37 2015 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Mon, 29 Jun 2015 11:41:37 +0200 Subject: [9] RFR(M): 8076112: Add @HotSpotIntrinsicCandidate annotation to indicate methods for which Java Runtime has intrinsics In-Reply-To: <558E594E.7080906@redhat.com> References: <558BEABD.7090907@oracle.com> <558E594E.7080906@redhat.com> Message-ID: <559112D1.5000903@oracle.com> Hi Andrew, On 06/27/2015 10:05 AM, Andrew Haley wrote: > On 25/06/15 12:49, Zolt?n Maj? wrote: >> Problem: There is need to indicate Java methods that are potentially >> intrinsified by JVM. > It's a great idea but is it a good name? HotSpot is not the only Java > VM. Do we expect people from to come along and add > J9IntrinsicCandidate, CACAOIntrinsicCandidate, and so on? thank you bringing up this issue. The name HotSpotIntrinsicCandidate resulted from a private discussion with Joe Darcy, Brian Goetz, and John Rose. The reason this name was picked is to make clear that a marked method's interaction with the VM (specifically with the HotSpot VM implementation) needs special attention. Best regards, Zoltan > > Andrew. From aph at redhat.com Mon Jun 29 09:45:31 2015 From: aph at redhat.com (Andrew Haley) Date: Mon, 29 Jun 2015 10:45:31 +0100 Subject: [9] RFR(M): 8076112: Add @HotSpotIntrinsicCandidate annotation to indicate methods for which Java Runtime has intrinsics In-Reply-To: <559112D1.5000903@oracle.com> References: <558BEABD.7090907@oracle.com> <558E594E.7080906@redhat.com> <559112D1.5000903@oracle.com> Message-ID: <559113BB.1020106@redhat.com> Hi, On 29/06/15 10:41, Zolt?n Maj? wrote: > > On 06/27/2015 10:05 AM, Andrew Haley wrote: >> On 25/06/15 12:49, Zolt?n Maj? wrote: >>> Problem: There is need to indicate Java methods that are potentially >>> intrinsified by JVM. >> It's a great idea but is it a good name? HotSpot is not the only Java >> VM. Do we expect people from to come along and add >> J9IntrinsicCandidate, CACAOIntrinsicCandidate, and so on? > > thank you bringing up this issue. > > The name HotSpotIntrinsicCandidate resulted from a private discussion > with Joe Darcy, Brian Goetz, and John Rose. The reason this name was > picked is to make clear that a marked method's interaction with the VM > (specifically with the HotSpot VM implementation) needs special attention. OK, cool. So has any thought been given to the other VMs? Do you expect that, say, J9 will use the HotSpotIntrinsicCandidate annotattion, or do you expect we will have similar annotations for each VM which uses OpenJDK libraries? Or is the need for this annotation totally HotSpot-specific? Andrew. From zoltan.majo at oracle.com Mon Jun 29 10:41:12 2015 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Mon, 29 Jun 2015 12:41:12 +0200 Subject: [9] RFR(M): 8076112: Add @HotSpotIntrinsicCandidate annotation to indicate methods for which Java Runtime has intrinsics In-Reply-To: <559113BB.1020106@redhat.com> References: <558BEABD.7090907@oracle.com> <558E594E.7080906@redhat.com> <559112D1.5000903@oracle.com> <559113BB.1020106@redhat.com> Message-ID: <559120C8.5070208@oracle.com> Hi, On 06/29/2015 11:45 AM, Andrew Haley wrote: > Hi, > > On 29/06/15 10:41, Zolt?n Maj? wrote: >> On 06/27/2015 10:05 AM, Andrew Haley wrote: >>> On 25/06/15 12:49, Zolt?n Maj? wrote: >>>> Problem: There is need to indicate Java methods that are potentially >>>> intrinsified by JVM. >>> It's a great idea but is it a good name? HotSpot is not the only Java >>> VM. Do we expect people from to come along and add >>> J9IntrinsicCandidate, CACAOIntrinsicCandidate, and so on? >> thank you bringing up this issue. >> >> The name HotSpotIntrinsicCandidate resulted from a private discussion >> with Joe Darcy, Brian Goetz, and John Rose. The reason this name was >> picked is to make clear that a marked method's interaction with the VM >> (specifically with the HotSpot VM implementation) needs special attention. > OK, cool. So has any thought been given to the other VMs? Do you > expect that, say, J9 will use the HotSpotIntrinsicCandidate > annotattion, or do you expect we will have similar annotations for > each VM which uses OpenJDK libraries? Or is the need for this > annotation totally HotSpot-specific? the need for this annotation resulted from the way HotSpot handles intrinsics. Here are the two main reasons: (1) Intrinsics in the HotSpot VM omit some checks (typically null checks and array bounds checks) that are instead performed in the JDK code. If HotSpot intrinsic code is changed, the matching JDK code must be changed as well (and vice versa). Otherwise we might run into correctness problems (e.g., the HotSpot intrinsic and the JDK method have different semantics) and/or performance problems (HotSpot suddenly not intrinsify a method because, e.g., the method's signature has changed and HotSpot's intrinsic list was not updated accordingly). Annotating intrinsified methods makes it less likely that a "mismatch" between a JDK method and its HotSpot-level intrinsic counterpart can be introduced. (2) With the newly added CheckIntrinsic flag, HotSpot verifies if all annotated methods are backed by intrinsics at the VM level and that all intrinsics are marked appropriately in the JDK. Other VM implementations will most likely intrinsify a different set of methods. So, if those methods were marked with the same annotation as HotSpot is looking for, it would be difficult for HotSpot to check the match between intrinsics and the JDK code they replace (Reason 2 from above). Also, if a JDK method is updated for which VM_A but not VM_B defines and intrinsic, only VM A's intrinsic code must be updated to match the JDK code, so it is maybe better to mark clearly which VM implementation intrinsifies an annotated method. So, the current design would require introducing a similar annotation for every VM that decided to implement what we just proposed for HotSpot with the current changeset. Thank you and best regards, Zoltan > > Andrew. From goetz.lindenmaier at sap.com Mon Jun 29 10:44:35 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 29 Jun 2015 10:44:35 +0000 Subject: RFR(S): 8130036: Fix problems with imprecise C++ coding. In-Reply-To: <55910F28.2050400@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2D000B06@DEWDFEMB12A.global.corp.sap> <55910F28.2050400@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2D000BE7@DEWDFEMB12A.global.corp.sap> Thanks David! Best regards, Goetz. -----Original Message----- From: David Holmes [mailto:david.holmes at oracle.com] Sent: Montag, 29. Juni 2015 11:26 To: Lindenmaier, Goetz; HotSpot Developers Cc: Zeller, Arno Subject: Re: RFR(S): 8130036: Fix problems with imprecise C++ coding. Hi Goetz, Good catches! If no-one steps in overnight I'll take care of this in my morning. Thanks, David On 29/06/2015 6:30 PM, Lindenmaier, Goetz wrote: > Hi, > > > > We detected some minor, but obviously wrong coding issues we would like to fix. > > > > In two places {} are missing after an if, whilst there are two statements that depend > > on the condition (CHECK macro expands to another statement). > > > > In compilerOracle.cpp, a wrong size is passed to jio_snprintf(). > > > > Please review this change. I please need a sponsor. > > http://cr.openjdk.java.net/~goetz/webrevs/8130036_blocks/webrev.01/8130036_blocks-hs-rt.changeset > > > > Best regards, > > Goetz. > > Sorry for the resend, the subject was missing ... > From aph at redhat.com Mon Jun 29 12:15:21 2015 From: aph at redhat.com (Andrew Haley) Date: Mon, 29 Jun 2015 13:15:21 +0100 Subject: Sign-extending 32-bit operands in adapters [Was: [aarch64-port-dev ] RFR: 8129426: aarch64: add support for PopCount in C2] In-Reply-To: <5589308C.6000309@redhat.com> References: <1434979401.21282.31.camel@mint> <558815DA.8020500@redhat.com> <1434985182.21282.34.camel@mint> <558823FD.5080800@redhat.com> <558829D2.4000503@redhat.com> <55882C94.7030505@redhat.com> <55882ECC.8030602@redhat.com> <5588313C.1070409@redhat.com> <5588345A.4060708@redhat.com> <5589308C.6000309@redhat.com> Message-ID: <559136D9.5000801@redhat.com> Here's a snippet from gen_i2c_adapter where we sign extend: if (!r_2->is_valid()) { // sign extend??? __ ldrsw(rscratch2, Address(esp, ld_off)); __ str(rscratch2, Address(sp, st_off)); but in another place we don't sign extend: // sign extend and use a full word? __ ldrw(r, Address(esp, ld_off)); } So, we sign extend when our argument is passed to compiled code in memory, but zero extend when it is passed in a register. The confusion (and those comments) about what should happen seems to come from the x86 code. I think we've agreed that we should zero extend, but I'm still far from convinced that we should ever use an input operand in any mode other than its natural size. Andrew. From doug.simon at oracle.com Mon Jun 29 12:38:12 2015 From: doug.simon at oracle.com (Doug Simon) Date: Mon, 29 Jun 2015 14:38:12 +0200 Subject: [9] RFR(M): 8076112: Add @HotSpotIntrinsicCandidate annotation to indicate methods for which Java Runtime has intrinsics In-Reply-To: <559120C8.5070208@oracle.com> References: <558BEABD.7090907@oracle.com> <558E594E.7080906@redhat.com> <559112D1.5000903@oracle.com> <559113BB.1020106@redhat.com> <559120C8.5070208@oracle.com> Message-ID: > On Jun 29, 2015, at 12:41 PM, Zolt?n Maj? wrote: > > Hi, > > > On 06/29/2015 11:45 AM, Andrew Haley wrote: >> Hi, >> >> On 29/06/15 10:41, Zolt?n Maj? wrote: >>> On 06/27/2015 10:05 AM, Andrew Haley wrote: >>>> On 25/06/15 12:49, Zolt?n Maj? wrote: >>>>> Problem: There is need to indicate Java methods that are potentially >>>>> intrinsified by JVM. >>>> It's a great idea but is it a good name? HotSpot is not the only Java >>>> VM. Do we expect people from to come along and add >>>> J9IntrinsicCandidate, CACAOIntrinsicCandidate, and so on? >>> thank you bringing up this issue. >>> >>> The name HotSpotIntrinsicCandidate resulted from a private discussion >>> with Joe Darcy, Brian Goetz, and John Rose. The reason this name was >>> picked is to make clear that a marked method's interaction with the VM >>> (specifically with the HotSpot VM implementation) needs special attention. >> OK, cool. So has any thought been given to the other VMs? Do you >> expect that, say, J9 will use the HotSpotIntrinsicCandidate >> annotattion, or do you expect we will have similar annotations for >> each VM which uses OpenJDK libraries? Or is the need for this >> annotation totally HotSpot-specific? > > the need for this annotation resulted from the way HotSpot handles intrinsics. Here are the two main reasons: > > (1) Intrinsics in the HotSpot VM omit some checks (typically null checks and array bounds checks) that are instead performed in the JDK code. If HotSpot intrinsic code is changed, the matching JDK code must be changed as well (and vice versa). Otherwise we might run into correctness problems (e.g., the HotSpot intrinsic and the JDK method have different semantics) and/or performance problems (HotSpot suddenly not intrinsify a method because, e.g., the method's signature has changed and HotSpot's intrinsic list was not updated accordingly). Annotating intrinsified methods makes it less likely that a "mismatch" between a JDK method and its HotSpot-level intrinsic counterpart can be introduced. I seems just plain wrong for an intrinsic to not implement the same semantics as the intrinsified method. I would expect an intrinsic to perform all necessary runtime checks and only have the compiler omit them if it can prove they are unnecessary. If all intrinsics obeyed this contract, then there?s no need for the @HotSpotIntrinsicCandidate annotation from a semantics perspective. And in terms of the keeping HotSpot in sync with the JDK, the responsibility should fall entirely on HotSpot to check that its intrinsics correspond to existing methods. > (2) With the newly added CheckIntrinsic flag, HotSpot verifies if all annotated methods are backed by intrinsics at the VM level and that all intrinsics are marked appropriately in the JDK. > > Other VM implementations will most likely intrinsify a different set of methods. So, if those methods were marked with the same annotation as HotSpot is looking for, it would be difficult for HotSpot to check the match between intrinsics and the JDK code they replace (Reason 2 from above). Also, if a JDK method is updated for which VM_A but not VM_B defines and intrinsic, only VM A's intrinsic code must be updated to match the JDK code, so it is maybe better to mark clearly which VM implementation intrinsifies an annotated method. > > So, the current design would require introducing a similar annotation for every VM that decided to implement what we just proposed for HotSpot with the current changeset. That is true which is a great reason to avoid an annotation altogether if possible. -Doug From goetz.lindenmaier at sap.com Mon Jun 29 12:46:42 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 29 Jun 2015 12:46:42 +0000 Subject: Sign-extending 32-bit operands in adapters [Was: [aarch64-port-dev ] RFR: 8129426: aarch64: add support for PopCount in C2] In-Reply-To: <559136D9.5000801@redhat.com> References: <1434979401.21282.31.camel@mint> <558815DA.8020500@redhat.com> <1434985182.21282.34.camel@mint> <558823FD.5080800@redhat.com> <558829D2.4000503@redhat.com> <55882C94.7030505@redhat.com> <55882ECC.8030602@redhat.com> <5588313C.1070409@redhat.com> <5588345A.4060708@redhat.com> <5589308C.6000309@redhat.com> <559136D9.5000801@redhat.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2D000CA6@DEWDFEMB12A.global.corp.sap> Hi Andrew, I have an off-topic question that touches this issue: You have CCallingConventionRequiresIntsAsLongs set to true. We once introduced this, because we have to sign-extend all ints and place them in long slots for PPC C calling conventions. If this is set, we do the cast in the frontend, and the i2l nodes can be optimized, and we don't need to do it in the native wrapper. Unfortunately, there are more and more intrinsics with explicitly constructed calls. We have to adapt these in the frontend, which causes not that nice shared changes. I think about doing the i2l cast right in the native wrapper. There, the cast will always be necessary, i.e., it's not optimized, but that's not really performance relevant. So basically I could remove the code guarded by CCallingConventionRequiresIntsAsLongs, except for that you use it ... But as I read the aarch code, it's not really necessary. You pass ints in small slots, anyways. So do you rely on that code? Best regards, Goetz. -----Original Message----- From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Andrew Haley Sent: Montag, 29. Juni 2015 14:15 To: Andrew Dinn; edward.nevill at gmail.com Cc: hotspot-dev at openjdk.java.net; aarch64-port-dev at openjdk.java.net Subject: Sign-extending 32-bit operands in adapters [Was: [aarch64-port-dev ] RFR: 8129426: aarch64: add support for PopCount in C2] Here's a snippet from gen_i2c_adapter where we sign extend: if (!r_2->is_valid()) { // sign extend??? __ ldrsw(rscratch2, Address(esp, ld_off)); __ str(rscratch2, Address(sp, st_off)); but in another place we don't sign extend: // sign extend and use a full word? __ ldrw(r, Address(esp, ld_off)); } So, we sign extend when our argument is passed to compiled code in memory, but zero extend when it is passed in a register. The confusion (and those comments) about what should happen seems to come from the x86 code. I think we've agreed that we should zero extend, but I'm still far from convinced that we should ever use an input operand in any mode other than its natural size. Andrew. From aph at redhat.com Mon Jun 29 12:54:38 2015 From: aph at redhat.com (Andrew Haley) Date: Mon, 29 Jun 2015 13:54:38 +0100 Subject: Sign-extending 32-bit operands in adapters [Was: [aarch64-port-dev ] RFR: 8129426: aarch64: add support for PopCount in C2] In-Reply-To: <4295855A5C1DE049A61835A1887419CC2D000CA6@DEWDFEMB12A.global.corp.sap> References: <1434979401.21282.31.camel@mint> <558815DA.8020500@redhat.com> <1434985182.21282.34.camel@mint> <558823FD.5080800@redhat.com> <558829D2.4000503@redhat.com> <55882C94.7030505@redhat.com> <55882ECC.8030602@redhat.com> <5588313C.1070409@redhat.com> <5588345A.4060708@redhat.com> <5589308C.6000309@redhat.com> <559136D9.5000801@redhat.com> <4295855A5C1DE049A61835A1887419CC2D000CA6@DEWDFEMB12A.global.corp.sap> Message-ID: <5591400E.9090702@redhat.com> On 06/29/2015 01:46 PM, Lindenmaier, Goetz wrote: > So basically I could remove the code guarded by CCallingConventionRequiresIntsAsLongs, > except for that you use it ... > But as I read the aarch code, it's not really necessary. You pass ints in small slots, anyways. > So do you rely on that code? Could you please point me to exactly the code you are talking about which we use? Andrew. From aph at redhat.com Mon Jun 29 13:00:29 2015 From: aph at redhat.com (Andrew Haley) Date: Mon, 29 Jun 2015 14:00:29 +0100 Subject: [aarch64-port-dev ] Sign-extending 32-bit operands in adapters [Was: RFR: 8129426: aarch64: add support for PopCount in C2] In-Reply-To: <5591400E.9090702@redhat.com> References: <1434979401.21282.31.camel@mint> <558815DA.8020500@redhat.com> <1434985182.21282.34.camel@mint> <558823FD.5080800@redhat.com> <558829D2.4000503@redhat.com> <55882C94.7030505@redhat.com> <55882ECC.8030602@redhat.com> <5588313C.1070409@redhat.com> <5588345A.4060708@redhat.com> <5589308C.6000309@redhat.com> <559136D9.5000801@redhat.com> <4295855A5C1DE049A61835A1887419CC2D000CA6@DEWDFEMB12A.global.corp.sap> <5591400E.9090702@redhat.com> Message-ID: <5591416D.7000804@redhat.com> On 06/29/2015 01:54 PM, Andrew Haley wrote: > On 06/29/2015 01:46 PM, Lindenmaier, Goetz wrote: >> So basically I could remove the code guarded by CCallingConventionRequiresIntsAsLongs, >> except for that you use it ... >> But as I read the aarch code, it's not really necessary. You pass ints in small slots, anyways. >> So do you rely on that code? > > Could you please point me to exactly the code you are talking about > which we use? Or is it simply that we set CCallingConventionRequiresIntsAsLongs = true? We don't need to do that. Andrew. From aph at redhat.com Mon Jun 29 13:01:55 2015 From: aph at redhat.com (Andrew Haley) Date: Mon, 29 Jun 2015 14:01:55 +0100 Subject: [9] RFR(M): 8076112: Add @HotSpotIntrinsicCandidate annotation to indicate methods for which Java Runtime has intrinsics In-Reply-To: References: <558BEABD.7090907@oracle.com> <558E594E.7080906@redhat.com> <559112D1.5000903@oracle.com> <559113BB.1020106@redhat.com> <559120C8.5070208@oracle.com> Message-ID: <559141C3.7000909@redhat.com> On 06/29/2015 01:38 PM, Doug Simon wrote: > I seems just plain wrong for an intrinsic to not implement the same > semantics as the intrinsified method. I would expect an intrinsic to > perform all necessary runtime checks and only have the compiler omit > them if it can prove they are unnecessary. If all intrinsics obeyed > this contract, then there?s no need for the > @HotSpotIntrinsicCandidate annotation from a semantics > perspective. And in terms of the keeping HotSpot in sync with the > JDK, the responsibility should fall entirely on HotSpot to check > that its intrinsics correspond to existing methods. Don't you think you're being rather idealistic? The other side of the argument is that it's much easier to write and maintain the arg-checking code if it's written in Java, and it also has the advantage that it benefits from profile data to guide the JIT. Andrew. From goetz.lindenmaier at sap.com Mon Jun 29 13:04:33 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 29 Jun 2015 13:04:33 +0000 Subject: [aarch64-port-dev ] Sign-extending 32-bit operands in adapters [Was: RFR: 8129426: aarch64: add support for PopCount in C2] In-Reply-To: <5591416D.7000804@redhat.com> References: <1434979401.21282.31.camel@mint> <558815DA.8020500@redhat.com> <1434985182.21282.34.camel@mint> <558823FD.5080800@redhat.com> <558829D2.4000503@redhat.com> <55882C94.7030505@redhat.com> <55882ECC.8030602@redhat.com> <5588313C.1070409@redhat.com> <5588345A.4060708@redhat.com> <5589308C.6000309@redhat.com> <559136D9.5000801@redhat.com> <4295855A5C1DE049A61835A1887419CC2D000CA6@DEWDFEMB12A.global.corp.sap> <5591400E.9090702@redhat.com> <5591416D.7000804@redhat.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2D000CEC@DEWDFEMB12A.global.corp.sap> Yes, right, that's what I mean. So I'll remove it. Best regards, Goetz. -----Original Message----- From: Andrew Haley [mailto:aph at redhat.com] Sent: Montag, 29. Juni 2015 15:00 To: Lindenmaier, Goetz; Andrew Dinn; edward.nevill at gmail.com Cc: hotspot-dev at openjdk.java.net; aarch64-port-dev at openjdk.java.net Subject: Re: [aarch64-port-dev ] Sign-extending 32-bit operands in adapters [Was: RFR: 8129426: aarch64: add support for PopCount in C2] On 06/29/2015 01:54 PM, Andrew Haley wrote: > On 06/29/2015 01:46 PM, Lindenmaier, Goetz wrote: >> So basically I could remove the code guarded by CCallingConventionRequiresIntsAsLongs, >> except for that you use it ... >> But as I read the aarch code, it's not really necessary. You pass ints in small slots, anyways. >> So do you rely on that code? > > Could you please point me to exactly the code you are talking about > which we use? Or is it simply that we set CCallingConventionRequiresIntsAsLongs = true? We don't need to do that. Andrew. From christian.thalinger at oracle.com Mon Jun 29 15:10:46 2015 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 29 Jun 2015 08:10:46 -0700 Subject: Result: New HotSpot Group Lead: Vladimir Kozlov Message-ID: Voting for HotSpot Group Lead Vladimir Kozlov [1] is now closed. Yes: 24 No: 0 Abstain: 0 According to the Bylaws definition of Simple Majority, this is sufficient to approve the new Group Lead. The OpenJDK Lead will ask the Governing Board to ratify this nomination. Christian Thalinger [1] http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-June/018973.html From kim.barrett at oracle.com Mon Jun 29 16:23:16 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 29 Jun 2015 12:23:16 -0400 Subject: RFR(S): 8130036: Fix problems with imprecise C++ coding. In-Reply-To: <4295855A5C1DE049A61835A1887419CC2D000B06@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2D000B06@DEWDFEMB12A.global.corp.sap> Message-ID: <694C986A-3C22-44CA-AD5B-4B78939EDE44@oracle.com> On Jun 29, 2015, at 4:30 AM, Lindenmaier, Goetz wrote: > > Hi, > > > > We detected some minor, but obviously wrong coding issues we would like to fix. > > > > In two places {} are missing after an if, whilst there are two statements that depend > > on the condition (CHECK macro expands to another statement). > > > > In compilerOracle.cpp, a wrong size is passed to jio_snprintf(). > > > > Please review this change. I please need a sponsor. > > http://cr.openjdk.java.net/~goetz/webrevs/8130036_blocks/webrev.01/8130036_blocks-hs-rt.changeset > > > > Best regards, > > Goetz. > > Sorry for the resend, the subject was missing ... Looks good. From doug.simon at oracle.com Mon Jun 29 17:48:46 2015 From: doug.simon at oracle.com (Doug Simon) Date: Mon, 29 Jun 2015 19:48:46 +0200 Subject: [9] RFR(M): 8076112: Add @HotSpotIntrinsicCandidate annotation to indicate methods for which Java Runtime has intrinsics In-Reply-To: <559141C3.7000909@redhat.com> References: <558BEABD.7090907@oracle.com> <558E594E.7080906@redhat.com> <559112D1.5000903@oracle.com> <559113BB.1020106@redhat.com> <559120C8.5070208@oracle.com> <559141C3.7000909@redhat.com> Message-ID: <9CDED78E-AC52-444C-95E0-6453D6E8D86C@oracle.com> > On Jun 29, 2015, at 3:01 PM, Andrew Haley wrote: > > On 06/29/2015 01:38 PM, Doug Simon wrote: > >> I seems just plain wrong for an intrinsic to not implement the same >> semantics as the intrinsified method. I would expect an intrinsic to >> perform all necessary runtime checks and only have the compiler omit >> them if it can prove they are unnecessary. If all intrinsics obeyed >> this contract, then there?s no need for the >> @HotSpotIntrinsicCandidate annotation from a semantics >> perspective. And in terms of the keeping HotSpot in sync with the >> JDK, the responsibility should fall entirely on HotSpot to check >> that its intrinsics correspond to existing methods. > > Don't you think you're being rather idealistic? The other side of the > argument is that it's much easier to write and maintain the > arg-checking code if it's written in Java, and it also has the > advantage that it benefits from profile data to guide the JIT. As I understand it, part of this change is to split intrinsification into one method that does the checks that then calls a second method which the VM may intrinsify on the assumption all checks have been performed by the first method. What?s to prevent a direct call to the latter via reflection that by-passes the first method? I understand that writing the checking logic in Java is desirable. Indeed, it?s possible: http://hg.openjdk.java.net/graal/graal/file/tip/graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/AESCryptSubstitutions.java#l95 Adding these checks did not impact the score for the SPECjvm2008 crypto.aes benchmark on Graal. I?m not sure if this performance non-impact holds for all existing intrinsics but unless one can guarantee an intrinsified method will only be executed after the necessary checks have been performed, one is asking for trouble. Maybe hiding the intrinsifiable methods from reflection is sufficient? -Doug From john.r.rose at oracle.com Mon Jun 29 20:47:41 2015 From: john.r.rose at oracle.com (John Rose) Date: Mon, 29 Jun 2015 13:47:41 -0700 Subject: [9] RFR(M): 8076112: Add @HotSpotIntrinsicCandidate annotation to indicate methods for which Java Runtime has intrinsics In-Reply-To: <9CDED78E-AC52-444C-95E0-6453D6E8D86C@oracle.com> References: <558BEABD.7090907@oracle.com> <558E594E.7080906@redhat.com> <559112D1.5000903@oracle.com> <559113BB.1020106@redhat.com> <559120C8.5070208@oracle.com> <559141C3.7000909@redhat.com> <9CDED78E-AC52-444C-95E0-6453D6E8D86C@oracle.com> Message-ID: On Jun 29, 2015, at 10:48 AM, Doug Simon wrote: > > As I understand it, part of this change is to split intrinsification into one method that does the checks that then calls a second method which the VM may intrinsify on the assumption all checks have been performed by the first method. What?s to prevent a direct call to the latter via reflection that by-passes the first method? The answer is simple: We mark the dangerous method private. I assume you are thinking about setAccessible, but if that's allowed there's nothing to prevent people from taking whole system down in a hundred different ways. At that point having a surprising intrinsic is the least of our problems. > I understand that writing the checking logic in Java is desirable. Indeed, that is the key compromise here. Coding the required checks in assembly code or compiler IR is (as we all know) a losing battle. You need Maxine/Graal snippets or real Java code to get it right. ? John From doug.simon at oracle.com Tue Jun 30 06:17:00 2015 From: doug.simon at oracle.com (Doug Simon) Date: Tue, 30 Jun 2015 08:17:00 +0200 Subject: [9] RFR(M): 8076112: Add @HotSpotIntrinsicCandidate annotation to indicate methods for which Java Runtime has intrinsics In-Reply-To: References: <558BEABD.7090907@oracle.com> <558E594E.7080906@redhat.com> <559112D1.5000903@oracle.com> <559113BB.1020106@redhat.com> <559120C8.5070208@oracle.com> <559141C3.7000909@redhat.com> <9CDED78E-AC52-444C-95E0-6453D6E8D86C@oracle.com> Message-ID: <9BC916B0-B9CF-42F7-8D94-BCF2AA351FA8@oracle.com> > On Jun 29, 2015, at 10:47 PM, John Rose wrote: > > On Jun 29, 2015, at 10:48 AM, Doug Simon wrote: >> >> As I understand it, part of this change is to split intrinsification into one method that does the checks that then calls a second method which the VM may intrinsify on the assumption all checks have been performed by the first method. What?s to prevent a direct call to the latter via reflection that by-passes the first method? > > The answer is simple: We mark the dangerous method private. > > I assume you are thinking about setAccessible, but if that's allowed there's nothing to prevent people from taking whole system down in a hundred different ways. At that point having a surprising intrinsic is the least of our problems. Ok, thanks for the clarification John. I?ll admit to occasionally forgetting that setAccessible is as unsafe as, well, Unsafe. >> I understand that writing the checking logic in Java is desirable. > > Indeed, that is the key compromise here. Coding the required checks in assembly code or compiler IR is (as we all know) a losing battle. You need Maxine/Graal snippets or real Java code to get it right. Snippets certainly make it easier. I?m surprised though that existing C2 IR logic for expressing runtime checks cannot be easily leveraged for some intrinsics. My perspective may shift rapidly though were I tasked with doing it ;-) -Doug From goetz.lindenmaier at sap.com Tue Jun 30 07:28:04 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 30 Jun 2015 07:28:04 +0000 Subject: RFR(S): 8130036: Fix problems with imprecise C++ coding. In-Reply-To: <694C986A-3C22-44CA-AD5B-4B78939EDE44@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2D000B06@DEWDFEMB12A.global.corp.sap> <694C986A-3C22-44CA-AD5B-4B78939EDE44@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2D000E8D@DEWDFEMB12A.global.corp.sap> Thanks! Best regards, Goetz. -----Original Message----- From: Kim Barrett [mailto:kim.barrett at oracle.com] Sent: Montag, 29. Juni 2015 18:23 To: Lindenmaier, Goetz Cc: HotSpot Developers; Zeller, Arno Subject: Re: RFR(S): 8130036: Fix problems with imprecise C++ coding. On Jun 29, 2015, at 4:30 AM, Lindenmaier, Goetz wrote: > > Hi, > > > > We detected some minor, but obviously wrong coding issues we would like to fix. > > > > In two places {} are missing after an if, whilst there are two statements that depend > > on the condition (CHECK macro expands to another statement). > > > > In compilerOracle.cpp, a wrong size is passed to jio_snprintf(). > > > > Please review this change. I please need a sponsor. > > http://cr.openjdk.java.net/~goetz/webrevs/8130036_blocks/webrev.01/8130036_blocks-hs-rt.changeset > > > > Best regards, > > Goetz. > > Sorry for the resend, the subject was missing ... Looks good. From goetz.lindenmaier at sap.com Tue Jun 30 07:28:28 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 30 Jun 2015 07:28:28 +0000 Subject: RFR(S): 8130036: Fix problems with imprecise C++ coding. In-Reply-To: <55910F28.2050400@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2D000B06@DEWDFEMB12A.global.corp.sap> <55910F28.2050400@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2D000E9C@DEWDFEMB12A.global.corp.sap> Hi David, thanks for pushing it! Best regards, Goetz. -----Original Message----- From: David Holmes [mailto:david.holmes at oracle.com] Sent: Montag, 29. Juni 2015 11:26 To: Lindenmaier, Goetz; HotSpot Developers Cc: Zeller, Arno Subject: Re: RFR(S): 8130036: Fix problems with imprecise C++ coding. Hi Goetz, Good catches! If no-one steps in overnight I'll take care of this in my morning. Thanks, David On 29/06/2015 6:30 PM, Lindenmaier, Goetz wrote: > Hi, > > > > We detected some minor, but obviously wrong coding issues we would like to fix. > > > > In two places {} are missing after an if, whilst there are two statements that depend > > on the condition (CHECK macro expands to another statement). > > > > In compilerOracle.cpp, a wrong size is passed to jio_snprintf(). > > > > Please review this change. I please need a sponsor. > > http://cr.openjdk.java.net/~goetz/webrevs/8130036_blocks/webrev.01/8130036_blocks-hs-rt.changeset > > > > Best regards, > > Goetz. > > Sorry for the resend, the subject was missing ... > From zoltan.majo at oracle.com Tue Jun 30 08:24:34 2015 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Tue, 30 Jun 2015 10:24:34 +0200 Subject: [9] RFR(M): 8076112: Add @HotSpotIntrinsicCandidate annotation to indicate methods for which Java Runtime has intrinsics In-Reply-To: References: <558BEABD.7090907@oracle.com> <558E594E.7080906@redhat.com> <559112D1.5000903@oracle.com> <559113BB.1020106@redhat.com> <559120C8.5070208@oracle.com> <559141C3.7000909@redhat.com> <9CDED78E-AC52-444C-95E0-6453D6E8D86C@oracle.com> Message-ID: <55925242.4070909@oracle.com> On 06/29/2015 10:47 PM, John Rose wrote: > On Jun 29, 2015, at 10:48 AM, Doug Simon > wrote: >> >> As I understand it, part of this change is to split intrinsification >> into one method that does the checks that then calls a second method >> which the VM may intrinsify on the assumption all checks have been >> performed by the first method. What?s to prevent a direct call to the >> latter via reflection that by-passes the first method? > > The answer is simple: We mark the dangerous method private. > > I assume you are thinking about setAccessible, but if that's allowed > there's nothing to prevent people from taking whole system down in a > hundred different ways. At that point having a surprising intrinsic > is the least of our problems. > >> I understand that writing the checking logic in Java is desirable. > > Indeed, that is the key compromise here. Coding the required checks > in assembly code or compiler IR is (as we all know) a losing battle. > You need Maxine/Graal snippets or real Java code to get it right. Thank you, Doug, for bringing up these issues. Thank you, John, for the clarifications. Best regards, Zoltan > > ? John From dmitry.dmitriev at oracle.com Tue Jun 30 13:17:45 2015 From: dmitry.dmitriev at oracle.com (Dmitry Dmitriev) Date: Tue, 30 Jun 2015 16:17:45 +0300 Subject: Rev1 RFR (S): 8112746 Followup to JEP 245: Validate JVM Command-Line Flag Arguments In-Reply-To: <558C798E.6040307@oracle.com> References: <558C798E.6040307@oracle.com> Message-ID: <559296F9.8030704@oracle.com> Hello Gerard, This revision looks good. But I have one concern about new upper range for G1ConcMarkStepDurationMillis which now equal to "DBL_MAX". This value can be very huge. For example, I check it on my Linux-x64 and got value which is more than 300 characters long. Moreover we can not pass that huge value to the JVM since JVM can process only values which less than 256 characters long. Otherwise it will report that option is improperly specified. And also output of "-XX:+PrintFlagsRanges" looks strange with this very long value :) I think that upper range can be lowered for that flag without impacting users. For example we can use very big value for that option, e.g. 10000000000000000000.0 (i.e. something between (double)max_intx and (double)max_uintx). G1ConcMarkStepDurationMillis is a duration in milliseconds, so max value 10000000000000000000.0 will represent duration equal to (((10000000000000000000.0 / 1000) / 3600 seconds) / 24 hours) / 365 days = ~317097919 years. I think that this will be enough for all :) Regards, Dmitry On 26.06.2015 0:58, Gerard Ziemski wrote: > hi all, > > This webrev gets the macro and quotes fix right. > > Please review this followup to my recent JEP 245 checkin. It addresses > the issues raised by Coleen, Dmitry and Kim during webrev. > > You can see https://bugs.openjdk.java.net/browse/JDK-8112746 for > details, but the most important change here is that we only check > constraint if the range check passes first. > > To quickly recap: I changed that part of the code when David pointed > out that I had to modify 2 tests in a way that looked like a > regression - I removed some test cases. However, Kim, later pointed > out that the original code had the advantage of having constraints > guaranteed that the flag values were within ranges. > > I checked in the code with ranges and constraints being checked both > regardless of each other, but this followup restores the original > behavior (and simplifies the code), where we first check ranges and > only check constraints if range passes. > > The 2 tests (ObjectAlignment.java and Options.java) seem to loose some > test cases, but those paths are still tested (though with different > values), so we in fact do not loose anything from test coverage point > of view. > > The change passes JPRT (hotspot) and RBT (vm.quick.testlist) > > > References: > > webrev:http://cr.openjdk.java.net/~gziemski/8112746_rev1 > this issue:https://bugs.openjdk.java.net/browse/JDK-8112746 > JEP 245:https://bugs.openjdk.java.net/browse/JDK-8059557 > > > hg stat: > # hg_stat > src/share/vm/gc/g1/g1_globals.hpp | 4 +- > src/share/vm/runtime/commandLineFlagConstraintsGC.cpp | 5 +- > src/share/vm/runtime/commandLineFlagRangeList.cpp | 58 ++++------ > src/share/vm/runtime/globals.cpp | 129 +++++++++++++---------- > src/share/vm/runtime/globals.hpp | 17 +-- > test/runtime/CompressedOops/ObjectAlignment.java | 3 +- > test/runtime/contended/Options.java | 2 - > 7 files changed, 103 insertions(+), 115 deletions(-) > > > > >