Re: RFR: Changes to disable and/or remove Solaris 32-bit from JDK8

On 2013-09-11 00:00, Kumar Srinivasan wrote: Here are the updated changes: The build changes are here: http://cr.openjdk.java.net/~ksrini/8020552/webrev.jdk8.1/ the delta changes since last reviewed: http://cr.openjdk.java.net/~ksrini/8020552/webrev.jdk8.1/webrev.delta/index.html The jdk

Re: code review round 1 for Full Debug Symbols on MacOS X hotspot (7165611)

On 2013-10-11 22:27, Daniel D. Daugherty wrote: Greetings, I'm ready for code review round 1 of the FDS on MacOS X hotspot changes. Below is the original code review round 0 invite (slightly edited for clarity). Working on FDS is like pulling a thread on a sweater... so there are four

Re: code review round 0 for MacOS X FDS whitespace/indent fixes (8027117)

On 2013-10-23 22:26, Daniel D. Daugherty wrote: Greetings, I have some MacOS X Full Debug Symbols whitespace/indent fixes. Here is the JDK8/HSX-25 webrev URL: OpenJDK: http://cr.openjdk.java.net/~dcubed/fds_revamp/8027117-webrev/0-jdk8/ Internal:

Re: Review request for 8025985: com.sun.management.OSMBeanFactory should not be public

On 2013-11-08 00:40, Mandy Chung wrote: com.sun.management API is an exported API [1] except com.sun.management.OSMBeanFactory class which is an implementation-specific class and it's currently annotated as @jdk.Exported(false) [2]. This patch will eliminate one use of @jdk.Exported(false).

hg: jdk8/tl: 8027566: Remove the old build system

Changeset: a667caba1e84 Author:ihse Date: 2013-11-14 10:53 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/rev/a667caba1e84 8027566: Remove the old build system Reviewed-by: erikj, tbell ! Makefile - NewMakefile.gmk ! common/autoconf/Makefile.in ! common/autoconf/basics.m4 !

hg: jdk8/tl/jaxp: 8027566: Remove the old build system

Changeset: 80acb8151797 Author:ihse Date: 2013-11-04 11:09 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/80acb8151797 8027566: Remove the old build system Reviewed-by: erikj, tbell + make/BuildJaxp.gmk ! make/Makefile - make/jprt.properties - make/scripts/update_src.sh -

hg: jdk8/tl/corba: 8027566: Remove the old build system

Changeset: 9729f9862eb4 Author:ihse Date: 2013-11-04 11:09 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/9729f9862eb4 8027566: Remove the old build system Reviewed-by: erikj, tbell + make/BuildCorba.gmk ! make/Makefile - make/com/Makefile - make/com/sun/Makefile -

hg: jdk8/tl/nashorn: 8027566: Remove the old build system

Changeset: 779e155419b8 Author:ihse Date: 2013-11-04 11:11 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/779e155419b8 8027566: Remove the old build system Reviewed-by: erikj, tbell + make/BuildNashorn.gmk ! make/Makefile - makefiles/BuildNashorn.gmk -

hg: jdk8/tl/jaxws: 8027566: Remove the old build system

Changeset: 1d1af4ce8eeb Author:ihse Date: 2013-11-04 11:10 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/1d1af4ce8eeb 8027566: Remove the old build system Reviewed-by: erikj, tbell + make/BuildJaxws.gmk ! make/Makefile - make/jprt.properties - make/scripts/update_src.sh

hg: jdk8/tl/langtools: 8027566: Remove the old build system

Changeset: 8043b9cf31ab Author:ihse Date: 2013-11-04 11:08 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/8043b9cf31ab 8027566: Remove the old build system Reviewed-by: erikj, tbell + make/BuildLangtools.gmk ! make/Makefile - make/jprt.properties -

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

On 2014-03-19 13:30, Staffan Larsen wrote: The serviceability libraries (as defined by jdk/make/lib/ServiceabilityLibraries.gmk) should be compiled with warnings as errors. To enable this all current warnings need to be fixed. The background for this is that we recently had a bug that could

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

On 2014-03-19 17:47, Erik Joelsson wrote: Build part looks good! Build part looks good to me to. /Magnus

Re: RFR(S) Solaris Full Debug Symbols (FDS) fix for 8033602 and 8034005

On 2014-11-11 01:00, Daniel D. Daugherty wrote: Greetings, I have a Solaris Full Debug Symbols (FDS) fix ready for review. Yes, it is a small fix, but it is in Makefiles so feel free to run screaming from the room... :-) On the plus side the fix does delete two work around source files (Coleen

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

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. bug:

Re: RFR: Resolve disabled warnings for the JVMTI demos

Looks good to me. /Magnus 10 mar 2015 kl. 16:37 skrev Staffan Larsen staffan.lar...@oracle.com: Please review these small fixes to remove a couple of warnings in the JVMTI demos. bug: https://bugs.openjdk.java.net/browse/JDK-8074841 bug:

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

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 the dlls now we are building with VS2013? Or maybe as a define in the source code before the include section for the

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

Looks good to me. /Magnus 7 apr 2015 kl. 17:21 skrev Erik Joelsson erik.joels...@oracle.com: (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

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

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/ Looks good to me.

Re: RFR(S): 8081037: serviceability/sa/ tests time out on Windows

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

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

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

Bursie wrote: 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

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

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 has some value on its own by reducing

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)

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 accessing

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

On 2015-12-22 08:46, Erik Joelsson wrote: 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. Looks good to me too. /Magnus

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

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 remote API and we would break compatibility (eg. JDK 8 jvmstat would not be able to query JVM exposed via JDK 9 jstatd). You're right.

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

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 remote API and we would break compatibility

Re: build_vm_def.sh broken on macosx?

cc:ing serviceability-dev, since I believe the SA agent is the primary consumer of dynamic symbols in the jvm library. On 2016-01-21 11:37, Magnus Ihse Bursie wrote: Hi, It seems that build_vm_def.sh is broken on macosx. The script lists all from *.o using nm, and filters them using this awk

Re: RFR: JDK-8178037 Move information from jdi-overview.html into jdk.jdi module-info.java

On 2017-04-20 04:21, David Holmes wrote: On 19/04/2017 10:54 PM, Magnus Ihse Bursie wrote: With JDK-8172312, the file src/jdk.jdi/share/classes/jdi-overview.html is no longer included in the generated documentation. The information provided by that file should move to src/jdk.jdi/share/classes

Re: RFR: JDK-8180322 Move JNI spec to specs directory

es (or technically extensions), and .xml is not one of them (and neither is .gmk :-(). I have instructed my editor to remove trailing whitespaces always, and sometimes this means a patch gets lots of whitespace cleanup. /Magnus > > Thanks, > David > >> On 1/06/2017 10:46

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

On 2018-05-23 02:05, Erik Joelsson wrote: 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. Argee, the current solution is not scaling

Re: RFR(S): 8196992: Resolve disabled warnings for libdt_socket

On 2018-02-23 02:03, Chris Plummer wrote: Hello, Please review the following: https://bugs.openjdk.java.net/browse/JDK-8196992 diff --git a/make/lib/Lib-jdk.jdwp.agent.gmk b/make/lib/Lib-jdk.jdwp.agent.gmk --- a/make/lib/Lib-jdk.jdwp.agent.gmk +++ b/make/lib/Lib-jdk.jdwp.agent.gmk @@ -43,7

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

real test coverage of this now.) /Magnus /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, now the time has come to streamline

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

On 2018-04-04 20:18, 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/ This update conditionally disables some new error checks,

Re: RFR: JDK-8202200: set INCLUDE_SA to false on s390x by default -was : RE: INCLUDE_SA/serviceability agent - support on s390x

On 2018-04-25 10:14, Baesken, Matthias wrote: Hi Erik, thanks ! Can I consider this as a review ? In the meantime I created a webrev + bug : webrev for review  : http://cr.openjdk.java.net/~mbaesken/webrevs/8202200/ Looks good

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

On 2018-03-28 01:52, Weijun Wang wrote: On Mar 24, 2018, at 6:03 AM, Magnus Ihse Bursie <magnus.ihse.bur...@oracle.com> wrote: https://bugs.openjdk.java.net/browse/JDK-8200193 -- for jdk.security.auth There is only one function to export and it already has JNIEXPORT, so you can just

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

On 2018-03-28 23:53, Martin Buchholz wrote: I can't find any documentation for what JNIEXPORT and friends actually do. People including myself have been cargo-culting JNIEXPORT and JNICALL for decades. Why aren't they in the JNI spec? That surprises me. I'm quite certain that javah (or rather,

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

urce code directories. /Magnus > > -Sundar > > On 16/03/18, 12:19 AM, Magnus Ihse Bursie wrote: >> >> >> On 2018-03-15 19:39, Erik Joelsson wrote: >>> Looks good to me. >>> >>> The removed source files, are those some kind of tests? &

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

On 2018-03-16 19:12, Magnus Ihse Bursie wrote: Hi Sundar, I almost missed your mail, since you removed both me and build-dev from the cc list... 16 mars 2018 kl. 06:14 skrev Sundararajan Athijegannathan <sundararajan.athijegannat...@oracle.com>: Renaming sawindbg as saproc soun

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

ously exported. You are correct, it was previously exported in libawt_headless. I meant that it is now also exported for libawt_xawt due to the JNIEXPORT. Sorry for mixing this up. /Magnus -phil. On 03/23/2018 06:56 AM, Magnus Ihse Bursie wrote: With modern compilers, we can use compi

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

mbols, 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, Magnus Ihse Bursie wrote: With modern compilers, we can use compiler directives (such as _attribute__((visibility("default"))), or _

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

3/23/2018 06:56 AM, Magnus Ihse Bursie wrote: With modern compilers, we can use compiler directives (such as _attribute__((visibility("default"))), or __declspec(dllexport)) to control symbol visibility, directly in the source code. This has historically not been present on all compil

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

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, Magnus Ihse Bursie wrote: With modern compilers, we can use compiler directives (such as _attribute__

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

On 2018-03-16 04:13, David Holmes wrote: Hi Magnus, Overall this seems okay. Thanks! On 16/03/2018 4:22 AM, 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

RFR: JDK-8200178 Remove mapfiles for JDK native libraries

With modern compilers, we can use compiler directives (such as _attribute__((visibility("default"))), or __declspec(dllexport)) to control symbol visibility, directly in the source code. This has historically not been present on all compilers, so we had to resort to using mapfiles (also known

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

> 23 mars 2018 kl. 15:45 skrev Alan Bateman <alan.bate...@oracle.com>: > >> On 23/03/2018 13:56, Magnus Ihse Bursie wrote: >> With modern compilers, we can use compiler directives (such as >> _attribute__((visibility("default"))), or __declspec(dlle

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

> 12 okt. 2018 kl. 18:16 skrev Erik Joelsson : > > >> 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,

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

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/browse/JDK-8212028 Webrev:

Re: [12] RFR for JDK-8214122: JDWP is broken on 32 bit Windows: transport library missing onLoad entry

the undecorated name, jdwpTransport_OnLoad. Regards, Alexey [1] https://docs.microsoft.com/en-us/cpp/build/reference/decorated-names?view=vs-2017#FormatC [2] https://docs.microsoft.com/en-ie/cpp/cpp/stdcall?view=vs-2017 On 12/12/2018 11:19, Magnus Ihse Bursie wrote: On 2018-12-11 18:16

Re: [PATCH] Windows 32-bit DLL name decoration

ibraryEntry(handle, "jdwpTransport_OnLoad"); #endif Thanks, -Simon Regards, Alexey https://bugs.openjdk.java.net/browse/JDK-8214122 On 10/12/2018 15:11, Magnus Ihse Bursie wrote: Since removing JNICALL is not an option, there are only two options: 1. Add |/export| option to the Makefile or pragm

Re: [PATCH] Windows 32-bit DLL name decoration

ad = (jdwpTransport_OnLoad_t) dbgsysFindLibraryEntry(handle, "jdwpTransport_OnLoad"); #endif Thanks, -Simon Regards, Alexey https://bugs.openjdk.java.net/browse/JDK-8214122 On 10/12/2018 15:11, Magnus Ihse Bursie wrote: Since removing JNICALL is not an option, there are only two optio

Re: [PATCH] Windows 32-bit DLL name decoration

On 2018-12-12 12:35, Alan Bateman wrote: On 12/12/2018 11:14, Magnus Ihse Bursie wrote: : I searched the code for "jdwpTransport_On" to see of there was any corresponding OnUnload function (or other), but could not find any. That's right, an unload wasn't needed whe

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

> 3 dec. 2018 kl. 20:27 skrev Roman Kennke : > > Round 5 of Shenandoah review includes: > - A fix for the @requires tag in TestFullGCCountTest.java. It should be > correct now. We believe the CMS @requires was also not quite right and > fixed it the same. > > It reads now: Don't run this test

Re: [PATCH] JDK-8214122 Prevent name mangling of jdwpTransport_OnLoad in Windows 32-bit DLL name decoration

/windows/native/include/jni_md.h#L31 ? Wouldn’t that be a more consistent move? We can't do that. Implementation of Java native methods must use __stdcall calling convention. Regards, Ali On 22 Nov 2018, at 17:29, Magnus Ihse Bursie <mailto:magnus.ihse.bur...@oracle.com>> wrote: I

Re: [PATCH] Windows 32-bit DLL name decoration

On 2018-12-10 16:02, Alexey Ivanov wrote: On 10/12/2018 10:41, Magnus Ihse Bursie wrote: On 2018-12-07 22:18, Simon Tooke wrote: Looking at the code, it seems (to me) the "correct" thing to do is to is to create a Windows-specific version of dbgsysBuildFunName() in linker_md.c

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

On 2018-11-26 23:47, Erik Joelsson wrote: Build changes look ok to me. I agree, but I'd like to point out a (possible) style improvement. In hotspot.m4, if test "x$OPENJDK_TARGET_CPU" = "xx86_64" || test "x$OPENJDK_TARGET_CPU" = "xaarch64" || test "x$OPENJDK_TARGET_CPU" == "xx86"; then

Re: [PATCH] JDK-8214122 Prevent name mangling of jdwpTransport_OnLoad in Windows 32-bit DLL name decoration

suggested by Ali. It's just yet another version of option 1 in disguise/map files. /Magnus Regards, Alexey On 19/11/2018 12:19, Magnus Ihse Bursie wrote: Hi Ali, From a build perspective this change looks OK. I'm not aware of the finer details on the OnLoad mechanism, like what calling

Re: [PATCH] JDK-8214122 Prevent name mangling of jdwpTransport_OnLoad in Windows 32-bit DLL name decoration

> 22 nov. 2018 kl. 18:04 skrev Alexey Ivanov : > > >> On 21/11/2018 12:16, Magnus Ihse Bursie wrote: >>> On 2018-11-20 16:49, Alexey Ivanov wrote: >>> Hi Ali, Magnus, >>> >>> I absolutely agree this change has to be reviewed by someone from >

Re: [PATCH] Windows 32-bit DLL name decoration

Hi Ali, From a build perspective this change looks OK. I'm not aware of the finer details on the OnLoad mechanism, like what calling convention is to be used. So maybe this is a no-go from that view. I'm cc:ing servicability so they can have a look at it. /Magnus On 2018-11-18 13:07, Ali

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

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, Christoph wrote: Hi David, please review an enhancement which I've identified when working with

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

On 2019-11-02 13:43, Daniel D. Daugherty wrote: Since this review contains build changes, I've added build-dev@... Thanks Dan for noticing this and cc:ing us. Yasumasa: build changes look fine. Thanks. /Magnus Dan On 11/1/19 4:56 AM, Yasumasa Suenaga wrote: (Changed subject to review

Re: RFR: 8232084: HotSpot build failed with GCC 9.2.1

On 2019-10-11 15:38, Yasumasa Suenaga wrote: Hi, Christos commented to B-1. Thanks! clang defines __GNU_C__ , but stringop-truncation is not supported. So I updated Plan B-1. It works fine on my Fedora30 box.   A. Use memcpy()   

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

On 2020-01-14 13:49, Baesken, Matthias wrote: Hi Magnus, thanks for the info , I already noticed yesterday the setting for arm-32 in the minimal build . Do you think  we could set it too for the other Linux platforms  in the minimal build  ( serviceability agent is not supported there as

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

On 2020-01-10 11:01, Baesken, Matthias wrote: Hello, I recently looked into the gcc lto optimization mode (see for some details https://gcc.gnu.org/onlinedocs/gccint/LTO-Overview.html and http://hubicka.blogspot.com/2019/05/gcc-9-link-time-and-inter-procedural.html ). This mode can

RFR: JDK-8242808 Fix all remaining deprecation warnings in jdk.hotspot.agent

After JDK-8242804, a few places remain which are using deprecated methods. They too should be fixed, and the deprecation warning should no longer be disabled. This patch presupposes the fix for JDK-8242804 has been applied (otherwise we cannot turn the deprecation warning back on). Some

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

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 "new Integer(42)" pattern of explicit boxing, which is deprecated. I

Re: RFR: JDK-8242808 Fix all remaining deprecation warnings in jdk.hotspot.agent

Rectangles (not Rectangle2D). /Magnus On 2020-04-15 11:37, David Holmes wrote: Hi Magnus, This one sounds like it needs a Swing/Java2D developer to review it :) Cheers, David On 15/04/2020 7:13 pm, Magnus Ihse Bursie wrote: After JDK-8242804, a few places remain which are using deprecated methods

Re: Ping: Re: RFR: JDK-8241618 Fix unchecked warning for jdk.hotspot.agent

as a way to comment the expected types? /Magnus thanks, Chris On 4/14/20 2:24 AM, Magnus Ihse Bursie wrote: Hi, Can I please get a review for this, simplified version of the patch? This only contain trivial changes, like this: - private Listobjects; // ArrayList + private List

Re: Ping: Re: RFR: JDK-8241618 Fix unchecked warning for jdk.hotspot.agent

On 4/14/20 2:24 AM, Magnus Ihse Bursie wrote: Hi, Can I please get a review for this, simplified version of the patch? This only contain trivial changes, like this: - private Listobjects; // ArrayList + private List objects; Basically all changes are to the container types List or Map

RFR: JDK-8242943 Fix all remaining unchecked warnings in jdk.hotspot.agent

This is the final part of removing all warnings from the build of jdk.hotspot.agent. This patch includes a number of non-trivial fixes for the few remaining unchecked warnings. The good news is that with this fix (and after the recent removal of Nashorn and rmic), the JDK build is finally

Re: RFR (T) 8242896: typo #ifdef INCLUDE_JVMTI in codeCache.cpp

On 2020-04-16 04:37, coleen.phillim...@oracle.com wrote: On 4/15/20 9:37 PM, David Holmes wrote: Hi Coleen, On 16/04/2020 10:59 am, coleen.phillim...@oracle.com wrote: open webrev at http://cr.openjdk.java.net/~coleenp/2020/8242896.01/webrev bug link

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

As a first step towards fixing deprecation warnings in SA, all the references (200+) to the deprecated java.util.Observer and Observable needs to be fixed, otherwise all other changes will drown in this one. This solution is the result of the preceding discussions in serviceability-dev. That

Ping: Re: RFR: JDK-8241618 Fix unchecked warning for jdk.hotspot.agent

). If the list of all the files look horrible in the webrev, have a look at the patch file instead, it is easier to scroll through and check the changes: http://cr.openjdk.java.net/~ihse/JDK-8241618-fix-unchecked-warnings-for-agent/webrev.02/open.patch /Magnus On 2020-03-30 16:25, Magnus Ihse Bursie

Re: RFR: JDK-8242943 Fix all remaining unchecked warnings in jdk.hotspot.agent

On 2020-04-20 21:19, Joe Darcy wrote: Hello, On 4/16/2020 5:47 AM, Magnus Ihse Bursie wrote: [snip] The tricky one here is the helper TableModelComparator. This one took me a while to wrap my head around. It implements Comparator, but the compare() method takes "rows" from the mo

Re: RFR: JDK-8242808 Fix all remaining deprecation warnings in jdk.hotspot.agent

Here is an updated version, that avoids the SuppressWarnings for modelToView: http://cr.openjdk.java.net/~ihse/JDK-8242808-fix-all-SA-deprecation/webrev.02 (Only change is in SourceCodePanel.java compared to v01) /Magnus On 2020-04-15 14:30, Magnus Ihse Bursie wrote: On 2020-04-15 12:59

Re: RFR: JDK-8242808 Fix all remaining deprecation warnings in jdk.hotspot.agent

3:35 PM, Magnus Ihse Bursie wrote: Hi swing-dev, Do you have any other suggestions for how to resolve the deprecation of modelToView() in this code? Basically, the code does this:    Rectangle rect = source.modelToView(offset);    source.scrollRectToVisible(rect

RFR: JDK-8241618 Fix unchecked warning for jdk.hotspot.agent

With the recent fixes in JDK-8241310, JDK-8237746 and JDK-8241073, and the upcoming fixes to remove the deprecated nashorn and jdk.rmi, the JDK build is very close to producing no warnings when compiling the Java classes. The one remaining sinner is jdk.hotspot.agent. Most of the warnings

Re: RFR: JDK-8241618 Fix unchecked warning for jdk.hotspot.agent

pHeap.java open/test/hotspot/jtreg/compiler/ciReplay/TestSAClient.java open/test/hotspot/jtreg/compiler/ciReplay/TestSAServer.java Thank you! I'll run these through our test system. /Magnus Chris On 3/25/20 12:29 PM, Magnus Ihse Bursie wrote: With the recent fixes in JDK-8241310, JDK-8237746 and J

Discussion about fixing deprecation in jdk.hotspot.agent

Hi everyone, As a follow-up to the ongoing review for JDK-8241618, I have also looked at fixing the deprecation warnings in jdk.hotspot.agent. These fall in three broad categories: * Deprecation of the boxing type constructors (e.g. "new Integer(42)"). * Deprecation of java.util.Observer

Re: Discussion about fixing deprecation in jdk.hotspot.agent

public static void registerVMInitializedObserver(Observer o) {     vmInitializedObservers.add(o);     o.update(null, null);   } It seems like if it isn't needed, we shouldn't add these classes and remove their use. Coleen On 3/30/20 8:14 AM, Magnus Ihse Bursie wrote: No opinions on this? /Magnus

Re: Discussion about fixing deprecation in jdk.hotspot.agent

with   the VM. */   public static void registerVMInitializedObserver(Observer o) {     vmInitializedObservers.add(o);     o.update(null, null);   } It seems like if it isn't needed, we shouldn't add these classes and remove their use. Coleen On 3/30/20 8:14 AM, Magnus Ihse Bursie wrote

Re: Discussion about fixing deprecation in jdk.hotspot.agent

No opinions on this? /Magnus On 2020-03-25 23:34, Magnus Ihse Bursie wrote: Hi everyone, As a follow-up to the ongoing review for JDK-8241618, I have also looked at fixing the deprecation warnings in jdk.hotspot.agent. These fall in three broad categories: * Deprecation of the boxing type

Re: RFR: JDK-8241618 Fix unchecked warning for jdk.hotspot.agent

/TestSAClient.java open/test/hotspot/jtreg/compiler/ciReplay/TestSAServer.java Chris On 3/25/20 12:29 PM, Magnus Ihse Bursie wrote: With the recent fixes in JDK-8241310, JDK-8237746 and JDK-8241073, and the upcoming fixes to remove the deprecated nashorn and jdk.rmi, the JDK build is very close

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

Yeah, I just noticed that. :-( I'll fix that before pushing. /Magnus Thanks, Coleen On 4/14/20 7:04 AM, Magnus Ihse Bursie wrote: As a first step towards fixing deprecation warnings in SA, all the references (200+) to the deprecated java.util.Observer and Observable needs to be fixed

RFR: JDK-8241463 Move build tools to respective modules

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 anymore. Instead, the build tools source code should move the the

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

you're right. I'll move them as well. I'll publish an updated webrev with these changes when there's agreement on where in the source code tree to move the files. /Magnus Naoto On 3/23/20 12:03 PM, Magnus Ihse Bursie wrote: The build tools (small java tools that are run during the build

Re: RFR: 8244224: Implementation of JEP 381: Remove the Solaris and SPARC Ports (serviceability)

On 2020-05-06 12:40, coleen.phillim...@oracle.com wrote: On 5/6/20 2:09 AM, serguei.spit...@oracle.com wrote: On 5/5/20 17:04, Mikael Vidstedt wrote: On May 5, 2020, at 4:48 PM,serguei.spit...@oracle.com wrote: Hi Mikael, The fixes in webrev look good to me. I've just noticed a couple

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

On Mon, 28 Sep 2020 19:53:37 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

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

On Thu, 3 Dec 2020 23:44:20 GMT, Magnus Ihse Bursie wrote: > A lot (but not all) of the data in make/data is tied to a specific module. > For instance, the publicsuffixlist is used by java.base, and fontconfig by > java.desktop. (A few directories, like mainmanifest, is *actua

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

A lot (but not all) of the data in make/data is tied to a specific module. For instance, the publicsuffixlist is used by java.base, and fontconfig by java.desktop. (A few directories, like mainmanifest, is *actually* used by make for the whole build.) These data files should move to the

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

On Fri, 4 Dec 2020 11:14:49 GMT, Alan Bateman wrote: >> To facilitate review, here is a list on how the different directories under >> make/data has moved. >> >> **To java.base:** >> * blacklistedcertsconverter >> * cacerts >> * characterdata >> * charsetmapping >> * cldr >> * currency >> *

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

On Fri, 4 Dec 2020 11:37:41 GMT, Magnus Ihse Bursie wrote: >> Are you proposing any text or guidelines to be added to JEP 201 as part of >> this? >> >> I think the location of jdwp.spec and its location in the build tree may >> need to be looked at ag

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

On Fri, 4 Dec 2020 14:05:54 GMT, Erik Joelsson wrote: >> My understanding of JEPs is that they should be viewed as living documents. >> In this case, I think it's perfectly valid to update JEP 201 with additional >> source code layout. Both for this and for the other missing dirs. > >

Re: RFR: 8253497: Core Libs Terminology Refresh [v2]

On Tue, 15 Dec 2020 01:41:07 GMT, Joe Wang wrote: >> I agree that there is room for improvement here. How about: >> "...an allow-list too restrictively, or a reject-list too broadly, may..." >> ? > > Your call, I'm not a native English speaker :-) It felt to me it's > 'restrictive' than

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: 8255616: Disable AOT and Graal in Oracle OpenJDK

On Fri, 30 Oct 2020 17:40:51 GMT, Vladimir Kozlov wrote: > We shipped Ahead-of-Time compilation (the jaotc tool) in JDK 9, as an > experimental feature. We shipped Graal as an experimental JIT compiler in JDK > 10. We haven't seen much use of these features, and the effort required to >

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

On Mon, 25 Jan 2021 19:38:16 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: 8257733: Move module-specific data from make to respective module

On 2021-01-15 19:27, mark.reinh...@oracle.com wrote: Feature JEPs are living documents until such time as they are delivered. In this case it would not be appropriate to update JEP 201, which is as much about the transition from the old source-code layout as it is about the new layout as of

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

On Sun, 24 Jan 2021 15:32:59 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

[jdk16] RFR: 8258378: Final nroff manpage update for JDK 16

Before RC phase we need to ensure we have the final set of manpage updates published in OpenJDK. - Commit messages: - 8258378: Final nroff manpage update for JDK 16 Changes: https://git.openjdk.java.net/jdk16/pull/142/files Webrev:

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

On Mon, 1 Feb 2021 12:35:05 GMT, Alan Hayward wrote: > > Hello, hsdis is a separate out-of-tree project and is not part of this jep. > > Unless there's something I'm missing it only requires a few lines of change > to src/utils/hsdis/makefile (it already has support for macos x86_64) I agree

  1   2   >