On Wed, 9 Sep 2020 15:13:29 GMT, Paul Sandoz wrote:
>> * Release fence guarantees that cacheArray field will published with a
>> non-null value.
>> * Without this fix, CacheValueMap.cacheArray can sometimes be seen as null.
>>
>> This is a follow up to @PaulSandoz's feedback
>>
On Wed, 9 Sep 2020 13:04:38 GMT, Aleksey Shipilev wrote:
>> Updated PR.
>
> Now I wonder (after reading the discussion), why not
> `UNSAFE.storeStoreFence()`? I am basically okay with either, given
> they currently map to the same thing. But it seems that semantically only
> `storeStoreFence`
* Release fence guarantees that cacheArray field will published with a non-null
value.
* Without this fix, CacheValueMap.cacheArray can sometimes be seen as null.
This is a follow up to @PaulSandoz's feedback
[here](https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-August/068248.html)
On Wed, 9 Sep 2020 12:43:20 GMT, Aleksey Shipilev wrote:
>> * Release fence guarantees that cacheArray field will published with a
>> non-null value.
>> * Without this fix, CacheValueMap.cacheArray can sometimes be seen as null.
>>
>> This is a follow up to @PaulSandoz's feedback
>>
On Thu, 10 Sep 2020 08:08:10 GMT, Aleksey Shipilev wrote:
>> * Release fence guarantees that cacheArray field will published with a
>> non-null value.
>> * Without this fix, CacheValueMap.cacheArray can sometimes be seen as null.
>>
>> This is a follow up to @PaulSandoz's feedback
>>
On Wed, 9 Sep 2020 12:35:06 GMT, Galder Zamarreño
wrote:
> * Release fence guarantees that cacheArray field will published with a
> non-null value.
> * Without this fix, CacheValueMap.cacheArray can sometimes be seen as null.
>
> This is a follow up to @PaulSandoz's feedback
>
On Sat, 12 Sep 2020 06:35:31 GMT, Ioi Lam wrote:
>> This is the same patch as
>> [8244778-archive-full-module-graph.v03](http://cr.openjdk.java.net/~iklam/jdk16/8244778-archive-full-module-graph.v03/)
>> published in
>>
Hello,
What about system errors (exception messages from strerr?). I mean in case one
wants to enforce English version with user.locale for support reasons?
Gruss
Bernd
--
http://bernd.eckenfels.net
Von: core-libs-dev im Auftrag von
Alexander Matveev
On Wed, 9 Sep 2020 12:35:06 GMT, Galder Zamarreño
wrote:
> * Release fence guarantees that cacheArray field will published with a
> non-null value.
> * Without this fix, CacheValueMap.cacheArray can sometimes be seen as null.
>
> This is a follow up to @PaulSandoz's feedback
>
On Wed, 9 Sep 2020 12:50:07 GMT, Galder Zamarreño
wrote:
>> src/java.base/share/classes/java/lang/ClassValue.java line 386:
>>
>>> 384: // since stores to the fields of ClassValueMap will
>>> not be reordered
>>> 385: // to occur after the store to the field
On Sat, 12 Sep 2020 13:00:22 GMT, Kevin Rushforth wrote:
>> Looks good. I confirmed that these are the only two calls to `setlocale` in
>> the jpackage sources.
>
> Note: the title of the JBS bug was updated. Can you update the PR title to
> match?
Looks good to me.
-
PR:
On Sat, 12 Sep 2020 02:15:29 GMT, Alexander Matveev
wrote:
> setlocale() affects several C functions. We do not use most of these
> functions. We only using isspace() and toLower().
> Based on how we use it I do not see any needs for setlocale(). After removing
> it I retested jpackage by
> This is the same patch as
> [8244778-archive-full-module-graph.v03](http://cr.openjdk.java.net/~iklam/jdk16/8244778-archive-full-module-graph.v03/)
> published in
> [hotspot-runtime-...@openjdk.java.net](https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-August/041496.html).
> The
On Thu, 10 Sep 2020 10:03:53 GMT, Severin Gehwolf wrote:
>> Marked as reviewed by shade (Reviewer).
>
> Just noting here that @galderz is a Red Hat employee and should be covered by
> the Red Hat OCA:
> https://www.oracle.com/technical-resources/oracle-contributor-agreement.html#r
@galderz
On Wed, 9 Sep 2020 12:53:41 GMT, Galder Zamarreño
wrote:
>> Ah yes, my bad 臘♂️
>
> Updated PR.
Now I wonder (after reading the discussion), why not
`UNSAFE.storeStoreFence()`? I am basically okay with either, given
they currently map to the same thing. But it seems that semantically only
On Sat, 12 Sep 2020 02:15:29 GMT, Alexander Matveev
wrote:
> setlocale() affects several C functions. We do not use most of these
> functions. We only using isspace() and toLower().
> Based on how we use it I do not see any needs for setlocale(). After removing
> it I retested jpackage by
On Sat, 12 Sep 2020 12:41:50 GMT, Kevin Rushforth wrote:
>> setlocale() affects several C functions. We do not use most of these
>> functions. We only using isspace() and toLower().
>> Based on how we use it I do not see any needs for setlocale(). After
>> removing it I retested jpackage by
On Sat, 12 Sep 2020 12:34:06 GMT, Claes Redestad wrote:
>> Ioi Lam 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 eight additional commits
JDK-8230652
Extracting the commands displayed by verbose output (including commands called
thru ToolProvider) , to contain the the
command, it's output, and it's return value on separate lines and formatted in
a way that they can be easily cut and
pasted into a script.
-
Commit
> This is the same patch as
> [8244778-archive-full-module-graph.v03](http://cr.openjdk.java.net/~iklam/jdk16/8244778-archive-full-module-graph.v03/)
> published in
> [hotspot-runtime-...@openjdk.java.net](https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-August/041496.html).
> The
> This is the same patch as
> [8244778-archive-full-module-graph.v03](http://cr.openjdk.java.net/~iklam/jdk16/8244778-archive-full-module-graph.v03/)
> published in
> [hotspot-runtime-...@openjdk.java.net](https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-August/041496.html).
> The
On Fri, 11 Sep 2020 14:17:45 GMT, Jaikiran Pai wrote:
> Can I please get a review and a sponsor for this patch which fixes the issue
> reported in
> https://bugs.openjdk.java.net/browse/JDK-8244706?
> The commit here sets the `OS` header flag to `255` (which represents
> `unknown`) as noted in
On Sat, 12 Sep 2020 17:38:34 GMT, Lance Andersen wrote:
>> Can I please get a review and a sponsor for this patch which fixes the issue
>> reported in
>> https://bugs.openjdk.java.net/browse/JDK-8244706?
>> The commit here sets the `OS` header flag to `255` (which represents
>> `unknown`) as
23 matches
Mail list logo