On Fri, 9 Sep 2022 11:51:55 GMT, Magnus Ihse Bursie wrote:
> I think this looks good now. But this is apparently tricky business, with the
> three of us taking turns of thinking wrongly about this. :-) Let's hear what
> Erik has to say, too.
>
> Have you verified that it still does the
On Fri, 9 Sep 2022 11:41:08 GMT, Jan Lahoda wrote:
>> Currently, when doing a small change inside a module that does not affect
>> the API of the module, the build system will skip rebuild of the dependent
>> modules. If there's a change that affects the module's API, the dependent
>> modules
On Thu, 8 Sep 2022 13:54:02 GMT, Erik Joelsson wrote:
>> I looked up what kind of dependencies we are passing in through `DEPEND`.
>> None, it turns out. It is not used. So that is not a worry. We might
>> consider removing it. Sending in exceptional dependencies like that is never
>> a good
On Fri, 9 Sep 2022 11:41:08 GMT, Jan Lahoda wrote:
>> Currently, when doing a small change inside a module that does not affect
>> the API of the module, the build system will skip rebuild of the dependent
>> modules. If there's a change that affects the module's API, the dependent
>> modules
> Currently, when doing a small change inside a module that does not affect the
> API of the module, the build system will skip rebuild of the dependent
> modules. If there's a change that affects the module's API, the dependent
> modules are recompiled. So far, this seems to work reasonably.
>
On Thu, 8 Sep 2022 13:54:02 GMT, Erik Joelsson wrote:
>> I looked up what kind of dependencies we are passing in through `DEPEND`.
>> None, it turns out. It is not used. So that is not a worry. We might
>> consider removing it. Sending in exceptional dependencies like that is never
>> a good
On Fri, 9 Sep 2022 10:05:11 GMT, Robbin Ehn wrote:
>> Please consider, only implemented on x64/aarch64 linux/windows.
>> (@TheRealMDoerr have now contributed PPC64)
>>
>> On my box calling clock_gettime via JNI goes from 35ns to 28ns when enabled.
>>
>> Passes t1-7 with option forced on, also
On Fri, 9 Sep 2022 10:44:47 GMT, Erik Österlund wrote:
>> Robbin Ehn has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Fixed ws
>
> This looks good to me. I looked through the code to see if I can find any
> additional thread state
On Fri, 9 Sep 2022 09:55:46 GMT, Martin Doerr wrote:
> Thanks for the update! LGTM. I hope that no other platform with older linux
> kernel is still needed.
Yes, thanks!
> src/hotspot/os/linux/systemMemoryBarrier_linux.cpp line 83:
>
>> 81:
>> 82: void LinuxSystemMemoryBarrier::emit() {
>>
> Please consider, only implemented on x64/aarch64 linux/windows.
> (@TheRealMDoerr have now contributed PPC64)
>
> On my box calling clock_gettime via JNI goes from 35ns to 28ns when enabled.
>
> Passes t1-7 with option forced on, also passes t1-4 as is in this PR.
Robbin Ehn has updated the
On Fri, 9 Sep 2022 07:27:43 GMT, Robbin Ehn wrote:
>> Please consider, only implemented on x64/aarch64 linux/windows.
>> (@TheRealMDoerr have now contributed PPC64)
>>
>> On my box calling clock_gettime via JNI goes from 35ns to 28ns when enabled.
>>
>> Passes t1-7 with option forced on, also
On Thu, 8 Sep 2022 18:13:56 GMT, Robbin Ehn wrote:
>> Please consider, only implemented on x64/aarch64 linux/windows.
>> (@TheRealMDoerr have now contributed PPC64)
>>
>> On my box calling clock_gettime via JNI goes from 35ns to 28ns when enabled.
>>
>> Passes t1-7 with option forced on, also
> Please consider, only implemented on x64/aarch64 linux/windows.
> (@TheRealMDoerr have now contributed PPC64)
>
> On my box calling clock_gettime via JNI goes from 35ns to 28ns when enabled.
>
> Passes t1-7 with option forced on, also passes t1-4 as is in this PR.
Robbin Ehn has updated the
13 matches
Mail list logo
