On Tue, 14 Jun 2022 11:54:40 GMT, Erik Joelsson wrote:
>> Magnus Ihse Bursie has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Fix exitTransportWithError signature
>
> make/autoconf/flags-ldflags.m4 line 132:
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 ha
e from our builds, at least on
> linux and windows. There are no more `__DATE__` and `__TIME__` macros in the
> source code.
Magnus Ihse Bursie has updated the pull request incrementally with one
additional commit since the last revision:
Fix exitTransportWithError signature
-
On Tue, 14 Jun 2022 09:48:25 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 b
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
configuration for a year or so internally within Oracle, with no
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
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 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 code is more or less functionally equivalent to the old. There were
some
On Wed, 18 May 2022 14:46:42 GMT, Alexey Ivanov wrote:
> Replaces usages of articles that follow each other in all combinations:
> a/the, an?/an?, the/the…
>
> It's the last issue in the series, and it still touches different areas of
> the code.
Build changes look good. Thanks for the
On Thu, 21 Apr 2022 11:22:48 GMT, Magnus Ihse Bursie wrote:
> I ran `codespell` on modules owned by the serviceability team
> (`java.instrument java.management.rmi java.management jdk.attach
> jdk.hotspot.agent jdk.internal.jvmstat jdk.jcmd jdk.jconsole jdk.jdi
> jdk.jdwp.agen
oling support for running `codespell`.
> The trouble with automating this is of course all false positives. But before
> even trying to solve that issue, all true positives must be fixed. Hence this
> PR.
Magnus Ihse Bursie has updated the pull request incrementally with one
additional commit
oling support for running `codespell`.
> The trouble with automating this is of course all false positives. But before
> even trying to solve that issue, all true positives must be fixed. Hence this
> PR.
Magnus Ihse Bursie has updated the pull request incrementally with one
additional commit
On Wed, 11 May 2022 13:05:45 GMT, Erik Gahlin wrote:
>> make/modules/jdk.jfr/Java.gmk line 26:
>>
>>> 24: #
>>> 25:
>>> 26: DISABLED_WARNINGS_java += exports lossy-conversions
>>
>> Note that with the fix of JDK-8286392 (and JDK-8286396) the
>> `lossy-conversions` warning should not be
On Wed, 11 May 2022 07:45:39 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
On Thu, 21 Apr 2022 16:17:20 GMT, Kevin Walls wrote:
>> I ran `codespell` on modules owned by the serviceability team
>> (`java.instrument java.management.rmi java.management jdk.attach
>> jdk.hotspot.agent jdk.internal.jvmstat jdk.jcmd jdk.jconsole jdk.jdi
>> jdk.jdwp.agent jdk.jstatd
On Thu, 21 Apr 2022 14:03:39 GMT, Daniel Fuchs wrote:
>> I ran `codespell` on modules owned by the serviceability team
>> (`java.instrument java.management.rmi java.management jdk.attach
>> jdk.hotspot.agent jdk.internal.jvmstat jdk.jcmd jdk.jconsole jdk.jdi
>> jdk.jdwp.agent jdk.jstatd
I ran `codespell` on modules owned by the serviceability team (`java.instrument
java.management.rmi java.management jdk.attach jdk.hotspot.agent
jdk.internal.jvmstat jdk.jcmd jdk.jconsole jdk.jdi jdk.jdwp.agent jdk.jstatd
jdk.management.agent jdk.management`), and accepted those changes where
On Fri, 15 Apr 2022 07:40:04 GMT, Magnus Ihse Bursie wrote:
> I ran `codespell` on hotspot, and accepted those changes where it indeed
> discovered real typos.
>
> You'd be surprised over the many implementions of instrinsics and other
> intructions accross all archtectures
ery to sucessfully seach for exisiting typos...
Magnus Ihse Bursie has updated the pull request incrementally with one
additional commit since the last revision:
Update copyright headers
-
Changes:
- all: https://git.openjdk.java.net/jdk/pull/8260/files
- new: https://git.openjdk
ery to sucessfully seach for exisiting typos...
Magnus Ihse Bursie has updated the pull request incrementally with one
additional commit since the last revision:
Fix some places according to code reviews
-
Changes:
- all: https://git.openjdk.java.net/jdk/pull/8260/fi
On Fri, 15 Apr 2022 07:40:04 GMT, Magnus Ihse Bursie wrote:
> I ran `codespell` on hotspot, and accepted those changes where it indeed
> discovered real typos.
>
> You'd be surprised over the many implementions of instrinsics and other
> intructions accross all archtectures
I ran `codespell` on hotspot, and accepted those changes where it indeed
discovered real typos.
You'd be surprised over the many implementions of instrinsics and other
intructions accross all archtectures I've encounted, so for the preceding
reason it's neccesery to sucessfully seach for
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 fix
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 few are in messages aimed at the user.
-
Commit messages:
-
On Thu, 14 Apr 2022 09:28:17 GMT, Andrey Turbanov wrote:
>> Found various typos of expected: `exepected`, `exept`, `epectedly`,
>> `expeced`, `Unexpeted`, etc.
>
> Andrey Turbanov has updated the pull request incrementally with one
> additional commit since the last revision:
>
> 8284853:
On Fri, 8 Apr 2022 13:43:39 GMT, Alan Bateman wrote:
> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which
> JDK version to target.
>
> We will refresh this PR periodically to pick up changes and fixes from the
> loom repo.
>
> Most of the new mechanisms in the
On Mon, 8 Nov 2021 11:17:47 GMT, Fei Yang wrote:
> This PR implements JEP 422: Linux/RISC-V Port [1].
> The PR starts as a squashed merge of the
> https://openjdk.java.net/projects/riscv-port branch.
>
> This has been tested with jtreg tier{1,2,3,4} and jcstress on HiFive
> Unmatched board.
On Mon, 7 Mar 2022 16:40:15 GMT, Lance Andersen wrote:
>> Hi
>>
>> I have reviewed the code for removing double semicolons at the end of lines
>>
>> all the best
>> matteo
>
> What problem are you having editing the PR header? You should be able to do
> so as the author of the PR
On Fri, 4 Mar 2022 17:17:12 GMT, Roger Riggs wrote:
>> Hi
>>
>> I have reviewed the code for removing double semicolons at the end of lines
>>
>> all the best
>> matteo
>
> We usually request that these be be broken up by area to attract the
> appropriate reviewers and avoid eye-strain. The
On Sun, 5 Dec 2021 23:45:32 GMT, Joe Darcy wrote:
> Exploratory builds indicate it is not currently necessary to exclude the
> doclint accessibility checks; this patch enables them.
>
> (Enabling the reference checks is left for future work.)
-
Marked as reviewed by ihse
On Thu, 4 Nov 2021 10:44:41 GMT, Magnus Ihse Bursie wrote:
> I ran bin/blessed-modifier-order.sh on source owned by serviceability. This
> scripts verifies that modifiers are in the "blessed" order, and fixes it
> otherwise. I have manually checked the changes made by
> I ran bin/blessed-modifier-order.sh on source owned by serviceability. This
> scripts verifies that modifiers are in the "blessed" order, and fixes it
> otherwise. I have manually checked the changes made by the script to make
> sure they are sound.
Magnus Ihse Bursi
On Thu, 4 Nov 2021 15:59:48 GMT, Chris Plummer wrote:
>> I ran bin/blessed-modifier-order.sh on source owned by serviceability. This
>> scripts verifies that modifiers are in the "blessed" order, and fixes it
>> otherwise. I have manually checked the changes made by the script to make
>> sure
I ran bin/blessed-modifier-order.sh on source owned by serviceability. This
scripts verifies that modifiers are in the "blessed" order, and fixes it
otherwise. I have manually checked the changes made by the script to make sure
they are sound.
-
Commit messages:
- 8276628: Use
I noticed the following piece of code in
src/jdk.internal.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/v1_0/PerfDataBuffer.java:
if(jvm_name.stringValue().indexOf("HotSpot") >= 0) {
if(jvm_version.stringValue().startsWith("1.4.2")) {
kludgeMantis(map, args);
}
}
It looks like there's
On 2021-09-02 07:01, Jakob Cornell wrote:
Hi all,
While working on changes for JBS 8271356 I spent some time testing on
locales other than en-US and found something a bit odd. I can
override the system default locale for JDB by setting the `LANG'
environment variable (on Linux), and I
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
On Fri, 5 Feb 2021 09:49:11 GMT, Andrew Haley wrote:
>> I reviewed bsd_aarch64.cpp digging bit deeper and left some comments.
>
>> > Umm, so how does patching work? We don't even know if other threads are
>> > executing the code we need to patch.
>>
>> I thought java can handle that scenario
On Wed, 3 Feb 2021 20:01:15 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
On Tue, 2 Feb 2021 21:20:52 GMT, Daniel D. Daugherty wrote:
>> Anton Kozlov has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> support macos_aarch64 in hsdis
>
> make/autoconf/flags.m4 line 140:
>
>> 138: else
>> 139:
We need to regenerate the exported nroff man pages to include the proper
version string. This will also bring in some recent textual updates to the man
pages.
-
Commit messages:
- 8261149: Initial nroff manpage update for JDK 17
Changes:
On 2021-02-02 21:47, Chris Plummer wrote:
Is there a reason why `java.desktop` continues to use `JNFJavaToNSString`? I
was looking to see how this was handled in other places, but I couldn't find an
example where `JNFJavaToNSString` was converted to call a newly implemented
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
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:
On Thu, 28 Jan 2021 22:40:57 GMT, Phil Race wrote:
> This removes the JNF dependency from the jdk.hotspot.agent module.
> The macro expansions are the same as already used in the Java desktop module
> - which actually uses a macro
> still but there there are hundreds of uses.
> The function of
On Tue, 26 Jan 2021 21:59:03 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
On Tue, 26 Jan 2021 22:04:48 GMT, Vladimir Kempik wrote:
>> make/autoconf/build-aux/autoconf-config.guess line 1275:
>>
>>> 1273: UNAME_PROCESSOR="aarch64"
>>> 1274: fi
>>> 1275: fi ;;
>>
>> Almost, but not quite, correct. We cannot change the
On Mon, 25 Jan 2021 16:00:23 GMT, Bernhard Urban-Forster
wrote:
>> @luhenry , could you please check this comment, I think SA-agent was MS's
>> job here.
>
> The target is identified by the header file now:
>
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
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
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
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
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
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.
>
>
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
>> *
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
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
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
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
>
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
>
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
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
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
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
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
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
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
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
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
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
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
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
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
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
).
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
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
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
/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
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
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
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
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
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
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
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
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
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
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()
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
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
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
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
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
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
/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
> 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
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
> 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
>
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
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
1 - 100 of 147 matches
Mail list logo
