Re: RFR: 8288396: Always create reproducible builds [v2]

On Tue, 14 Jun 2022 10:09:37 GMT, Magnus Ihse Bursie wrote: >> When we started introducing some possibly more intrusive compiler flags and >> functionality for reproducible builds, we also introduced a flag to turn >> this off out of an abundance of caution. But we have been been using this

Re: RFR: 8287894: Use fixed timestamp as an alternative of __DATE__ macro in jdk.jdi to make Windows build reproducible

On Tue, 7 Jun 2022 19:57:48 GMT, Alexey Pavlyutkin wrote: > Hi! > > Here is a fix to jdk.jdi that fixes reproducible build for Windows. The idea > of the fix is to re-use value of --with-hotspot-build-time option to generate > deterministic timestamp exactly like it's done to hotspot

Re: RFR: 8287254: Clean up Xcode sysroot logic

On Tue, 24 May 2022 17:09:10 GMT, Magnus Ihse Bursie wrote: > The logic in BASIC_SETUP_DEVKIT for setting a correct sysroot for Xcode is > hard to follow. This should be straightened out. We also expose variables > that are no longer used. So there's a bit of related cleanup. > > The new

Re: RFR: 8244681: Add a warning for possibly lossy conversion in compound assignments

On Mon, 9 May 2022 15:56:35 GMT, Adam Sotona wrote: > Please review this patch adding new lint option, **lossy-conversions**, to > javac to warn about type casts in compound assignments with possible lossy > conversions. > > The new lint warning is shown if the type of the right-hand operand

Re: RFR: 8284891: Fix typos in build system files

On Thu, 14 Apr 2022 16:05:48 GMT, Magnus Ihse Bursie wrote: > I ran `codespell` on the `make` directory, and accepted those changes where > it indeed discovered real typos. > > (Due to false positives this can unfortunately not be run automatically) > > Most of the fixes are in comments. A

Re: RFR: 8282657: Code cleanup: removing double semicolons at the end of lines

On Sat, 5 Mar 2022 06:49:16 GMT, Julian Waters wrote: > Should I change the JBS issue title to match the PR title, or is it preferred > for the PR title to change? They need to match. You can either do it manually, or change the title to just the bug number and the bot will change it for you.

Re: RFR: 8202056: Expand serial warning to check for bad overloads of serial-related methods and ineffectual fields

On Mon, 27 Sep 2021 01:00:18 GMT, Joe Darcy wrote: > This is an initial PR for expanded lint warnings done under two bugs: > > 8202056: Expand serial warning to check for bad overloads of serial-related > methods and ineffectual fields > 8160675: Issue lint warning for non-serializable

Re: RFR: 8272805: Avoid looking up standard charsets [v2]

On Sun, 22 Aug 2021 23:02:06 GMT, Sergey Bylokhov wrote: >> This is the continuation of JDK-8233884, JDK-8271456, and JDK-8272120. >> >> In many places standard charsets are looked up via their names, for example: >> absolutePath.getBytes("UTF-8"); >> >> This could be done more efficiently(up

Re: [jdk17] RFR: 8268630: ProblemList serviceability/jvmti/CompiledMethodLoad/Zombie.java on linux-aarch64

On Fri, 11 Jun 2021 20:11:12 GMT, Daniel D. Daugherty wrote: > Target is JDK17: > A trivial fix to ProblemList > serviceability/jvmti/CompiledMethodLoad/Zombie.java on linux-aarch64. Marked as reviewed by erikj (Reviewer). - PR: https://git.openjdk.java.net/jdk17/pull/33

Re: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal

On Mon, 17 May 2021 18:23:41 GMT, Weijun Wang wrote: > Please review this implementation of [JEP > 411](https://openjdk.java.net/jeps/411). > > The code change is divided into 3 commits. Please review them one by one. > > 1. >

Re: RFR: 8264805: Remove the experimental Ahead-of-Time Compiler [v4]

On Thu, 8 Apr 2021 17:24:38 GMT, Vladimir Kozlov wrote: >> As part of [JEP 410](http://openjdk.java.net/jeps/410) remove code related >> to Ahead-of-Time Compiler from JDK: >> >> - `jdk.aot` module — the `jaotc` tool >> - `src/hotspot/share/aot` — loads AoT compiled code into VM for

Re: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v29]

On Mon, 22 Mar 2021 12:50:14 GMT, Anton Kozlov wrote: >> Please review the implementation of JEP 391: macOS/AArch64 Port. >> >> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and >> windows/aarch64. >> >> Major changes are in: >> * src/hotspot/cpu/aarch64: support of

Re: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9]

On 2021-02-26 06:37, daniel.daughe...@oracle.com wrote: On 2/26/21 7:55 AM, Vladimir Kempik wrote: On Tue, 2 Feb 2021 23:07:08 GMT, Daniel D. Daugherty wrote: Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision:    support

Re: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v3]

On 2021-01-26 04:44, Magnus Ihse Bursie wrote: On 2021-01-26 13:09, Vladimir Kempik wrote: On Tue, 26 Jan 2021 12:02:02 GMT, Alan Hayward wrote: AIUI, the configure line needs passing a prebuilt JavaNativeFoundation framework ie: `--with-extra-ldflags='-F

Re: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port

On Fri, 22 Jan 2021 18:49:42 GMT, Anton Kozlov wrote: > Please review the implementation of JEP 391: macOS/AArch64 Port. > > It's heavily based on existing ports to linux/aarch64, macos/x86_64, and > windows/aarch64. > > Major changes are in: > * src/hotspot/cpu/aarch64: support of the new

Re: RFR: 8259045: Exception message from saproc.dll is garbled on Windows with Japanese locale

On Mon, 4 Jan 2021 09:25:55 GMT, Yasumasa Suenaga wrote: > I got garbled exception message as following when I run `livenmethods` CLHSDB > command: > > sun.jvm.hotspot.debugger.DebuggerException : ?w???W > > My Windows laptop is set Japanese Locale, garbled message was written in >

Re: RFR: 8257733: Move module-specific data from make to respective module

On Fri, 4 Dec 2020 14:03:08 GMT, Erik Joelsson wrote: >>> And I can certainly move jdwp.spec to java.base instead. >> >> If jdwp.spec has to move to the src tree then src/java.se is probably the >> most suitable home because Java SE specifies JDWP as an optiona

Re: RFR: 8257733: Move module-specific data from make to respective module

On Fri, 4 Dec 2020 12:30:02 GMT, Alan Bateman wrote: >> And I can certainly move jdwp.spec to java.base instead. That's the reason I >> need input on this: All I know is that is definitely not the responsibility >> of the Build Group to maintain that document, and I made my best guess at >>

Re: RFR: 8212879: Make JVMTI TagMap table not hash on oop address

On Fri, 30 Oct 2020 20:23:04 GMT, Coleen Phillimore wrote: > This change turns the HashTable that JVMTI uses for object tagging into a > regular Hotspot hashtable - the one in hashtable.hpp with resizing and > rehashing. Instead of pointing directly to oops so that GC has to walk the >

Re: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v3]

On Mon, 21 Sep 2020 07:10:47 GMT, Bernhard Urban-Forster wrote: >> I assume you need the rest of the PATH on Windows. > >> I assume you need the rest of the PATH on Windows. > > Doesn't look like it actually. I've reverted it, thanks for catching it. Thanks, I tried the updated patch and it

Re: RFR: 8248238: Implementation of JEP: Windows AArch64 Support

On Wed, 16 Sep 2020 20:26:10 GMT, Monica Beckwith wrote: > This is a continuation of > https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009566.html > > Changes since then: > * We've improved the write barrier as suggested by Andrew [1] > * The define-guards around R18 have

Re: RFR: 8248238: Implementation of JEP: Windows AArch64 Support

On Fri, 18 Sep 2020 20:32:36 GMT, Erik Joelsson wrote: >> This is a continuation of >> https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009566.html >> >> Changes since then: >> * We've improved the write barrier as suggested by Andrew [1] >

Re: RFR: 8248238: Implementation of JEP: Windows AArch64 Support

On Fri, 18 Sep 2020 13:33:07 GMT, Erik Joelsson wrote: >> This is a continuation of >> https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009566.html >> >> Changes since then: >> * We've improved the write barrier as suggested by Andrew [1] >

Re: RFR: 8248238: Implementation of JEP: Windows AArch64 Support

On Wed, 16 Sep 2020 20:26:10 GMT, Monica Beckwith wrote: > This is a continuation of > https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009566.html > > Changes since then: > * We've improved the write barrier as suggested by Andrew [1] > * The define-guards around R18 have

Re: RFR: JDK-8247589: Implementation of Alpine Linux/x64 Port

On Mon, 7 Sep 2020 11:23:28 GMT, Aleksei Voitylov wrote: > continuing the review thread from here > https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-September/068546.html > >> The download side of using JNI in these tests is that it complicates the >> setup a bit for those that run

Re: RFR: JDK-8242804 Fix trivial deprecation issues in jdk.hotspot.agent

Looks good. /Erik On 2020-04-15 01:18, Magnus Ihse Bursie wrote: In the quest for getting rid of warning messages in jdk.hotspot.agent, the time has now come for another major source of deprecation messages, that are trivial to fix and might hide more tricky issues. This patch handles the

Re: RFR: JDK-8242629 Remove references to deprecated java.util.Observer and Observable

Hello Magnus, I'll let someone else judge the validity of the approach, though I think it seems ok. src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/GenericGrowableArray.java: Double imports. src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/InstanceKlass.java: Triple

Re: RFR: JDK-8241463 Move build tools to respective modules

Looks good. /Erik On 2020-03-23 12:03, Magnus Ihse Bursie wrote: The build tools (small java tools that are run during the build to generate source code, or data, needed in the JDK) have historically been placed in the "make" directory. This maybe made sense long time ago, but does not do so

Re: serviceability agent : problems when using gcc LTO (link time optimization)

On 2020-01-15 07:29, Volker Simonis wrote: Do you know if newer versions of GCC use the gold linker by default? I remember from some experiments which I did many years ago that gold was considerably faster compared to the default ld linker. The default linker is system configured so it depends

Re: RFR: 8233600: cross-builds fails after JDK-8233285

://cr.openjdk.java.net/~bulasevich/8233600/webrev.00 regards, Boris On 06.11.2019 16:33, Erik Joelsson wrote: I looked closer at it now and the build change is not good. Any toolchain definition with BUILD in the name, like TOOLCHAIN_BUILD_LINK_CXX, is only meant to be used for building tools

Re: RFR: 8233285: Demangling C++ symbols in jhsdb jstack --mixed

I looked closer at it now and the build change is not good. Any toolchain definition with BUILD in the name, like TOOLCHAIN_BUILD_LINK_CXX, is only meant to be used for building tools that are run during the build. I believe the fix is to just remove the "BUILD_". /Erik On 2019-11-06 05:13,

Re: RFR: 8230857: Avoid reflection in sun.tools.common.ProcessHelper

Hello, On 2019-09-17 05:59, David Holmes wrote: Hi Magnus, On 17/09/2019 9:26 pm, Magnus Ihse Bursie wrote: On 2019-09-17 01:01, David Holmes wrote: Hi Christoph, Sorry for the delay getting back you. cc'd build-dev to get some clarification on the below ... On 12/09/2019 7:30 pm, Langer,

Re: RFR: 8214545: sun/management/jmxremote/bootstrap tests hang in revokeall.exe on Windows

Build changes look good. /Erik On 2019-05-19 17:43, David Holmes wrote: Hi Daniil, cc: Boris and Erik J. On 20/05/2019 7:12 am, Daniil Titov wrote: Please review the change that fixes the failure of sun/management/jmxremote/bootstrap JMX tests on Windows platform.  While running, these

Re: RFR: JDK-8223319: Add copyright footer to specs and man pages

, serguei.spit...@oracle.com wrote: Thank you, Erik. Is it the same with the jdwp-protocol.html? If so then I'm Okay with the fix. Thanks, Serguei On 5/3/19 11:50 AM, Erik Joelsson wrote: The new footer looks exactly like on the api docs today. jvmti.html: 36481,36484c36481

Re: RFR: JDK-8223319: Add copyright footer to specs and man pages

ote: Hi Erik, Could you, please, show a simple diff for jvmti.html and jdwp-protocol.html? Thanks, Serguei On 5/3/19 09:37, Erik Joelsson wrote: The (optional) specs and man pages should have the same copyright footer as the generated API docs. This patch adds the logic to add such footers. It also re

Re: RFR: JDK-8223319: Add copyright footer to specs and man pages

removing the footer in jvmit.html, I suspect that you also need to make changes to jvmti.xsl, which was also modified when the copyright footer was inserted in this changeset: http://hg.openjdk.java.net/jdk/jdk/rev/9884b717f2ed Thanks, iris -Original Message- From: Erik Joelsson Sent

RFR: JDK-8223319: Add copyright footer to specs and man pages

The (optional) specs and man pages should have the same copyright footer as the generated API docs. This patch adds the logic to add such footers. It also removes the existing footer in jvmti.html. Bug: https://bugs.openjdk.java.net/browse/JDK-8223319 Webrev:

Re: RFR (S) 8222529: sun.jdwp.listenerAddress agent property uses wrong encoding

Hello, Change looks good. As to why java.lib is not added to JDKLIB_LIBS like -ljava is on other platforms, I don't know, but it's hardly the responsibility of this change to figure that out. /Erik On 2019-04-26 05:21, Langer, Christoph wrote: Hi Gary, fair point. cc-ing build-dev. Can

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

Build changes look ok to me. /Erik On 2018-11-26 13:39, Roman Kennke wrote: Hi, This is the first round of changes for including Shenandoah GC into mainline. I divided the review into parts that roughly correspond to the mailing lists that would normally review it, and I divided it into

Re: [8u] RFR: 8212110: Build of saproc.dll broken on Windows 32 bit after JDK-8210647

Looks good to me. /Erik On 2018-11-15 11:31, Severin Gehwolf wrote: Hi, When the SA optimization fix got backported to JDK 11 a build issue on Windows 32 bit was discovered by SAP. This would be the JDK 8 equivalent for the old build system. Note that the JDK 8 build still uses GZ which is

Re: [8u] RFR: 8210647: libsaproc is being compiled without optimization

Looks ok to me. /Erik On 2018-11-15 06:57, Severin Gehwolf wrote: Hi, Could I please get reviews for this 8u backport of JDK-8210647. Since the build system is different in 8, the patch looks different. For the Windows build changes I've refactored the make file a bit so as to facilitate

Re: RFR: JDK-8212028: Use run-test makefile framework for testing in Oracle's Mach5

On 2018-10-12 01:37, Magnus Ihse Bursie wrote: Hi Erik, Thank you for preserving through this, so we finally can move to 100% run-test! On 2018-10-12 00:29, Erik Joelsson wrote: Hello, (adding serviceability-dev and hotspot-dev for test changes) Bug: https://bugs.openjdk.java.net

RFR: JDK-8212028: Use run-test makefile framework for testing in Oracle's Mach5

Hello, (adding serviceability-dev and hotspot-dev for test changes) Bug: https://bugs.openjdk.java.net/browse/JDK-8212028 Webrev: http://cr.openjdk.java.net/~erikj/8212028/webrev.01/index.html (From ihse-runtestprebuilt-branch in jdk-sandbox) In order to fully adopt the new run-test

Re: RFR: 8210647: libsaproc is being compiled without optimization.

Looks good to me. /Erik On 2018-09-14 06:33, Severin Gehwolf wrote: Hi, Could I please get a review of this one-liner fix. It changes optimization of libsaproc from -O0 to -O3 (as per Magnus' suggestion). I've run servicability tests and haven't seen any new failures. Thoughts? Bug:

Re: 8210087: Classes in jdk.unsupported not accessible from jconsole plugin

Looks good. /Erik On 2018-09-03 00:27, Alan Bateman wrote: JDK-8210087 [1] is an issue with the launcher generated for jconsole. The launcher needs to be compiled with --add-modules ALL-DEFAULT so that plugins compiled (and run) in an unnamed module can make use of exported APIs in

Re: RFR: JDK-8189429: SA: MacOSX: Replace the deprecated PT_ATTACH with PT_ATTACHEXC

Build changes look good. /Erik On 2018-06-24 10:37, Jini George wrote: Hi Erik, Thank you very much for looking into this. I have addressed your comments. The latest webrev is at: http://cr.openjdk.java.net/~jgeorge/8189429/webrev.06/ Thank you, Jini. On 6/23/2018 3:31 AM, Erik

Re: RFR: JDK-8189429: SA: MacOSX: Replace the deprecated PT_ATTACH with PT_ATTACHEXC

Hello Jini, In general this looks pretty good, but it's also breaking some new ground as it's adding generation of native source in the java gensrc step. Mixing native code with the java code that the genrcs targets and gensrc output directories are meant for seems ok for now, but may cause

Re: RFR 8203802: Jvmti test fails to build with VS2017

Looks good to me. /Erik On 2018-05-29 14:35, Daniil Titov wrote: Hi Serguei, Thank you, for review. I will need one more reviewer to push this changes. Best regards, Daniil On 5/29/18, 12:01 PM, "serguei.spit...@oracle.com" wrote: Hi Daniil, It looks good.

Re: RFR(M) : 8199380 : [TESTBUG] Open source VM testbase AOD tests

Build changes look good. /Erik On 2018-05-23 12:44, Igor Ignatyev wrote: http://cr.openjdk.java.net/~iignatyev/8199380/webrev.00/ 2370 lines changed: 2370 ins; 0 del; 0 mod; Hi all, could you please review this patch which open sources AOD tests from VM testbase? these tests test

Re: RFR(XL) : 8199383 : [TESTBUG] Open source VM testbase JVMTI tests

Looks like the line "# } nsk/jvmti" is a left over. Otherwise this looks ok, even if it's an enormous amount of duplication. Hopefully we can figure out a better way to express common parameters for tests soon. /Erik On 2018-05-22 16:35, Igor Ignatyev wrote:

Re: RFR(L) : 8199382 : [TESTBUG] Open source VM testbase JDI tests

Build change looks good. /Erik On 2018-05-03 21:14, Igor Ignatyev wrote: http://cr.openjdk.java.net/~iignatyev/8199382/webrev.00/index.html 577169 lines changed: 577169 ins; 0 del; 0 mod; Hi all, could you please review the patch which open sources JDI tests from vm testbase? These tests

Re: INCLUDE_SA/serviceability agent - support on s390x

Makes sense to me. Looks good. /Erik On 2018-04-23 05:01, Baesken, Matthias wrote: Hello,   as far as I know  the serviceability agent   is not  supported on  linux s390x . However  (unlike  on aix where it is not supported as well) ,   INCLUDE_SA=false is not set  in the central

Re: RFR: JDK-8199782: Fix compilation warnings detected by Solaris Developer Studio 12.6

On 2018-04-04 17:00, David Holmes wrote: Hi Gary, On 5/04/2018 4:18 AM, Gary Adams wrote: Getting the sources ready for the next Solaris developer studio toolchain.    Issue: https://bugs.openjdk.java.net/browse/JDK-8199782    Webrev: http://cr.openjdk.java.net/~gadams/8199782/webrev.00/

Re: RFR: JDK-8200178 Remove mapfiles for JDK native libraries

Build changes still look good to me. /Erik On 2018-03-28 03:31, Magnus Ihse Bursie wrote: On 2018-03-28 01:52, Weijun Wang wrote: On Mar 24, 2018, at 6:03 AM, Magnus Ihse Bursie wrote: https://bugs.openjdk.java.net/browse/JDK-8200193 -- for

Re: RFR: JDK-8200178 Remove mapfiles for JDK native libraries

I have looked at the build changes and they look good. Will you file followups for each component team to look over their exported symbols, at least for the libraries with $(EXPORT_ALL_SYMBOLS)? It sure looks like there is some technical debt laying around here. /Erik On 2018-03-23 06:56,

Re: RFR: JDK-8199682 Clean up building the saproc library

Looks good to me. The removed source files, are those some kind of tests? /Erik On 2018-03-15 11:22, Magnus Ihse Bursie wrote: The saproc library has historically been built in quite odd ways on almost all platforms. When the old build system was converted, this was not changed. However,

Re: RFR: JDK-8080990: libdt_socket/socket_md.c(202) : warning C4996: 'gethostbyname': Use getaddrinfo() or GetAddrInfoW()

Build change looks fine. /Erik On 2018-01-25 10:46, Gary Adams wrote: Here's a first pass attempt to remove the -D_WINSOCK_DEPRECATED_NO_WARNINGS build flag and update the winsock deprecated functions.   Issue: https://bugs.openjdk.java.net/browse/JDK-8080990   Webrev:

Re: Review Request: JDK-8173858: Rename libmanagement_rmi to libmanagement_agent

Looks good. /Erik On 2017-02-02 23:27, Mandy Chung wrote: libmanagement_agent should be the proper library name for jdk.management.agent. It was an oversight with the current name. http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8173858/webrev.00/ This patch also takes out the qualified

Re: RFR: 8173607: JMX RMI connector should be in its own module

Build changes look ok. /Erik On 2017-01-31 19:26, Daniel Fuchs wrote: Hi, Please find below a patch for: 8173607: JMX RMI connector should be in its own module https://bugs.openjdk.java.net/browse/JDK-8173607 webrev: http://cr.openjdk.java.net/~dfuchs/webrev_8173607/webrev.05 This patch

Re: Review Request: JDK-8173608: Separate JDK management agent from java.management module

On 2017-01-31 17:04, Mandy Chung wrote: On Jan 31, 2017, at 12:20 AM, Erik Joelsson <erik.joels...@oracle.com> wrote: Are all the libraries added to LIBS still needed for this breakout lib? And are all of them still needed for libmanagement.so from which this was split out? Good cat

Re: Review Request: JDK-8173608: Separate JDK management agent from java.management module

Hello Mandy, In Lib-jdk.management.agent.gmk: OPENJDK_TARGET_OS and OPENJDK_TARGET_OS_TYPE are both "windows" on Windows platforms, so no need to treat Windows differently when defining the src dirs. The -DPSAPI_VERSION=1 seems to be copied from Lib-jdk.management.gmk and/or

RFR: JDK-8166202: Tracefile gensrc cannot handle closed src dir in different location

The xml/xsl source files used to generate sources for trace in hotspot have hard coded relative paths in them that make assumptions on where the oracle closed files are located. The source files should not make these kind of assumptions since that makes it difficult to change the repository

Re: RFR(8u) JDK-8153252: SA: Hotspot build on Windows fails if make/closed folder does not exist

Looks good to me. /Erik On 2016-04-13 22:49, Poonam Bajaj Parhar wrote: Hello, As per Erik's suggestion not to remove the existing check for HS_ALT_MAKE, here is the updated webrev: http://cr.openjdk.java.net/~poonam/8153252/webrev.01/ Thanks, Poonam On 4/11/2016 12:15 PM, Poonam Bajaj

Re: RFR: JDK-8151653: Hotspot build does not respect --enable-openjdk-only

, David Holmes wrote: On 14/03/2016 11:22 AM, David Holmes wrote: Hi Erik, On 12/03/2016 2:31 AM, Erik Joelsson wrote: Hello, When building hotspot with closed sources present and configuring with --enable-openjdk-only, various closed parts are included in the build anyway, at least on

RFR: JDK-8151653: Hotspot build does not respect --enable-openjdk-only

Hello, When building hotspot with closed sources present and configuring with --enable-openjdk-only, various closed parts are included in the build anyway, at least on Windows. This needs to be fixed in preparation for the new hotspot build for build output comparisons to be meaningful

Re: RFR: JDK-8150723: HSDB toolbar icons are missing.

remove this whole SetupCopyFiles >>>>> construct and just add .gif to jdk.hotspot.agent_COPY. >>>> Comments in CompileJavaModules.gmk are as below: >>>> >>>>### Copy gif files >>>># Special handling to copy gif fil

Re: RFR(L): JDK-8067194 Restructure hotspot/agent/src to conform the modular source layout

Hello Dmitry, Nice to see this happen! make/lib/Lib-jdk.hotspot.agent.gmk: Missing a "/libsaproc" here: SA_SRC += $(SA_TOPDIR)/share/native $(SA_TOPDIR)/$(OPENJDK_TARGET_OS)/native/libsaproc Otherwise it looks good. /Erik On 2015-12-21 22:50, Dmitry Samersoff wrote: Everybody, Please,

Re: RFR 8142398: IllegalAccessException Class sun.usagetracker.UsageTrackerClient$4 (module java.base) can not access a member of class java.lang.management.ManagementFactory (module java.management)

Build changes look good to me. /Erik On 2015-12-14 17:55, Jaroslav Bachorik wrote: Please, review the following change Issue : https://bugs.openjdk.java.net/browse/JDK-8138677 Webrev: http://cr.openjdk.java.net/~jbachorik/8138677/webrev.00 The problem is that the class UsageTrackerClient is

Re: RFR 8043138: Attach API should not require jvmstat rmi protocol

On 2015-11-25 09:11, Staffan Larsen wrote: On 24 nov. 2015, at 17:03, Jaroslav Bachorik wrote: Please, review the following change Issue : https://bugs.openjdk.java.net/browse/JDK-8043138 Webrevs: * top level:

Re: RFR 8043138: Attach API should not require jvmstat rmi protocol

Build changes look good to me now. /Erik On 2015-11-25 17:53, Jaroslav Bachorik wrote: On 25.11.2015 11:36, Magnus Ihse Bursie wrote: On 2015-11-25 10:39, Alan Bateman wrote: On 25/11/2015 09:25, Jaroslav Bachorik wrote: I don't think we can just repackage these interfaces - they are

Re: RFR 8043138: Attach API should not require jvmstat rmi protocol

On 2015-11-25 10:28, Jaroslav Bachorik wrote: On 25.11.2015 09:37, Erik Joelsson wrote: On 2015-11-25 09:11, Staffan Larsen wrote: On 24 nov. 2015, at 17:03, Jaroslav Bachorik <jaroslav.bacho...@oracle.com> wrote: Please, review the following change Issue : https://bugs.openjdk.ja

Re: RFR: JDK-8142336: Convert the SA agent build to modular build-infra makefiles

: On 2015-11-10 11:39, Magnus Ihse Bursie wrote: On 2015-11-09 19:33, Erik Joelsson wrote: Hello, As a stepping stone in the hotspot makefile conversion, I have broken out the serviceability agent separately and converted it into proper modular build-infra makefiles. Doing this conversion separately

RFR: JDK-8142336: Convert the SA agent build to modular build-infra makefiles

Hello, As a stepping stone in the hotspot makefile conversion, I have broken out the serviceability agent separately and converted it into proper modular build-infra makefiles. Doing this conversion separately has some value on its own by reducing the special cases currently needed for

Re: RFR 8140481: NoClassDefFoundError thrown by ManagementFactory.getPlatformMBeanServer

The change looks good to me, but I think someone else from the jigsaw team should review this as well. /Erik On 2015-11-02 09:08, Jaroslav Bachorik wrote: Please, review the following build change Issue : https://bugs.openjdk.java.net/browse/JDK-8140481 Webrev:

Re: RFR 8140481: NoClassDefFoundError thrown by ManagementFactory.getPlatformMBeanServer

Looks good to me. /Erik On 2015-11-02 11:28, Jaroslav Bachorik wrote: On 2.11.2015 09:28, Alan Bateman wrote: On 02/11/2015 08:08, Jaroslav Bachorik wrote: Please, review the following build change Issue : https://bugs.openjdk.java.net/browse/JDK-8140481 Webrev:

Re: RFR 8043937: Drop support for the IIOP transport from the JMX RMIConnector

Contains changes to the top level repo as well as a correct version of jdk/make/rmic/Rmic-java.management.gmk (thanks to Erik Joelsson) The updated webrev and the updated @deprecated in RMIIIOPServerImpl looks good. Can you make sure to test out boot cycle builds before pushing this? That would

Re: RFR: 8076470 - JEP 240: Remove the JVM TI hprof Agent

Looks good to me. /Erik On 2015-08-07 08:57, Staffan Larsen wrote: Please review the following changes to remove the hprof JVMTI agent. There are changes in three different repositories. All tests that used the hprof agent has been removed in previous changesets. Note: This does not remove

Re: RFR: 8079360 AttachProviderImpl could not be instantiated

Looks good to me. /Erik On 2015-05-06 20:51, Staffan Larsen wrote: This is another library that needs to be compiled with -DPSAPI_VERSION=1 due to the recent Windows compiler upgrade. I have also fixed a better error message that prints the underlaying exception if something like this

Re: RFR: JDK-8079248 JDK fails with jdk\\bin\\management_ext.dll: The specified procedure could not be found

On 2015-05-04 10:25, Staffan Larsen wrote: On 4 maj 2015, at 09:54, Magnus Ihse Bursie magnus.ihse.bur...@oracle.com wrote: 4 maj 2015 kl. 09:27 skrev David Holmes david.hol...@oracle.com: Hi Staffan, Seems fine as a spot fix but I'm wondering if this shouldn't be a common option for all

RFR: JDK-8077422: hprof agent: Build failed with VS2013 Update 4

Hello, This bug has been marked as won't fix since the code it affects is going to be removed. However, until that removal happens, we can't build using VS2013 SP4. I'm in the process of updating the compilers used internally at Oracle to that specific version and to be able to continue that

Re: RFR: 8076473 Remove the jhat code and update makefiles

Looks good to me. /Erik On 2015-04-23 05:15, Alan Bateman wrote: On 23/04/2015 13:06, Staffan Larsen wrote: Please review this change to remove the jhat tool. I will not push this change until the tests have been removed (see a different review thread). JEP:

Re: RFR: 8076473 Remove the jhat code and update makefiles

No, that file is old legacy and not used anymore. It will hopefully soon go away. /Erik On 2015-04-23 12:52, serguei.spit...@oracle.com wrote: It looks good. A question: Do we want to get rid of the jhat in the jdk/closed/old-build/common/Release.gmk ? jhat.1 \

Re: RFR(S): JDK-8077137 Port jdk.internal.instrumentation to jdk 9

Looks good to me. /Erik On 2015-04-08 12:21, Staffan Larsen wrote: Please review these small changes to support an addition of closed code to the java.instrument module. webrev: http://cr.openjdk.java.net/~sla/8077137-open/webrev.01/ http://cr.openjdk.java.net/~sla/8077137-open/webrev.01/

RFR

Hello, When upgrading the toolchain to VS2013, management.dll stopped working on certain Windows hosts. I've identified this to be related to the call to GetProcessMemoryInfo. By adding -DPSAPI_VERSION=1 to CFLAGS, the problem goes away. Bug: https://bugs.openjdk.java.net/browse/JDK-8076557

RFR: JDK-8076557: The specified procedure could not be found in management.dll

(corrected subject) On 2015-04-07 17:15, Erik Joelsson wrote: Hello, When upgrading the toolchain to VS2013, management.dll stopped working on certain Windows hosts. I've identified this to be related to the call to GetProcessMemoryInfo. By adding -DPSAPI_VERSION=1 to CFLAGS, the problem

Re: RFR 8042901: Allow com.sun.management to be in a different module to java.lang.management

Looks good, thanks! /Erik On 2015-04-01 20:03, shanliang wrote: Erik Joelsson wrote: Hello, (Adding build-dev since this touches makefiles and jigsaw-dev since this touches modules.xml) In general, the build changes look pretty good. I much appreciate moving the OS specific source

Re: RFR 8042901: Allow com.sun.management to be in a different module to java.lang.management

Hello, (Adding build-dev since this touches makefiles and jigsaw-dev since this touches modules.xml) In general, the build changes look pretty good. I much appreciate moving the OS specific source into OS specific source dirs. A few notes however. Though I realize you followed existing

Re: RFR: JDK-8075056 Remove Version.java.template from jconsole

Looks good. /Erik On 2015-03-12 13:54, Staffan Larsen wrote: The build for jconsole currently takes a template file and inserts the version number of the build into the file. We can simplify this by removing the template file and reading the java.runtime.version system property at runtime.

Re: RFR: 8058470 [jconsole] VM Summary Tab is blank for JDK9's jconsole.

Hello, The specification for the properties file format says that a comment is a line that has either a ! or # as the first non whitespace character. Greping around in the source shows we have several instances if comments tarting a few spaces in. I don't think we are using ! for comments

Re: RFR: JDK-8067479: verify-modules fails in bootcycle build

Hello, Any chance someone from serviceability could take a look at this? /Erik On 2015-01-12 03:45, David Holmes wrote: Hi Erik, On 10/01/2015 12:34 AM, Erik Joelsson wrote: Hello, Please review this patch which fixes the verify-modules target when running bootcycle build, and also

Re: Review request: 8055230: Rename attach provider implementation class

Nice! /Erik On 2014-08-26 06:29, Mandy Chung wrote: Webrev: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8055230/ This patch renames the class name of attach provider implementation class to be the same for all platforms. This simplifies the build logic and removes the need for

Re: RFRF: 8043936 Drop HPROF as demo, keep as HPROF agent shipped with JDK

Build changes look ok to me. /Erik On 2014-08-25 15:35, Staffan Larsen wrote: Please review the following change to remove hprof as part of the demo package. Instead, the source code has been moved to the jdk.hprof.agent module. bug: https://bugs.openjdk.java.net/browse/JDK-8043936 webrev:

Re: RFR 8037825 Fix warnings and enable warnings as errors in serviceability native libraries

Hello, Nice work! Removing warnings and enforcing them is definitely something we like. For the makefile change, ideally the new variable WARNINGS_ARE_ERRORS should be set in configure. I would suggest flags.m4, in FLAGS_SETUP_COMPILER_FLAGS_MISC. Also, instead of making the conditional on

Re: RFR 8037825 Fix warnings and enable warnings as errors in serviceability native libraries

.01/root/ http://cr.openjdk.java.net/~sla/8037825/webrev.01/jdk/ Thanks, /Staffan On 19 mar 2014, at 14:03, Erik Joelsson erik.joels...@oracle.com wrote: Hello, Nice work! Removing warnings and enforcing them is definitely something we like. For the makefile change, ideally the new variable

Re: RFR(XS): JDK-8034176 Update mapfile for libjfr

Looks good, but I can't help but wonder why the mapfile for libjfr is in the open. /Erik On 2014-02-11 12:00, Staffan Larsen wrote: Resending (email to build-dev bounced since I used the wrong sender address). On 11 feb 2014, at 11:18, staf...@larsen.se wrote: Please review this small fix

hg: jdk8/tl: 8032632: Wrong version for the first jdk8 fcs build

Changeset: 7238a870ddb7 Author:erikj Date: 2014-01-24 10:39 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/rev/7238a870ddb7 8032632: Wrong version for the first jdk8 fcs build Reviewed-by: katleman ! common/autoconf/spec.gmk.in

hg: jdk8/tl/jdk: 8032217: failure in man page processing

Changeset: ff56039c4870 Author:erikj Date: 2014-01-22 12:13 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ff56039c4870 8032217: failure in man page processing Reviewed-by: dholmes, tbell ! make/Images.gmk

hg: jdk8/tl: 8030781: System.setProperties(null) drops all system properties (RELEASE not set)

Changeset: 53d74b77ee53 Author:erikj Date: 2014-01-08 14:02 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/rev/53d74b77ee53 8030781: System.setProperties(null) drops all system properties (RELEASE not set) Reviewed-by: alanb, ihse, tbell ! common/autoconf/generated-configure.sh !

hg: jdk8/tl/jdk: 8030781: System.setProperties(null) drops all system properties (RELEASE not set)

Changeset: 2437ccbf3504 Author:erikj Date: 2014-01-08 14:04 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2437ccbf3504 8030781: System.setProperties(null) drops all system properties (RELEASE not set) Reviewed-by: alanb + test/java/lang/System/SetPropertiesNull.java

hg: jdk8/tl/jdk: 8027963: Create unlimited policy jars.

Changeset: 427c78c88229 Author:erikj Date: 2013-12-05 09:25 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/427c78c88229 8027963: Create unlimited policy jars. Reviewed-by: wetmore, ihse ! make/CreateSecurityJars.gmk ! make/SignJars.gmk -

  1   2   >