On Mon, 24 Apr 2023 21:44:00 GMT, Christoph Langer wrote:
>> This is an attempt to fix the issue on Windows when no cygwin Git is
>> installed or the Git for Windows installation has precedence in PATH lookup.
>> The path to the Windows GIT installation usually resides in `C:\Program
>>
> This is an attempt to fix the issue on Windows when no cygwin Git is
> installed or the Git for Windows installation has precedence in PATH lookup.
> The path to the Windows GIT installation usually resides in `C:\Program
> Files` which contains a space and thus needs some special handling.
>
On Mon, 24 Apr 2023 21:04:50 GMT, Erik Joelsson wrote:
> I think this change makes sense. Given how small this set of tools is now, I
> think we should add a comment on `PLATFORM_SETUP_OPENJDK_BUILD_AND_TARGET` in
> platform.m4 saying something about needing to be careful to only use tools
>
On Mon, 24 Apr 2023 20:11:50 GMT, Christoph Langer wrote:
> This is an attempt to fix the issue on Windows when no cygwin Git is
> installed or the Git for Windows installation has precedence in PATH lookup.
> The path to the Windows GIT installation usually resides in `C:\Program
> Files`
This is an attempt to fix the issue on Windows when no cygwin Git is installed
or the Git for Windows installation has precedence in PATH lookup. The path to
the Windows GIT installation usually resides in `C:\Program Files` which
contains a space and thus needs some special handling.
There
On Mon, 17 Apr 2023 14:56:16 GMT, Christian Stein wrote:
> Please review the change to update to using jtreg 7.2.
>
> The primary change is to the `jib-profiles.js` file, which specifies the
> version of jtreg to use, for those systems that rely on this file. In
> addition, the
On Fri, 21 Apr 2023 06:56:43 GMT, Christoph Langer wrote:
> We figured that seemingly the correct toolchain could be (and is) already
> installed by default on Github runners and it makes sense to skip the
> expensive installation operation which takes some 10+ minutes.
>
> I also tested the
On Fri, 21 Apr 2023 18:25:32 GMT, Jorn Vernee wrote:
> Implement captureCallState support for upcall stubs.
>
> The method handle of an upcall stub linked with this linker option has an
> additional leading memory segment parameter into which the capture state
> (e.g. errno) should be
On Fri, 21 Apr 2023 18:25:32 GMT, Jorn Vernee wrote:
> Implement captureCallState support for upcall stubs.
>
> The method handle of an upcall stub linked with this linker option has an
> additional leading memory segment parameter into which the capture state
> (e.g. errno) should be
On Fri, 21 Apr 2023 20:26:12 GMT, Roger Riggs wrote:
>> Define an internal jdk.internal.util.Architecture enumeration and static
>> methods to replace uses of the system property `os.arch`.
>> The enumeration values are defined to match those used in the build.
>> The initial values are: `X64,
On Fri, 21 Apr 2023 12:21:39 GMT, Christoph Langer wrote:
>> We figured that seemingly the correct toolchain could be (and is) already
>> installed by default on Github runners and it makes sense to skip the
>> expensive installation operation which takes some 10+ minutes.
>>
>> I also tested
On Fri, 21 Apr 2023 18:25:32 GMT, Jorn Vernee wrote:
> Implement captureCallState support for upcall stubs.
>
> The method handle of an upcall stub linked with this linker option has an
> additional leading memory segment parameter into which the capture state
> (e.g. errno) should be
On Fri, 21 Apr 2023 18:25:32 GMT, Jorn Vernee wrote:
> Implement captureCallState support for upcall stubs.
>
> The method handle of an upcall stub linked with this linker option has an
> additional leading memory segment parameter into which the capture state
> (e.g. errno) should be
Implement captureCallState support for upcall stubs.
The method handle of an upcall stub linked with this linker option has an
additional leading memory segment parameter into which the capture state (e.g.
errno) should be written. After returning from Java, this value is then
actually written
14 matches
Mail list logo
