Re: RFR (round 4), JDK-8214259: Implementation: JEP 189: Shenandoah: A Low-Pause Garbage Collector

On Nov 30, 2018, at 3:22 PM, coleen.phillim...@oracle.com wrote: > > Hi, I looked at the runtime changes, which are very few, since you've > upstreamed most of the runtime dependent changes already. > They look good to me. "since you've upstreamed most of the runtime dependent changes already"

Re: RFR 8208183: update HSDIS plugin license to UPL

On Aug 21, 2018, at 9:41 AM, Andrew Haley wrote: > > On 08/21/2018 11:14 AM, Magnus Ihse Bursie wrote: >> Am I correct in understanding that there are no more legal barriers >> towards doing such a thing anymore? > > You'd still be linking GPLv2-only code (libjvm) against GPLv3-or-later > code

Re: RFR: JDK-8198243: Add build time check for global operator new/delete in object files

On Feb 22, 2018, at 11:41 AM, Erik Joelsson wrote: > > We could grep for the mangled strings for the operators instead, which is > super fast. Problem is just figuring out all the possible combinations. Idea: Do a config-style move where you compile a test file of C++ code, strip out all the n

Re: RFR 8167227: Simplify the JDK 9 API-specification overview page (docs only)

On Jun 18, 2017, at 3:47 AM, mark.reinh...@oracle.com wrote: > > Current output, for reference: > http://download.java.net/java/jdk9/docs/api/overview-summary.html > Yes, the language changes are good. (From a non-legal English

Re: .hgignore missing webrevs?

On Sep 11, 2014, at 11:40 AM, Bradford Wetmore wrote: > Thanks, John, I agree. The pattern I will check in will be: > >^webrev > > Thanks, > > Brad > > P.S. Following the OpenJDK codereview directory layout suggestion [1], I > thought about also putting in: > >^[0-9][0-9][0-9][0-

Re: .hgignore missing webrevs?

On Sep 10, 2014, at 4:22 PM, Bradford Wetmore wrote: > My original thought was the former. But I note both are currently being > used, so some people may prefer the latter. I would prefer the more general pattern, to give the user more latitude, and also to make a simpler rule. — John

Re: Symbols in libjvm.so

That topic comes up every so often. This conversation on hotspot-dev in Ferbruary is probably relevant: http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-February/012631.html On Sep 5, 2014, at 1:14 PM, S. Bharadwaj Yadavalli wrote: > Looking at the command that links Hotspot object fi

Re: Thread dump during build with ctrl-\

On Feb 4, 2014, at 10:48 PM, David Holmes wrote: > I don't see how make and all the intervening shells could know to pass the > signal through to the JVM process. ?? IIRC they don't need to pass the signal, because the signal goes from the tty to the current group of processes. A waiting shel

Re: RFR: 8026062 : (s) webrev.ksh: fix bug title web scraping, remove teamware, sac, "open bug" and wxfile support

On Oct 9, 2013, at 3:54 PM, Mike Duigou wrote: > Hello all; > > This changeset revisits webrev's integration with bugs.openjdk.java.net to > correct problems with the scraping of bug titles from jbs html. I also > eliminated the now obsolete "-O" option since bugs are now all visible on the >

Re: RFR JDK-8025920 webrev.ksh does not provide any details about changes in zip files

On Oct 4, 2013, at 7:49 AM, Tomas Hurka wrote: > updated webrev: I love it: A meta-webrev. Glad to see this tool getting more attention. — John

Re: Code review request: 8011402: Move blacklisting certificate logic from hard code to data

On Sep 11, 2013, at 6:06 AM, Weijun Wang wrote: > It seems there needs a pair of " around `. Don't why. Maybe it's about the > pipes? This command test `cat /dev/null` != 1 expands after command substitution to a command with two arguments: test != 1 That gets a complaint from test. If y

Re: AdapterMethodHandle not found

On May 3, 2013, at 8:42 AM, Pete Brunet wrote: > Error occurred during initialization of VM > java/lang/NoClassDefFoundError: java/lang/invoke/AdapterMethodHandle It's a micro-version mismatch, from running a down-rev JVM on an up-rev rt.jar (JDK). But I don't understand why your makefile is

Re: RFR (M): 8008772: remove gamma launcher

On May 2, 2013, at 4:44 PM, Christian Thalinger wrote: > is anyone using env.{sh,csh}? I'll suggest that the answer is going to be "no". I think very few people have ever used them. — John

Re: RFR: 8004823: Add VM support for type annotation reflection

This is good work. You can count me as a reviewer. One comment: There are a couple of places where a field index is used as an annotation array index (one old one new). I think it would be best to put an explicit range check like this: - if (md == NULL) + if (md == NULL || index() >= md->l

Re: Need reviewer on addition of whitespace normalizer script

Lest Kelly have all the fun, I'll jump in. On Mar 3, 2012, at 3:36 AM, David Holmes wrote: > So the question is: what does the script think a TAB represents? The same thing that /usr/bin/expand does, as noted earlier. Or read the perl code. When was the last time anybody on the hotspot team u

Re: JDK8 Preliminary Repository Layout

On Apr 28, 2011, at 2:48 AM, Fredrik Öhrström wrote: > I think it is much better to use the rebase extension to do > hg pull --rebase Repo history is simplified if individual developers (a) delay commits and merges and (b) minimize private merges. For my part, I use mq to manage my bug fixes i

Re: OpenJDK Build Procedures

On Feb 7, 2011, at 9:37 AM, Kelly O'Hair wrote: > It is critical that all changes to the OpenJDK build process, as defined in > the existing Makefiles, be reviewed > by the Build Infrastructure Group (http://openjdk.java.net/groups/build/) via > the build-dev@openjdk.java.net > mailing list prio

Re: JDK build questions

On Apr 16, 2010, at 1:55 PM, Kelly O'Hair wrote: > So often the raw performance comes down to the VM generated code Yes, that's the main story. Performance is strongly determined by code generated by the dynamic compiler (aka "JIT"). C++-generated instructions are rarely executed, apart from t

Re: printf errors compiling with new gcc

We talked about this on the bsd-port mailing list. It may be due to new error checks in GCC 4.2. On Mac, even after those compile-time errors are fixed, GCC 4.2 does not build a usable hotspot. After upgrading to Snow Leopard (10.6), I had to back the gcc to 4.0 for building hotspot. HT

Re: How to speed up Hotspot Build

On Feb 7, 2009, at 7:47 PM, Erik Trimble wrote: Just for reference, here's some comparative data: Here at Sun, on a dual 2.2Ghz Opteron w/ 4gb of RAM, it takes around 30 minutes to do a build. Those settings work for my laptop, too. HotSpot (alone) builds in under 30 minutes. I run JVM

Re: Howto re-compile ony parts?

On May 12, 2008, at 8:53 AM, Kelly O'Hair wrote: The HOTSPOT_BUILD_JOBS=N is for hotspot only and I don't have many details on this one, it's been around for a long time. As I understand it, this is more of a top level 'make -j N'. Yes. It is the environmental input to adjust-mflags.sh ; se

Re: Is 'optimized' a legit target?

Yes, 'optimized' is legit. It supports more flags, for tuning experiments, etc. Its performance characteristics are closer to product, because it omits all the 'assert' code, Here are the various build subdirectories, in brief: product -- hardwires many flag values, no asserts, code is optimi

Re: Extending the pattern list in .hgignore to exclude webrev directories

Please also check out (and refactor, steal, cross-link, or modify): http://wikis.sun.com/display/SunOnMac/MercurialTips -- John On Feb 1, 2008, at 8:40 AM, Mark Reinhold wrote: A better way to do this is to add the following to your ~/.hgrc: [ui] ignore = ~/.hgignore Then you can a

Re: Quick confirmation

On Jan 25, 2008, at 7:44 AM, Max (Weijun) Wang wrote: Is your webrev page above a custom script or is that possible with mercurial mq directly? Aha, our precious webrev, the latest version is at -- http://cvs.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/tools/ scripts/webrev.sh Whoever

Re: Quick confirmation

On Jan 25, 2008, at 2:20 AM, Volker Simonis wrote: I've also noticed that there are no updates in the Mercurial repositories since the inital b24 upload. Is this because of the distributed nature of mercurial and the fact that every team inside SUN keeps their own, private repositories? Yes an