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 cou
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:
- _FI
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 repo
Hi Erik,
Build and hotspot changes seem okay.
Thanks,
David
On 5/04/2019 8:03 am, Erik Joelsson wrote:
On 2019-04-04 14:26, Kim Barrett wrote:
OK, I can do that.
--
src/hotspot/share/utilities/macros.hpp
645 #
Thanks for clarifying Erik.
Looks good.
David
On 4/04/2019 11:48 pm, Erik Joelsson wrote:
Hello David,
On 2019-04-03 18:49, David Holmes wrote:
Hi Erik,
On 4/04/2019 1:33 am, Erik Joelsson wrote:
Hello Jie,
This issue applies not only to --with-jmh, but to any configure
parameter given w
> On Apr 4, 2019, at 6:03 PM, Erik Joelsson wrote:
>
>
> 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
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 THIS_FI
> 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 __FILE__ with my new THIS_FILE, and I suspect som
Erik:
Looks good.
Tim
On 04/04/19 12:56, Erik Joelsson wrote:
I found the issue. It was broken before too, but the old piping
construct just ignored the error (but it was still printed). Fixed by
making sure the bootcycle-build directory exists before calling the
bootcycle build.
Bug: https:/
I found the issue. It was broken before too, but the old piping
construct just ignored the error (but it was still printed). Fixed by
making sure the bootcycle-build directory exists before calling the
bootcycle build.
Bug: https://bugs.openjdk.java.net/browse/JDK-8221996
Webrev: http://cr.op
This looks good to me and should work continue to work for us.
/Erik
On 2019-04-04 08:36, Langer, Christoph wrote:
Hi Erik,
Good. Then we are back at my latest webrev:
http://cr.openjdk.java.net/~clanger/webrevs/8221880.1/
Ah, right, this change does not remove JDK_RC_PLATFORM_NAME from
ver
It's not just you. I see it in our CI as well. It was caused by my
change https://bugs.openjdk.java.net/browse/JDK-8221764 Will look into it.
/Erik
On 2019-04-04 11:35, Andrew Haley wrote:
This is jdk-jdk, 54423:6c0ab8bd8da5
Building JVM variant 'server' with features 'aot cds cmsgc compiler1
This is jdk-jdk, 54423:6c0ab8bd8da5
Building JVM variant 'server' with features 'aot cds cmsgc compiler1 compiler2
dtrace epsilongc g1gc graal jfr jni-check jvmci jvmti management nmt parallelgc
serialgc services shenandoahgc vm-structs'
Boot cycle build step 2: Building a new JDK image using pr
Hi Erik,
> > Good. Then we are back at my latest webrev:
> http://cr.openjdk.java.net/~clanger/webrevs/8221880.1/
>
> Ah, right, this change does not remove JDK_RC_PLATFORM_NAME from
> version-numbers, but it does remove it from spec.gmk.in. Could you leave
> it in spec.gmk.in? Then you can commi
Hi Erik,
Thank you so much for your review and suggestions.
Hello Jie,
Looks good, just some grammatical notes on the first paragraph. Here
is my suggestion:
Docker tests with default parameters may fail on OS versions newer
than oraclelinux 7.6.
For example, they pass on Ubuntu 16.04 but f
Thanks Erik for fixing this issue.
On 2019年04月04日 21:48, Erik Joelsson wrote:
Hello David,
On 2019-04-03 18:49, David Holmes wrote:
Hi Erik,
On 4/04/2019 1:33 am, Erik Joelsson wrote:
Hello Jie,
This issue applies not only to --with-jmh, but to any configure
parameter given with a relativ
On 2019-04-04 07:15, Langer, Christoph wrote:
Hello Erik,
In OpenJDK builds, the current strings evaluate to "OpenJDK Platform"
and for Oracle builds "Java(TM) Platform SE". It makes me curious as to
what you need to modify the string to?
We want to print "SapMachine" there, see this commit:
Hello Erik,
> >> In OpenJDK builds, the current strings evaluate to "OpenJDK Platform"
> >> and for Oracle builds "Java(TM) Platform SE". It makes me curious as to
> >> what you need to modify the string to?
> > We want to print "SapMachine" there, see this commit:
> >
> https://github.com/SAP/Sap
Hello,
On 2019-04-04 00:10, Langer, Christoph wrote:
Hi Erik,
Looking closer at what we are doing, we are actually overriding
JDK_RC_PLATFORM_NAME as well, and there are a couple of direct
references to that variable in our custom makefiles. So I will still
need to update those if this goes in
Hello David,
On 2019-04-03 18:49, David Holmes wrote:
Hi Erik,
On 4/04/2019 1:33 am, Erik Joelsson wrote:
Hello Jie,
This issue applies not only to --with-jmh, but to any configure
parameter given with a relative path. I think the proper fix would be
to record the current working directory
Hello Jie,
Looks good, just some grammatical notes on the first paragraph. Here is
my suggestion:
Docker tests with default parameters may fail on OS versions newer than
oraclelinux 7.6.
For example, they pass on Ubuntu 16.04 but fail on Ubuntu 18.04 if run
like this:
/Erik
On 2019-04-03
Hello Kim,
On 2019-04-03 16:34, Kim Barrett wrote:
On Apr 3, 2019, at 9:51 AM, Erik Joelsson wrote:
On 2019-04-02 16:02, Kim Barrett wrote:
Bug: https://bugs.openjdk.java.net/browse/JDK-8221851
Webrev: http://cr.openjdk.java.net/~erikj/8221851/webrev.01/index.html
/Erik
Here's an alternativ
The main difference is that instead of ensuring correct invariant when
we store anything into the heap (e.g. read-barrier before reads,
write-barrier before writes, plus a bunch of other stuff), we ensure the
strong invariance on objects when they get loaded, by employing what is
currently our wri
On 4/2/19 10:12 PM, Roman Kennke wrote:
> The main difference is that instead of ensuring correct invariant when
> we store anything into the heap (e.g. read-barrier before reads,
> write-barrier before writes, plus a bunch of other stuff), we ensure the
> strong invariance on objects when they get
Hi Erik,
> Looking closer at what we are doing, we are actually overriding
> JDK_RC_PLATFORM_NAME as well, and there are a couple of direct
> references to that variable in our custom makefiles. So I will still
> need to update those if this goes in.
Ok, but I think then we can/will keep JDK_RC_P
25 matches
Mail list logo
