2019年4月10日(水) 13:55 David Holmes :
>
> Hi Erik,
>
> On 9/04/2019 11:55 pm, Erik Joelsson wrote:
> > Hello,
> >
> > Here is a new webrev with an even simpler change:
> >
> > http://cr.openjdk.java.net/~erikj/8221851/webrev.06/
> >
> >
Hi Erik,
On 9/04/2019 11:55 pm, Erik Joelsson wrote:
Hello,
Here is a new webrev with an even simpler change:
http://cr.openjdk.java.net/~erikj/8221851/webrev.06/
I decided to just remove the usage of THIS_FILE from exceptions.hpp
since it did not work well. It currently does not work at
Hello,
Here is a new webrev with an even simpler change:
http://cr.openjdk.java.net/~erikj/8221851/webrev.06/
I decided to just remove the usage of THIS_FILE from exceptions.hpp
since it did not work well. It currently does not work at all on Windows
or Macosx builds. On Linux it invalidates
h a better name?), don't bother with
THIS_FILE, and define THREAD_AND_LOCATION as
#define THREAD_AND_LOCATION THREAD, this_file_helper(__FILE__),
__LINE__
Moved to exceptions.hpp, renamed to "basename", and removed the
THIS_FILE macro.
“basename” might not count as a “better name”,
suming all that, consider instead putting this_file_helper in
exceptions.hpp (perhaps with a better name?), don't bother with
THIS_FILE, and define THREAD_AND_LOCATION as
#define THREAD_AND_LOCATION THREAD, this_file_helper(__FILE__),
__LINE__
Moved to exceptions.hpp, renamed to "basena
On 2019-04-08 11:40, Kim Barrett wrote:
On Apr 8, 2019, at 10:28 AM, Erik Joelsson wrote:
Hello,
On 2019-04-05 15:46, Kim Barrett wrote:
Assuming all that, consider instead putting this_file_helper in
exceptions.hpp (perhaps with a better name?), don't bother with
THIS_FILE, and d
> On Apr 8, 2019, at 10:28 AM, Erik Joelsson wrote:
>
> Hello,
>
> On 2019-04-05 15:46, Kim Barrett wrote:
>> Assuming all that, consider instead putting this_file_helper in
>> exceptions.hpp (perhaps with a better name?), don't bother with
>> THIS_F
r 5, 2019, at 11:09 AM, Erik Joelsson
wrote:
So to make it clear. This patch now does the following:
* Removes the setting of -DTHIS_FILE=... from all compilation units
involved in building Hotspot.
* Introduces THIS_FILE as a macro in Hotspot src which gets just the
filename from the __FILE__ ma
Hello,
On 2019-04-05 15:46, Kim Barrett wrote:
On Apr 5, 2019, at 11:09 AM, Erik Joelsson wrote:
So to make it clear. This patch now does the following:
* Removes the setting of -DTHIS_FILE=... from all compilation units involved in
building Hotspot.
* Introduces THIS_FILE as a macro in
> On Apr 5, 2019, at 11:09 AM, Erik Joelsson wrote:
> So to make it clear. This patch now does the following:
>
> * Removes the setting of -DTHIS_FILE=... from all compilation units involved
> in building Hotspot.
>
> * Introduces THIS_FILE as a macro in Hotspot sr
annot simply use a general offset as I
proposed. Instead, I have taken Kim's proposal and implemented THIS_FILE
using the this_file_helper inline function he posted.
New webrev: http://cr.openjdk.java.net/~erikj/8221851/webrev.03/
Not being very familiar with the Hotspot code base, I'm
On 2019-04-04 22:23, Ioi Lam wrote:
On 4/4/19 10:08 PM, David Holmes wrote:
Adding back build-dev
On 5/04/2019 2:41 pm, Ioi Lam wrote:
#define THIS_FILE (__FILE__ + FILE_MACRO_OFFSET)
This make me a little uneasy, as it could potential point past the
end of the string.
The intent of
his.
> >
> > Cheers, Thomas
> >
> >
> >
> >
> >
> > On Fri, Apr 5, 2019 at 8:00 AM David Holmes > <mailto:david.hol...@oracle.com>> wrote:
> >
> > On 5/04/2019 3:23 pm, Ioi Lam wrote:
> > >
> > >
n 5/04/2019 3:23 pm, Ioi Lam wrote:
>
>
> On 4/4/19 10:08 PM, David Holmes wrote:
>> Adding back build-dev
>>
>> On 5/04/2019 2:41 pm, Ioi Lam wrote:
>>> #define THIS_FILE (__FILE__ + FILE_MACRO_OFFSET)
>>>
>&g
19 3:23 pm, Ioi Lam wrote:
>> >
>> >
>> > On 4/4/19 10:08 PM, David Holmes wrote:
>> >> Adding back build-dev
>> >>
>> >> On 5/04/2019 2:41 pm, Ioi Lam wrote:
>> >>> #define THIS_FILE (__FILE__ + FILE_MACRO_OFFSET)
>> &g
ote:
> >
> >
> > On 4/4/19 10:08 PM, David Holmes wrote:
> >> Adding back build-dev
> >>
> >> On 5/04/2019 2:41 pm, Ioi Lam wrote:
> >>> #define THIS_FILE (__FILE__ + FILE_MACRO_OFFSET)
> >>>
> >>> This make me a little
On 5/04/2019 3:23 pm, Ioi Lam wrote:
On 4/4/19 10:08 PM, David Holmes wrote:
Adding back build-dev
On 5/04/2019 2:41 pm, Ioi Lam wrote:
#define THIS_FILE (__FILE__ + FILE_MACRO_OFFSET)
This make me a little uneasy, as it could potential point past the
end of the string.
The intent of
On 4/4/19 10:08 PM, David Holmes wrote:
Adding back build-dev
On 5/04/2019 2:41 pm, Ioi Lam wrote:
#define THIS_FILE (__FILE__ + FILE_MACRO_OFFSET)
This make me a little uneasy, as it could potential point past the
end of the string.
The intent of course is that that is impossible
Adding back build-dev
On 5/04/2019 2:41 pm, Ioi Lam wrote:
#define THIS_FILE (__FILE__ + FILE_MACRO_OFFSET)
This make me a little uneasy, as it could potential point past the end
of the string.
The intent of course is that that is impossible:
- _FILE_ is an absolute file path within the
#if FILE_MACRO_OFFSET
646 #define THIS_FILE (__FILE__ + FILE_MACRO_OFFSET)
647 #else
648 #define THIS_FILE __FILE__
649 #endif
Is the "#if FILE_MACRO_OFFSET" an intentional test for 0, or is this
an implicit test for "defined"?
If the former, e.g. we're assuming
.hpp
>> 645 #if FILE_MACRO_OFFSET
>> 646 #define THIS_FILE (__FILE__ + FILE_MACRO_OFFSET)
>> 647 #else
>> 648 #define THIS_FILE __FILE__
>> 649 #endif
>>
>> Is the "#if FILE_MACRO_OFFSET" an intentional test for 0, or is this
>> an implic
On 2019-04-04 14:26, Kim Barrett wrote:
OK, I can do that.
--
src/hotspot/share/utilities/macros.hpp
645 #if FILE_MACRO_OFFSET
646 #define THIS_FILE (__FILE__ + FILE_MACRO_OFFSET)
647 #else
648 #define
> On Apr 4, 2019, at 9:36 AM, Erik Joelsson wrote:
>
> Hello Kim,
>
> On 2019-04-03 16:34, Kim Barrett wrote:
>>> On Apr 3, 2019, at 9:51 AM, Erik Joelsson
>>> wrote:Additionally, I would like to replace all (or at least most)
>>> instances of __F
th in exception messages might
be enough to still address JDK-8204551 though.
Right, even more reason to find a solution then.
Additionally, I would like to replace all (or at least most) instances of
__FILE__ with my new THIS_FILE, and I suspect some other places would be more
performance sen
at bug, and I don't think I have a very deep
hierarchy. Using a workspace-relative path in exception messages might
be enough to still address JDK-8204551 though.
> Additionally, I would like to replace all (or at least most) instances of
> __FILE__ with my new THIS_FILE, and I suspect som
Hello Kim,
On 2019-04-02 16:02, Kim Barrett wrote:
On Apr 2, 2019, at 5:39 PM, Erik Joelsson wrote:
In JDK-8204551, exceptions.hpp started using THIS_FILE instead of __FILE__ to
generate exception messages. This is causing the precompiled header to no
longer provide any benefit on Linux/GCC
> On Apr 2, 2019, at 5:39 PM, Erik Joelsson wrote:
>
> In JDK-8204551, exceptions.hpp started using THIS_FILE instead of __FILE__ to
> generate exception messages. This is causing the precompiled header to no
> longer provide any benefit on Linux/GCC. The problem is that the THI
In JDK-8204551, exceptions.hpp started using THIS_FILE instead of
__FILE__ to generate exception messages. This is causing the precompiled
header to no longer provide any benefit on Linux/GCC. The problem is
that the THIS_FILE macro is provided on the command line and is
different for each
12:27 PM Magnus Ihse Bursie
> wrote:
>
> On 2018-11-30 19:03, Volker Simonis wrote:
>
> On Fri, Nov 30, 2018 at 6:37 PM Erik Joelsson
> wrote:
>
> Hello Volker,
>
> The fix looks good. Thanks for finding and fixing it!
>
> Thanks!
>
> Now for some history o
finding and fixing it!
Thanks!
Now for some history on why THIS_FILE. The short story is that it's for
more reproducible and comparable builds.
When we started the build infra project, one of the design decisions was
to use absolute paths everywhere to avoid having to keep track of the
cu
Volker Simonis wrote:
>
> On Fri, Nov 30, 2018 at 6:37 PM Erik Joelsson
> wrote:
>
> Hello Volker,
>
> The fix looks good. Thanks for finding and fixing it!
>
> Thanks!
>
> Now for some history on why THIS_FILE. The short story is that it's for
> more reproducible
On 2018-11-30 19:03, Volker Simonis wrote:
On Fri, Nov 30, 2018 at 6:37 PM Erik Joelsson wrote:
Hello Volker,
The fix looks good. Thanks for finding and fixing it!
Thanks!
Now for some history on why THIS_FILE. The short story is that it's for
more reproducible and comparable b
Hello,
On 2018-11-30 10:03, Volker Simonis wrote:
Thanks for the background information. But as far as I can see, this
currently only works because "THIS_FILE" is always empty which of
course makes builds to various locations highly comparable :) On the
other hand, HotSpot is
On Fri, Nov 30, 2018 at 6:37 PM Erik Joelsson wrote:
>
> Hello Volker,
>
> The fix looks good. Thanks for finding and fixing it!
>
Thanks!
> Now for some history on why THIS_FILE. The short story is that it's for
> more reproducible and comparable builds.
>
>
Hello Volker,
The fix looks good. Thanks for finding and fixing it!
Now for some history on why THIS_FILE. The short story is that it's for
more reproducible and comparable builds.
When we started the build infra project, one of the design decisions was
to use absolute paths everywhe
tive files defines "THIS_FILE" to hold
the name of the current compilation unit. However, setting "THIS_FILE"
in NativeCompilation.gmk is broken and results in "THIS_FILE" always
being the empty string. I first thought that this is just a simple
quoting issue, but afte
Filed https://bugs.openjdk.java.net/browse/JDK-8205451
/Erik
On 2018-06-20 16:36, Erik Joelsson wrote:
That certainly looks like a bug. That macro was added to try to get
rid of the __FILE__ macro in the source code. Using __FILE__ and
__DATE__ makes it hard to achieve fully reproducible buil
That certainly looks like a bug. That macro was added to try to get rid
of the __FILE__ macro in the source code. Using __FILE__ and __DATE__
makes it hard to achieve fully reproducible builds where we can verify
build changes by simply comparing the output files.
/Erik
On 2018-06-20 16:30,
While exploring the *.cmdline files created by the build (thank you, those
are very helpful!) I noticed that they all contain
-DTHIS_FILE='""'
Probably there should be an actual file name there.
39 matches
Mail list logo
