On Thu, 10 Feb 2022 22:20:48 GMT, Roger Riggs wrote:
>> Naoto Sato has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Fixed LocalizedPrinterParser.toString() to reflect requestedTemplate
>
> src/java.base/share/classes/sun/util/locale/provi
> Following the prior discussion [1], here is the PR for the subject
> enhancement. CSR has also been updated according to the suggestion.
>
> [1]
> https://mail.openjdk.java.net/pipermail/core-libs-dev/2022-January/085175.html
Naoto Sato has updated the pull request incrementally with one addi
On Tue, 8 Feb 2022 19:08:45 GMT, Naoto Sato wrote:
>> Following the prior discussion [1], here is the PR for the subject
>> enhancement. CSR has also been updated according to the suggestion.
>>
>> [1]
>> https://mail.openjdk.java.net/pipermail/core-libs-dev/2022-January/085175.html
>
> Naoto
On Tue, 8 Feb 2022 19:08:45 GMT, Naoto Sato wrote:
>> Following the prior discussion [1], here is the PR for the subject
>> enhancement. CSR has also been updated according to the suggestion.
>>
>> [1]
>> https://mail.openjdk.java.net/pipermail/core-libs-dev/2022-January/085175.html
>
> Naoto
On Thu, 10 Feb 2022 18:46:13 GMT, Pavel Kharskii wrote:
> …C promotion B35 on February 10, 2022
>
> Remove EA from JDK 18 version string starting with Initial RC promotion B35
> on February 10, 2022
Marked as reviewed by iris (Reviewer).
-
PR: https://git.openjdk.java.net/jdk18/p
On Thu, 10 Feb 2022 18:46:13 GMT, Pavel Kharskii wrote:
> …C promotion B35 on February 10, 2022
>
> Remove EA from JDK 18 version string starting with Initial RC promotion B35
> on February 10, 2022
Marked as reviewed by erikj (Reviewer).
-
PR: https://git.openjdk.java.net/jdk18/
…C promotion B35 on February 10, 2022
Remove EA from JDK 18 version string starting with Initial RC promotion B35 on
February 10, 2022
-
Commit messages:
- 8280415: Remove EA from JDK 18 version string starting with Initial RC
promotion B35 on February 10, 2022
Changes: https://g
> Current adhoc version build strings are not ideal. Some of the problems:
> * A build number of "0" is inserted, which make the version string look like
> it's an official build, at least when not reading carefully
> * The version string gives little indication on what source code the build
>
> PAC is an optional feature in AArch64 8.3 and is compulsory in v9. One
> of its uses is to protect against ROP based attacks. This is done by
> signing the Link Register whenever it is stored on the stack, and
> authenticating the value when it is loaded back from the stack. If an
> attacker were
On Mon, 7 Feb 2022 15:12:04 GMT, Andrew Haley wrote:
>> How about extending the existing enter() function:
>>
>> // Enter a new stack frame for the current method.
>> // nested: Indicates a frame has already been entered (and not left) for
>> the current method.
>> void MacroAssembler::en
On Thu, 10 Feb 2022 16:18:18 GMT, Andrew Haley wrote:
>>> Doing this caused 7 failures across a full jtreg run, namely:
>>
>> I'm glad we caught that.
>
> Status? Is branch protection really incompatible with PreserveFramePointer?
Eventually found a missing signing in the exception handling. I'
> Current adhoc version build strings are not ideal. Some of the problems:
> * A build number of "0" is inserted, which make the version string look like
> it's an official build, at least when not reading carefully
> * The version string gives little indication on what source code the build
>
On Tue, 8 Feb 2022 09:40:49 GMT, Andrew Haley wrote:
>> Doing this caused 7 failures across a full jtreg run, namely:
>>
>> serviceability/sa/ClhsdbFindPC.java#xcomp-core
>> vmTestbase/jit/misctests/fpustack/GraphApplet.java
>> vmTestbase/nsk/jdi/MonitorWaitRequest/MonitorWaitRequest001/TestDesc
> Current adhoc version build strings are not ideal. Some of the problems:
> * A build number of "0" is inserted, which make the version string look like
> it's an official build, at least when not reading carefully
> * The version string gives little indication on what source code the build
>
On Thu, 10 Feb 2022 15:52:50 GMT, Magnus Ihse Bursie wrote:
>> Current adhoc version build strings are not ideal. Some of the problems:
>> * A build number of "0" is inserted, which make the version string look
>> like it's an official build, at least when not reading carefully
>> * The versio
> Current adhoc version build strings are not ideal. Some of the problems:
> * A build number of "0" is inserted, which make the version string look like
> it's an official build, at least when not reading carefully
> * The version string gives little indication on what source code the build
>
> Current adhoc version build strings are not ideal. Some of the problems:
> * A build number of "0" is inserted, which make the version string look like
> it's an official build, at least when not reading carefully
> * The version string gives little indication on what source code the build
>
Hi Andrew,
On Wed, 2022-02-09 at 03:54 +, Andrew Hughes wrote:
> On 20:33 Thu 03 Feb , Severin Gehwolf wrote:
> > On Wed, 2021-12-22 at 11:14 +0100, Severin Gehwolf wrote:
> > > On Fri, 2021-12-10 at 15:11 +0100, Severin Gehwolf wrote:
> > > > Hi,
> > > >
> > > > Please review this adapta
On Fri, 4 Feb 2022 10:55:40 GMT, Maxim Kartashev wrote:
> Some dll/exe files end up having absolute path names embedded in them despite
> the use of `--disable-absolute-paths-in-output` build option. This option
> effectively translates into adding `-pathmap` to compilation lines, but
> doesn'
> Some dll/exe files end up having absolute path names embedded in them despite
> the use of `--disable-absolute-paths-in-output` build option. This option
> effectively translates into adding `-pathmap` to compilation lines, but
> doesn't (always) achieve the desired effects. The reason for tha
On Wed, 13 Oct 2021 00:00:22 GMT, Magnus Ihse Bursie wrote:
> This patch expands the newly added system for hsdis backends to include LLVM.
>
> The actual code in hsdis-llvm.cpp is based heavily on the work by @luhenry,
> as published in the never integrated PR
> https://github.com/openjdk/jdk
> Current adhoc version build strings are not ideal. Some of the problems:
> * A build number of "0" is inserted, which make the version string look like
> it's an official build, at least when not reading carefully
> * The version string gives little indication on what source code the build
>
On Fri, 4 Feb 2022 18:37:51 GMT, Maxim Kartashev wrote:
>> Some dll/exe files end up having absolute path names embedded in them
>> despite the use of `--disable-absolute-paths-in-output` build option. This
>> option effectively translates into adding `-pathmap` to compilation lines,
>> but do
23 matches
Mail list logo
