On Wed, 27 Jan 2021 13:09:56 GMT, Matthias Baesken wrote:
>> The function AllocateSpaceForGP in freetypeScaler.c calls potentially 2
>> times malloc ; however the memory is not always freed correctly in case of
>> errors.
>> See also the related sonar issue :
>> https://sonarcloud.io/project/
On Thu, 28 Jan 2021 07:53:44 GMT, Aleksey Shipilev wrote:
>> Matthias Baesken has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> JDK-8260426
>
> This looks fine to me, modulo stylistic nits
Pull from master to get x86_32 GHA jobs fixed and
On Wed, 27 Jan 2021 12:16:47 GMT, Thomas Stuefe wrote:
>> Yes, I think that is better: `realloc` can fail as well, and we don't want
>> to leak those?
>
> Please also reset the free'd pointers to NULL in GPData* before returning.
Hello Thomas and Aleksey, I moved the free calls and added the N
On Thu, 28 Jan 2021 00:41:13 GMT, Sergey Bylokhov wrote:
>> src/java.desktop/windows/native/libawt/windows/awt_Toolkit.cpp line 2611:
>>
>>> 2609: Sleep(100);
>>> 2610: }
>>> 2611:
>>
>> It can cause infinite looping as the message queue to get DISPOSE events is
>> removed so if w
> This test was failing in our nightly mach5 testing. Appropriate stability
> code in form of waitForIdle and delay is added.
> mach5 job running for several iterations on all platforms is ok. Link in JBS.
Prasanta Sadhukhan has updated the pull request incrementally with one
additional commit s
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
> This change intended to enhance the lazy initialization of the standard color
> profiles concurrently by different threads.
>
> We defer standard profiles loading because most of UI application uses a
> small amount of data from the profile like numComponents and colorSpaceType,
> and this da
On Wed, 27 Jan 2021 18:38:27 GMT, Alexander Zuev wrote:
>> Sergey Bylokhov has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 14 commits:
>>
>> - Merge branch 'master' into JDK-6986863
>> - Merge branch 'master' into JDK-6986863
>>
On Wed, 27 Jan 2021 12:35:38 GMT, Prasanta Sadhukhan
wrote:
>> Prasanta Sadhukhan has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Prevent infinite loop
>
> src/java.desktop/windows/native/libawt/windows/awt_Toolkit.cpp line 2611:
>
>>
On Wed, 27 Jan 2021 12:39:01 GMT, Prasanta Sadhukhan
wrote:
>> This test was failing in our nightly mach5 testing. Appropriate stability
>> code in form of waitForIdle and delay is added.
>> mach5 job running for several iterations on all platforms is ok. Link in JBS.
>
> Prasanta Sadhukhan has
On Wed, 27 Jan 2021 19:23:48 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
> conservative ol
On Wed, 27 Jan 2021 19:23:48 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
> conservative ol
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
old version (support ended in 2019).
The driving issue for bumping
On Fri, 22 Jan 2021 10:35:13 GMT, Sergey Bylokhov wrote:
>> This change intended to enhance the lazy initialization of the standard
>> color profiles concurrently by different threads.
>>
>> We defer standard profiles loading because most of UI application uses a
>> small amount of data from t
On Fri, 22 Jan 2021 10:35:13 GMT, Sergey Bylokhov wrote:
>> This change intended to enhance the lazy initialization of the standard
>> color profiles concurrently by different threads.
>>
>> We defer standard profiles loading because most of UI application uses a
>> small amount of data from t
On Wed, 27 Jan 2021 08:36:19 GMT, Magnus Ihse Bursie wrote:
> Build changes per se now looks okay. However, I agree with Erik that unless
> this PR can wait for the JNF removal, at the very least the build docs needs
> to be updated to explain how to successfully build for this platform. (I can
> Please review the implementation of JEP 391: macOS/AArch64 Port.
>
> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and
> windows/aarch64.
>
> Major changes are in:
> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks
> JDK-8253817, JDK-8253818)
> The function AllocateSpaceForGP in freetypeScaler.c calls potentially 2
> times malloc ; however the memory is not always freed correctly in case of
> errors.
> See also the related sonar issue :
> https://sonarcloud.io/project/issues?id=shipilev_jdk&languages=c&open=AXck8B_SBBG2CXpcngxr&reso
On Wed, 27 Jan 2021 12:35:38 GMT, Prasanta Sadhukhan
wrote:
>> This test was failing in our nightly mach5 testing. Appropriate stability
>> code in form of waitForIdle and delay is added.
>> mach5 job running for several iterations on all platforms is ok. Link in JBS.
>
> Prasanta Sadhukhan has
> This test was failing in our nightly mach5 testing. Appropriate stability
> code in form of waitForIdle and delay is added.
> mach5 job running for several iterations on all platforms is ok. Link in JBS.
Prasanta Sadhukhan has updated the pull request incrementally with one
additional commit s
On Wed, 27 Jan 2021 12:02:06 GMT, Aleksey Shipilev wrote:
>> Then we would free as well for the realloc code path
>> } else {
>> /* do we have enough space? */
>> ...
>> }
>> Is this okay?
>
> Yes, I think that is better: `realloc` can fail as well, and we don't want to
>
On Sat, 23 Jan 2021 19:06:05 GMT, Alexey Ivanov wrote:
> Replace presentational attribute `border="1"` on `` element with CSS
> styles:
> table {border: outset 1px}
> th, td {border: inset 1px}
>
> These declarations produce the same rendering as the default one in Firefox
> and Edge.
>
> A
On Wed, 27 Jan 2021 11:41:48 GMT, Aleksey Shipilev wrote:
>> The function AllocateSpaceForGP in freetypeScaler.c calls potentially 2
>> times malloc ; however the memory is not always freed correctly in case of
>> errors.
>> See also the related sonar issue :
>> https://sonarcloud.io/project/
On Wed, 27 Jan 2021 11:59:29 GMT, Matthias Baesken wrote:
>> src/java.desktop/share/native/libfontmanager/freetypeScaler.c line 1290:
>>
>>> 1288:
>>> 1289: /* failure if any of mallocs failed */
>>> 1290: if (gpdata->pointTypes == NULL || gpdata->pointCoords == NULL)
>>
>> I think it
On Wed, 27 Jan 2021 08:39:33 GMT, Matthias Baesken wrote:
> The function AllocateSpaceForGP in freetypeScaler.c calls potentially 2
> times malloc ; however the memory is not always freed correctly in case of
> errors.
> See also the related sonar issue :
> https://sonarcloud.io/project/issue
On 1/26/21 6:42 PM, erik.joels...@oracle.com wrote:
> My understanding is that Apple chose to not provide JNF for aarch64, so
> if you want to build OpenJDK, you first need to build JNF yourself (it's
> available in github). Phil is working on removing this dependency
> completely, which will solve
The function AllocateSpaceForGP in freetypeScaler.c calls potentially 2 times
malloc ; however the memory is not always freed correctly in case of errors.
See also the related sonar issue :
https://sonarcloud.io/project/issues?id=shipilev_jdk&languages=c&open=AXck8B_SBBG2CXpcngxr&resolved=false&
I don't know why the Skara tools decided to associate my comment with
Alan Hayward's comment as they are not at all related. :(
David
On 27/01/2021 4:50 pm, David Holmes wrote:
On Tue, 26 Jan 2021 12:34:11 GMT, Alan Hayward
wrote:
AIUI, the configure line needs passing a prebuilt JavaNativ
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 the
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 a
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:
> https://github.com/openjdk/jdk/pull/2200/files#diff-51442e74eeef2163f0f0643df0ae995083
31 matches
Mail list logo
