On Thu, 24 Mar 2022 03:53:52 GMT, Phil Race wrote:
> And unless you're backing up your claim that this patch is changing runtime
> characteristic with data, that's just a guess, just like the initial
> optimization level of this library (and as most of the native libraries in
> the JDK... :-()
On Wed, 23 Mar 2022 23:17:38 GMT, Magnus Ihse Bursie wrote:
>> [JDK-8247872](https://bugs.openjdk.java.net/browse/JDK-8247872) (upgrade
>> HarfBuzz to 2.7.2) caused build time to go up with 24 seconds on my
>> reference linux machine. This was one of the four culprits that caused a
>> 25-30% b
On Wed, 5 Jan 2022 08:42:41 GMT, Aleksey Shipilev wrote:
> Following up on suggestion here:
> https://github.com/openjdk/jdk/pull/6720#discussion_r778457819
Thank you!
-
Marked as reviewed by serb (Reviewer).
PR: https://git.openjdk.java.net/jdk/pull/6964
On Mon, 6 Dec 2021 11:12:22 GMT, Aleksey Shipilev wrote:
> This adds the test repeat feature in the build system. This is convenient to
> follow-up on intermittently failing tests: the `REPEAT_COUNT > 0` would run
> the test multiple times, until we run out of repeats or the tests fail.
>
> Wi
The "missing-explicit-ctor" check was disabled by the
[JDK-8071961](https://bugs.openjdk.java.net/browse/JDK-8071961) and later was
fixed by the [JDK-8250853](https://bugs.openjdk.java.net/browse/JDK-8250853).
So we can re-enable this check again.
The fix will remove the "Java.gmk" file and as
On Thu, 2 Dec 2021 10:55:57 GMT, Andrew Leonard wrote:
> This is the case at Adoptium for example, which uses the Mozilla trusted CA
> certs.
But they didn't think skipping this test was too strong a step? For example
validation of the certs expiration is quite useful. I tried to update the te
On Wed, 1 Dec 2021 18:30:06 GMT, Andrew Leonard wrote:
> Addition of a configure option --with-cacerts-src='user cacerts folder' to
> allow developers to specify their own cacerts PEM folder for generation of
> the cacerts store using the deterministic openjdk GenerateCacerts tool.
>
> Signed-
On Thu, 21 Oct 2021 17:04:08 GMT, Jiří Vaněk wrote:
> The run targets of makefile to run J2DBench.jar/J2DAnalyzer.jar were
> lacking the dist directory. This patch is fixing it. Note, that
> build.xml have correct paths
src/demo/share/java2d/J2DBench/Makefile line 2:
> 1: #
> 2: # Copyright (c)
On Thu, 21 Oct 2021 17:04:08 GMT, Jiří Vaněk wrote:
> The run targets of makefile to run J2DBench.jar/J2DAnalyzer.jar were
> lacking the dist directory. This patch is fixing it. Note, that
> build.xml have correct paths
this looks fine, please update the copyright date
-
PR: https:
On Sun, 10 Oct 2021 22:35:40 GMT, Sergey Bylokhov wrote:
> This fix changes the AbsPathsInImage test to skip *.dSYM directories.
This pull request has now been integrated.
Changeset: dd93c6e2
Author: Sergey Bylokhov
URL:
https://git.openjdk.java.net/jdk/com
This fix changes the AbsPathsInImage test to skip *.dSYM directories.
-
Commit messages:
- Update AbsPathsInImage.java
Changes: https://git.openjdk.java.net/jdk/pull/5885/files
Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5885&range=00
Issue: https://bugs.openjdk.java.ne
On Fri, 24 Sep 2021 13:36:51 GMT, Jie Fu wrote:
>> Hi all,
>>
>> I'd like to update the testing docs for MacOS with Non-US locale.
>>
>> Our experiments show that the solution mentioned for Windows with Non-US
>> locale also works for MacOS.
>> So it would be helpful to mention MacOS explicitl
On Sun, 22 Aug 2021 15:09:26 GMT, Alan Bateman wrote:
>> Sergey Bylokhov has updated the pull request with a new target base due to a
>> merge or a rebase. The incremental webrev excludes the unrelated changes
>> brought in by the merge/rebase. The pull request cont
On Sun, 22 Aug 2021 18:31:02 GMT, Andrey Turbanov
wrote:
> I think it's worth to update _static_ initializer in
> `sun.datatransfer.DataFlavorUtil.CharsetComparator` too.
Updated as suggested.
-
PR: https://git.openjdk.java.net/jdk/pull/5210
n this fix: the Xerces library(should be fixed upstream),
> J2DBench(should be compatible to 1.4), some code in the network(the change
> there are not straightforward, will do it later).
>
> Tested by the tier1/tier2/tier3 tests on Linux/Windows/macOS.
Sergey Bylokhov has updated the
This is the continuation of JDK-8233884, JDK-8271456, and JDK-8272120.
See https://github.com/openjdk/jdk/pull/5063 and
https://github.com/openjdk/jdk/pull/4951
In many places standard charsets are looked up via their names, for example:
absolutePath.getBytes("UTF-8");
This could be done more ef
On Thu, 8 Jul 2021 18:59:56 GMT, Alexandre Iline wrote:
> JDK-8270108: Update JCov version to 3.0.9
Will it support the new class file format in jdk18?
-
PR: https://git.openjdk.java.net/jdk/pull/4729
On Thu, 8 Jul 2021 18:59:56 GMT, Alexandre Iline wrote:
> JDK-8270108: Update JCov version to 3.0.9
Marked as reviewed by serb (Reviewer).
-
PR: https://git.openjdk.java.net/jdk/pull/4729
On Tue, 18 May 2021 15:55:09 GMT, Phil Race wrote:
> See the bug report for lots of explanation.
> The short version (not that short) is that Swing adds a new line char to
> editable TextComponents
> It used to work because harfbuzz asked CoreText which mapped it to an
> invisible glyph
> Now h
On Tue, 18 May 2021 15:55:09 GMT, Phil Race wrote:
> See the bug report for lots of explanation.
> The short version (not that short) is that Swing adds a new line char to
> editable TextComponents
> It used to work because harfbuzz asked CoreText which mapped it to an
> invisible glyph
> Now h
On Wed, 12 May 2021 00:06:34 GMT, Sergey Bylokhov wrote:
> Performance in one of the tests in the bimg_misc group is dropped by 20%(or
> 5% of the group) after some unused code was removed from the libawt. I assume
> the size of the lib became smaller and GCC heuristics were changed
Performance in one of the tests in the bimg_misc group is dropped by 20%(or 5%
of the group) after some unused code was removed from the libawt. I assume the
size of the lib became smaller and GCC heuristics were changed to do not try to
increase the size by inlining over some percent. I tested
On Fri, 30 Apr 2021 20:07:53 GMT, Phil Race wrote:
> Upgrade to harfbuzz 2.8
I assume the build using bundled lib is fine on all our platforms.
-
Marked as reviewed by serb (Reviewer).
PR: https://git.openjdk.java.net/jdk/pull/3826
On Wed, 31 Mar 2021 19:02:46 GMT, Mikael Vidstedt wrote:
>> This adds the necessary macosx-aarch64 support to the build configurations
>> at Oracle.
>
> Mikael Vidstedt has updated the pull request with a new target base due to a
> merge or a rebase. The incremental webrev excludes the unrelate
On Tue, 30 Mar 2021 06:25:21 GMT, Mikael Vidstedt wrote:
> This adds the necessary macosx-aarch64 support to the build configurations at
> Oracle.
make/conf/jib-profiles.js line 456:
> 454: configure_args: concat(common.configure_args_64bit,
> "--with-zlib=system",
> 455:
On Thu, 11 Mar 2021 18:00:15 GMT, Ajit Ghaisas wrote:
>> **Description :**
>> This is the implementation of [JEP 382 : New macOS Rendering
>> Pipeline](https://bugs.openjdk.java.net/browse/JDK-8238361)
>> It implements a Java 2D internal rendering pipeline for macOS using the
>> Apple Metal API
On Sat, 13 Mar 2021 00:15:16 GMT, Phil Race wrote:
> From a build perspective this partially reverts
> https://bugs.openjdk.java.net/browse/JDK-8249821 except that it keeps
> the harfbuzz sources separate and still supports building and running against
> a system harfbuzz which is only of inte
On Fri, 12 Mar 2021 00:09:54 GMT, Kevin Rushforth wrote:
>> Ajit Ghaisas has updated the pull request with a new target base due to a
>> merge or a rebase. The incremental webrev excludes the unrelated changes
>> brought in by the merge/rebase. The pull request contains 47 additional
>> commit
On Fri, 12 Mar 2021 02:29:04 GMT, Jayathirth D V wrote:
>> src/java.desktop/macosx/classes/sun/java2d/metal/MTLSurfaceData.java line
>> 323:
>>
>>> 321: * more code just to support a few uncommon cases.
>>> 322: */
>>> 323: public boolean canRenderLCDText(SunGraphics2D sg2d) {
>>
On Thu, 11 Mar 2021 18:00:15 GMT, Ajit Ghaisas wrote:
>> **Description :**
>> This is the implementation of [JEP 382 : New macOS Rendering
>> Pipeline](https://bugs.openjdk.java.net/browse/JDK-8238361)
>> It implements a Java 2D internal rendering pipeline for macOS using the
>> Apple Metal API
On Wed, 10 Mar 2021 11:43:43 GMT, Ajit Ghaisas wrote:
>> src/java.desktop/macosx/classes/sun/lwawt/macosx/CWarningWindow.java line
>> 304:
>>
>>> 302: };
>>> 303: }
>>> 304: public MTLLayer createMTLLayer() {
>>
>> TODO to test that this functionality wo
On Tue, 9 Mar 2021 20:16:25 GMT, Alexey Ushakov wrote:
>> src/java.desktop/macosx/classes/sun/java2d/metal/MTLBlitLoops.java line 499:
>>
>>> 497: }
>>> 498:
>>> 499: // We can convert argb_pre data from MTL surface in two places:
>>
>> Does anybody check that this is true for
On Tue, 9 Mar 2021 22:11:20 GMT, Alexey Ushakov wrote:
>> src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLSurfaceDataBase.h
>> line 109:
>>
>>> 107: #define MTLSD_TEXTURE sun_java2d_pipe_hw_AccelSurface_TEXTURE
>>> 108: #define MTLSD_FLIP_BACKBUFFER
>>> sun_java2d_pipe_hw_A
On Sun, 7 Mar 2021 22:48:47 GMT, Sergey Bylokhov wrote:
>> Ajit Ghaisas has updated the pull request with a new target base due to a
>> merge or a rebase. The incremental webrev excludes the unrelated changes
>> brought in by the merge/rebase. The pull request cont
On Mon, 8 Mar 2021 08:06:03 GMT, Ajit Ghaisas wrote:
>> **Description :**
>> This is the implementation of [JEP 382 : New macOS Rendering
>> Pipeline](https://bugs.openjdk.java.net/browse/JDK-8238361)
>> It implements a Java 2D internal rendering pipeline for macOS using the
>> Apple Metal API.
On Mon, 8 Mar 2021 07:46:54 GMT, Yasumasa Suenaga wrote:
>> src/jdk.accessibility/windows/native/common/AccessBridgeDebug.cpp line 80:
>>
>>> 78: uli.LowPart = ft.dwLowDateTime;
>>> 79: uli.HighPart = ft.dwHighDateTime;
>>> 80: return (uli.QuadPart / 1ULL) - 1164447360ULL; //
On Fri, 5 Feb 2021 22:00:54 GMT, Kevin Rushforth wrote:
>> Ajit Ghaisas has updated the pull request with a new target base due to a
>> merge or a rebase. The incremental webrev excludes the unrelated changes
>> brought in by the merge/rebase. The pull request contains 36 additional
>> commits
On Mon, 1 Mar 2021 11:17:39 GMT, Ajit Ghaisas wrote:
>> **Description :**
>> This is the implementation of [JEP 382 : New macOS Rendering
>> Pipeline](https://bugs.openjdk.java.net/browse/JDK-8238361)
>> It implements a Java 2D internal rendering pipeline for macOS using the
>> Apple Metal API.
On Sun, 7 Mar 2021 19:34:36 GMT, Thomas Stuefe wrote:
> I wondered why C++ std headers are even used. The source code looks C-ish;
> but "8196681: Java Access Bridge logging and debug flags dynamically
> controlled" added some coding, adding a bunch of C++11x semantics and
> included C++ std h
On Thu, 4 Feb 2021 02:32:31 GMT, Phil Race wrote:
> remove un-needed disabling now JNF has gone ..
Marked as reviewed by serb (Reviewer).
-
PR: https://git.openjdk.java.net/jdk/pull/2396
On Tue, 2 Feb 2021 23:22:12 GMT, Phil Race wrote:
>> This completes the desktop module JNF removal
>>
>> * remove -framework JavaNativeFoundation from make files
>>
>> * remove #import from all
>> source files. If needed add import of JNIUtilities.h to get jni.h
>> definitions - better any
On Mon, 1 Feb 2021 23:47:06 GMT, Phil Race wrote:
>> src/java.desktop/macosx/native/libawt_lwawt/awt/CTextPipe.m line 611:
>>
>>> 609: const jchar *unichars = (*env)->GetStringChars(env, str, NULL);
>>> 610: if (unichars == NULL) {
>>> 611: return;
>>
>> Do not we ne
On Tue, 2 Feb 2021 21:18:42 GMT, Kevin Rushforth wrote:
>> We are just specifying an additional run mode for JDK internal use.
>> It means that when we are saying to process only events for that mode, then
>> only those will be processed.
>> And it is used only for nested event loops.
>> Nothing
On Mon, 1 Feb 2021 19:09:59 GMT, Phil Race wrote:
>> This completes the desktop module JNF removal
>>
>> * remove -framework JavaNativeFoundation from make files
>>
>> * remove #import from all
>> source files. If needed add import of JNIUtilities.h to get jni.h
>> definitions - better any
On Thu, 28 Jan 2021 16:08:53 GMT, Erik Joelsson wrote:
>> To guarantee backwards compatible binaries on Macos, we use the option
>> -mmacosx-version-min. This is currently set to 10.9, which is a really
>> ancient version. I propose we bump this to 10.12, which is still a rather
>> conservativ
On Wed, 27 Jan 2021 20:43:44 GMT, Phil Race wrote:
>> To guarantee backwards compatible binaries on Macos, we use the option
>> -mmacosx-version-min. This is currently set to 10.9, which is a really
>> ancient version. I propose we bump this to 10.12, which is still a rather
>> conservative ol
On Mon, 11 Jan 2021 19:27:12 GMT, Phil Race wrote:
>> Proposed updates to JNI error handling.
>
> Phil Race has updated the pull request incrementally with one additional
> commit since the last revision:
>
> 8259343: [macOS] Update JNI error handling in Cocoa code.
Marked as reviewed by ser
On Tue, 12 Jan 2021 17:21:53 GMT, Phil Race wrote:
>> src/java.desktop/macosx/native/libosxapp/JNIUtilities.h line 197:
>>
>>> 195: } \
>>> 196: if (getenv("JNU_NO_COCOA_EXCEPTION") == NULL) { \
>>> 197: [NSException raise:NSGenericException format:@"Java
>>> Excep
On Mon, 11 Jan 2021 17:09:14 GMT, Phil Race wrote:
>> src/java.desktop/macosx/native/libosxapp/JNIUtilities.h line 41:
>>
>>> 39:NSLog(@"%@",[NSThread callStackSymbols]); \
>>> 40:if ([NSThread isMainThread] == NO) { \
>>> 41:if ((*env)->ExceptionOccurred(env) == NULL
On Mon, 11 Jan 2021 19:27:12 GMT, Phil Race wrote:
>> Proposed updates to JNI error handling.
>
> Phil Race has updated the pull request incrementally with one additional
> commit since the last revision:
>
> 8259343: [macOS] Update JNI error handling in Cocoa code.
src/java.desktop/macosx/n
On Fri, 8 Jan 2021 19:17:17 GMT, Phil Race wrote:
>> That code for sure should be called, it is even improved recently by
>> JDK-8255681
>> I'll check how it was intended to work.
>
> I hadn't noticed that line - and definintely not realised it was recent.
> I suppose he must have had a way to t
On Wed, 6 Jan 2021 21:14:06 GMT, Phil Race wrote:
> Proposed updates to JNI error handling.
src/java.desktop/macosx/native/libosxapp/JNIUtilities.h line 41:
> 39:NSLog(@"%@",[NSThread callStackSymbols]); \
> 40:if ([NSThread isMainThread] == NO) { \
> 41:if ((*env)->
On Fri, 8 Jan 2021 19:05:09 GMT, Phil Race wrote:
>> Proposed updates to JNI error handling.
>
> src/java.desktop/macosx/native/libosxapp/JNIUtilities.h line 46:
>
>> 44: if ((*env)->ExceptionOccurred(env) != NULL) { \
>> 45: (*env)->ExceptionDescribe(env); \
>> 4
On Fri, 8 Jan 2021 02:40:58 GMT, Phil Race wrote:
>> src/java.desktop/macosx/native/libosxapp/JNIUtilities.h line 41:
>>
>>> 39:NSLog(@"%@",[NSThread callStackSymbols]); \
>>> 40:if ([NSThread isMainThread] == NO) { \
>>> 41:JNU_ThrowInternalError(env, "Bad JNI Lookup
On Wed, 6 Jan 2021 21:14:06 GMT, Phil Race wrote:
> Proposed updates to JNI error handling.
src/java.desktop/macosx/native/libosxapp/JNIUtilities.h line 180:
> 178: * nature of the problem that has been detected and how survivable it is.
> 179: */
> 180: #define CHECK_EXCEPTION() \
Since thi
On Wed, 9 Dec 2020 17:40:34 GMT, Victor Dyakov wrote:
>>> > @kevinrushforth @prrace could you please review?
>>>
>>> As we discussed yesterday, it is reviewed but not ready to be approved.
>>> We are waiting for a reply from Apple.
>>
>> @prrace
>> We are waiting for it for three months alread
On Tue, 24 Nov 2020 19:10:04 GMT, Joe Darcy wrote:
> With the default constructors warnings in java.desktop and jdk.accessibility
> now fixed, the warning should be enabled in the build for those modules.
Marked as reviewed by serb (Reviewer).
-
PR: https://git.openjdk.java.net/jd
On Tue, 17 Nov 2020 21:04:08 GMT, Erik Joelsson wrote:
> In Xcode 12.2, the framework JavaVM was removed in the sysroot and all
> (relevant) frameworks inside were just moved one step up so we still find
> things like JavaNativeFoundation and JavaRuntimeSupport. There is however one
> test tha
On Tue, 10 Nov 2020 16:38:25 GMT, Kevin Rushforth wrote:
>> Change looks ok from a build point of view, but I can't comment on the
>> validity and implications of using this key.
>
> I ran a 3D lighting test that is designed to be a GPU stress test. It's a
> worst case, to be sure, but it take
On Tue, 10 Nov 2020 16:38:25 GMT, Kevin Rushforth wrote:
>> Change looks ok from a build point of view, but I can't comment on the
>> validity and implications of using this key.
>
> I ran a 3D lighting test that is designed to be a GPU stress test. It's a
> worst case, to be sure, but it take
This is a review request for the bug particularly fixed some time ago:
https://mail.openjdk.java.net/pipermail/2d-dev/2015-May/005425.html
In that review request it was found that the old fix does not work well in all
cases, see:
https://mail.openjdk.java.net/pipermail/2d-dev/2015-August/005611.h
On Thu, 5 Nov 2020 17:52:19 GMT, Phil Race wrote:
>> This upgrades JDK to import the current 2.7.2 version of harfbuzz - an
>> OpenType text shaping library
>>
>> https://bugs.openjdk.java.net/browse/JDK-8247872
>>
>> This has passed building and headless and headful automated tests on all
>>
On Mon, 2 Nov 2020 16:23:19 GMT, Phil Race wrote:
>> I'm just a bit curious about the added, empty,
>> `src/java.desktop/share/native/libharfbuzz/abc.txt`...
>>
>> If it really is in upstream source, I'm not saying you should remove it. It
>> just looks very odd. It's not a merge artifact?
>>
On Tue, 3 Nov 2020 01:07:51 GMT, Phil Race wrote:
>> If we build a headless only JDK, configure will require X11 libraries and
>> headers to be present. This used to be necessary, but thanks to massive
>> cleanups in the AWT headless code, this is no longer the case.
>>
>> We should fix config
On Mon, 2 Nov 2020 11:59:09 GMT, Maurizio Cimadamore
wrote:
>> This patch contains the changes associated with the third incubation round
>> of the foreign memory access API incubation (see JEP 393 [1]). This
>> iteration focus on improving the usability of the API in 3 main ways:
>>
>> * fi
On Sun, 6 Sep 2020 13:57:19 GMT, Dmitriy Dumanskiy
wrote:
> **isEmpty** is faster + has less byte code + easier to read. Benchmarks could
> be found
>
> [here](https://medium.com/javarevisited/micro-optimizations-in-java-string-equals-22be19fd8416).
src/demo/share/java2d/J2DBench/src/j2dben
On Mon, 7 Sep 2020 07:20:02 GMT, Magnus Ihse Bursie wrote:
>> 8251549: Update docs on building for Git
>
> doc/building.md line 92:
>
>> 90: spaces and/or mixed upper and lower case letters.
>> 91:
>> 92: * Clone the JDK repository using [Git for
>> Windows](https://gitforwindows.
On 27.08.2020 12:55, Philip Race wrote:
SAP or IBM can look at it if they want as a separate fix.
ok, +1
-phil.
On 8/27/20, 12:45 PM, Sergey Bylokhov wrote:
Hi, Phil.
Probably we could enable WARNINGS_AS_ERRORS_xlc as well? I guess we will need a
confirmation from the SAP gurus.
On
Hi, Phil.
Probably we could enable WARNINGS_AS_ERRORS_xlc as well? I guess we will need a
confirmation from the SAP gurus.
On 27.08.2020 12:39, Philip Race wrote:
Bug : https://bugs.openjdk.java.net/browse/JDK-8074844
Webrev : http://cr.openjdk.java.net/~prr/8074844/index.html
This resolves t
undle-build-version from the jib configuration for CI builds.
New webrev, only difference is in jib-profiles.js.
http://cr.openjdk.java.net/~erikj/8252145/webrev.02/
/Erik
On 2020-08-25 16:35, Sergey Bylokhov wrote:
Looks fine.
On 25.08.2020 07:27, Erik Joelsson wrote:
On 2020-08-24 19:18, S
Looks fine.
On 25.08.2020 07:27, Erik Joelsson wrote:
On 2020-08-24 19:18, Sergey Bylokhov wrote:
Hi, Erik.
I would like to highlight one thing affected by this fix. The text in the
default about dialog in the Swing application will be changed.
For my local build:
- Current text: "
On 25.08.2020 16:25, Philip Race wrote:
On 8/25/20, 4:01 PM, Sergey Bylokhov wrote:
It is applied if the "automatic graphics switching" is enabled, if the user
disables
this feature for the "power adapter" mode, then the discrete graphics will be
always used.
That&#
https://bugs.openjdk.java.net/browse/JDK-8132775
Since FX does not have the launcher it depends on the "bin/java" or the packed
application.
-- Kevin
On 8/25/2020 4:01 PM, Sergey Bylokhov wrote:
On 25.08.2020 15:40, Philip Race wrote:
On 8/25/20, 12:27 PM, Sergey Bylokhov wrote:
O
On 25.08.2020 15:40, Philip Race wrote:
On 8/25/20, 12:27 PM, Sergey Bylokhov wrote:
On 25.08.2020 05:43, Kevin Rushforth wrote:
Does this only apply when the MacBook is running on battery, or will this
affect performance even when the laptop is plugged in? If the latter, I wonder
what
le.com/en-us/HT202043
-- Kevin
On 8/24/2020 11:27 PM, Sergey Bylokhov wrote:
On 24.08.2020 13:35, Philip Race wrote:
Is there any performance cost to doing this ? I'd expect so. Any estimate ?
Yes, performance is affected for sure:
- SwingMark:
OGL_Base: 14000
OGL_Fix: 24000
On 24.08.2020 13:35, Philip Race wrote:
Is there any performance cost to doing this ? I'd expect so. Any estimate ?
Yes, performance is affected for sure:
- SwingMark:
OGL_Base: 14000
OGL_Fix: 24000
Metal: 18000
- Here is a j2dbench for the common draw operations(new/old/metal):
Hi, Erik.
I would like to highlight one thing affected by this fix. The text in the
default about dialog in the Swing application will be changed.
For my local build:
- Current text: "Java Version 1.0 (16)"
- After the fix: "Java Version 16 (0)"
I am not sure why the build version and as a r
Hello.
Please review the fix for jdk/client.
Bug: https://bugs.openjdk.java.net/browse/JDK-8251854
Fix: http://cr.openjdk.java.net/~serb/8251854/webrev.00
This is a review request for the bug particularly fixed some time ago:
https://mail.openjdk.java.net/pipermail/2d-dev/2015-May/005425.html
I
+1
On 21.07.2020 12:24, Erik Joelsson wrote:
Here is a late fix for Macos Catalina. In JDK-8244951, I added a missing
entitlement to enable sound recording with the hardened runtime signing. It was
later discovered that this wasn't quite enough. To be able to record sound you
also need to spe
On 6/17/20 6:11 am, Erik Joelsson wrote:
On 2020-06-16 23:25, Sergey Bylokhov wrote:
As far as I understand this new temp folder will be cleaned after every
tests run, doesn't it look like a workaround for problematic tests and
product bugs?
This new tmp folder is created in the jtreg
As far as I understand this new temp folder will be cleaned after every
tests run, doesn't it look like a workaround for problematic tests and
product bugs?
Personally, I found many bugs in the tests and some product bugs as
well, which caused "leakage" of the temporary files.
Probably additional
On 6/8/20 3:06 pm, Claes Redestad wrote:
Right, -O3 is now likely the default for most files.
I'm not sure you suggest the reported ~2% difference between -Os and
-O2/-O3 as an argument against changing to -O3 by default. It might be
statistically significant - or just noise - but we should at a
On 6/8/20 2:17 pm, Claes Redestad wrote:
Not too similar, since that involves a compiler bug that basically
forced applying the -O1 flag to a critical piece of the runtime.>
Obviously there needs to be a pragmatic approach when hitting a compiler
bug like the one discussed in that thread, with
On 6/8/20 10:45 am, Magnus Ihse Bursie wrote:
On 2020-06-08 19:31, Sergey Bylokhov wrote:
One of the reasons why -0s was used from the beginning is the performance of
the client related libraries, especially java2d.
Does anybody run or plan to run performance tests to check that we do not have
One of the reasons why -0s was used from the beginning is the performance of
the client related libraries, especially java2d.
Does anybody run or plan to run performance tests to check that we do not have
performance there?
On 6/8/20 8:55 am, Magnus Ihse Bursie wrote:
From Jim's bug report:
Looks fine.
On 4/15/20 10:22 pm, Igor Ignatyev wrote:
http://cr.openjdk.java.net/~iignatyev//8240904/webrev.00
35 lines changed: 26 ins; 0 del; 10 mod
Hi all,
8233827[1] which added screenshots to so-called failure handler had an
unexpected side-effect on linux, where users might observer
Looks fine.
On 4/8/20 2:15 pm, Philip Race wrote:
Bug: https://bugs.openjdk.java.net/browse/JDK-8242325
Webrev : http://cr.openjdk.java.net/~prr/8242325/
With the impending removal of the Solaris SPARC port, there is even less point
than before to keeping around the VIS version of medialib, and
Hello, Christoph.
Could you shed some light on the changes below:
-statusWindow->fgGC = XCreateGC(dpy, status, valuemask, &values);
+statusWindow->fgGC = create_gc(status, FALSE);
XSetForeground(dpy, statusWindow->fgGC, fg);
-statusWindow->bgGC = XCreateGC(dpy, status, valuemask
via
"make test", and it could easily be enabled in mach5 for personal jobs(I do
this time to time)
-phil.
On 12/30/19, 11:33 AM, Sergey Bylokhov wrote:
On 12/23/19 9:15 pm, Phil Race wrote:
I am not sure what the right mailing list(s) are for this change.
It definitely isn't a c
I guess it is too late to fix it, will need to update the files at the end of
2020.
On 1/2/20 10:57 am, Erik Joelsson wrote:
Build files look good.
/Erik
On 2019-12-24 19:22, Sergey Bylokhov wrote:
Hello.
Here is an updated version:
Bug: https://bugs.openjdk.java.net/browse/JDK-8235975
logs from the OS
And it does not spend much resources compared to current handlers.
Also why exclude Windows ? No easy way to get the screenshot ?
There is no command-line program that can take a screenshot on windows by
default
-phil.
On 12/11/19 1:00 AM, Sergey Bylokhov wrote:
Hello.
P
the patch.
- "Aes128CtsHmacSha2EType.java" is updated to "Copyright (c) 2018"
On 12/22/19 11:24 pm, Sergey Bylokhov wrote:
Hello.
Please review the fix for JDK 15.
Bug: https://bugs.openjdk.java.net/browse/JDK-8235975
Patch (2 Mb): http://cr.openjdk.java.net/~serb/8235975/
Hello.
Please review the fix for JDK 15.
Bug: https://bugs.openjdk.java.net/browse/JDK-8235975
Patch (2 Mb): http://cr.openjdk.java.net/~serb/8235975/webrev.02/open.patch
Fix: http://cr.openjdk.java.net/~serb/8235975/webrev.02
I have updated the source code copyrights by the "update_copyright_ye
+1
On 11/1/19 7:41 am, Alexey Ivanov wrote:
Thank you, Dmitry!
The changes look good to me.
On 01/11/2019 13:09, Dmitry Markov wrote:
Hi Alexey,
I have updated the fix. Please find the new version here:
http://cr.openjdk.java.net/~dmarkov/8232880/webrev.03/
Thanks,
Dmitry
On 31 Oct 2019,
Hi, Dmitry.
I suggest to make this block more generic, and describe the "### Client UI -
Tests".
It would be useful to mention that the tests in this category use different key
combinations,
which might be registered as a system shortcuts, and it could cause a test
failure. It is suggested
to
Hello.
Please review the fix for JDK 14.
Bug: https://bugs.openjdk.java.net/browse/JDK-8231027
Fix: http://cr.openjdk.java.net/~serb/8231027/webrev.00
One common typo is fixed across a few components like client, build, and
hotspot.
--
Best regards, Sergey.
+1
On 21/05/2019 06:49, Erik Joelsson wrote:
Looks even better!
/Erik
On 2019-05-20 17:56, David Holmes wrote:
Thank you everyone for taking a look at this.
Here is version 2:
http://cr.openjdk.java.net/~dholmes/8224087/webrev.v2/
Changes:
- set c99 rather than gnu99
- Volker's change for
Hi, David.
Should not the minimum version of c standard mentioned in the doc/building.html?
On 20/05/2019 00:40, David Holmes wrote:
Bug: https://bugs.openjdk.java.net/browse/JDK-8224087
webrev: http://cr.openjdk.java.net/~dholmes/8224087/webrev/
The need to remove a for-loop declaration expres
Hi, Erik.
I remember that some of the code uses the "internal" as a mark which enables additional
assertions. Will this "internal" mark be used for the local builds?
On 07/05/2019 07:21, Erik Joelsson wrote:
This change changes how the version string will look in Oracle CI builds. A
string th
+1
On 17/04/2019 06:15, Erik Joelsson wrote:
Looks good!
/Erik
On 2019-04-16 16:40, Philip Race wrote:
freetype 2.10 has been released and this fix upgrades
the JDK's internal copy from the previous latest of 2.9.1
Bug : https://bugs.openjdk.java.net/browse/JDK-8222362
Webrev : http://cr.ope
1 - 100 of 185 matches
Mail list logo
