On Tue, Nov 27, 2018 at 7:25 PM, Nick Gasson wrote:
> > I missed one thing then looking at this. In TimeZone_md.c it should be
> > #ifdef MACOSX rather than #ifndef. I can sponsor the change for you but
> > I need to change this one line before pushing.
>
> Hi Alan,
>
> Yes feel free to modify
> I missed one thing then looking at this. In TimeZone_md.c it should be
> #ifdef MACOSX rather than #ifndef. I can sponsor the change for you but
> I need to change this one line before pushing.
Hi Alan,
Yes feel free to modify it. I think looking at the at other files
with these #defines more
> On Nov 26, 2018, at 4:39 PM, Roman Kennke wrote:
> *) shared-gc
> - This is mostly boilerplate that is common to any GC
> - referenceProcessor.cpp has a little change to make one assert not fail
> (next to CMS and G1)
> - taskqueue.hpp has some small adjustments to enable
Hi
I looked at the tests changes only. It seems that a some tests might
start failing if JDK built without Shenandoah GC. Also some test are not
going to be selected as expected.
Unfortunately logic of '@requires' and @run in jtreg tests doesn't
always work well for specific cases of
> On Nov 27, 2018, at 4:46 AM, Roman Kennke wrote:
>
> Hi Kim,
>
>>> Sections to review (at this point) are the following:
>>>
>>> *) shared-gc
>>>- This is mostly boilerplate that is common to any GC
>>>- referenceProcessor.cpp has a little change to make one assert not fail
>>>
Hi,
Please review a follow up webrev[1] based on Priyanka’s patch, it simply added
a test case for Mac only that will link with libjli.
Note that, to use invoke API, one should probably link with libjvm, which works
for all supported platforms, not just Mac.
Cheers,
Henry
[1]
Hi.
Please take a look on a suggested change in OpenJDK make system which allows to
generate an image instrumented for code coverage analysis with JCov. There will
need to be follow-on changes making it possible to run test with code coverage.
When —with-jcov options supplied during
I agree. Is casting to int actually the right thing ? Definitely not always
Looking here (for example)
1042 int len;
1060 len = (int)(strlen(vendor) + 1 + strlen(renderer) + 1 +
1+strlen(version)+1 + 1);
we use len ONLY as an argument to malloc
1061 pAdapterId = malloc(len);]
So
Looks good to me.
Mandy
On 11/27/18 1:00 PM, Roger Riggs wrote:
Hi,
Updated webrev:
http://cr.openjdk.java.net/~rriggs/webrev-props-only-raw-4/index.html
- Updated defaults for VENDOR, VENDOR_URL, VENDOR_URL_BUG to:
COMPANY_NAME=N/A
VENDOR_URL=https://openjdk.java.net/
This looks good to me.
/Erik
On 2018-11-27 13:00, Roger Riggs wrote:
Hi,
Updated webrev:
http://cr.openjdk.java.net/~rriggs/webrev-props-only-raw-4/index.html
- Updated defaults for VENDOR, VENDOR_URL, VENDOR_URL_BUG to:
COMPANY_NAME=N/A
VENDOR_URL=https://openjdk.java.net/
Good. Thank you for testing. I don't have any more question about build changes.
I will wait C2 changes.
About C2 nodes names:
>> Is it possible to reuse LoadBarrier by adding GC specific flag to it?
>> I am not against adding new nodes if really needed. My concern is about
>> using GC name in
Hi,
Updated webrev:
http://cr.openjdk.java.net/~rriggs/webrev-props-only-raw-4/index.html
- Updated defaults for VENDOR, VENDOR_URL, VENDOR_URL_BUG to:
COMPANY_NAME=N/A
VENDOR_URL=https://openjdk.java.net/
VENDOR_URL_BUG=https://bugreport.java.com/bugreport/
- Added Brent's suggestion to
On 26/11/2018 09:08, Nick Gasson wrote:
Hi Alan,
I've done this here:
http://cr.openjdk.java.net/~njian/8214077/webrev.3/
I missed one thing then looking at this. In TimeZone_md.c it should be
#ifdef MACOSX rather than #ifndef. I can sponsor the change for you but
I need to change this one
>>> You need to check if shenandoahgc is disabled first - check
>>> DISABLED_JVM_FEATURES list (see code for jvmci).
>>
>> Why? If Shenandoah is disabled, it will be on this list, and therefore
>> not be built (see JvmFeatures.gmk).
>
> Did you test with --with-jvm-variants=-shenandoahgc to make
Hi Vladimir,
> On 11/27/18 1:37 AM, Roman Kennke wrote:
>> Hi Vladimir,
>>
>>> You need to check if shenandoahgc is disabled first - check
>>> DISABLED_JVM_FEATURES list (see code for jvmci).
>>
>> Why? If Shenandoah is disabled, it will be on this list, and therefore
>> not be built (see
On 11/27/18 1:37 AM, Roman Kennke wrote:
Hi Vladimir,
You need to check if shenandoahgc is disabled first - check
DISABLED_JVM_FEATURES list (see code for jvmci).
Why? If Shenandoah is disabled, it will be on this list, and therefore
not be built (see JvmFeatures.gmk).
Did you test with
+1
-phil.
On 11/27/18 8:45 AM, Erik Joelsson wrote:
Looks ok to me.
/Erik
On 2018-11-27 05:52, Volker Simonis wrote:
Hi,
can I please have a review for the following trivial change which
handles the absence of Xrandr more generically:
Looks ok to me.
/Erik
On 2018-11-27 07:33, Volker Simonis wrote:
Hi,
can I please have a review for the following trivial change which
simply disables the symbol visibility flags on AIX:
http://cr.openjdk.java.net/~simonis/webrevs/2018/8214063/
Looks ok to me.
/Erik
On 2018-11-27 05:52, Volker Simonis wrote:
Hi,
can I please have a review for the following trivial change which
handles the absence of Xrandr more generically:
http://cr.openjdk.java.net/~simonis/webrevs/2018/8214343/
https://bugs.openjdk.java.net/browse/JDK-8214343
On Tue, Nov 27, 2018 at 4:35 PM Volker Simonis wrote:
>
> Hi,
>
> can I please have a review for the following trivial change which
> simply disables the symbol visibility flags on AIX:
>
> http://cr.openjdk.java.net/~simonis/webrevs/2018/8214063/
>
Looks good.
/Erik
On 2018-11-27 02:25, Magnus Ihse Bursie wrote:
On 2018-11-26 20:33, Erik Joelsson wrote:
Nice to see this finally happening!
ProcessMarkdown.gmk: Looks like indentation got messed up on lines 79
and 98. Looks good otherwise.
Ooops. Updated webrev:
On Tue, Nov 27, 2018 at 4:56 PM Baesken, Matthias
wrote:
>
> > Change "8202322: AIX: symbol visibility flags not support on xlc 12.1"
> > [1] blindly introduced these flags for all xlC compiler versions >
>
> Hello, probably you did not look correctly at my change 8202322 .
>
> It did NOT
> Change "8202322: AIX: symbol visibility flags not support on xlc 12.1"
> [1] blindly introduced these flags for all xlC compiler versions >
Hello, probably you did not look correctly at my change 8202322 .
It did NOT "blindly" introduce visibility flags for all xlC compilers,
but
Hi Magnus,
Thanks for taking a look. I was wanting to change the SAFE_ALLOC definition,
but since that file is in java.base, I was not sure of changing it.
Krishna
From: Magnus Ihse Bursie
Sent: Tuesday, November 27, 2018 6:52 PM
To: Krishna Addepalli
Cc: Philip Race ;
Hi Phil,
To reduce the scope, I have created a new webrev, which addresses only warnings
on Linux platform.
Warnings for other platforms will be addressed in separate bugs.
Here is the new webrev: http://cr.openjdk.java.net/~kaddepalli/8074824/webrev02/
For your reference, I'm attaching
Hi,
can I please have a review for the following trivial change which
simply disables the symbol visibility flags on AIX:
http://cr.openjdk.java.net/~simonis/webrevs/2018/8214063/
https://bugs.openjdk.java.net/browse/JDK-8214063
Change "8202322: AIX: symbol visibility flags not support on xlc
Looks good Volker. I agree, NO_XRANDR is reasonable and better than HAVE_XRANDR.
I have to say, the amount of work this took is insane for the size of
the problem involved.
Cheers, Thomas
On Tue, Nov 27, 2018 at 2:54 PM Volker Simonis wrote:
>
> Hi,
>
> can I please have a review for the
Hi,
can I please have a review for the following trivial change which
handles the absence of Xrandr more generically:
http://cr.openjdk.java.net/~simonis/webrevs/2018/8214343/
https://bugs.openjdk.java.net/browse/JDK-8214343
Change JDK-8213944 fixed the build on AIX (which has no Xrandr) by
> 27 nov. 2018 kl. 14:32 skrev Krishna Addepalli :
>
> Hi Magnus,
>
> Thanks for taking a look. I was wanting to change the SAFE_ALLOC definition,
> but since that file is in java.base, I was not sure of changing it.
If you do change it, does it trigger compilation warnings/errors
On 27/11/2018 13:28, Magnus Ihse Bursie wrote:
26 nov. 2018 kl. 13:27 skrev Alan Bateman :
On 26/11/2018 09:08, Nick Gasson wrote:
Hi Alan,
I've done this here:
http://cr.openjdk.java.net/~njian/8214077/webrev.3/
This looks good and I think means we no longer have any stat usages in
> 26 nov. 2018 kl. 13:27 skrev Alan Bateman :
>
>> On 26/11/2018 09:08, Nick Gasson wrote:
>> Hi Alan,
>>
>> I've done this here:
>>
>> http://cr.openjdk.java.net/~njian/8214077/webrev.3/
> This looks good and I think means we no longer have any stat usages in
> libjava.
Do we have stat
I normally do not comment on component source code changes, but I glanced
through this and noticed that a lot of size_t values are casted to int, in
situations where a size_t is expected, like SAFE_ALLOC or so. Perhaps it would
be better to change the argument to those functions, rather than to
> Do you support 32-bit x86? You have OPENJDK_TARGET_CPU == xx86 check.
>
> Do you support all x86 OSs?
We enable this because we can actually run on such hardware. We fall
back to 'passive' mode though, which means Shenandoah acts more or less
like Parallel GC, and doesn't involve any barriers
On 2018-11-26 20:33, Erik Joelsson wrote:
Nice to see this finally happening!
ProcessMarkdown.gmk: Looks like indentation got messed up on lines 79
and 98. Looks good otherwise.
Ooops. Updated webrev:
http://cr.openjdk.java.net/~ihse/JDK-8178317-man-pages-according-to-JEP299/webrev.02
On 2018-11-26 19:57, Magnus Ihse Bursie wrote:
This patch will finally implement the last part of JEP 299, moving man
pages into the prescribed location in the source tree.
This patch also prepares for supplying man pages in markdown format,
which will be converted to troff (standard man page
Thanks for reviewing, Erik!
Roman
> Build changes look ok to me.
>
> /Erik
>
> On 2018-11-26 13:39, Roman Kennke wrote:
>> Hi,
>>
>> This is the first round of changes for including Shenandoah GC into
>> mainline.
>> I divided the review into parts that roughly correspond to the mailing
>>
36 matches
Mail list logo
