Hi Christoph, thank's for the review .
Could I have a second one for example from the awt or build-dev reviewers ?
Best Regards, Matthias
> -Original Message-
> From: Langer, Christoph
> Sent: Montag, 4. Juni 2018 16:49
> To: Baesken, Matthias ; Thomas Stüfe
> ; '[email protected]
Hi Erik , is there some info available about the performance impact when
disabling disabling speculative execution ?
And which compiler versions are needed for this ?
Best regards, Matthias
>We need to add compilation flags for disabling speculative execution to
>our native librar
On 04/06/2018 21:40, Bob Vandette wrote:
:
I could live with a jlink option to create a JRE. The problem is that the list
of modules required to produce a
compatible JRE is not documented anywhere. I tried fishing the list out of the
build makefile but it’s not trivial. I ended
up running “j
On 04/06/2018 22:22, Erik Joelsson wrote:
Given the feedback, I have revised the patch to restore the ability to
produce a legacy jre image, but it is still removed from the default
"product-images" and "images" targets. To build it you need to specify
it explicitly as "legacy-jre-image" (or ma
Thanks Erik,
We do have quite a few requests to build that jRE for AdoptOpenJDK
binaries, and this should let us continue doing that.
Cheers,
Martijn
On 5 June 2018 at 09:41, Alan Bateman wrote:
> On 04/06/2018 22:22, Erik Joelsson wrote:
>
>> Given the feedback, I have revised the patch to re
Build change itself looks good to me. I think this solves the problem for the
time being, even if the cleanup is not as complete.
For JDK 12, we should see if we can go further.
/Magnus
> 4 juni 2018 kl. 23:22 skrev Erik Joelsson :
>
> Given the feedback, I have revised the patch to restore
Looks fine to me.
Thanks,
David
Hi!
Please review this very small fix. It only applies to JDK 8.
bug report:
https://bugs.openjdk.java.net/browse/JDK-8204053
webrev:
http://cr.openjdk.java.net/~dbuck/8204053.0/
JPRT hotspot testset run and passed. Efficacy of fix manually confirmed.
Cheers
Hello,
On 2018-06-04 23:10, David Holmes wrote:
Sorry to be late to this party ...
On 5/06/2018 6:10 AM, Erik Joelsson wrote:
New webrev: http://cr.openjdk.java.net/~erikj/8202384/webrev.02/
Renamed the new jvm variant to "hardened".
As it is a hardened server build I'd prefer if that were
Hello Matthias,
For GCC, you need 7.3.0 or later. For Microsoft you need VS2017 and I
think some minimal update version (the option is called -Qspectre), we
use 15.5.5.
I was not involved in the benchmarking so I don't know any details
there, only the conclusion.
/Erik
On 2018-06-05 01:3
Build change looks ok, but the validity of disabling the warning needs
review from someone else.
/Erik
On 2018-06-05 00:47, Baesken, Matthias wrote:
Hi Christoph, thank's for the review .
Could I have a second one for example from the awt or build-dev reviewers ?
Best Regards, Matthias
Hi Erik,
you wrote: "Note that this applies to the build time C++ flags, not
the compiler in the JVM itself." So what about the code generated by
the HotSpot (i.e. stubs, template interpreter, c1, c2, Graal)? Is this
code already "hardened" against speculative execution? If yes, that's
fine, if no
Hello Volker,
On 2018-06-05 09:35, Volker Simonis wrote:
Hi Erik,
you wrote: "Note that this applies to the build time C++ flags, not
the compiler in the JVM itself." So what about the code generated by
the HotSpot (i.e. stubs, template interpreter, c1, c2, Graal)? Is this
code already "hardene
Hello again,
Looks like Jesper updated the bug description with more info.
/Erik
On 2018-06-05 08:50, Erik Joelsson wrote:
Hello Matthias,
For GCC, you need 7.3.0 or later. For Microsoft you need VS2017 and I
think some minimal update version (the option is called -Qspectre), we
use 15.5.5
On Tue, Jun 5, 2018 at 6:47 PM, Erik Joelsson wrote:
> Hello Volker,
>
> On 2018-06-05 09:35, Volker Simonis wrote:
>>
>> Hi Erik,
>>
>> you wrote: "Note that this applies to the build time C++ flags, not
>> the compiler in the JVM itself." So what about the code generated by
>> the HotSpot (i.e.
> On 5 Jun 2018, at 08:10, David Holmes wrote:
>
> Sorry to be late to this party ...
>
> On 5/06/2018 6:10 AM, Erik Joelsson wrote:
>> New webrev: http://cr.openjdk.java.net/~erikj/8202384/webrev.02/
>> Renamed the new jvm variant to "hardened".
>
> As it is a hardened server build I'd prefer
This looks good to me except for what looks like in my browser like
missing indentation in
http://cr.openjdk.java.net/~mbaesken/webrevs/8204211.1/src/java.desktop/windows/native/libawt/java2d/windows
/GDIRenderer.cpp.udiff.html
You can fix that with or without an updated webrev.
Good to clear a
Oh .. can I please ask that you make sure that VS2017 is OK with the
re-enabled
warning ? I seriously doubt that it has anything new to add over VS2013,
but a jdk-submit
will tell you if it has ..
VS2017 is now the default so a jdk-submit will use that.
-phil.
On 06/05/2018 12:43 PM, Phil Rac
Looks fine.
On 05/06/2018 09:05, Erik Joelsson wrote:
Build change looks ok, but the validity of disabling the warning needs
review from someone else.
/Erik
On 2018-06-05 00:47, Baesken, Matthias wrote:
Hi Christoph, thank's for the review .
Could I have a second one for example from the
I have checked the fix using mach5.
On 05/06/2018 12:45, Phil Race wrote:
Oh .. can I please ask that you make sure that VS2017 is OK with the
re-enabled
warning ? I seriously doubt that it has anything new to add over VS2013,
but a jdk-submit
will tell you if it has ..
VS2017 is now the defa
In that case Matthias is good to go after fixing the indentation.
-phil.
On 06/05/2018 01:37 PM, Sergey Bylokhov wrote:
I have checked the fix using mach5.
On 05/06/2018 12:45, Phil Race wrote:
Oh .. can I please ask that you make sure that VS2017 is OK with the
re-enabled
warning ? I serio
Hi Erik, Jesper,
On 6/06/2018 2:59 AM, [email protected] wrote:
On 5 Jun 2018, at 08:10, David Holmes wrote:
Sorry to be late to this party ...
On 5/06/2018 6:10 AM, Erik Joelsson wrote:
New webrev: http://cr.openjdk.java.net/~erikj/8202384/webrev.02/
Renamed the new jvm variant
21 matches
Mail list logo
