Hi Erik -
Quite right, thanks. Actually I should include recognising VS2015 while
I'm doing this.
Update: http://cr.openjdk.java.net/~kevinw/8203349/webrev.01/
Also, update Abstract_VM_Version::internal_vm_info_string() in
src/share/vm/runtime/vm_version.cpp so the long version string is
Hi all,
Here is an updated webrev:
http://cr.openjdk.java.net/~clanger/webrevs/8201429.2/
Can someone from the graphics/awt team please have a look at that change?
Especially checking that we don't break non-AIX platforms? Thanks in advance.
@Ichiroh: Thanks for your review and tests. Adressing
Hi Igor,
we get compiler warnings on linux ppc64le (GCC 4.8.5):
libnativeGC05.c:80:19: error: 'pair_getj_mid' may be used uninitialized in this
function [-Werror=maybe-uninitialized]
j = (*env)->CallIntMethod(env, pair, pair_getj_mid);
^
libnativeGC05.c:78:19
Hi,
Currently the jfr (Flight Recorder) feature is being built by default
for Zero JVMs. However, it's not clear whether there will be jfr
support for the Zero variant JVM. At this point, when
StartFlightRecording option is being used for a Zero JVM it
asserts/crashes. It seems more appropriate to
Hi,
I tried to use the IJG's contact page, but no joy. Seems broken; there a
spinning icon when you hit "send", but nothing happens.
http://jpegclub.org/reference/contact/
So I used a slightly older mailing list on sourceforge. The request to
update their code has been sent, and I hope it will
Hello Kevin,
I have a machine with both 2015 and 2017 installed and checked the link
version numbers:
VS2015:
C:\Program Files (x86)\Microsoft Visual Studio 14.0>link /?
Microsoft (R) Incremental Linker Version 14.00.24215.1
Copyright (C) Microsoft Corporation. All rights reserved.
VS2017:
The change makes sense, but I think I would prefer if the conditional
was based on jvm variant rather than the target cpu, like this:
if ! HOTSPOT_CHECK_JVM_VARIANT(zero); then
/Erik
On 2018-05-18 06:57, Severin Gehwolf wrote:
Hi,
Currently the jfr (Flight Recorder) feature is being built b
Hi Erik,
On Fri, 2018-05-18 at 08:41 -0700, Erik Joelsson wrote:
> The change makes sense, but I think I would prefer if the conditional
> was based on jvm variant rather than the target cpu, like this:
>
> if ! HOTSPOT_CHECK_JVM_VARIANT(zero); then
Thanks for the review!
New webrev:
http://cr
Looks good (assuming you have verified that it behaves as it should)
/Erik
On 2018-05-18 09:27, Severin Gehwolf wrote:
Hi Erik,
On Fri, 2018-05-18 at 08:41 -0700, Erik Joelsson wrote:
The change makes sense, but I think I would prefer if the conditional
was based on jvm variant rather than t
Great, thanks, rebuilt the webrev.
If we add many more there we might want to rethink or reword the sanity
warning, but I'd like to save that for another time. 8-)
Thanks
Kevin
On 18/05/2018 16:29, Erik Joelsson wrote:
Hello Kevin,
I have a machine with both 2015 and 2017 installed and che
Looks good.
/Erik
On 2018-05-18 09:53, Kevin Walls wrote:
Great, thanks, rebuilt the webrev.
If we add many more there we might want to rethink or reword the
sanity warning, but I'd like to save that for another time. 8-)
Thanks
Kevin
On 18/05/2018 16:29, Erik Joelsson wrote:
Hello Kevi
I admire your perseverance :) but I think this is a fools errand.
The amount of work you have to put into this far outbalances the
amount of work the OpenJDK maintainers would have to spend when (if
ever) they were to merge down upstream libjpeg.
Note that we have a lot of experience with downstr
Hi Martin,
as it breaks build, it definitely has to be fixed. I have filed 8203437. the
obvious fix for this warning would be:
> diff -r 3af6ed2513aa
> test/hotspot/jtreg/vmTestbase/gc/gctests/nativeGC05/libnativeGC05.c
> --- a/test/hotspot/jtreg/vmTestbase/gc/gctests/nativeGC05/libnativeGC05.c
Hi,
I'd like to get a review of a backport from 9 to 8u:
8078437: Enable use of devkits for Windows.
JBS: https://bugs.openjdk.java.net/browse/JDK-8078437
9 changeset:
URL: http://hg.openjdk.java.net/jdk9/dev/rev/bc02cff96b92
9 review thread:
http://mail.openjdk.java.net/pipermail/build-dev/
Hello,
In toolchain_windows.m4, line 296 needs indentation. Also you skipped
line 327-332 which were broken up in the jdk 9 change.
Can't see anything functionally bad, only style issues.
I don't think you need to specify --with-toolchain-version=2013 when
using the devkit, it should contain
Thanks Erik -
OK, got those indent and line breaks added, updated webrev in the same
location.
Quite right, it will accept the devkit location with being told its
specific toolchain version.
Thanks for the feeback!
Kevin
On 18/05/2018 22:14, Erik Joelsson wrote:
Hello,
In toolchain_wind
Looks good.
/Erik
On 2018-05-18 14:58, Kevin Walls wrote:
Thanks Erik -
OK, got those indent and line breaks added, updated webrev in the same
location.
Quite right, it will accept the devkit location with being told its
specific toolchain version.
Thanks for the feeback!
Kevin
On 18/
17 matches
Mail list logo
