> For the other files, it seems strange to force the use of a charset
> which is different from the charset of record for all our source files
> (i.e. US-ASCII).
Can you clarify where this "charset of record" rule comes from? Is this written
down somewhere, or more of an oral tradition?
The
> On Nov 27, 2019, at 9:44 PM, Erik Joelsson wrote:
>
> On 2019-11-26 16:39, Weijun Wang wrote:
>>
>>> On Nov 27, 2019, at 12:14 AM, Erik Joelsson
>>> wrote:
>>>
>>> On 2019-11-25 16:42, Weijun Wang wrote:
> On Nov 26, 2019, at 12:36 AM, Erik Joelsson
> wrote:
>
> Build
Hi Martin,
On 2019-11-27 19:03, Doerr, Martin wrote:
Hi Claes,
that kind of surprises me. I'd expect files which rather benefit from -O3 to be
far less than those which benefit from -Os.
Most performance critical code lives inside the code cache and is not dependent
on C++ compiler
Martin,
Agreed, but this is not the email-thread to have that discussion on
behalf of all OpenJDK.
-- Jon
On 11/27/2019 10:18 AM, Martin Buchholz wrote:
The ubiquitous use of UTF-8 is one of the few clear successes in the
software world.
In 2019, most software projects should declare that
The ubiquitous use of UTF-8 is one of the few clear successes in the
software world.
In 2019, most software projects should declare that all their source files
are encoded in UTF-8, not US-ASCII.
On Wed, Nov 27, 2019 at 9:04 AM Dan Smith wrote:
> Please review this patch to make explicit use of
Hi Claes,
that kind of surprises me. I'd expect files which rather benefit from -O3 to be
far less than those which benefit from -Os.
Most performance critical code lives inside the code cache and is not dependent
on C++ compiler optimizations.
I'd expect GC code, C2's register allocation and a
fixuppandoc is notable because it reads generated files .. which
presumably contain non-ASCII UTF-8 characters.
For the other files, it seems strange to force the use of a charset
which is different from the charset of record for all our source files
(i.e. US-ASCII). I'm not saying that
Hi,
we discussed doing the opposite for Mac OS X recently, where builds are
currently set to -Os by default. -O3 helped various networking
(micro)benchmarks by up to 20%.
Rather than doing -Os by default and then cherry-pick things over to -O3
on a case-by-case basis, I'd suggest the opposite:
Please review this patch to make explicit use of the UTF-8 charset in build
tools' IO code.
JDK-8065704 changed the platform default to US-ASCII, so the intended effect of
this change is to address a regression and restore the typical earlier behavior.
My particular interest is in fixuppandoc,
Hello Martin, I checked building libjvm.so with -Os (instead of -O3) .
I used gcc-7 on linux x86_64 .
The size of libjvm.so dropped from24M (normal night make with -O3)
to 18M ( test make with -Os) .
(adding the link-time gc might reduce the size by another ~ 10 % ,
yes - The attempted incremental patch is not much use. The source files
were moved several times, and despite using "hg addremove -s 60", many
of the files show as a remove and a new file.
/Andy
On 11/26/2019 9:01 PM, Philip Race wrote:
> I believe otherwise it is an accurate incremental
On 2019-11-26 16:39, Weijun Wang wrote:
On Nov 27, 2019, at 12:14 AM, Erik Joelsson wrote:
On 2019-11-25 16:42, Weijun Wang wrote:
On Nov 26, 2019, at 12:36 AM, Erik Joelsson wrote:
Build change looks good.
Thanks.
One question: I see the output to stdout from FieldGen.java shown in
The fix is pushed in jdk/client, after pre-integration-testing (PIT) is
done, it will be propagated to jdk/jdk.
Regards
Prasanta
On 26-Nov-19 6:09 PM, Baesken, Matthias wrote:
Thanks for the update on this .
Do you plan to push it today or tomorrow ?
Best regards, Matthias
-Original
13 matches
Mail list logo
