From david.holmes at oracle.com Tue Mar 1 03:45:59 2016
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 1 Mar 2016 13:45:59 +1000
Subject: RFR: JDK-8150822: Fix typo in JDK-8150201
In-Reply-To: <56D41B46.7000900@oracle.com>
References: <56D41B46.7000900@oracle.com>
Message-ID: <56D51077.9030007@oracle.com>
Looks good.
Thanks,
David
-----
On 29/02/2016 8:19 PM, Erik Joelsson wrote:
> In JDK-8150201, some debug flags were corrected. In one of the
> overrides, the file name was misspelled so the debug flag correction is
> not in effect.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8150822
>
> Patch:
> diff -r 63a9e10565c4 make/solaris/makefiles/amd64.make
> --- a/make/solaris/makefiles/amd64.make
> +++ b/make/solaris/makefiles/amd64.make
> @@ -39,7 +39,7 @@
> # of OPT_CFLAGS. Restore it here.
> ifeq ($(ENABLE_FULL_DEBUG_SYMBOLS),1)
> OPT_CFLAGS/generateOptoStub.o += -g0 -xs
> - OPT_CFLAGS/LinearScan.o += -g0 -xs
> + OPT_CFLAGS/c1_LinearScan.o += -g0 -xs
> endif
>
>
>
> /Erik
From david.holmes at oracle.com Tue Mar 1 05:49:59 2016
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 1 Mar 2016 15:49:59 +1000
Subject: RFR: 8078112: Integrate Selection/Resolution test suite into
jtreg tests
In-Reply-To: <56D42B0B.6050008@oracle.com>
References: <56D42B0B.6050008@oracle.com>
Message-ID: <56D52D87.3040900@oracle.com>
Hi Dmitry,
On 29/02/2016 9:27 PM, Dmitry Dmitriev wrote:
> Hello,
>
> Please review this patch, which integrates the selection/resolution test
> suite into the JTreg test suite. This test suite was developed by Eric
> Mccorkle(OpenJDK: emc). Thanks Eric for that!
>
> This test suite uses a template-based generation scheme to exercise all
> aspects of the updated selection/resolution test suite from JVMS 8. It
> runs a very large number of tests, representing a very wide variety of
> cases. Extensive javadoc comments are found throughout the test code
> which describe the suite's functioning in more detail.
>
> Also note that this suite as already undergone extensive review as part
> of the development process.
>
> JBS: https://bugs.openjdk.java.net/browse/JDK-8078112
> webrev.00: http://cr.openjdk.java.net/~ddmitriev/8078112/webrev.00/
>
> Testing: Jprt, RBT(all platforms, product & fastdebug builds)
I hate to open this debate again but I see:
@library /runtime/SelectionResolution/classes
but no instructions on how to build the library contents.
Do we really need to specify a timeout?
@run main/othervm/timeout=300
Will these tests now run as part of JPRT submissions? If so:
a) have they been tested on all platforms?
b) how long do they take to run?
Thanks,
David
> Thanks,
> Dmitry
From roland.westrelin at oracle.com Tue Mar 1 11:25:53 2016
From: roland.westrelin at oracle.com (Roland Westrelin)
Date: Tue, 1 Mar 2016 12:25:53 +0100
Subject: [8u] backport of 8148353: [linux-sparc] Crash in libawt.so on
Linux SPARC
In-Reply-To: <20160301002500.GA4515@vimes>
References: <826FAB32-8FC1-4FDA-AE0E-0F3D083D8AFA@oracle.com>
<56D4D5BC.30503@oracle.com> <20160301002500.GA4515@vimes>
Message-ID: <8DC85D52-4C2C-4280-A01D-7F323AB4B7E1@oracle.com>
Thanks Rob & Vladimir.
Roland.
From paul.sandoz at oracle.com Tue Mar 1 15:03:20 2016
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 1 Mar 2016 16:03:20 +0100
Subject: RFR (S) 8150465: Unsafe methods to produce uninitialized arrays
In-Reply-To: <56CF86EE.6070704@oracle.com>
References: <56CE3222.6040207@oracle.com> <56CECE5E.4080105@redhat.com>
<56CF053A.3070607@oracle.com> <56CF0C1A.4040600@redhat.com>
<56CF1163.4040005@oracle.com>
<6D79C6DB-B770-4CAA-9338-154589441F8B@oracle.com>
<56CF86EE.6070704@oracle.com>
Message-ID:
Hi Jim,
My comment was not an intent to stifle discussion (which it thankfully did not do!) or to exactly equate functionality, it was just pointing out that the unsafe approach of non-zeroing is not uncharted territory when we are all at sea with Unsafe.
FWIW (you may know this already perhaps) Unsafe.allocateMemory is used in the constructor of DirectByteBuffer [*], which zeros out the contents, and is safe because it?s all carefully performed in the constructor.
Paul.
[*]
DirectByteBuffer(int cap) { // package-private
super(-1, 0, cap, cap);
boolean pa = VM.isDirectMemoryPageAligned();
int ps = Bits.pageSize();
long size = Math.max(1L, (long)cap + (pa ? ps : 0));
Bits.reserveMemory(size, cap);
long base = 0;
try {
base = unsafe.allocateMemory(size);
} catch (OutOfMemoryError x) {
Bits.unreserveMemory(size, cap);
throw x;
}
unsafe.setMemory(base, size, (byte) 0);
if (pa && (base % ps != 0)) {
// Round up to page boundary
address = base + ps - (base & (ps - 1));
} else {
address = base;
}
cleaner = Cleaner.create(this, new Deallocator(base, size, cap));
att = null;
}
> On 25 Feb 2016, at 23:57, Jim Graham wrote:
>
> Just to play devil's advocate here.
>
> It's true that from a code correctness-safety perspective Unsafe programmers can already shoot themselves in the foot with uninitialized allocations, but from the security point of view the two methods don't have the same opportunity to leak information.
>
> Unsafe.allocateMemory returns a long, which is just a long to any untrusted code since it can't use the Unsafe methods to access the data in it.
>
> The new uninitialized array allocation returns a primitive array which can be inspected by untrusted code for any stale elements that hold private information from a previous allocation - should that array ever be leaked to untrusted code...
>
> ...jim
>
> On 2/25/2016 7:47 AM, Paul Sandoz wrote:
>>
>>> On 25 Feb 2016, at 15:36, Aleksey Shipilev wrote:
>>>
>>> On 02/25/2016 05:13 PM, Andrew Haley wrote:
>>>> On 02/25/2016 01:44 PM, Aleksey Shipilev wrote:
>>>>> Of course, you will still see garbage data if after storing the array
>>>>> elements into the uninitialized array you would publish it racily. But
>>>>> the same is true for the "regular" allocations and subsequent writes.
>>>>> The only difference is whether you see "real" garbage, or some
>>>>> "synthetic" garbage like zeros. It is, of course, a caller
>>>>> responsibility to publish array safely in both cases, if garbage is
>>>>> unwanted.
>>>>
>>>> Of course, my worry with this optimization assumes that programmers
>>>> make mistakes. But you did say "complicated processing is done after
>>>> the allocation." And that's where programmers make mistakes.
>>>
>>> Of course they do; at least half of the Unsafe methods is suitable for
>>> shooting oneself in a foot in creative ways. Unsafe is a sharp tool, and
>>> Unsafe callers are trusted in their madness. This is not your average
>>> Joe's use case, for sure.
>>>
>>
>> FTR the contents of the memory allocated by Unsafe.allocateMemory are also uninitialized.
>>
>> Paul.
>>
From mikael.vidstedt at oracle.com Tue Mar 1 16:58:10 2016
From: mikael.vidstedt at oracle.com (Mikael Vidstedt)
Date: Tue, 1 Mar 2016 08:58:10 -0800
Subject: RFR (M): 8149159: Clean up Unsafe
In-Reply-To: <56C7757E.4070806@oracle.com>
References: <56C61A07.4010604@oracle.com> <56C7757E.4070806@oracle.com>
Message-ID: <56D5CA22.7050308@oracle.com>
Thanks for all the great feedback/questions. Updated webrev(s) here:
http://cr.openjdk.java.net/~mikael/webrevs/8149159_unsafecleanup/hotspot/webrev.01.incr/webrev/
http://cr.openjdk.java.net/~mikael/webrevs/8149159_unsafecleanup/jdk/webrev.01.incr/webrev/
Also, here are the changes after rebasing on top of hs-comp to include
Aleksey's recent changes to Unsafe. There were some conflicts in
unsafe.cpp where the new methods/functions were added, so I had to
resolve that and apply the cleanup to them as well.
hotspot:
http://cr.openjdk.java.net/~mikael/webrevs/8149159_unsafecleanup/hotspot/webrev.01/webrev/
jdk:
http://cr.openjdk.java.net/~mikael/webrevs/8149159_unsafecleanup/jdk/webrev.01/webrev/
* Changes
Apart from resolving the conflicts in unsafe.cpp, this change include
the following changes compared to webrev.00:
Claes - you are absolutely about right about the missing annotations, I
have gone through and added the ForceInline annotation to all the
s.m.Unsafe methods were it was missing. Thanks for catching that!
Chris - I chose to completely remove the UnsafeWrapper macro and its
uses from unsafe.cpp. After all it's empty right now, and if somebody
feels like adding it back it can simply be injected into the
UNSAFE_ENTRY/UNSAFE_LEAF macros.
* Testing
I've run both -testset hotspot and -testset core on this, and FWIW it's
all green.
* Comments/other
Stas - Wrt to the changes to the unsafe.cpp function names, I chose to
rename the functions to include the suffix "0" to reflect the name
change of the corresponding java (native) methods. While it's not
strictly necessary it does feel just a tad clearer/more intuitive to me
to have the names match.
John/Paul - I filed https://bugs.openjdk.java.net/browse/JDK-8150921 to
cover the migration from single (long) addressing modes for the Unsafe
getters/setters to the double-register (Object + long) equivalents.
Cheers,
Mikael
On 2016-02-19 12:05, Claes Redestad wrote:
> Good stuff! But quite a few delegating methods in sun.misc.Unsafe did
> not get the @ForceInline treatment, which seems like an oversight?
>
> Thanks!
> /Claes
>
> On 2016-02-18 20:22, Mikael Vidstedt wrote:
>>
>> Please review the following change which does some relatively
>> significant cleaning up of the Unsafe implementation.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8149159
>> Webrev (hotspot):
>> http://cr.openjdk.java.net/~mikael/webrevs/8149159_unsafecleanup/hotspot/webrev.00/webrev/
>> Webrev (jdk):
>> http://cr.openjdk.java.net/~mikael/webrevs/8149159_unsafecleanup/jdk/webrev.00/webrev/
>>
>> Summary:
>>
>> * To avoid code duplication sun.misc.Unsafe now delegates all work to
>> jdk.internal.misc.Unsafe. This also means that the VM - and
>> unsafe.cpp specifically - no longer needs to know or care about
>> s.m.Unsafe.
>> * The s.m.Unsafe delegation methods have all been decorated with
>> @ForceInline to minimize the risk of performance regressions, though
>> it is highly likely that they will be inlined even without the
>> annotations.
>> * The documentation has been updated to reflect that it is the
>> responsibility of the user of Unsafe to make sure arguments are valid.
>> * The argument checking has, to the extent possible, been moved from
>> unsafe.cpp up to Java to simplify the native code and allow the JIT
>> to optimize it.
>> * Some of the argument checks have been relaxed. For example, the
>> recently introduced U.copySwapMemory does not check for null pointers
>> anymore. See docs for j.i.m.U.checkPointer for the complete reasoning
>> behind this. Note that the Unsafe methods today, apart from
>> U.copySwapMemory, do not perform the NULL related check(s).
>> * A test was added for j.i.m.U.copyMemory, based on U.copySwapMemory.
>> Feel free to point out that I should merge them (because I should).
>>
>> Also, unsafe.cpp was cleaned up rather dramatically. Some specific
>> highlights:
>>
>> * Unsafe_ functions are now declared static, as are the other
>> unsafe.cpp local functions.
>> * Created unsafe.hpp and moved some functions used in other parts of
>> the VM to that. Removed some "extern" function declarations (extern
>> is bad, kittens die when extern is (over-)used).
>> * Remove scary looking comment about UNSAFE_LEAF not being possible
>> to use - there's nothing special about it, it's just a JVM_LEAF.
>> * Used UNSAFE_LEAF for a few simple leaf methods
>> * Added helpful braces around UNSAFE_ENTRY/UNSAFE_END to help
>> auto-indent
>> * Removed unused Unsafe_<...>##140 functions/macros
>> * Updated macro argument names to be consistent throughout unsafe.cpp
>> macro definitions
>> * Replaced some checks with asserts - as per above the checks are now
>> performed in j.i.m.Unsafe instead.
>> * Removed all the s.m.Unsafe related code
>>
>>
>> Testing:
>>
>> * jtreg: hotspot_jprt group, jdk/internal
>> * JPRT: hotspot testset
>> * Perf: JMH unsafe-bench.jar (no significant changes)
>>
>> I'm taking suggestions on additional things to test.
>>
>> Cheers,
>> Mikael
>>
>
From dmitry.dmitriev at oracle.com Tue Mar 1 17:38:53 2016
From: dmitry.dmitriev at oracle.com (Dmitry Dmitriev)
Date: Tue, 1 Mar 2016 20:38:53 +0300
Subject: RFR: 8078112: Integrate Selection/Resolution test suite into
jtreg tests
In-Reply-To: <56D52D87.3040900@oracle.com>
References: <56D42B0B.6050008@oracle.com> <56D52D87.3040900@oracle.com>
Message-ID: <56D5D3AD.7030308@oracle.com>
Hello David,
Thank you for the comments! I added build instructions to the tests.
I specify timeout because on fastdebug builds test needs more time.
Only two tests will be run as part of JPRT submissions -
InvokeStaticSuccessTest and NoSuchMethodErrorTest.
InvokeStaticSuccessTest takes 1-3 seconds and NoSuchMethodErrorTest
takes 2-9 seconds. Other tests are excluded from JPRT run.
Updated webrev.01:
http://cr.openjdk.java.net/~ddmitriev/8078112/webrev.01/
Thank you,
Dmitry
On 01.03.2016 8:49, David Holmes wrote:
> Hi Dmitry,
>
> On 29/02/2016 9:27 PM, Dmitry Dmitriev wrote:
>> Hello,
>>
>> Please review this patch, which integrates the selection/resolution test
>> suite into the JTreg test suite. This test suite was developed by Eric
>> Mccorkle(OpenJDK: emc). Thanks Eric for that!
>>
>> This test suite uses a template-based generation scheme to exercise all
>> aspects of the updated selection/resolution test suite from JVMS 8. It
>> runs a very large number of tests, representing a very wide variety of
>> cases. Extensive javadoc comments are found throughout the test code
>> which describe the suite's functioning in more detail.
>>
>> Also note that this suite as already undergone extensive review as part
>> of the development process.
>>
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8078112
>> webrev.00: http://cr.openjdk.java.net/~ddmitriev/8078112/webrev.00/
>>
>> Testing: Jprt, RBT(all platforms, product & fastdebug builds)
>
> I hate to open this debate again but I see:
>
> @library /runtime/SelectionResolution/classes
>
> but no instructions on how to build the library contents.
>
> Do we really need to specify a timeout?
>
> @run main/othervm/timeout=300
>
> Will these tests now run as part of JPRT submissions? If so:
> a) have they been tested on all platforms?
> b) how long do they take to run?
>
> Thanks,
> David
>
>
>> Thanks,
>> Dmitry
From tom.benson at oracle.com Tue Mar 1 18:39:29 2016
From: tom.benson at oracle.com (Tom Benson)
Date: Tue, 1 Mar 2016 13:39:29 -0500
Subject: [9] RFR (S) 8146436: Add -XX:+UseAggressiveHeapShrink option
In-Reply-To: <56D5325B.80903@oracle.com>
References: <56B39A43.5070409@oracle.com> <56BB8F3D.3070502@oracle.com>
<56BB9831.5030504@oracle.com> <56BB9A9A.7060901@oracle.com>
<56BB9FEA.5070506@oracle.com> <56BBA27C.2080106@oracle.com>
<56BBA353.2020805@oracle.com> <56C5E177.9030104@oracle.com>
<56CB3524.7030800@oracle.com> <56CF46B4.9080800@oracle.com>
<56D5325B.80903@oracle.com>
Message-ID: <56D5E1E1.3060803@oracle.com>
Hi Chris,
Looks good.
I do notice that the trace printed at line 273 in cardGeneration will
show "shrink factors" of zero when ShrinkHeapInSteps is disabled, when
100 might be expected. But OTOH, you could interpret zero as 'not in
use.' I would leave it as is, but perhaps the other reviewer (or you)
will have a different opinion. OK with that as well.
Tom
On 3/1/2016 1:10 AM, Chris Plummer wrote:
> On 2/25/16 10:23 AM, Chris Plummer wrote:
>> On 2/22/16 8:19 AM, Chris Plummer wrote:
>>> On 2/18/16 7:21 AM, Tom Benson wrote:
>>>> Hi Chris,
>>>>
>>>> On 2/10/2016 3:53 PM, Chris Plummer wrote:
>>>>> On 2/10/16 12:50 PM, Tom Benson wrote:
>>>>>>
>>>>>> I've heard from another GC team person that there might be more
>>>>>> feedback on the name coming, after some discussion. Not sure if
>>>>>> it will constitute the 'landslide' I mentioned. 8^)
>>>>> No problem. I'll wait for that to settle before sending out a
>>>>> final webrev.
>>>>
>>>> "Landslide" may not be the right term, but there was mild consensus
>>>> among the GC team that it's worth going through CCC again to
>>>> replace UseAggressiveHeapShrink. Our suggestion is
>>>> "ShrinkHeapInSteps", which would be on by default, and hopefully
>>>> describes what's happening without any other implications. So
>>>> you'd disable it to get what you want.
>>>> Tom
>>> Hi Tom,
>>>
>>> Ok, I'll get started with this. Just got back from vacation today,
>>> but it shouldn't take long to get to it.
>>>
>> Updated webrev:
>>
>> http://cr.openjdk.java.net/~cjplummer/8146436/webrev.03/
>>
>> thanks,
> Ping. Tom and Jon can you give final approval for this?
>
> Thanks.
>
> Chris
>>
>> Chris
>>
>>> thanks,
>>>
>>> Chris
>>>>
>>>>>
>>>>> thanks,
>>>>>
>>>>> Chris
>>>>>> Tom
>>>>>>
>>>>>> On 2/10/2016 3:39 PM, Chris Plummer wrote:
>>>>>>> Hi Tom,
>>>>>>>
>>>>>>> if (!UseAggressiveHeapShrink) {
>>>>>>> // If UseAggressiveHeapShrink is false (the default),
>>>>>>> // we don't want shrink all the way back to initSize if
>>>>>>> people call
>>>>>>> // System.gc(), because some programs do that between
>>>>>>> "phases" and then
>>>>>>> // we'd just have to grow the heap up again for the next
>>>>>>> phase. So we
>>>>>>> // damp the shrinking: 0% on the first call, 10% on the
>>>>>>> second call, 40%
>>>>>>> // on the third call, and 100% by the fourth call. But
>>>>>>> if we recompute
>>>>>>> // size without shrinking, it goes back to 0%.
>>>>>>> shrink_bytes = shrink_bytes / 100 * current_shrink_factor;
>>>>>>> }
>>>>>>> assert(shrink_bytes <= max_shrink_bytes, "invalid shrink
>>>>>>> size");
>>>>>>> if (current_shrink_factor == 0) {
>>>>>>> _shrink_factor = 10;
>>>>>>> } else {
>>>>>>> _shrink_factor = MIN2(current_shrink_factor * 4,
>>>>>>> (size_t) 100);
>>>>>>> }
>>>>>>>
>>>>>>> I got rid of the changes at the start of the method, and added
>>>>>>> the !UseAggressiveHeapShrink check and the comment, so the first
>>>>>>> 2 lines above and the closing right brace are now the only
>>>>>>> change in the file, other than the copyright date. If you want I
>>>>>>> could also move the _shrink_factor adjustment into this block
>>>>>>> since the value of _shrink_factor becomes irrelevant if
>>>>>>> UseAggressiveHeapShrink is true. The assert should remain
>>>>>>> outside the block.
>>>>>>>
>>>>>>> cheers,
>>>>>>>
>>>>>>> Chris
>>>>>>>
>>>>>>> On 2/10/16 12:16 PM, Tom Benson wrote:
>>>>>>>> Hi Chris,
>>>>>>>> OK, that all sounds good.
>>>>>>>>
>>>>>>>> >> I can change it, although that will mean filing a new CCC.
>>>>>>>> Ah, I'd forgotten about that. Not worth it, unless there's a
>>>>>>>> landslide of support for a different name.
>>>>>>>>
>>>>>>>> Tnx,
>>>>>>>> Tom
>>>>>>>>
>>>>>>>> On 2/10/2016 3:06 PM, Chris Plummer wrote:
>>>>>>>>> Hi Tom,
>>>>>>>>>
>>>>>>>>> Thanks for having a look. Comments inline below:
>>>>>>>>>
>>>>>>>>> On 2/10/16 11:27 AM, Tom Benson wrote:
>>>>>>>>>> Hi Chris,
>>>>>>>>>> My apologies if I missed the discussion somewhere, but is
>>>>>>>>>> there a specific rationale for adding this that can be
>>>>>>>>>> mentioned in the bug report? I can imagine scenarios where
>>>>>>>>>> it would be useful, but maybe the real need can be called out.
>>>>>>>>> In general, it is for customers that want to minimize the
>>>>>>>>> amount of memory used by the java heap, and are willing to
>>>>>>>>> sacrifice some performance (induce more frequent GCs) to save
>>>>>>>>> that memory. When heap usage fluctuates greatly, the GC will
>>>>>>>>> tend to hold on to that memory longer than needed due to the
>>>>>>>>> the current algorithm which requires 4 full GCs before
>>>>>>>>> MaxHeapFreeRatio is fully honored. If this is what you are
>>>>>>>>> looking for, I can add it to the CR.
>>>>>>>>>>
>>>>>>>>>> I think it might be clearer if the new code in cardGeneration
>>>>>>>>>> was moved down to where the values are used. IE, I would
>>>>>>>>>> leave the inits of current_shrink_factor and _shrink_factor
>>>>>>>>>> as they were at lines 190/191. Then down at 270, just don't
>>>>>>>>>> divide by the shrink factor if UseAggressiveHeapShrink is
>>>>>>>>>> set, and the updates to shrink factor can be in the same
>>>>>>>>>> conditional. This has the advantage that you can fix the
>>>>>>>>>> comment just above it to match this special case. Do you
>>>>>>>>>> think that would work?
>>>>>>>>> Yes, that makes sense. I'll get started on it. I have a
>>>>>>>>> vacation coming up shortly, so what I'll get a new webrev out
>>>>>>>>> soon, but probably will need to wait until after my trip to do
>>>>>>>>> more thorough testing and push the changes.
>>>>>>>>>>
>>>>>>>>>> It looks like the ending "\" at line 3330 in globals.hpp
>>>>>>>>>> isn't aligned, and the copyright in cardGeneration.cpp needs
>>>>>>>>>> to be updated.
>>>>>>>>> Ok.
>>>>>>>>>>
>>>>>>>>>> One other nit, which you can ignore unless someone comes
>>>>>>>>>> forward to agree with me 8^) , is that I'd prefer the name
>>>>>>>>>> ShrinkHeapAggressively instead. Maybe this was already
>>>>>>>>>> debated elsewhere....
>>>>>>>>> The name choice hasn't really been discussed or questioned. It
>>>>>>>>> was what was suggested to me, so I stuck with it (The initial
>>>>>>>>> work was done by someone else. I'm just getting it integrated
>>>>>>>>> into 9). I can change it, although that will mean filing a new
>>>>>>>>> CCC.
>>>>>>>>>
>>>>>>>>> thanks,
>>>>>>>>>
>>>>>>>>> Chris
>>>>>>>>>> Tom
>>>>>>>>>>
>>>>>>>>>> On 2/4/2016 1:36 PM, Chris Plummer wrote:
>>>>>>>>>>> Hello,
>>>>>>>>>>>
>>>>>>>>>>> Please review the following for adding the -XX
>>>>>>>>>>> UseAggressiveHeapShrink option. When turned on, it tells the
>>>>>>>>>>> GC to reduce the heap size to the new target size
>>>>>>>>>>> immediately after a full GC rather than doing it
>>>>>>>>>>> progressively over 4 GCs.
>>>>>>>>>>>
>>>>>>>>>>> Webrev:
>>>>>>>>>>> http://cr.openjdk.java.net/~cjplummer/8146436/webrev.02/
>>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8146436
>>>>>>>>>>>
>>>>>>>>>>> Testing:
>>>>>>>>>>> -JPRT with '-testset hotspot'
>>>>>>>>>>> -JPRT with '-testset hotspot -vmflags
>>>>>>>>>>> "-XX:+UseAggressiveHeapShrink"'
>>>>>>>>>>> -added new TestMaxMinHeapFreeRatioFlags.java test
>>>>>>>>>>>
>>>>>>>>>>> thanks,
>>>>>>>>>>>
>>>>>>>>>>> Chris
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
From aleksey.shipilev at oracle.com Tue Mar 1 18:45:15 2016
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Tue, 1 Mar 2016 21:45:15 +0300
Subject: RFR (S) 8150465: Unsafe methods to produce uninitialized arrays
In-Reply-To: <56CE3222.6040207@oracle.com>
References: <56CE3222.6040207@oracle.com>
Message-ID: <56D5E33B.4050606@oracle.com>
On 02/25/2016 01:43 AM, Aleksey Shipilev wrote:
> Webrevs:
> http://cr.openjdk.java.net/~shade/8150465/webrev.hs.01/
> http://cr.openjdk.java.net/~shade/8150465/webrev.jdk.01/
For the record, after all good reviews and discussions happened in this
thread, I'll be pushing these soon:
http://cr.openjdk.java.net/~shade/8150465/webrev.hs.04/
http://cr.openjdk.java.net/~shade/8150465/webrev.jdk.04/
Thanks,
-Aleksey
From david.holmes at oracle.com Tue Mar 1 21:13:54 2016
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 2 Mar 2016 07:13:54 +1000
Subject: RFR: 8078112: Integrate Selection/Resolution test suite into
jtreg tests
In-Reply-To: <56D5D3AD.7030308@oracle.com>
References: <56D42B0B.6050008@oracle.com> <56D52D87.3040900@oracle.com>
<56D5D3AD.7030308@oracle.com>
Message-ID: <56D60612.7020903@oracle.com>
On 2/03/2016 3:38 AM, Dmitry Dmitriev wrote:
> Hello David,
>
> Thank you for the comments! I added build instructions to the tests.
Thank you.
> I specify timeout because on fastdebug builds test needs more time.
Don't we set a different default timeout when running fastdebug? Perhaps
not. Anyway I see there are a range of different timeout values
specified so presumably this has been tuned for the slowest machines ?
> Only two tests will be run as part of JPRT submissions -
> InvokeStaticSuccessTest and NoSuchMethodErrorTest.
> InvokeStaticSuccessTest takes 1-3 seconds and NoSuchMethodErrorTest
> takes 2-9 seconds. Other tests are excluded from JPRT run.
Thanks - I misread the change to TEST.groups.
> Updated webrev.01:
> http://cr.openjdk.java.net/~ddmitriev/8078112/webrev.01/
I can't comment on the details of the tests themselves but the adding of
the test suite seems okay.
Thanks,
David
> Thank you,
> Dmitry
>
> On 01.03.2016 8:49, David Holmes wrote:
>> Hi Dmitry,
>>
>> On 29/02/2016 9:27 PM, Dmitry Dmitriev wrote:
>>> Hello,
>>>
>>> Please review this patch, which integrates the selection/resolution test
>>> suite into the JTreg test suite. This test suite was developed by Eric
>>> Mccorkle(OpenJDK: emc). Thanks Eric for that!
>>>
>>> This test suite uses a template-based generation scheme to exercise all
>>> aspects of the updated selection/resolution test suite from JVMS 8. It
>>> runs a very large number of tests, representing a very wide variety of
>>> cases. Extensive javadoc comments are found throughout the test code
>>> which describe the suite's functioning in more detail.
>>>
>>> Also note that this suite as already undergone extensive review as part
>>> of the development process.
>>>
>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8078112
>>> webrev.00: http://cr.openjdk.java.net/~ddmitriev/8078112/webrev.00/
>>>
>>> Testing: Jprt, RBT(all platforms, product & fastdebug builds)
>>
>> I hate to open this debate again but I see:
>>
>> @library /runtime/SelectionResolution/classes
>>
>> but no instructions on how to build the library contents.
>>
>> Do we really need to specify a timeout?
>>
>> @run main/othervm/timeout=300
>>
>> Will these tests now run as part of JPRT submissions? If so:
>> a) have they been tested on all platforms?
>> b) how long do they take to run?
>>
>> Thanks,
>> David
>>
>>
>>> Thanks,
>>> Dmitry
>
From jon.masamitsu at oracle.com Tue Mar 1 23:05:57 2016
From: jon.masamitsu at oracle.com (Jon Masamitsu)
Date: Tue, 1 Mar 2016 15:05:57 -0800
Subject: [9] RFR (S) 8146436: Add -XX:+UseAggressiveHeapShrink option
In-Reply-To: <56D5325B.80903@oracle.com>
References: <56B39A43.5070409@oracle.com> <56BB8F3D.3070502@oracle.com>
<56BB9831.5030504@oracle.com> <56BB9A9A.7060901@oracle.com>
<56BB9FEA.5070506@oracle.com> <56BBA27C.2080106@oracle.com>
<56BBA353.2020805@oracle.com> <56C5E177.9030104@oracle.com>
<56CB3524.7030800@oracle.com> <56CF46B4.9080800@oracle.com>
<56D5325B.80903@oracle.com>
Message-ID: <56D62055.9060102@oracle.com>
On 2/29/2016 10:10 PM, Chris Plummer wrote:
> On 2/25/16 10:23 AM, Chris Plummer wrote:
>> On 2/22/16 8:19 AM, Chris Plummer wrote:
>>> On 2/18/16 7:21 AM, Tom Benson wrote:
>>>> Hi Chris,
>>>>
>>>> On 2/10/2016 3:53 PM, Chris Plummer wrote:
>>>>> On 2/10/16 12:50 PM, Tom Benson wrote:
>>>>>>
>>>>>> I've heard from another GC team person that there might be more
>>>>>> feedback on the name coming, after some discussion. Not sure if
>>>>>> it will constitute the 'landslide' I mentioned. 8^)
>>>>> No problem. I'll wait for that to settle before sending out a
>>>>> final webrev.
>>>>
>>>> "Landslide" may not be the right term, but there was mild consensus
>>>> among the GC team that it's worth going through CCC again to
>>>> replace UseAggressiveHeapShrink. Our suggestion is
>>>> "ShrinkHeapInSteps", which would be on by default, and hopefully
>>>> describes what's happening without any other implications. So
>>>> you'd disable it to get what you want.
>>>> Tom
>>> Hi Tom,
>>>
>>> Ok, I'll get started with this. Just got back from vacation today,
>>> but it shouldn't take long to get to it.
>>>
>> Updated webrev:
>>
>> http://cr.openjdk.java.net/~cjplummer/8146436/webrev.03/
>>
>> thanks,
> Ping. Tom and Jon can you give final approval for this?
Changes look good. Reviewed.
Jon
>
> Thanks.
>
> Chris
>>
>> Chris
>>
>>> thanks,
>>>
>>> Chris
>>>>
>>>>>
>>>>> thanks,
>>>>>
>>>>> Chris
>>>>>> Tom
>>>>>>
>>>>>> On 2/10/2016 3:39 PM, Chris Plummer wrote:
>>>>>>> Hi Tom,
>>>>>>>
>>>>>>> if (!UseAggressiveHeapShrink) {
>>>>>>> // If UseAggressiveHeapShrink is false (the default),
>>>>>>> // we don't want shrink all the way back to initSize if
>>>>>>> people call
>>>>>>> // System.gc(), because some programs do that between
>>>>>>> "phases" and then
>>>>>>> // we'd just have to grow the heap up again for the next
>>>>>>> phase. So we
>>>>>>> // damp the shrinking: 0% on the first call, 10% on the
>>>>>>> second call, 40%
>>>>>>> // on the third call, and 100% by the fourth call. But
>>>>>>> if we recompute
>>>>>>> // size without shrinking, it goes back to 0%.
>>>>>>> shrink_bytes = shrink_bytes / 100 * current_shrink_factor;
>>>>>>> }
>>>>>>> assert(shrink_bytes <= max_shrink_bytes, "invalid shrink
>>>>>>> size");
>>>>>>> if (current_shrink_factor == 0) {
>>>>>>> _shrink_factor = 10;
>>>>>>> } else {
>>>>>>> _shrink_factor = MIN2(current_shrink_factor * 4,
>>>>>>> (size_t) 100);
>>>>>>> }
>>>>>>>
>>>>>>> I got rid of the changes at the start of the method, and added
>>>>>>> the !UseAggressiveHeapShrink check and the comment, so the first
>>>>>>> 2 lines above and the closing right brace are now the only
>>>>>>> change in the file, other than the copyright date. If you want I
>>>>>>> could also move the _shrink_factor adjustment into this block
>>>>>>> since the value of _shrink_factor becomes irrelevant if
>>>>>>> UseAggressiveHeapShrink is true. The assert should remain
>>>>>>> outside the block.
>>>>>>>
>>>>>>> cheers,
>>>>>>>
>>>>>>> Chris
>>>>>>>
>>>>>>> On 2/10/16 12:16 PM, Tom Benson wrote:
>>>>>>>> Hi Chris,
>>>>>>>> OK, that all sounds good.
>>>>>>>>
>>>>>>>> >> I can change it, although that will mean filing a new CCC.
>>>>>>>> Ah, I'd forgotten about that. Not worth it, unless there's a
>>>>>>>> landslide of support for a different name.
>>>>>>>>
>>>>>>>> Tnx,
>>>>>>>> Tom
>>>>>>>>
>>>>>>>> On 2/10/2016 3:06 PM, Chris Plummer wrote:
>>>>>>>>> Hi Tom,
>>>>>>>>>
>>>>>>>>> Thanks for having a look. Comments inline below:
>>>>>>>>>
>>>>>>>>> On 2/10/16 11:27 AM, Tom Benson wrote:
>>>>>>>>>> Hi Chris,
>>>>>>>>>> My apologies if I missed the discussion somewhere, but is
>>>>>>>>>> there a specific rationale for adding this that can be
>>>>>>>>>> mentioned in the bug report? I can imagine scenarios where
>>>>>>>>>> it would be useful, but maybe the real need can be called out.
>>>>>>>>> In general, it is for customers that want to minimize the
>>>>>>>>> amount of memory used by the java heap, and are willing to
>>>>>>>>> sacrifice some performance (induce more frequent GCs) to save
>>>>>>>>> that memory. When heap usage fluctuates greatly, the GC will
>>>>>>>>> tend to hold on to that memory longer than needed due to the
>>>>>>>>> the current algorithm which requires 4 full GCs before
>>>>>>>>> MaxHeapFreeRatio is fully honored. If this is what you are
>>>>>>>>> looking for, I can add it to the CR.
>>>>>>>>>>
>>>>>>>>>> I think it might be clearer if the new code in cardGeneration
>>>>>>>>>> was moved down to where the values are used. IE, I would
>>>>>>>>>> leave the inits of current_shrink_factor and _shrink_factor
>>>>>>>>>> as they were at lines 190/191. Then down at 270, just don't
>>>>>>>>>> divide by the shrink factor if UseAggressiveHeapShrink is
>>>>>>>>>> set, and the updates to shrink factor can be in the same
>>>>>>>>>> conditional. This has the advantage that you can fix the
>>>>>>>>>> comment just above it to match this special case. Do you
>>>>>>>>>> think that would work?
>>>>>>>>> Yes, that makes sense. I'll get started on it. I have a
>>>>>>>>> vacation coming up shortly, so what I'll get a new webrev out
>>>>>>>>> soon, but probably will need to wait until after my trip to do
>>>>>>>>> more thorough testing and push the changes.
>>>>>>>>>>
>>>>>>>>>> It looks like the ending "\" at line 3330 in globals.hpp
>>>>>>>>>> isn't aligned, and the copyright in cardGeneration.cpp needs
>>>>>>>>>> to be updated.
>>>>>>>>> Ok.
>>>>>>>>>>
>>>>>>>>>> One other nit, which you can ignore unless someone comes
>>>>>>>>>> forward to agree with me 8^) , is that I'd prefer the name
>>>>>>>>>> ShrinkHeapAggressively instead. Maybe this was already
>>>>>>>>>> debated elsewhere....
>>>>>>>>> The name choice hasn't really been discussed or questioned. It
>>>>>>>>> was what was suggested to me, so I stuck with it (The initial
>>>>>>>>> work was done by someone else. I'm just getting it integrated
>>>>>>>>> into 9). I can change it, although that will mean filing a new
>>>>>>>>> CCC.
>>>>>>>>>
>>>>>>>>> thanks,
>>>>>>>>>
>>>>>>>>> Chris
>>>>>>>>>> Tom
>>>>>>>>>>
>>>>>>>>>> On 2/4/2016 1:36 PM, Chris Plummer wrote:
>>>>>>>>>>> Hello,
>>>>>>>>>>>
>>>>>>>>>>> Please review the following for adding the -XX
>>>>>>>>>>> UseAggressiveHeapShrink option. When turned on, it tells the
>>>>>>>>>>> GC to reduce the heap size to the new target size
>>>>>>>>>>> immediately after a full GC rather than doing it
>>>>>>>>>>> progressively over 4 GCs.
>>>>>>>>>>>
>>>>>>>>>>> Webrev:
>>>>>>>>>>> http://cr.openjdk.java.net/~cjplummer/8146436/webrev.02/
>>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8146436
>>>>>>>>>>>
>>>>>>>>>>> Testing:
>>>>>>>>>>> -JPRT with '-testset hotspot'
>>>>>>>>>>> -JPRT with '-testset hotspot -vmflags
>>>>>>>>>>> "-XX:+UseAggressiveHeapShrink"'
>>>>>>>>>>> -added new TestMaxMinHeapFreeRatioFlags.java test
>>>>>>>>>>>
>>>>>>>>>>> thanks,
>>>>>>>>>>>
>>>>>>>>>>> Chris
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
From james.graham at oracle.com Tue Mar 1 23:34:29 2016
From: james.graham at oracle.com (Jim Graham)
Date: Tue, 1 Mar 2016 15:34:29 -0800
Subject: RFR (S) 8150465: Unsafe methods to produce uninitialized arrays
In-Reply-To:
References: <56CE3222.6040207@oracle.com> <56CECE5E.4080105@redhat.com>
<56CF053A.3070607@oracle.com> <56CF0C1A.4040600@redhat.com>
<56CF1163.4040005@oracle.com>
<6D79C6DB-B770-4CAA-9338-154589441F8B@oracle.com>
<56CF86EE.6070704@oracle.com>
Message-ID: <56D62705.2020506@oracle.com>
Thanks Paul,
That code doesn't seem to follow the recommendations in the new
allocateUninit() method as far as publicizing the address field. Unless
unsafe.setMemory() does a fence?
...jim
On 3/1/16 7:03 AM, Paul Sandoz wrote:
> Hi Jim,
>
> My comment was not an intent to stifle discussion (which it thankfully did not do!) or to exactly equate functionality, it was just pointing out that the unsafe approach of non-zeroing is not uncharted territory when we are all at sea with Unsafe.
>
> FWIW (you may know this already perhaps) Unsafe.allocateMemory is used in the constructor of DirectByteBuffer [*], which zeros out the contents, and is safe because it?s all carefully performed in the constructor.
>
> Paul.
>
> [*]
> DirectByteBuffer(int cap) { // package-private
>
> super(-1, 0, cap, cap);
> boolean pa = VM.isDirectMemoryPageAligned();
> int ps = Bits.pageSize();
> long size = Math.max(1L, (long)cap + (pa ? ps : 0));
> Bits.reserveMemory(size, cap);
>
> long base = 0;
> try {
> base = unsafe.allocateMemory(size);
> } catch (OutOfMemoryError x) {
> Bits.unreserveMemory(size, cap);
> throw x;
> }
> unsafe.setMemory(base, size, (byte) 0);
> if (pa && (base % ps != 0)) {
> // Round up to page boundary
> address = base + ps - (base & (ps - 1));
> } else {
> address = base;
> }
> cleaner = Cleaner.create(this, new Deallocator(base, size, cap));
> att = null;
>
>
>
>
> }
>
>> On 25 Feb 2016, at 23:57, Jim Graham wrote:
>>
>> Just to play devil's advocate here.
>>
>> It's true that from a code correctness-safety perspective Unsafe programmers can already shoot themselves in the foot with uninitialized allocations, but from the security point of view the two methods don't have the same opportunity to leak information.
>>
>> Unsafe.allocateMemory returns a long, which is just a long to any untrusted code since it can't use the Unsafe methods to access the data in it.
>>
>> The new uninitialized array allocation returns a primitive array which can be inspected by untrusted code for any stale elements that hold private information from a previous allocation - should that array ever be leaked to untrusted code...
>>
>> ...jim
>>
>> On 2/25/2016 7:47 AM, Paul Sandoz wrote:
>>>
>>>> On 25 Feb 2016, at 15:36, Aleksey Shipilev wrote:
>>>>
>>>> On 02/25/2016 05:13 PM, Andrew Haley wrote:
>>>>> On 02/25/2016 01:44 PM, Aleksey Shipilev wrote:
>>>>>> Of course, you will still see garbage data if after storing the array
>>>>>> elements into the uninitialized array you would publish it racily. But
>>>>>> the same is true for the "regular" allocations and subsequent writes.
>>>>>> The only difference is whether you see "real" garbage, or some
>>>>>> "synthetic" garbage like zeros. It is, of course, a caller
>>>>>> responsibility to publish array safely in both cases, if garbage is
>>>>>> unwanted.
>>>>>
>>>>> Of course, my worry with this optimization assumes that programmers
>>>>> make mistakes. But you did say "complicated processing is done after
>>>>> the allocation." And that's where programmers make mistakes.
>>>>
>>>> Of course they do; at least half of the Unsafe methods is suitable for
>>>> shooting oneself in a foot in creative ways. Unsafe is a sharp tool, and
>>>> Unsafe callers are trusted in their madness. This is not your average
>>>> Joe's use case, for sure.
>>>>
>>>
>>> FTR the contents of the memory allocated by Unsafe.allocateMemory are also uninitialized.
>>>
>>> Paul.
>>>
>
From rob.mckenna at oracle.com Tue Mar 1 00:25:00 2016
From: rob.mckenna at oracle.com (Rob McKenna)
Date: Tue, 1 Mar 2016 00:25:00 +0000
Subject: [8u] backport of 8148353: [linux-sparc] Crash in libawt.so on
Linux SPARC
In-Reply-To: <56D4D5BC.30503@oracle.com>
References: <826FAB32-8FC1-4FDA-AE0E-0F3D083D8AFA@oracle.com>
<56D4D5BC.30503@oracle.com>
Message-ID: <20160301002500.GA4515@vimes>
Approved
-Rob
On 29/02/16 03:35, Vladimir Kozlov wrote:
> Looks good.
>
> Note, the code fix was applied cleanly to jdk 8u. Only test have to be
> modified.
>
> Thanks,
> Vladimir
>
> On 2/29/16 12:52 PM, Roland Westrelin wrote:
> >Hi,
> >
> >Please approve and review the following backport to 8u.
> >
> >8148353 was pushed to jdk9 last week (on Wednesday) and it hasn?t caused any new failures during nightly testing. The change doesn?t apply cleanly to 8u: I had to rework the test because the infrastructure to run native jtreg tests doesn?t seem to exist in 8. I restricted the test to linux-sparc to keep it simple.
> >
> >https://bugs.openjdk.java.net/browse/JDK-8148353
> >http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/1f4f4866aee0
> >
> >New webrev:
> >http://cr.openjdk.java.net/~roland/8148353/webrev.8u.00/
> >
> >review thread:
> >http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2016-February/thread.html#21530
> >
> >Note that when I pushed 8148353 to 9, the fix version was set to 8 and so a backport was created for 9.
> >
> >Roland.
> >
From dmitry.dmitriev at oracle.com Wed Mar 2 08:10:11 2016
From: dmitry.dmitriev at oracle.com (Dmitry Dmitriev)
Date: Wed, 2 Mar 2016 11:10:11 +0300
Subject: RFR: 8078112: Integrate Selection/Resolution test suite into
jtreg tests
In-Reply-To: <56D60612.7020903@oracle.com>
References: <56D42B0B.6050008@oracle.com> <56D52D87.3040900@oracle.com>
<56D5D3AD.7030308@oracle.com> <56D60612.7020903@oracle.com>
Message-ID: <56D69FE3.6050605@oracle.com>
Hello David,
Yes, you are right about the slowest machine. Thank you for the review!
Dmitry
On 02.03.2016 0:13, David Holmes wrote:
> On 2/03/2016 3:38 AM, Dmitry Dmitriev wrote:
>> Hello David,
>>
>> Thank you for the comments! I added build instructions to the tests.
>
> Thank you.
>
>> I specify timeout because on fastdebug builds test needs more time.
>
> Don't we set a different default timeout when running fastdebug?
> Perhaps not. Anyway I see there are a range of different timeout
> values specified so presumably this has been tuned for the slowest
> machines ?
>
>> Only two tests will be run as part of JPRT submissions -
>> InvokeStaticSuccessTest and NoSuchMethodErrorTest.
>> InvokeStaticSuccessTest takes 1-3 seconds and NoSuchMethodErrorTest
>> takes 2-9 seconds. Other tests are excluded from JPRT run.
>
> Thanks - I misread the change to TEST.groups.
>
>> Updated webrev.01:
>> http://cr.openjdk.java.net/~ddmitriev/8078112/webrev.01/
>>
>
> I can't comment on the details of the tests themselves but the adding
> of the test suite seems okay.
>
> Thanks,
> David
>
>> Thank you,
>> Dmitry
>>
>> On 01.03.2016 8:49, David Holmes wrote:
>>> Hi Dmitry,
>>>
>>> On 29/02/2016 9:27 PM, Dmitry Dmitriev wrote:
>>>> Hello,
>>>>
>>>> Please review this patch, which integrates the selection/resolution
>>>> test
>>>> suite into the JTreg test suite. This test suite was developed by
>>>> Eric
>>>> Mccorkle(OpenJDK: emc). Thanks Eric for that!
>>>>
>>>> This test suite uses a template-based generation scheme to exercise
>>>> all
>>>> aspects of the updated selection/resolution test suite from JVMS
>>>> 8. It
>>>> runs a very large number of tests, representing a very wide variety of
>>>> cases. Extensive javadoc comments are found throughout the test code
>>>> which describe the suite's functioning in more detail.
>>>>
>>>> Also note that this suite as already undergone extensive review as
>>>> part
>>>> of the development process.
>>>>
>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8078112
>>>> webrev.00: http://cr.openjdk.java.net/~ddmitriev/8078112/webrev.00/
>>>>
>>>> Testing: Jprt, RBT(all platforms, product & fastdebug builds)
>>>
>>> I hate to open this debate again but I see:
>>>
>>> @library /runtime/SelectionResolution/classes
>>>
>>> but no instructions on how to build the library contents.
>>>
>>> Do we really need to specify a timeout?
>>>
>>> @run main/othervm/timeout=300
>>>
>>> Will these tests now run as part of JPRT submissions? If so:
>>> a) have they been tested on all platforms?
>>> b) how long do they take to run?
>>>
>>> Thanks,
>>> David
>>>
>>>
>>>> Thanks,
>>>> Dmitry
>>
From aph at redhat.com Wed Mar 2 08:45:30 2016
From: aph at redhat.com (Andrew Haley)
Date: Wed, 2 Mar 2016 08:45:30 +0000
Subject: RFR (S) 8150465: Unsafe methods to produce uninitialized arrays
In-Reply-To: <56D62705.2020506@oracle.com>
References: <56CE3222.6040207@oracle.com> <56CECE5E.4080105@redhat.com>
<56CF053A.3070607@oracle.com> <56CF0C1A.4040600@redhat.com>
<56CF1163.4040005@oracle.com>
<6D79C6DB-B770-4CAA-9338-154589441F8B@oracle.com>
<56CF86EE.6070704@oracle.com>
<56D62705.2020506@oracle.com>
Message-ID: <56D6A82A.2030302@redhat.com>
On 01/03/16 23:34, Jim Graham wrote:
> Thanks Paul,
>
> That code doesn't seem to follow the recommendations in the new
> allocateUninit() method as far as publicizing the address field. Unless
> unsafe.setMemory() does a fence?
DirectByteBuffer.cleaner is final, so there is a fence at the end of
DirectByteBuffer's constructor. But there is perhaps a race here
because a Deallocator instance is created before the
Unsafe.setMemory() becomes observable to the cleaner thread. I don't
think that matters as long as the Deallocator is sane, but it's not a
pattern I like much.
Andrew.
From kirk.pepperdine at gmail.com Wed Mar 2 11:34:04 2016
From: kirk.pepperdine at gmail.com (kirk.pepperdine at gmail.com)
Date: Wed, 2 Mar 2016 05:34:04 -0600
Subject: safepoint accumulating time counter
In-Reply-To:
References:
<7845BD64-DD13-4ED8-A2A1-B6858BF2FA7A@oracle.com>
Message-ID: <2627E4E9-9B1B-421D-9EBD-2FD89861341D@gmail.com>
Hi Brian,
You can see the name of the MXBean interface in the metadata view. In that view you can see that the Diagnostic MXBean is not the one you are looking for. It would seem that this MXBean has not been registered with the PlatformMBeanServer.
Regards,
Kirk
> On Feb 29, 2016, at 5:04 PM, Brian Toal wrote:
>
> When I pull up jconsole and connect to a 1.8 runtime, I see
> com.sun.management (not sun.management) and under the HotSpotDiagnostic
> MBean I don't see any of the attributes mentioned. Is there something I
> need to do to enable the sun.management.HotspotRuntimeMBean?
>
> On Mon, Feb 29, 2016 at 10:02 AM, Carsten Varming wrote:
>
>> Dear Brian,
>>
>> I believe the HotspotRuntimeMBean[1] exports total time spent in
>> safepoints.
>>
>> [1]:
>> http://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/file/5972ad24ef27/src/share/classes/sun/management/HotspotRuntimeMBean.java
>>
>> Carsten
>>
>> On Mon, Feb 29, 2016 at 12:35 PM, charlie hunt
>> wrote:
>>
>>> Hi Brian,
>>>
>>> Nice to hear from you!
>>>
>>> Look at +PrintSafepointStatistics. I think you will figure it out from
>>> there.
>>>
>>> AFAIR, info is not exposed in an MBean.
>>>
>>> hths,
>>>
>>> Charlie
>>>
>>>> On Feb 29, 2016, at 10:32 AM, Brian Toal wrote:
>>>>
>>>> Hi, does the JVM expose total time spent in safepoints via an MBean or
>>>> another mechanism other than PrintGCApplicationStoppedTime?
>>> Specifically,
>>>> I'm curious whether this feature exists in Java 8.
>>>
>>
>>
From erik.joelsson at oracle.com Wed Mar 2 12:27:43 2016
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Wed, 2 Mar 2016 13:27:43 +0100
Subject: RFR JDK-8149644 Integrate VarHandles
In-Reply-To: <9C47EF6F-80D6-467E-A5CB-2FDD5FF6AE17@oracle.com>
References: <9C47EF6F-80D6-467E-A5CB-2FDD5FF6AE17@oracle.com>
Message-ID: <56D6DC3F.30402@oracle.com>
Build part looks ok.
/Erik
On 2016-02-11 16:39, Paul Sandoz wrote:
> Hi,
>
> This is the implementation review request for VarHandles.
>
> Langtools:
> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8149644-varhandles-integration/langtools/webrev/index.html
>
> Hotspot:
> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8149644-varhandles-integration/hotspot/webrev/index.html
>
> JDK:
> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8149644-varhandles-integration/jdk/webrev/index.html
>
> The spec/API review is proceeding here [1].
>
> The patches depend on Unsafe changes [2] and ByteBuffer changes [3].
>
> Recent (as of today) JPRT runs for core and hotspot tests pass without failure. Many parts of the code have been soaking in the Valhalla repo for over a year, and it?s been soaking in the sandbox for quite and many a JPRT run was performed.
>
> It is planned to push through hs-comp as is the case for the dependent patches, and thus minimise any delays due to integration between forests.
>
>
> The Langtools changes are small. Tweaks were made to support updates to signature polymorphic methods and where may be located, in addition to supporting compilation of calls to MethodHandle.link*.
>
>
> The Hotspot changes are not very large. It?s mostly a matter of augmenting checks for MethodHandle to include that for VarHandle. It?s tempting to generalise the ?invokehandle" invocation as i believe there are other use-cases where it might be useful, but i resisted temptation here. I wanted to focus on the minimal changes required.
>
>
> The JDK changes are more substantial, but a large proportion are new tests. The source compilation approach taken is to use templates, the same approach as for code in the nio package, to generate both implementation and test source code. The implementations are generated by the build, the tests are pre-generated. I believe the tests should have good coverage but we have yet to run any code coverage tool.
>
> The approach to invocation of VarHandle signature polymoprhic methods is slightly different to that of MethodHandles. I wanted to ensure that linking for the common cases avoids lambda form creation, compilation and therefore class spinning. That reduces start up costs and also potential circular dependencies that might be induced in the VM boot process if VarHandles are employed early on.
>
> For common basic (i.e. erased ref and widened primitive) method signatures, namely all those that matter for the efficient atomic operations there are pre-generated methods that would otherwise be generated from creating and compiling invoker lambda forms. Those methods reside on the VarHandleGuards class. When the VM makes an up call to MethodHandleNatives.linkMethod to link a call site then this up-called method will first check if an appropriate pre-generated method exists on VarHandleGuards and if so it links to that, otherwise it falls back to a method on a class generated from compiling a lambda form. For testing purposes there is a system property available to switch off this optimisation when linking [*].
>
> Each VarHandle instance of the same variable type produced from the same factory will share an underlying immutable instance of a VarForm that contains a set of MemberName instances, one for each implementation of a signature polymorphic method (a value of null means unsupported). The invoke methods (on VarHandleGuards or on lambda forms) will statically link to such MemberName instances using a call to MethodHandle.linkToStatic.
>
> There are a couple of TODOs in comments, those are all on non-critical code paths and i plan to chase them up afterwards.
>
> C1 does not support constant folding for @Stable arrays hence why in certain cases we have exploded stuff into fields that are operated on using if/else loops. We can simplify such code if/when C1 support is added.
>
>
> Thanks,
> Paul.
>
> [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-January/038150.html
> [2] http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2016-January/020953.html
> http://mail.openjdk.java.net/pipermail/hotspot-dev/2016-January/021514.html
> [3] http://mail.openjdk.java.net/pipermail/nio-dev/2016-February/003535.html
>
> [*] This technique might be useful for common signatures of MH invokers to reduce associated costs of lambda form creation and compilation in the interim of something better.
From tobias.hartmann at oracle.com Wed Mar 2 12:30:57 2016
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Wed, 2 Mar 2016 13:30:57 +0100
Subject: [9] RFR(XS): 8151024: Remove TCKJapaneseChronology.java from the
problem list
Message-ID: <56D6DD01.40208@oracle.com>
Hi,
please review the following patch that removes TCKJapaneseChronology.java from the problem list after JDK-8134979 was fixed (closed as duplicate of JDK-8134974).
https://bugs.openjdk.java.net/browse/JDK-8151024
http://cr.openjdk.java.net/~thartmann/8151024/webrev.00/
I intend to push this into hs-comp.
Best regards,
Tobias
From paul.sandoz at oracle.com Wed Mar 2 12:33:01 2016
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Wed, 2 Mar 2016 13:33:01 +0100
Subject: RFR (M): 8149159: Clean up Unsafe
In-Reply-To: <56D5CA22.7050308@oracle.com>
References: <56C61A07.4010604@oracle.com> <56C7757E.4070806@oracle.com>
<56D5CA22.7050308@oracle.com>
Message-ID: <5BC69CC7-9933-4504-AA23-8BDCF75CEEE9@oracle.com>
> On 1 Mar 2016, at 17:58, Mikael Vidstedt wrote:
>
>
> Thanks for all the great feedback/questions. Updated webrev(s) here:
>
> http://cr.openjdk.java.net/~mikael/webrevs/8149159_unsafecleanup/hotspot/webrev.01.incr/webrev/
> http://cr.openjdk.java.net/~mikael/webrevs/8149159_unsafecleanup/jdk/webrev.01.incr/webrev/
>
+1
> Also, here are the changes after rebasing on top of hs-comp to include Aleksey's recent changes to Unsafe. There were some conflicts in unsafe.cpp where the new methods/functions were added, so I had to resolve that and apply the cleanup to them as well.
>
> hotspot: http://cr.openjdk.java.net/~mikael/webrevs/8149159_unsafecleanup/hotspot/webrev.01/webrev/
> jdk: http://cr.openjdk.java.net/~mikael/webrevs/8149159_unsafecleanup/jdk/webrev.01/webrev/
>
>
> * Changes
>
> Apart from resolving the conflicts in unsafe.cpp, this change include the following changes compared to webrev.00:
>
> Claes - you are absolutely about right about the missing annotations, I have gone through and added the ForceInline annotation to all the s.m.Unsafe methods were it was missing. Thanks for catching that!
>
IMO this is a nice to have and good to be consistent to avoid any missing anything; not strictly necessary for methods that are not marked as intrinsic in the ?real? Unsafe (i assumed, perhaps incorrectly, that was the case for all such non-annotated methods).
> Chris - I chose to completely remove the UnsafeWrapper macro and its uses from unsafe.cpp. After all it's empty right now, and if somebody feels like adding it back it can simply be injected into the UNSAFE_ENTRY/UNSAFE_LEAF macros.
>
>
> * Testing
>
> I've run both -testset hotspot and -testset core on this, and FWIW it's all green.
>
>
> * Comments/other
>
> Stas - Wrt to the changes to the unsafe.cpp function names, I chose to rename the functions to include the suffix "0" to reflect the name change of the corresponding java (native) methods. While it's not strictly necessary it does feel just a tad clearer/more intuitive to me to have the names match.
>
> John/Paul - I filed https://bugs.openjdk.java.net/browse/JDK-8150921 to cover the migration from single (long) addressing modes for the Unsafe getters/setters to the double-register (Object + long) equivalents.
>
Great! For that we might require some careful analysis of generated code to ensure the double addressing accessor with a null base value generates the same code as the current single addressing accessor.
Paul.
From vladimir.x.ivanov at oracle.com Wed Mar 2 13:06:57 2016
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Wed, 2 Mar 2016 16:06:57 +0300
Subject: [9] RFR(XS): 8151024: Remove TCKJapaneseChronology.java from the
problem list
In-Reply-To: <56D6DD01.40208@oracle.com>
References: <56D6DD01.40208@oracle.com>
Message-ID: <56D6E571.50707@oracle.com>
Looks good.
Best regards,
Vladimir Ivanov
On 3/2/16 3:30 PM, Tobias Hartmann wrote:
> Hi,
>
> please review the following patch that removes TCKJapaneseChronology.java from the problem list after JDK-8134979 was fixed (closed as duplicate of JDK-8134974).
>
> https://bugs.openjdk.java.net/browse/JDK-8151024
> http://cr.openjdk.java.net/~thartmann/8151024/webrev.00/
>
> I intend to push this into hs-comp.
>
> Best regards,
> Tobias
>
From tobias.hartmann at oracle.com Wed Mar 2 13:13:32 2016
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Wed, 2 Mar 2016 14:13:32 +0100
Subject: [9] RFR(XS): 8151024: Remove TCKJapaneseChronology.java from the
problem list
In-Reply-To: <56D6E571.50707@oracle.com>
References: <56D6DD01.40208@oracle.com> <56D6E571.50707@oracle.com>
Message-ID: <56D6E6FC.6010100@oracle.com>
Thanks, Vladimir.
Best regards,
Tobias
On 02.03.2016 14:06, Vladimir Ivanov wrote:
> Looks good.
>
> Best regards,
> Vladimir Ivanov
>
> On 3/2/16 3:30 PM, Tobias Hartmann wrote:
>> Hi,
>>
>> please review the following patch that removes TCKJapaneseChronology.java from the problem list after JDK-8134979 was fixed (closed as duplicate of JDK-8134974).
>>
>> https://bugs.openjdk.java.net/browse/JDK-8151024
>> http://cr.openjdk.java.net/~thartmann/8151024/webrev.00/
>>
>> I intend to push this into hs-comp.
>>
>> Best regards,
>> Tobias
>>
From kirk.pepperdine at gmail.com Wed Mar 2 15:20:18 2016
From: kirk.pepperdine at gmail.com (kirk.pepperdine at gmail.com)
Date: Wed, 2 Mar 2016 09:20:18 -0600
Subject: PollArrayWrapper.c
Message-ID: <680AB042-BF0E-43AF-93ED-7167FCD03AF4@gmail.com>
Hi,
I was looking at PollArrayWrapper.c and I saw this.
#define RESTARTABLE(_cmd, _result) do { \
do { \
_result = _cmd; \
} while((_result == -1) && (errno == EINTR)); \
} while(0)
Is there a reason why this logic is wrapped in a do { ?. } while(0)
Regards,
Kirk
From aph at redhat.com Wed Mar 2 15:51:41 2016
From: aph at redhat.com (Andrew Haley)
Date: Wed, 2 Mar 2016 15:51:41 +0000
Subject: PollArrayWrapper.c
In-Reply-To: <680AB042-BF0E-43AF-93ED-7167FCD03AF4@gmail.com>
References: <680AB042-BF0E-43AF-93ED-7167FCD03AF4@gmail.com>
Message-ID: <56D70C0D.3060608@redhat.com>
On 03/02/2016 03:20 PM, kirk.pepperdine at gmail.com wrote:
> Is there a reason why this logic is wrapped in a do { ?. } while(0)
Every multi-statement #define must always be wrapped in do { ?. } while(0)
consider
if (blah)
MACRO;
else
stuff;
The { } mean the right thing happens with multiple statments;
the while 0 eats the trailing semicolon in
MACRO;
Andrew.
From kirk.pepperdine at gmail.com Wed Mar 2 15:56:30 2016
From: kirk.pepperdine at gmail.com (kirk.pepperdine at gmail.com)
Date: Wed, 2 Mar 2016 09:56:30 -0600
Subject: PollArrayWrapper.c
In-Reply-To: <56D70C0D.3060608@redhat.com>
References: <680AB042-BF0E-43AF-93ED-7167FCD03AF4@gmail.com>
<56D70C0D.3060608@redhat.com>
Message-ID:
Hi Andrew,
Thanks for the boring (as in good) answer. In this case it?s superfluous as it?s wrapping a single statement but..
Regards,
Kirk
> On Mar 2, 2016, at 9:51 AM, Andrew Haley wrote:
>
> On 03/02/2016 03:20 PM, kirk.pepperdine at gmail.com wrote:
>> Is there a reason why this logic is wrapped in a do { ?. } while(0)
>
> Every multi-statement #define must always be wrapped in do { ?. } while(0)
>
> consider
>
> if (blah)
> MACRO;
> else
> stuff;
>
> The { } mean the right thing happens with multiple statments;
> the while 0 eats the trailing semicolon in
>
> MACRO;
>
> Andrew.
>
From aph at redhat.com Wed Mar 2 15:58:46 2016
From: aph at redhat.com (Andrew Haley)
Date: Wed, 2 Mar 2016 15:58:46 +0000
Subject: PollArrayWrapper.c
In-Reply-To:
References: <680AB042-BF0E-43AF-93ED-7167FCD03AF4@gmail.com>
<56D70C0D.3060608@redhat.com>
Message-ID: <56D70DB6.4020305@redhat.com>
On 03/02/2016 03:56 PM, kirk.pepperdine at gmail.com wrote:
> Thanks for the boring (as in good) answer. In this case it?s superfluous as it?s wrapping a single statement but..
... always do it, because that might change, and it costs nothing.
Andrew.
From dmitry.dmitriev at oracle.com Wed Mar 2 16:03:52 2016
From: dmitry.dmitriev at oracle.com (Dmitry Dmitriev)
Date: Wed, 2 Mar 2016 19:03:52 +0300
Subject: RFR(XS): 8149973: Optimize object alignment check in debug builds.
In-Reply-To: <56CDA375.4090501@oracle.com>
References: <56CD892B.20409@oracle.com> <56CDA375.4090501@oracle.com>
Message-ID: <56D70EE8.4020403@oracle.com>
Hello Coleen,
I implement refactoring which removes repeating of '&' expression.
In g1OopClosures.inline.hpp and g1RemSet.inline.hpp I removed extracting
of oopDesc* from oop and added call to check_obj_alignment instead.
Updated webrev.01:
http://cr.openjdk.java.net/~ddmitriev/8149973/webrev.01/
Testing: jprt, hotspot_all & vm.quick(still in progress, no new failures).
Thanks,
Dmitry
On 24.02.2016 15:35, Coleen Phillimore wrote:
>
> From
> http://cr.openjdk.java.net/~ddmitriev/8149973/webrev.00/src/share/vm/gc/g1/g1OopClosures.inline.hpp.udiff.html
>
> http://cr.openjdk.java.net/~ddmitriev/8149973/webrev.00/src/share/vm/gc/g1/g1RemSet.inline.hpp.udiff.html
>
>
> Can you just call
>
> assert(check_obj_alignment(o), "not oop aligned");
>
> rather than repeating the & expression? The check_obj_alignment is
> inlined.
>
> Coleen
>
> On 2/24/16 5:42 AM, Dmitry Dmitriev wrote:
>> Hello,
>>
>> Please, review small optimization to the object alignment check in
>> the debug builds. In this fix I replace division by
>> MinObjAlignmentInBytes to bitwise AND operation with
>> MinObjAlignmentInBytesMask, because MinObjAlignmentInBytes is a power
>> of two. Suggested construction already used in MacroAssembler, e.g.
>> hotspot/src/cpu/x86/vm/c1_MacroAssembler_x86.cpp).
>>
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8149973
>> webrev.00: http://cr.openjdk.java.net/~ddmitriev/8149973/webrev.00/
>>
>> Testing: jprt, hotspot_all
>>
>> Thanks,
>> Dmitry
>
From coleen.phillimore at oracle.com Wed Mar 2 16:32:11 2016
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Wed, 2 Mar 2016 11:32:11 -0500
Subject: RFR(XS): 8149973: Optimize object alignment check in debug builds.
In-Reply-To: <56D70EE8.4020403@oracle.com>
References: <56CD892B.20409@oracle.com> <56CDA375.4090501@oracle.com>
<56D70EE8.4020403@oracle.com>
Message-ID: <56D7158B.9090002@oracle.com>
Dmitry,
That change looks nice!
Coleen
On 3/2/16 11:03 AM, Dmitry Dmitriev wrote:
> Hello Coleen,
>
> I implement refactoring which removes repeating of '&' expression.
> In g1OopClosures.inline.hpp and g1RemSet.inline.hpp I removed
> extracting of oopDesc* from oop and added call to check_obj_alignment
> instead.
> Updated webrev.01:
> http://cr.openjdk.java.net/~ddmitriev/8149973/webrev.01/
>
> Testing: jprt, hotspot_all & vm.quick(still in progress, no new
> failures).
>
> Thanks,
> Dmitry
>
>
> On 24.02.2016 15:35, Coleen Phillimore wrote:
>>
>> From
>> http://cr.openjdk.java.net/~ddmitriev/8149973/webrev.00/src/share/vm/gc/g1/g1OopClosures.inline.hpp.udiff.html
>>
>> http://cr.openjdk.java.net/~ddmitriev/8149973/webrev.00/src/share/vm/gc/g1/g1RemSet.inline.hpp.udiff.html
>>
>>
>> Can you just call
>>
>> assert(check_obj_alignment(o), "not oop aligned");
>>
>> rather than repeating the & expression? The check_obj_alignment is
>> inlined.
>>
>> Coleen
>>
>> On 2/24/16 5:42 AM, Dmitry Dmitriev wrote:
>>> Hello,
>>>
>>> Please, review small optimization to the object alignment check in
>>> the debug builds. In this fix I replace division by
>>> MinObjAlignmentInBytes to bitwise AND operation with
>>> MinObjAlignmentInBytesMask, because MinObjAlignmentInBytes is a
>>> power of two. Suggested construction already used in MacroAssembler,
>>> e.g. hotspot/src/cpu/x86/vm/c1_MacroAssembler_x86.cpp).
>>>
>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8149973
>>> webrev.00: http://cr.openjdk.java.net/~ddmitriev/8149973/webrev.00/
>>>
>>> Testing: jprt, hotspot_all
>>>
>>> Thanks,
>>> Dmitry
>>
>
From dmitry.dmitriev at oracle.com Wed Mar 2 16:58:19 2016
From: dmitry.dmitriev at oracle.com (Dmitry Dmitriev)
Date: Wed, 2 Mar 2016 19:58:19 +0300
Subject: RFR(XS): 8149973: Optimize object alignment check in debug builds.
In-Reply-To: <56D7158B.9090002@oracle.com>
References: <56CD892B.20409@oracle.com> <56CDA375.4090501@oracle.com>
<56D70EE8.4020403@oracle.com> <56D7158B.9090002@oracle.com>
Message-ID: <56D71BAB.9040806@oracle.com>
Coleen, thank you!
Dmitry
On 02.03.2016 19:32, Coleen Phillimore wrote:
> Dmitry,
> That change looks nice!
> Coleen
>
> On 3/2/16 11:03 AM, Dmitry Dmitriev wrote:
>> Hello Coleen,
>>
>> I implement refactoring which removes repeating of '&' expression.
>> In g1OopClosures.inline.hpp and g1RemSet.inline.hpp I removed
>> extracting of oopDesc* from oop and added call to check_obj_alignment
>> instead.
>> Updated webrev.01:
>> http://cr.openjdk.java.net/~ddmitriev/8149973/webrev.01/
>>
>> Testing: jprt, hotspot_all & vm.quick(still in progress, no new
>> failures).
>>
>> Thanks,
>> Dmitry
>>
>>
>> On 24.02.2016 15:35, Coleen Phillimore wrote:
>>>
>>> From
>>> http://cr.openjdk.java.net/~ddmitriev/8149973/webrev.00/src/share/vm/gc/g1/g1OopClosures.inline.hpp.udiff.html
>>>
>>> http://cr.openjdk.java.net/~ddmitriev/8149973/webrev.00/src/share/vm/gc/g1/g1RemSet.inline.hpp.udiff.html
>>>
>>>
>>> Can you just call
>>>
>>> assert(check_obj_alignment(o), "not oop aligned");
>>>
>>> rather than repeating the & expression? The check_obj_alignment is
>>> inlined.
>>>
>>> Coleen
>>>
>>> On 2/24/16 5:42 AM, Dmitry Dmitriev wrote:
>>>> Hello,
>>>>
>>>> Please, review small optimization to the object alignment check in
>>>> the debug builds. In this fix I replace division by
>>>> MinObjAlignmentInBytes to bitwise AND operation with
>>>> MinObjAlignmentInBytesMask, because MinObjAlignmentInBytes is a
>>>> power of two. Suggested construction already used in
>>>> MacroAssembler, e.g.
>>>> hotspot/src/cpu/x86/vm/c1_MacroAssembler_x86.cpp).
>>>>
>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8149973
>>>> webrev.00: http://cr.openjdk.java.net/~ddmitriev/8149973/webrev.00/
>>>>
>>>> Testing: jprt, hotspot_all
>>>>
>>>> Thanks,
>>>> Dmitry
>>>
>>
>
From thomas.schatzl at oracle.com Wed Mar 2 17:03:57 2016
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Wed, 02 Mar 2016 18:03:57 +0100
Subject: RFR(XS): 8149973: Optimize object alignment check in debug builds.
In-Reply-To: <56D70EE8.4020403@oracle.com>
References: <56CD892B.20409@oracle.com> <56CDA375.4090501@oracle.com>
<56D70EE8.4020403@oracle.com>
Message-ID: <1456938237.10257.0.camel@oracle.com>
Hi,
On Wed, 2016-03-02 at 19:03 +0300, Dmitry Dmitriev wrote:
> Hello Coleen,
>
> I implement refactoring which removes repeating of '&' expression.
> In g1OopClosures.inline.hpp and g1RemSet.inline.hpp I removed
> extracting
> of oopDesc* from oop and added call to check_obj_alignment instead.
> Updated webrev.01:
> http://cr.openjdk.java.net/~ddmitriev/8149973/webrev.01/
>
> Testing: jprt, hotspot_all & vm.quick(still in progress, no new
> failures).
looks good.
Thomas
From dmitry.dmitriev at oracle.com Wed Mar 2 17:18:41 2016
From: dmitry.dmitriev at oracle.com (Dmitry Dmitriev)
Date: Wed, 2 Mar 2016 20:18:41 +0300
Subject: RFR(XS): 8149973: Optimize object alignment check in debug builds.
In-Reply-To: <1456938237.10257.0.camel@oracle.com>
References: <56CD892B.20409@oracle.com> <56CDA375.4090501@oracle.com>
<56D70EE8.4020403@oracle.com> <1456938237.10257.0.camel@oracle.com>
Message-ID: <56D72071.6050304@oracle.com>
Thomas, thank you for the review!
Dmitry
On 02.03.2016 20:03, Thomas Schatzl wrote:
> Hi,
>
> On Wed, 2016-03-02 at 19:03 +0300, Dmitry Dmitriev wrote:
>> Hello Coleen,
>>
>> I implement refactoring which removes repeating of '&' expression.
>> In g1OopClosures.inline.hpp and g1RemSet.inline.hpp I removed
>> extracting
>> of oopDesc* from oop and added call to check_obj_alignment instead.
>> Updated webrev.01:
>> http://cr.openjdk.java.net/~ddmitriev/8149973/webrev.01/
>>
>> Testing: jprt, hotspot_all & vm.quick(still in progress, no new
>> failures).
> looks good.
>
> Thomas
From Guy.Delamarter at oracle.com Wed Mar 2 23:33:42 2016
From: Guy.Delamarter at oracle.com (Guy Delamarter)
Date: Wed, 2 Mar 2016 15:33:42 -0800
Subject: [9] RFR(S): 8144693: Intrinsify StringCoding.hasNegatives() on SPARC
Message-ID: <56D77856.1020707@oracle.com>
Hi,
Please review the following patch adding a SPARC intrinsic for
StringCoding.hasNegatives to hotspot and supporting changes.
Tobias Hartmann (tobias.hartmann at oracle.com) has offered to
sponsor these changes.
Summary:
hasNegatives is a utility method for encoding/decoding under the new
Compact Strings framework, returning whether the given byte array
(segment) contains any negative entries. hasNegatives is an intrinsic
candidate, emitted by hotspot as a node in the latest Java 9 builds,
but the SPARC node match and (inline assembly) implementation have
been missing up to now. This implementation checks aligned 8-byte
windows onto the array segment for negative bytes, carefully ignoring
bytes in the window that happen to be outside the segment.
It was discovered that the private access of the hasNegatives method
prevented direct testing of the intrinsic from outside StringCoding,
so that was changed to public. Subsequent to this change a compiler
test class (TestHasNegatives) was added providing useful validation
coverage.
Webrevs:
http://cr.openjdk.java.net/~thartmann/8144693/hotspot/webrev.00/
http://cr.openjdk.java.net/~thartmann/8144693/jdk/webrev.00/
Issue:
https://bugs.openjdk.java.net/browse/JDK-8144693
Thanks,
Guy Delamarter
From david.holmes at oracle.com Thu Mar 3 02:43:07 2016
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 3 Mar 2016 12:43:07 +1000
Subject: RFR(XS): 8149973: Optimize object alignment check in debug builds.
In-Reply-To: <56D70EE8.4020403@oracle.com>
References: <56CD892B.20409@oracle.com> <56CDA375.4090501@oracle.com>
<56D70EE8.4020403@oracle.com>
Message-ID: <56D7A4BB.5050402@oracle.com>
On 3/03/2016 2:03 AM, Dmitry Dmitriev wrote:
> Hello Coleen,
>
> I implement refactoring which removes repeating of '&' expression.
> In g1OopClosures.inline.hpp and g1RemSet.inline.hpp I removed extracting
> of oopDesc* from oop and added call to check_obj_alignment instead.
> Updated webrev.01:
> http://cr.openjdk.java.net/~ddmitriev/8149973/webrev.01/
>
> Testing: jprt, hotspot_all & vm.quick(still in progress, no new failures).
I'm unclear on how the CHECK_UNHANDLED_OOPS case is handled in the
cast_from_oop. In the original we had to "unwrap" obj as obj.obj(), but
that no longer appears anywhere. ??
Thanks,
David
> Thanks,
> Dmitry
>
>
> On 24.02.2016 15:35, Coleen Phillimore wrote:
>>
>> From
>> http://cr.openjdk.java.net/~ddmitriev/8149973/webrev.00/src/share/vm/gc/g1/g1OopClosures.inline.hpp.udiff.html
>>
>> http://cr.openjdk.java.net/~ddmitriev/8149973/webrev.00/src/share/vm/gc/g1/g1RemSet.inline.hpp.udiff.html
>>
>>
>> Can you just call
>>
>> assert(check_obj_alignment(o), "not oop aligned");
>>
>> rather than repeating the & expression? The check_obj_alignment is
>> inlined.
>>
>> Coleen
>>
>> On 2/24/16 5:42 AM, Dmitry Dmitriev wrote:
>>> Hello,
>>>
>>> Please, review small optimization to the object alignment check in
>>> the debug builds. In this fix I replace division by
>>> MinObjAlignmentInBytes to bitwise AND operation with
>>> MinObjAlignmentInBytesMask, because MinObjAlignmentInBytes is a power
>>> of two. Suggested construction already used in MacroAssembler, e.g.
>>> hotspot/src/cpu/x86/vm/c1_MacroAssembler_x86.cpp).
>>>
>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8149973
>>> webrev.00: http://cr.openjdk.java.net/~ddmitriev/8149973/webrev.00/
>>>
>>> Testing: jprt, hotspot_all
>>>
>>> Thanks,
>>> Dmitry
>>
>
From coleen.phillimore at oracle.com Thu Mar 3 02:58:00 2016
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Wed, 2 Mar 2016 21:58:00 -0500
Subject: RFR(XS): 8149973: Optimize object alignment check in debug builds.
In-Reply-To: <56D7A4BB.5050402@oracle.com>
References: <56CD892B.20409@oracle.com> <56CDA375.4090501@oracle.com>
<56D70EE8.4020403@oracle.com> <56D7A4BB.5050402@oracle.com>
Message-ID: <56D7A838.4080609@oracle.com>
On 3/2/16 9:43 PM, David Holmes wrote:
> On 3/03/2016 2:03 AM, Dmitry Dmitriev wrote:
>> Hello Coleen,
>>
>> I implement refactoring which removes repeating of '&' expression.
>> In g1OopClosures.inline.hpp and g1RemSet.inline.hpp I removed extracting
>> of oopDesc* from oop and added call to check_obj_alignment instead.
>> Updated webrev.01:
>> http://cr.openjdk.java.net/~ddmitriev/8149973/webrev.01/
>>
>> Testing: jprt, hotspot_all & vm.quick(still in progress, no new
>> failures).
>
> I'm unclear on how the CHECK_UNHANDLED_OOPS case is handled in the
> cast_from_oop. In the original we had to "unwrap" obj as obj.obj(),
> but that no longer appears anywhere. ??
It's done implicitly.
Coleen
>
> Thanks,
> David
>
>> Thanks,
>> Dmitry
>>
>>
>> On 24.02.2016 15:35, Coleen Phillimore wrote:
>>>
>>> From
>>> http://cr.openjdk.java.net/~ddmitriev/8149973/webrev.00/src/share/vm/gc/g1/g1OopClosures.inline.hpp.udiff.html
>>>
>>>
>>> http://cr.openjdk.java.net/~ddmitriev/8149973/webrev.00/src/share/vm/gc/g1/g1RemSet.inline.hpp.udiff.html
>>>
>>>
>>>
>>> Can you just call
>>>
>>> assert(check_obj_alignment(o), "not oop aligned");
>>>
>>> rather than repeating the & expression? The check_obj_alignment is
>>> inlined.
>>>
>>> Coleen
>>>
>>> On 2/24/16 5:42 AM, Dmitry Dmitriev wrote:
>>>> Hello,
>>>>
>>>> Please, review small optimization to the object alignment check in
>>>> the debug builds. In this fix I replace division by
>>>> MinObjAlignmentInBytes to bitwise AND operation with
>>>> MinObjAlignmentInBytesMask, because MinObjAlignmentInBytes is a power
>>>> of two. Suggested construction already used in MacroAssembler, e.g.
>>>> hotspot/src/cpu/x86/vm/c1_MacroAssembler_x86.cpp).
>>>>
>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8149973
>>>> webrev.00: http://cr.openjdk.java.net/~ddmitriev/8149973/webrev.00/
>>>>
>>>> Testing: jprt, hotspot_all
>>>>
>>>> Thanks,
>>>> Dmitry
>>>
>>
From vladimir.kozlov at oracle.com Thu Mar 3 04:37:58 2016
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Wed, 2 Mar 2016 20:37:58 -0800
Subject: [9] RFR(S): 8144693: Intrinsify StringCoding.hasNegatives() on
SPARC
In-Reply-To: <56D77856.1020707@oracle.com>
References: <56D77856.1020707@oracle.com>
Message-ID: <56D7BFA6.1000401@oracle.com>
Why you are avoiding the same register for src and dst in instructions?
For example:
+ add(t3, 0x80, t2);
I think you can use less registers if you reuse registers. The less
registers you use - less registers will be spilled on stack in the code
which use your code.
'size' register is defined as 32-bit values in .ad file. It may have
garbage in apper bits - I would suggest to sign extend it before using:
signx(size);
If size is small (t5 != 0 for unaligned header) may be we should just
jump to tail code to do right shift (to mov(0, result); instruction).
But I am not insisting on this.
Thanks,
Vladimir
On 3/2/16 3:33 PM, Guy Delamarter wrote:
> Hi,
>
> Please review the following patch adding a SPARC intrinsic for
> StringCoding.hasNegatives to hotspot and supporting changes.
>
> Tobias Hartmann (tobias.hartmann at oracle.com) has offered to
> sponsor these changes.
>
>
> Summary:
>
> hasNegatives is a utility method for encoding/decoding under the new
> Compact Strings framework, returning whether the given byte array
> (segment) contains any negative entries. hasNegatives is an intrinsic
> candidate, emitted by hotspot as a node in the latest Java 9 builds,
> but the SPARC node match and (inline assembly) implementation have
> been missing up to now. This implementation checks aligned 8-byte
> windows onto the array segment for negative bytes, carefully ignoring
> bytes in the window that happen to be outside the segment.
>
> It was discovered that the private access of the hasNegatives method
> prevented direct testing of the intrinsic from outside StringCoding,
> so that was changed to public. Subsequent to this change a compiler
> test class (TestHasNegatives) was added providing useful validation
> coverage.
>
>
> Webrevs:
> http://cr.openjdk.java.net/~thartmann/8144693/hotspot/webrev.00/
> http://cr.openjdk.java.net/~thartmann/8144693/jdk/webrev.00/
>
> Issue:
> https://bugs.openjdk.java.net/browse/JDK-8144693
>
>
> Thanks,
> Guy Delamarter
>
From dmitry.dmitriev at oracle.com Thu Mar 3 08:52:12 2016
From: dmitry.dmitriev at oracle.com (Dmitry Dmitriev)
Date: Thu, 3 Mar 2016 11:52:12 +0300
Subject: RFR(XS): 8149973: Optimize object alignment check in debug builds.
In-Reply-To: <56D7A4BB.5050402@oracle.com>
References: <56CD892B.20409@oracle.com> <56CDA375.4090501@oracle.com>
<56D70EE8.4020403@oracle.com> <56D7A4BB.5050402@oracle.com>
Message-ID: <56D7FB3C.8070701@oracle.com>
Hello David,
Good question, as Coleen wrote this is done implicitly. Let me add few
more details.
cast_from_oop is defined in share/vm/oops/oopsHierarchy.hpp:
template inline T cast_from_oop(oop o) {
return (T)(CHECK_UNHANDLED_OOPS_ONLY((void*))o);
}
CHECK_UNHANDLED_OOPS_ONLY is defined in share/vm/utilities/macros.hpp:
#ifdef CHECK_UNHANDLED_OOPS
#define CHECK_UNHANDLED_OOPS_ONLY(code) code
#define NOT_CHECK_UNHANDLED_OOPS(code)
#else
#define CHECK_UNHANDLED_OOPS_ONLY(code)
#define NOT_CHECK_UNHANDLED_OOPS(code) code
#endif // CHECK_UNHANDLED_OOPS
I.e. in case when CHECK_UNHANDLED_OOPS is defined cast_from_oop will
looks like this:
template inline T cast_from_oop(oop o) {
return (T)((void*)o);
}
oop have an explicit user conversions for 'void *':
operator void* () const { return (void *)obj(); }
I.e. cast_from_oop(obj) will evaluates to the: (intptr_t)
(obj.obj())
Thanks,
Dmitry
On 03.03.2016 5:43, David Holmes wrote:
> On 3/03/2016 2:03 AM, Dmitry Dmitriev wrote:
>> Hello Coleen,
>>
>> I implement refactoring which removes repeating of '&' expression.
>> In g1OopClosures.inline.hpp and g1RemSet.inline.hpp I removed extracting
>> of oopDesc* from oop and added call to check_obj_alignment instead.
>> Updated webrev.01:
>> http://cr.openjdk.java.net/~ddmitriev/8149973/webrev.01/
>>
>> Testing: jprt, hotspot_all & vm.quick(still in progress, no new
>> failures).
>
> I'm unclear on how the CHECK_UNHANDLED_OOPS case is handled in the
> cast_from_oop. In the original we had to "unwrap" obj as obj.obj(),
> but that no longer appears anywhere. ??
>
> Thanks,
> David
>
>> Thanks,
>> Dmitry
>>
>>
>> On 24.02.2016 15:35, Coleen Phillimore wrote:
>>>
>>> From
>>> http://cr.openjdk.java.net/~ddmitriev/8149973/webrev.00/src/share/vm/gc/g1/g1OopClosures.inline.hpp.udiff.html
>>>
>>>
>>> http://cr.openjdk.java.net/~ddmitriev/8149973/webrev.00/src/share/vm/gc/g1/g1RemSet.inline.hpp.udiff.html
>>>
>>>
>>>
>>> Can you just call
>>>
>>> assert(check_obj_alignment(o), "not oop aligned");
>>>
>>> rather than repeating the & expression? The check_obj_alignment is
>>> inlined.
>>>
>>> Coleen
>>>
>>> On 2/24/16 5:42 AM, Dmitry Dmitriev wrote:
>>>> Hello,
>>>>
>>>> Please, review small optimization to the object alignment check in
>>>> the debug builds. In this fix I replace division by
>>>> MinObjAlignmentInBytes to bitwise AND operation with
>>>> MinObjAlignmentInBytesMask, because MinObjAlignmentInBytes is a power
>>>> of two. Suggested construction already used in MacroAssembler, e.g.
>>>> hotspot/src/cpu/x86/vm/c1_MacroAssembler_x86.cpp).
>>>>
>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8149973
>>>> webrev.00: http://cr.openjdk.java.net/~ddmitriev/8149973/webrev.00/
>>>>
>>>> Testing: jprt, hotspot_all
>>>>
>>>> Thanks,
>>>> Dmitry
>>>
>>
From vladimir.x.ivanov at oracle.com Thu Mar 3 10:40:51 2016
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Thu, 3 Mar 2016 13:40:51 +0300
Subject: [9] RFR (XS): 8139247: Improper locking of
MethodData::_extra_data_lock
Message-ID: <56D814B3.3000605@oracle.com>
http://cr.openjdk.java.net/~vlivanov/8139247/webrev.00
https://bugs.openjdk.java.net/browse/JDK-8139247
Solaris Studio C++ compiler generates tightly coupled
Monitor::lock/unlock calls for unnamed MutexLocker which breaks
synchronization between ciMethodData::load_extra_data() and
MethodData::bci_to_extra_data().
MutexLocker(mdo->extra_data_lock());
is compiled into:
load_extra_data+0x001d: movq %r13,%rdi
load_extra_data+0x0020: call lock [ 0xfffffd7fe6df46c0, .+0x7cc5c0 ]
load_extra_data+0x0025: movq %r13,%rdi
load_extra_data+0x0028: call unlock [ 0xfffffd7fe6df47f0, .+0x7cc6e8
But after adding a name, we hit a compiler bug in SS12u4 and
Monitor::unlock call is missed. So, have to add a workaround (same as in
JDK-8146616 [1]).
Testing: verified machine code for ciMethodData::load_extra_data().
Best regards,
Vladimir Ivanov
[1] https://bugs.openjdk.java.net/browse/JDK-8146616
From roland.westrelin at oracle.com Thu Mar 3 11:42:25 2016
From: roland.westrelin at oracle.com (Roland Westrelin)
Date: Thu, 3 Mar 2016 12:42:25 +0100
Subject: [9] RFR (XS): 8139247: Improper locking of
MethodData::_extra_data_lock
In-Reply-To: <56D814B3.3000605@oracle.com>
References: <56D814B3.3000605@oracle.com>
Message-ID: <9D853112-129A-435C-B6F8-196CEF50883C@oracle.com>
> http://cr.openjdk.java.net/~vlivanov/8139247/webrev.00
That looks good to me.
Roland.
From christian.tornqvist at oracle.com Thu Mar 3 12:37:56 2016
From: christian.tornqvist at oracle.com (Christian Tornqvist)
Date: Thu, 3 Mar 2016 07:37:56 -0500
Subject: RFR(M): 8151156 - [TESTBUG] Integrate trivial Hotspot test changes
from Jake before Jigsaw M3
Message-ID: <1c4cd01d17549$837e4d10$8a7ae730$@oracle.com>
Hi everyone,
Please review this change that integrates some of the trivial Hotspot test
changes made in Jake, these are all going into jdk9-dev in order to make it
into master before M3 hits. There are three different kind of changes
included in this webrev:
- Adding/correcting Module exports (using @module), this is a no-op
in JDK 9 until Jigsaw M3 gets in.
- @run driver -> @run main, jtreg has a bug where module exports
doesn't work correctly with driver
(https://bugs.openjdk.java.net/browse/CODETOOLS-7901589)
- Two tests (test/serviceability/dcmd/gc/HeapDumpTest.java and
test/serviceability/dcmd/gc/HeapDumpAllTest.java) had @build with a
misspelled package name, a new version of jtreg will treat this as an error
Changes have been tested by running all of the Hotspot Jtreg tests.
Webrev:
http://cr.openjdk.java.net/~ctornqvi/webrev/8151156/webrev.00/
Bug:
https://bugs.openjdk.java.net/browse/JDK-8151156
Thanks,
Christian
From george.triantafillou at oracle.com Thu Mar 3 13:00:41 2016
From: george.triantafillou at oracle.com (George Triantafillou)
Date: Thu, 3 Mar 2016 08:00:41 -0500
Subject: RFR(M): 8151156 - [TESTBUG] Integrate trivial Hotspot test
changes from Jake before Jigsaw M3
In-Reply-To: <1c4cd01d17549$837e4d10$8a7ae730$@oracle.com>
References: <1c4cd01d17549$837e4d10$8a7ae730$@oracle.com>
Message-ID: <56D83579.30403@oracle.com>
Hi Christian,
Changes look good.
-George
On 3/3/2016 7:37 AM, Christian Tornqvist wrote:
> Hi everyone,
>
>
>
> Please review this change that integrates some of the trivial Hotspot test
> changes made in Jake, these are all going into jdk9-dev in order to make it
> into master before M3 hits. There are three different kind of changes
> included in this webrev:
>
>
>
> - Adding/correcting Module exports (using @module), this is a no-op
> in JDK 9 until Jigsaw M3 gets in.
>
> - @run driver -> @run main, jtreg has a bug where module exports
> doesn't work correctly with driver
> (https://bugs.openjdk.java.net/browse/CODETOOLS-7901589)
>
> - Two tests (test/serviceability/dcmd/gc/HeapDumpTest.java and
> test/serviceability/dcmd/gc/HeapDumpAllTest.java) had @build with a
> misspelled package name, a new version of jtreg will treat this as an error
>
>
>
> Changes have been tested by running all of the Hotspot Jtreg tests.
>
>
>
> Webrev:
>
> http://cr.openjdk.java.net/~ctornqvi/webrev/8151156/webrev.00/
>
>
>
> Bug:
>
> https://bugs.openjdk.java.net/browse/JDK-8151156
>
>
>
> Thanks,
>
> Christian
>
>
>
From harold.seigel at oracle.com Thu Mar 3 13:51:34 2016
From: harold.seigel at oracle.com (harold seigel)
Date: Thu, 3 Mar 2016 08:51:34 -0500
Subject: RFR(M): 8151156 - [TESTBUG] Integrate trivial Hotspot test
changes from Jake before Jigsaw M3
In-Reply-To: <1c4cd01d17549$837e4d10$8a7ae730$@oracle.com>
References: <1c4cd01d17549$837e4d10$8a7ae730$@oracle.com>
Message-ID: <56D84166.9060100@oracle.com>
Hi Christian,
The changes look good. Are there any copyrights that need to be updated?
Thanks, Harold
On 3/3/2016 7:37 AM, Christian Tornqvist wrote:
> Hi everyone,
>
>
>
> Please review this change that integrates some of the trivial Hotspot test
> changes made in Jake, these are all going into jdk9-dev in order to make it
> into master before M3 hits. There are three different kind of changes
> included in this webrev:
>
>
>
> - Adding/correcting Module exports (using @module), this is a no-op
> in JDK 9 until Jigsaw M3 gets in.
>
> - @run driver -> @run main, jtreg has a bug where module exports
> doesn't work correctly with driver
> (https://bugs.openjdk.java.net/browse/CODETOOLS-7901589)
>
> - Two tests (test/serviceability/dcmd/gc/HeapDumpTest.java and
> test/serviceability/dcmd/gc/HeapDumpAllTest.java) had @build with a
> misspelled package name, a new version of jtreg will treat this as an error
>
>
>
> Changes have been tested by running all of the Hotspot Jtreg tests.
>
>
>
> Webrev:
>
> http://cr.openjdk.java.net/~ctornqvi/webrev/8151156/webrev.00/
>
>
>
> Bug:
>
> https://bugs.openjdk.java.net/browse/JDK-8151156
>
>
>
> Thanks,
>
> Christian
>
>
>
From daniel.daugherty at oracle.com Thu Mar 3 16:49:29 2016
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Thu, 3 Mar 2016 09:49:29 -0700
Subject: [9] RFR (XS): 8139247: Improper locking of
MethodData::_extra_data_lock
In-Reply-To: <56D814B3.3000605@oracle.com>
References: <56D814B3.3000605@oracle.com>
Message-ID: <56D86B19.7010206@oracle.com>
On 3/3/16 3:40 AM, Vladimir Ivanov wrote:
> http://cr.openjdk.java.net/~vlivanov/8139247/webrev.00
src/share/vm/ci/ciMethodData.cpp
Nicely done!
We've been bitten by the "MutexLocker /*missing name*/ (lock);" before.
It's interesting that fixing that runs into JDK-8146616. We should
probably make an audit run on finding missing name instances (again).
Thumbs up!
Dan
> https://bugs.openjdk.java.net/browse/JDK-8139247
>
> Solaris Studio C++ compiler generates tightly coupled
> Monitor::lock/unlock calls for unnamed MutexLocker which breaks
> synchronization between ciMethodData::load_extra_data() and
> MethodData::bci_to_extra_data().
>
> MutexLocker(mdo->extra_data_lock());
>
> is compiled into:
>
> load_extra_data+0x001d: movq %r13,%rdi
> load_extra_data+0x0020: call lock [ 0xfffffd7fe6df46c0, .+0x7cc5c0 ]
> load_extra_data+0x0025: movq %r13,%rdi
> load_extra_data+0x0028: call unlock [ 0xfffffd7fe6df47f0, .+0x7cc6e8
>
> But after adding a name, we hit a compiler bug in SS12u4 and
> Monitor::unlock call is missed. So, have to add a workaround (same as
> in JDK-8146616 [1]).
>
> Testing: verified machine code for ciMethodData::load_extra_data().
>
> Best regards,
> Vladimir Ivanov
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8146616
From christian.tornqvist at oracle.com Thu Mar 3 20:35:32 2016
From: christian.tornqvist at oracle.com (Christian Tornqvist)
Date: Thu, 3 Mar 2016 15:35:32 -0500
Subject: RFR(M): 8151156 - [TESTBUG] Integrate trivial Hotspot
test changes from Jake before Jigsaw M3
In-Reply-To: <56D84166.9060100@oracle.com>
References: <1c4cd01d17549$837e4d10$8a7ae730$@oracle.com>
<56D84166.9060100@oracle.com>
Message-ID: <1c77701d1758c$3bfb2100$b3f16300$@oracle.com>
Hi Harold,
I've updated the copyrights, thanks for the review!
Thanks,
Christian
-----Original Message-----
From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of
harold seigel
Sent: Thursday, March 3, 2016 8:52 AM
To: hotspot-dev at openjdk.java.net
Subject: Re: RFR(M): 8151156 - [TESTBUG] Integrate trivial Hotspot test
changes from Jake before Jigsaw M3
Hi Christian,
The changes look good. Are there any copyrights that need to be updated?
Thanks, Harold
On 3/3/2016 7:37 AM, Christian Tornqvist wrote:
> Hi everyone,
>
>
>
> Please review this change that integrates some of the trivial Hotspot
test
> changes made in Jake, these are all going into jdk9-dev in order to
> make
it
> into master before M3 hits. There are three different kind of changes
> included in this webrev:
>
>
>
> - Adding/correcting Module exports (using @module), this is a
no-op
> in JDK 9 until Jigsaw M3 gets in.
>
> - @run driver -> @run main, jtreg has a bug where module
exports
> doesn't work correctly with driver
> (https://bugs.openjdk.java.net/browse/CODETOOLS-7901589)
>
> - Two tests (test/serviceability/dcmd/gc/HeapDumpTest.java and
> test/serviceability/dcmd/gc/HeapDumpAllTest.java) had @build with a
> misspelled package name, a new version of jtreg will treat this as an
error
>
>
>
> Changes have been tested by running all of the Hotspot Jtreg tests.
>
>
>
> Webrev:
>
> http://cr.openjdk.java.net/~ctornqvi/webrev/8151156/webrev.00/
>
>
>
> Bug:
>
> https://bugs.openjdk.java.net/browse/JDK-8151156
>
>
>
> Thanks,
>
> Christian
>
>
>
From david.holmes at oracle.com Thu Mar 3 21:50:04 2016
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 4 Mar 2016 07:50:04 +1000
Subject: [9] RFR (XS): 8139247: Improper locking of
MethodData::_extra_data_lock
In-Reply-To: <56D86B19.7010206@oracle.com>
References: <56D814B3.3000605@oracle.com> <56D86B19.7010206@oracle.com>
Message-ID: <56D8B18C.5080104@oracle.com>
On 4/03/2016 2:49 AM, Daniel D. Daugherty wrote:
> On 3/3/16 3:40 AM, Vladimir Ivanov wrote:
>> http://cr.openjdk.java.net/~vlivanov/8139247/webrev.00
>
> src/share/vm/ci/ciMethodData.cpp
> Nicely done!
+1 from me.
> We've been bitten by the "MutexLocker /*missing name*/ (lock);" before.
> It's interesting that fixing that runs into JDK-8146616. We should
Yeah - how did Vladimir detect that? Detailed check of the generated code?
> probably make an audit run on finding missing name instances (again).
Yep here's another one in ./share/vm/utilities/decoder.cpp
DecoderLocker::DecoderLocker() :
MutexLockerEx(DecoderLocker::is_first_error_thread() ?
NULL : Decoder::shared_decoder_lock(), true) {
_decoder = is_first_error_thread() ?
Decoder::get_error_handler_instance() : Decoder::get_shared_instance();
assert(_decoder != NULL, "null decoder");
}
Cheers,
David
-----
> Thumbs up!
>
> Dan
>
>
>> https://bugs.openjdk.java.net/browse/JDK-8139247
>>
>> Solaris Studio C++ compiler generates tightly coupled
>> Monitor::lock/unlock calls for unnamed MutexLocker which breaks
>> synchronization between ciMethodData::load_extra_data() and
>> MethodData::bci_to_extra_data().
>>
>> MutexLocker(mdo->extra_data_lock());
>>
>> is compiled into:
>>
>> load_extra_data+0x001d: movq %r13,%rdi
>> load_extra_data+0x0020: call lock [ 0xfffffd7fe6df46c0, .+0x7cc5c0 ]
>> load_extra_data+0x0025: movq %r13,%rdi
>> load_extra_data+0x0028: call unlock [ 0xfffffd7fe6df47f0, .+0x7cc6e8
>>
>> But after adding a name, we hit a compiler bug in SS12u4 and
>> Monitor::unlock call is missed. So, have to add a workaround (same as
>> in JDK-8146616 [1]).
>>
>> Testing: verified machine code for ciMethodData::load_extra_data().
>>
>> Best regards,
>> Vladimir Ivanov
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8146616
>
From david.holmes at oracle.com Thu Mar 3 21:57:39 2016
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 4 Mar 2016 07:57:39 +1000
Subject: [9] RFR (XS): 8139247: Improper locking of
MethodData::_extra_data_lock
In-Reply-To: <56D814B3.3000605@oracle.com>
References: <56D814B3.3000605@oracle.com>
Message-ID: <56D8B353.4030904@oracle.com>
On 3/03/2016 8:40 PM, Vladimir Ivanov wrote:
> http://cr.openjdk.java.net/~vlivanov/8139247/webrev.00
> https://bugs.openjdk.java.net/browse/JDK-8139247
>
> Solaris Studio C++ compiler generates tightly coupled
> Monitor::lock/unlock calls for unnamed MutexLocker which breaks
Just to be clear this is not a compiler bug - the anonymous instance can
be destructed at any time after construction as it lives only until the
end of the expression that defines it. Arguably any compiler not doing
this is the buggy one. :)
Cheers,
David
> synchronization between ciMethodData::load_extra_data() and
> MethodData::bci_to_extra_data().
>
> MutexLocker(mdo->extra_data_lock());
>
> is compiled into:
>
> load_extra_data+0x001d: movq %r13,%rdi
> load_extra_data+0x0020: call lock [ 0xfffffd7fe6df46c0, .+0x7cc5c0 ]
> load_extra_data+0x0025: movq %r13,%rdi
> load_extra_data+0x0028: call unlock [ 0xfffffd7fe6df47f0, .+0x7cc6e8
>
> But after adding a name, we hit a compiler bug in SS12u4 and
> Monitor::unlock call is missed. So, have to add a workaround (same as in
> JDK-8146616 [1]).
>
> Testing: verified machine code for ciMethodData::load_extra_data().
>
> Best regards,
> Vladimir Ivanov
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8146616
From jon.masamitsu at oracle.com Thu Mar 3 23:46:06 2016
From: jon.masamitsu at oracle.com (Jon Masamitsu)
Date: Thu, 3 Mar 2016 15:46:06 -0800
Subject: RFR 8150013: ParNew: Prune nmethods scavengable list
In-Reply-To:
References:
Message-ID: <56D8CCBE.4040900@oracle.com>
Carsten,
Changes look good.
A couple of suggestions.
http://cr.openjdk.java.net/~cvarming/scavenge_nmethods_auto_prune/2/src/share/vm/code/codeCache.cpp.frames.html
661 if (is_live) {
662 // Perform cur->oops_do(f), maybe just once per nmethod.
663 f->do_code_blob(cur);
664 }
665 nmethod* const next = cur->scavenge_root_link();
666 if (fix_relocations) {
667 if (!is_live || !cur->detect_scavenge_root_oops()) {
668 unlink_scavenge_root_nmethod(cur, prev);
669 } else {
670 prev = cur;
671 }
672 }
673 cur = next;
Although this does not change the actions, I find this easier to
read. You and Tony (and whoever else wants to) can vote
on it.
if (is_live) { ... } else {
if (fix_relocations) { if (cur->detect_scavenge_root_oops()) { prev =
cur; } else { unlink_scavenge_root_nmethod(cur, prev);} } cur =
cur->scavenge_root_link(); }
Also I'd suggest a comment before the if-test
if you find it correct.
// Unless the relocations have been updated (fixed), the //
detect_scavenge_root_oops() will not be precise so skip // the check to
unlink. Note that not doing the unlinking // is safe but less optimal.
if (fix_relocations) {
The comment in the header file for fix_relocations helped
but a comment here might be helpful.
I'll sponsor.
Jon
On 2/28/2016 6:16 PM, Carsten Varming wrote:
> Dear Hotspot developers,
>
> Any chance of a review of this patch? The patch cut between 7ms and
> 10ms of every ParNew with one application at Twitter and I expect a
> 1-2ms improvement for most applications.
>
> I touch the code cache and GenCollectedHeap, so I assume I need
> reviews from both gc and compiler reviewers. Thank you Tony Printezis
> for the review (posted on the hotspot-gc-dev list).
>
> I also need a sponsor.
>
> Carsten
>
> On Fri, Feb 19, 2016 at 10:52 AM, Carsten Varming > wrote:
>
> Dear Hotspot developers,
>
> I would like to contribute a patch for JDK-8150013
> . The current
> webrev can be found here:
> http://cr.openjdk.java.net/~cvarming/scavenge_nmethods_auto_prune/2/
> .
>
> Suggestions for improvements are very welcome.
>
> Carsten
>
>
From david.holmes at oracle.com Fri Mar 4 02:38:24 2016
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 4 Mar 2016 12:38:24 +1000
Subject: RFR(M): 8151156 - [TESTBUG] Integrate trivial Hotspot test
changes from Jake before Jigsaw M3
In-Reply-To: <1c4cd01d17549$837e4d10$8a7ae730$@oracle.com>
References: <1c4cd01d17549$837e4d10$8a7ae730$@oracle.com>
Message-ID: <56D8F520.5030504@oracle.com>
Hi Christian,
On 3/03/2016 10:37 PM, Christian Tornqvist wrote:
> Hi everyone,
>
>
>
> Please review this change that integrates some of the trivial Hotspot test
> changes made in Jake, these are all going into jdk9-dev in order to make it
> into master before M3 hits. There are three different kind of changes
> included in this webrev:
>
>
>
> - Adding/correcting Module exports (using @module), this is a no-op
> in JDK 9 until Jigsaw M3 gets in.
>
> - @run driver -> @run main, jtreg has a bug where module exports
> doesn't work correctly with driver
> (https://bugs.openjdk.java.net/browse/CODETOOLS-7901589)
Could this change have an adverse impact on the nightlies, now that
unexpected/unwanted options will be passed through to the initial VM?
Can you file a follow up bug to switch these all back to @driver once
the jtreg problem is fixed.
Thanks,
David
> - Two tests (test/serviceability/dcmd/gc/HeapDumpTest.java and
> test/serviceability/dcmd/gc/HeapDumpAllTest.java) had @build with a
> misspelled package name, a new version of jtreg will treat this as an error
>
>
>
> Changes have been tested by running all of the Hotspot Jtreg tests.
>
>
>
> Webrev:
>
> http://cr.openjdk.java.net/~ctornqvi/webrev/8151156/webrev.00/
>
>
>
> Bug:
>
> https://bugs.openjdk.java.net/browse/JDK-8151156
>
>
>
> Thanks,
>
> Christian
>
>
>
From christian.tornqvist at oracle.com Fri Mar 4 04:40:06 2016
From: christian.tornqvist at oracle.com (Christian Tornqvist)
Date: Thu, 3 Mar 2016 23:40:06 -0500
Subject: RFR(M): 8151156 - [TESTBUG] Integrate trivial Hotspot test
changes from Jake before Jigsaw M3
In-Reply-To: <56D8F520.5030504@oracle.com>
References: <1c4cd01d17549$837e4d10$8a7ae730$@oracle.com>
<56D8F520.5030504@oracle.com>
Message-ID: <1c97f01d175cf$ed887c40$c89974c0$@oracle.com>
Hi David,
I've filed https://bugs.openjdk.java.net/browse/JDK-8151248 to deal with
changing them back. As for nightly, I'd be surprised if they would fail,
we'll handle them if they do.
Thanks,
Christian
-----Original Message-----
From: David Holmes [mailto:david.holmes at oracle.com]
Sent: Thursday, March 3, 2016 9:38 PM
To: Christian Tornqvist ; 'hotspot-dev
developers'
Subject: Re: RFR(M): 8151156 - [TESTBUG] Integrate trivial Hotspot test
changes from Jake before Jigsaw M3
Hi Christian,
On 3/03/2016 10:37 PM, Christian Tornqvist wrote:
> Hi everyone,
>
>
>
> Please review this change that integrates some of the trivial Hotspot
> test changes made in Jake, these are all going into jdk9-dev in order
> to make it into master before M3 hits. There are three different kind
> of changes included in this webrev:
>
>
>
> - Adding/correcting Module exports (using @module), this is a
no-op
> in JDK 9 until Jigsaw M3 gets in.
>
> - @run driver -> @run main, jtreg has a bug where module exports
> doesn't work correctly with driver
> (https://bugs.openjdk.java.net/browse/CODETOOLS-7901589)
Could this change have an adverse impact on the nightlies, now that
unexpected/unwanted options will be passed through to the initial VM?
Can you file a follow up bug to switch these all back to @driver once the
jtreg problem is fixed.
Thanks,
David
> - Two tests (test/serviceability/dcmd/gc/HeapDumpTest.java and
> test/serviceability/dcmd/gc/HeapDumpAllTest.java) had @build with a
> misspelled package name, a new version of jtreg will treat this as an
> error
>
>
>
> Changes have been tested by running all of the Hotspot Jtreg tests.
>
>
>
> Webrev:
>
> http://cr.openjdk.java.net/~ctornqvi/webrev/8151156/webrev.00/
>
>
>
> Bug:
>
> https://bugs.openjdk.java.net/browse/JDK-8151156
>
>
>
> Thanks,
>
> Christian
>
>
>
From david.holmes at oracle.com Fri Mar 4 04:43:57 2016
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 4 Mar 2016 14:43:57 +1000
Subject: RFR(M): 8151156 - [TESTBUG] Integrate trivial Hotspot test
changes from Jake before Jigsaw M3
In-Reply-To: <1c97f01d175cf$ed887c40$c89974c0$@oracle.com>
References: <1c4cd01d17549$837e4d10$8a7ae730$@oracle.com>
<56D8F520.5030504@oracle.com>
<1c97f01d175cf$ed887c40$c89974c0$@oracle.com>
Message-ID: <56D9128D.8020509@oracle.com>
On 4/03/2016 2:40 PM, Christian Tornqvist wrote:
> Hi David,
>
> I've filed https://bugs.openjdk.java.net/browse/JDK-8151248 to deal with
Thanks.
> changing them back. As for nightly, I'd be surprised if they would fail,
> we'll handle them if they do.
Okay.
David
> Thanks,
> Christian
>
> -----Original Message-----
> From: David Holmes [mailto:david.holmes at oracle.com]
> Sent: Thursday, March 3, 2016 9:38 PM
> To: Christian Tornqvist ; 'hotspot-dev
> developers'
> Subject: Re: RFR(M): 8151156 - [TESTBUG] Integrate trivial Hotspot test
> changes from Jake before Jigsaw M3
>
> Hi Christian,
>
> On 3/03/2016 10:37 PM, Christian Tornqvist wrote:
>> Hi everyone,
>>
>>
>>
>> Please review this change that integrates some of the trivial Hotspot
>> test changes made in Jake, these are all going into jdk9-dev in order
>> to make it into master before M3 hits. There are three different kind
>> of changes included in this webrev:
>>
>>
>>
>> - Adding/correcting Module exports (using @module), this is a
> no-op
>> in JDK 9 until Jigsaw M3 gets in.
>>
>> - @run driver -> @run main, jtreg has a bug where module exports
>> doesn't work correctly with driver
>> (https://bugs.openjdk.java.net/browse/CODETOOLS-7901589)
>
> Could this change have an adverse impact on the nightlies, now that
> unexpected/unwanted options will be passed through to the initial VM?
>
> Can you file a follow up bug to switch these all back to @driver once the
> jtreg problem is fixed.
>
> Thanks,
> David
>
>> - Two tests (test/serviceability/dcmd/gc/HeapDumpTest.java and
>> test/serviceability/dcmd/gc/HeapDumpAllTest.java) had @build with a
>> misspelled package name, a new version of jtreg will treat this as an
>> error
>>
>>
>>
>> Changes have been tested by running all of the Hotspot Jtreg tests.
>>
>>
>>
>> Webrev:
>>
>> http://cr.openjdk.java.net/~ctornqvi/webrev/8151156/webrev.00/
>>
>>
>>
>> Bug:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8151156
>>
>>
>>
>> Thanks,
>>
>> Christian
>>
>>
>>
>
From christian.tornqvist at oracle.com Fri Mar 4 17:12:58 2016
From: christian.tornqvist at oracle.com (Christian Tornqvist)
Date: Fri, 4 Mar 2016 12:12:58 -0500
Subject: RFR: 8078112: Integrate Selection/Resolution test suite
into jtreg tests
In-Reply-To: <56D5D3AD.7030308@oracle.com>
References: <56D42B0B.6050008@oracle.com> <56D52D87.3040900@oracle.com>
<56D5D3AD.7030308@oracle.com>
Message-ID: <022d01d17639$19e4bf10$4dae3d30$@oracle.com>
Hi Dmitry,
This looks good, thanks for taking care of this.
Thanks,
Christian
-----Original Message-----
From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Dmitry Dmitriev
Sent: Tuesday, March 1, 2016 12:39 PM
To: David Holmes ; hotspot-dev at openjdk.java.net
Subject: Re: RFR: 8078112: Integrate Selection/Resolution test suite into jtreg tests
Hello David,
Thank you for the comments! I added build instructions to the tests.
I specify timeout because on fastdebug builds test needs more time.
Only two tests will be run as part of JPRT submissions - InvokeStaticSuccessTest and NoSuchMethodErrorTest.
InvokeStaticSuccessTest takes 1-3 seconds and NoSuchMethodErrorTest takes 2-9 seconds. Other tests are excluded from JPRT run.
Updated webrev.01:
http://cr.openjdk.java.net/~ddmitriev/8078112/webrev.01/
Thank you,
Dmitry
On 01.03.2016 8:49, David Holmes wrote:
> Hi Dmitry,
>
> On 29/02/2016 9:27 PM, Dmitry Dmitriev wrote:
>> Hello,
>>
>> Please review this patch, which integrates the selection/resolution
>> test suite into the JTreg test suite. This test suite was developed
>> by Eric
>> Mccorkle(OpenJDK: emc). Thanks Eric for that!
>>
>> This test suite uses a template-based generation scheme to exercise
>> all aspects of the updated selection/resolution test suite from JVMS
>> 8. It runs a very large number of tests, representing a very wide
>> variety of cases. Extensive javadoc comments are found throughout
>> the test code which describe the suite's functioning in more detail.
>>
>> Also note that this suite as already undergone extensive review as
>> part of the development process.
>>
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8078112
>> webrev.00: http://cr.openjdk.java.net/~ddmitriev/8078112/webrev.00/
>>
>> Testing: Jprt, RBT(all platforms, product & fastdebug builds)
>
> I hate to open this debate again but I see:
>
> @library /runtime/SelectionResolution/classes
>
> but no instructions on how to build the library contents.
>
> Do we really need to specify a timeout?
>
> @run main/othervm/timeout=300
>
> Will these tests now run as part of JPRT submissions? If so:
> a) have they been tested on all platforms?
> b) how long do they take to run?
>
> Thanks,
> David
>
>
>> Thanks,
>> Dmitry
From dmitry.dmitriev at oracle.com Fri Mar 4 17:20:51 2016
From: dmitry.dmitriev at oracle.com (Dmitry Dmitriev)
Date: Fri, 4 Mar 2016 20:20:51 +0300
Subject: RFR: 8078112: Integrate Selection/Resolution test suite into
jtreg tests
In-Reply-To: <022d01d17639$19e4bf10$4dae3d30$@oracle.com>
References: <56D42B0B.6050008@oracle.com> <56D52D87.3040900@oracle.com>
<56D5D3AD.7030308@oracle.com>
<022d01d17639$19e4bf10$4dae3d30$@oracle.com>
Message-ID: <56D9C3F3.6010400@oracle.com>
Hi Christian,
Thank you for the review!
Dmitry
On 04.03.2016 20:12, Christian Tornqvist wrote:
> Hi Dmitry,
>
> This looks good, thanks for taking care of this.
>
> Thanks,
> Christian
>
> -----Original Message-----
> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Dmitry Dmitriev
> Sent: Tuesday, March 1, 2016 12:39 PM
> To: David Holmes ; hotspot-dev at openjdk.java.net
> Subject: Re: RFR: 8078112: Integrate Selection/Resolution test suite into jtreg tests
>
> Hello David,
>
> Thank you for the comments! I added build instructions to the tests.
>
> I specify timeout because on fastdebug builds test needs more time.
>
> Only two tests will be run as part of JPRT submissions - InvokeStaticSuccessTest and NoSuchMethodErrorTest.
> InvokeStaticSuccessTest takes 1-3 seconds and NoSuchMethodErrorTest takes 2-9 seconds. Other tests are excluded from JPRT run.
>
> Updated webrev.01:
> http://cr.openjdk.java.net/~ddmitriev/8078112/webrev.01/
>
>
> Thank you,
> Dmitry
>
> On 01.03.2016 8:49, David Holmes wrote:
>> Hi Dmitry,
>>
>> On 29/02/2016 9:27 PM, Dmitry Dmitriev wrote:
>>> Hello,
>>>
>>> Please review this patch, which integrates the selection/resolution
>>> test suite into the JTreg test suite. This test suite was developed
>>> by Eric
>>> Mccorkle(OpenJDK: emc). Thanks Eric for that!
>>>
>>> This test suite uses a template-based generation scheme to exercise
>>> all aspects of the updated selection/resolution test suite from JVMS
>>> 8. It runs a very large number of tests, representing a very wide
>>> variety of cases. Extensive javadoc comments are found throughout
>>> the test code which describe the suite's functioning in more detail.
>>>
>>> Also note that this suite as already undergone extensive review as
>>> part of the development process.
>>>
>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8078112
>>> webrev.00: http://cr.openjdk.java.net/~ddmitriev/8078112/webrev.00/
>>>
>>> Testing: Jprt, RBT(all platforms, product & fastdebug builds)
>> I hate to open this debate again but I see:
>>
>> @library /runtime/SelectionResolution/classes
>>
>> but no instructions on how to build the library contents.
>>
>> Do we really need to specify a timeout?
>>
>> @run main/othervm/timeout=300
>>
>> Will these tests now run as part of JPRT submissions? If so:
>> a) have they been tested on all platforms?
>> b) how long do they take to run?
>>
>> Thanks,
>> David
>>
>>
>>> Thanks,
>>> Dmitry
>
From christian.thalinger at oracle.com Fri Mar 4 17:50:28 2016
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Fri, 4 Mar 2016 07:50:28 -1000
Subject: RFR 8150013: ParNew: Prune nmethods scavengable list
In-Reply-To: <56D8CCBE.4040900@oracle.com>
References:
<56D8CCBE.4040900@oracle.com>
Message-ID:
Jon asked me to have a quick look over the code cache changes. Looks good to me.
> On Mar 3, 2016, at 1:46 PM, Jon Masamitsu wrote:
>
> Carsten,
>
> Changes look good.
>
> A couple of suggestions.
>
> http://cr.openjdk.java.net/~cvarming/scavenge_nmethods_auto_prune/2/src/share/vm/code/codeCache.cpp.frames.html
>
> 661 if (is_live) {
> 662 // Perform cur->oops_do(f), maybe just once per nmethod.
> 663 f->do_code_blob(cur);
> 664 }
> 665 nmethod* const next = cur->scavenge_root_link();
> 666 if (fix_relocations) {
> 667 if (!is_live || !cur->detect_scavenge_root_oops()) {
> 668 unlink_scavenge_root_nmethod(cur, prev);
> 669 } else {
> 670 prev = cur;
> 671 }
> 672 }
> 673 cur = next;
>
> Although this does not change the actions, I find this easier to
> read. You and Tony (and whoever else wants to) can vote
> on it.
>
> if (is_live) { ... } else {
> if (fix_relocations) { if (cur->detect_scavenge_root_oops()) { prev = cur; } else { unlink_scavenge_root_nmethod(cur, prev);} } cur = cur->scavenge_root_link(); }
>
> Also I'd suggest a comment before the if-test
> if you find it correct.
>
> // Unless the relocations have been updated (fixed), the // detect_scavenge_root_oops() will not be precise so skip // the check to unlink. Note that not doing the unlinking // is safe but less optimal. if (fix_relocations) {
>
> The comment in the header file for fix_relocations helped
> but a comment here might be helpful.
>
> I'll sponsor.
>
> Jon
>
> On 2/28/2016 6:16 PM, Carsten Varming wrote:
>> Dear Hotspot developers,
>>
>> Any chance of a review of this patch? The patch cut between 7ms and 10ms of every ParNew with one application at Twitter and I expect a 1-2ms improvement for most applications.
>>
>> I touch the code cache and GenCollectedHeap, so I assume I need reviews from both gc and compiler reviewers. Thank you Tony Printezis for the review (posted on the hotspot-gc-dev list).
>>
>> I also need a sponsor.
>>
>> Carsten
>>
>> On Fri, Feb 19, 2016 at 10:52 AM, Carsten Varming > wrote:
>>
>> Dear Hotspot developers,
>>
>> I would like to contribute a patch for JDK-8150013
>> . The current
>> webrev can be found here:
>> http://cr.openjdk.java.net/~cvarming/scavenge_nmethods_auto_prune/2/
>> .
>>
>> Suggestions for improvements are very welcome.
>>
>> Carsten
>>
>>
>
From varming at gmail.com Fri Mar 4 18:23:57 2016
From: varming at gmail.com (Carsten Varming)
Date: Fri, 4 Mar 2016 13:23:57 -0500
Subject: RFR 8150013: ParNew: Prune nmethods scavengable list
In-Reply-To:
References:
<56D8CCBE.4040900@oracle.com>
Message-ID:
Dear Christian,
Thank you for your review.
Carsten
On Fri, Mar 4, 2016 at 12:50 PM, Christian Thalinger <
christian.thalinger at oracle.com> wrote:
> Jon asked me to have a quick look over the code cache changes. Looks good
> to me.
>
> > On Mar 3, 2016, at 1:46 PM, Jon Masamitsu
> wrote:
> >
> > Carsten,
> >
> > Changes look good.
> >
> > A couple of suggestions.
> >
> >
> http://cr.openjdk.java.net/~cvarming/scavenge_nmethods_auto_prune/2/src/share/vm/code/codeCache.cpp.frames.html
> >
> > 661 if (is_live) {
> > 662 // Perform cur->oops_do(f), maybe just once per nmethod.
> > 663 f->do_code_blob(cur);
> > 664 }
> > 665 nmethod* const next = cur->scavenge_root_link();
> > 666 if (fix_relocations) {
> > 667 if (!is_live || !cur->detect_scavenge_root_oops()) {
> > 668 unlink_scavenge_root_nmethod(cur, prev);
> > 669 } else {
> > 670 prev = cur;
> > 671 }
> > 672 }
> > 673 cur = next;
> >
> > Although this does not change the actions, I find this easier to
> > read. You and Tony (and whoever else wants to) can vote
> > on it.
> >
> > if (is_live) { ... } else {
> > if (fix_relocations) { if (cur->detect_scavenge_root_oops()) { prev =
> cur; } else { unlink_scavenge_root_nmethod(cur, prev);} } cur =
> cur->scavenge_root_link(); }
> >
> > Also I'd suggest a comment before the if-test
> > if you find it correct.
> >
> > // Unless the relocations have been updated (fixed), the //
> detect_scavenge_root_oops() will not be precise so skip // the check to
> unlink. Note that not doing the unlinking // is safe but less optimal. if
> (fix_relocations) {
> >
> > The comment in the header file for fix_relocations helped
> > but a comment here might be helpful.
> >
> > I'll sponsor.
> >
> > Jon
> >
> > On 2/28/2016 6:16 PM, Carsten Varming wrote:
> >> Dear Hotspot developers,
> >>
> >> Any chance of a review of this patch? The patch cut between 7ms and
> 10ms of every ParNew with one application at Twitter and I expect a 1-2ms
> improvement for most applications.
> >>
> >> I touch the code cache and GenCollectedHeap, so I assume I need reviews
> from both gc and compiler reviewers. Thank you Tony Printezis for the
> review (posted on the hotspot-gc-dev list).
> >>
> >> I also need a sponsor.
> >>
> >> Carsten
> >>
> >> On Fri, Feb 19, 2016 at 10:52 AM, Carsten Varming > wrote:
> >>
> >> Dear Hotspot developers,
> >>
> >> I would like to contribute a patch for JDK-8150013
> >> . The current
> >> webrev can be found here:
> >> http://cr.openjdk.java.net/~cvarming/scavenge_nmethods_auto_prune/2/
> >> <
> http://cr.openjdk.java.net/%7Ecvarming/scavenge_nmethods_auto_prune/2/>.
> >>
> >> Suggestions for improvements are very welcome.
> >>
> >> Carsten
> >>
> >>
> >
>
>
From vladimir.x.ivanov at oracle.com Sun Mar 6 12:49:24 2016
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Sun, 6 Mar 2016 15:49:24 +0300
Subject: [9] RFR (XS): 8139247: Improper locking of
MethodData::_extra_data_lock
In-Reply-To: <56D8B18C.5080104@oracle.com>
References: <56D814B3.3000605@oracle.com> <56D86B19.7010206@oracle.com>
<56D8B18C.5080104@oracle.com>
Message-ID: <56DC2754.7030902@oracle.com>
Roland, Dan, David, thanks for the reviews.
Updated fix:
http://cr.openjdk.java.net/~vlivanov/8139247/webrev.01/
I found that ciSpeculativeTrapData::translate_from may block on
Compile_lock (in ciMethod ctor [1]), so MDO extra lock has to be
unlocked first since it has leaf rank.
>> We've been bitten by the "MutexLocker /*missing name*/ (lock);" before.
>> It's interesting that fixing that runs into JDK-8146616. We should
>
> Yeah - how did Vladimir detect that? Detailed check of the generated code?
Well, initially I missed that the locker doesn't have a name and went
right to the generated code, since I vaguely remembered that there was
some bug in SS12u4. And the control flow shape was similar
When I added a name, I looked at it again and noticed unlock() is missed.
>> probably make an audit run on finding missing name instances (again).
>
> Yep here's another one in ./share/vm/utilities/decoder.cpp
>
> DecoderLocker::DecoderLocker() :
> MutexLockerEx(DecoderLocker::is_first_error_thread() ?
> NULL : Decoder::shared_decoder_lock(), true) {
> _decoder = is_first_error_thread() ?
> Decoder::get_error_handler_instance() :
> Decoder::get_shared_instance();
> assert(_decoder != NULL, "null decoder");
> }
Are you sure? It is a constructor call:
class DecoderLocker : public MutexLockerEx {
All DecodeLocker usages are named.
Best regards,
Vladimir Ivanov
[1]
http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/tip/src/share/vm/ci/ciMethod.cpp#l108
>
> Cheers,
> David
> -----
>
>
>> Thumbs up!
>>
>> Dan
>>
>>
>>> https://bugs.openjdk.java.net/browse/JDK-8139247
>>>
>>> Solaris Studio C++ compiler generates tightly coupled
>>> Monitor::lock/unlock calls for unnamed MutexLocker which breaks
>>> synchronization between ciMethodData::load_extra_data() and
>>> MethodData::bci_to_extra_data().
>>>
>>> MutexLocker(mdo->extra_data_lock());
>>>
>>> is compiled into:
>>>
>>> load_extra_data+0x001d: movq %r13,%rdi
>>> load_extra_data+0x0020: call lock [ 0xfffffd7fe6df46c0, .+0x7cc5c0 ]
>>> load_extra_data+0x0025: movq %r13,%rdi
>>> load_extra_data+0x0028: call unlock [ 0xfffffd7fe6df47f0, .+0x7cc6e8
>>>
>>> But after adding a name, we hit a compiler bug in SS12u4 and
>>> Monitor::unlock call is missed. So, have to add a workaround (same as
>>> in JDK-8146616 [1]).
>>>
>>> Testing: verified machine code for ciMethodData::load_extra_data().
>>>
>>> Best regards,
>>> Vladimir Ivanov
>>>
>>> [1] https://bugs.openjdk.java.net/browse/JDK-8146616
>>
From david.holmes at oracle.com Sun Mar 6 21:03:26 2016
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 7 Mar 2016 07:03:26 +1000
Subject: [9] RFR (XS): 8139247: Improper locking of
MethodData::_extra_data_lock
In-Reply-To: <56DC2754.7030902@oracle.com>
References: <56D814B3.3000605@oracle.com> <56D86B19.7010206@oracle.com>
<56D8B18C.5080104@oracle.com> <56DC2754.7030902@oracle.com>
Message-ID: <56DC9B1E.7040803@oracle.com>
On 6/03/2016 10:49 PM, Vladimir Ivanov wrote:
> Roland, Dan, David, thanks for the reviews.
>
> Updated fix:
> http://cr.openjdk.java.net/~vlivanov/8139247/webrev.01/
>
> I found that ciSpeculativeTrapData::translate_from may block on
> Compile_lock (in ciMethod ctor [1]), so MDO extra lock has to be
> unlocked first since it has leaf rank.
That's interesting - it means even if other compilers were not unlocking
the mutex immediately, they were unlocking it prior to this modified
code (else the problem would have been detected earlier). Which all
suggest that as far as locking is concerned the behaviour of this code
is somewhat untested!
Why was the assertion removed?
Don't forget to update copyright year.
>>> We've been bitten by the "MutexLocker /*missing name*/ (lock);" before.
>>> It's interesting that fixing that runs into JDK-8146616. We should
>>
>> Yeah - how did Vladimir detect that? Detailed check of the generated
>> code?
> Well, initially I missed that the locker doesn't have a name and went
> right to the generated code, since I vaguely remembered that there was
> some bug in SS12u4. And the control flow shape was similar
>
> When I added a name, I looked at it again and noticed unlock() is missed.
>
>>> probably make an audit run on finding missing name instances (again).
>>
>> Yep here's another one in ./share/vm/utilities/decoder.cpp
>>
>> DecoderLocker::DecoderLocker() :
>> MutexLockerEx(DecoderLocker::is_first_error_thread() ?
>> NULL : Decoder::shared_decoder_lock(), true) {
>> _decoder = is_first_error_thread() ?
>> Decoder::get_error_handler_instance() :
>> Decoder::get_shared_instance();
>> assert(_decoder != NULL, "null decoder");
>> }
> Are you sure? It is a constructor call:
>
> class DecoderLocker : public MutexLockerEx {
>
> All DecodeLocker usages are named.
Yep my mistake - thanks. I was only looking at the grep results, I
hadn't check the actual usage.
Thanks,
David
>
> Best regards,
> Vladimir Ivanov
>
> [1]
> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/tip/src/share/vm/ci/ciMethod.cpp#l108
>
>
>>
>> Cheers,
>> David
>> -----
>>
>>
>>> Thumbs up!
>>>
>>> Dan
>>>
>>>
>>>> https://bugs.openjdk.java.net/browse/JDK-8139247
>>>>
>>>> Solaris Studio C++ compiler generates tightly coupled
>>>> Monitor::lock/unlock calls for unnamed MutexLocker which breaks
>>>> synchronization between ciMethodData::load_extra_data() and
>>>> MethodData::bci_to_extra_data().
>>>>
>>>> MutexLocker(mdo->extra_data_lock());
>>>>
>>>> is compiled into:
>>>>
>>>> load_extra_data+0x001d: movq %r13,%rdi
>>>> load_extra_data+0x0020: call lock [ 0xfffffd7fe6df46c0, .+0x7cc5c0 ]
>>>> load_extra_data+0x0025: movq %r13,%rdi
>>>> load_extra_data+0x0028: call unlock [ 0xfffffd7fe6df47f0, .+0x7cc6e8
>>>>
>>>> But after adding a name, we hit a compiler bug in SS12u4 and
>>>> Monitor::unlock call is missed. So, have to add a workaround (same as
>>>> in JDK-8146616 [1]).
>>>>
>>>> Testing: verified machine code for ciMethodData::load_extra_data().
>>>>
>>>> Best regards,
>>>> Vladimir Ivanov
>>>>
>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8146616
>>>
From vladimir.x.ivanov at oracle.com Sun Mar 6 21:49:49 2016
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Mon, 7 Mar 2016 00:49:49 +0300
Subject: [9] RFR (XS): 8139247: Improper locking of
MethodData::_extra_data_lock
In-Reply-To: <56DC9B1E.7040803@oracle.com>
References: <56D814B3.3000605@oracle.com> <56D86B19.7010206@oracle.com>
<56D8B18C.5080104@oracle.com> <56DC2754.7030902@oracle.com>
<56DC9B1E.7040803@oracle.com>
Message-ID: <56DCA5FD.4050202@oracle.com>
>> Updated fix:
>> http://cr.openjdk.java.net/~vlivanov/8139247/webrev.01/
>>
>> I found that ciSpeculativeTrapData::translate_from may block on
>> Compile_lock (in ciMethod ctor [1]), so MDO extra lock has to be
>> unlocked first since it has leaf rank.
>
> That's interesting - it means even if other compilers were not unlocking
> the mutex immediately, they were unlocking it prior to this modified
> code (else the problem would have been detected earlier). Which all
> suggest that as far as locking is concerned the behaviour of this code
> is somewhat untested!
Yes, it turns out the bug is not specific to Solaris x86. I'm not sure
why it fails only there though.
> Why was the assertion removed?
It's useless. SpeculativeTrapData is just a view over a memory location
and the location is the same:
SpeculativeTrapData* data_src = new SpeculativeTrapData(dp_src);
SpeculativeTrapData* data_src2 = new SpeculativeTrapData(dp_src);
> Don't forget to update copyright year.
Will do. Thanks!
Best regards,
Vladimir Ivanov
From gromero at linux.vnet.ibm.com Sun Mar 6 22:27:03 2016
From: gromero at linux.vnet.ibm.com (Gustavo Romero)
Date: Sun, 6 Mar 2016 19:27:03 -0300
Subject: RFR(M) 8150353: PPC64LE: Support RTM on linux
In-Reply-To:
References: <56CE0975.8060807@linux.vnet.ibm.com>
<56CEB349.1050102@oracle.com> <56CEB73D.8030904@linux.vnet.ibm.com>
<56CEB982.5030706@oracle.com>
Message-ID: <56DCAEB7.8010003@linux.vnet.ibm.com>
Hi Thomas
Thanks for offering the hosting. :-)
Thomas, could you please host this updated version that incorporates the
comments made by you, Martin, and Vladimir (Martin also kindly offered
the hosting but probably is yet out of office - but I'm not sure).
Webrev updated version:
http://81.de.7a9f.ip4.static.sl-reverse.com./8150353/webrev.zip
Thanks a lot.
Best regards,
Gustavo
On 25-02-2016 07:57, Thomas St?fe wrote:
> Hi Gustavo,
>
> I can host this for you, if you have no access to cr.openjdk.java.net. Just
> send me the patch file.
>
> About your change:
>
> src/cpu/ppc/vm/globalDefinitions_ppc.hpp
>
> small nit: Could be probably be merged with the paragraph above where we do
> the same thing for AIX, but I do not have strong emotions.
>
>
> src/cpu/ppc/vm/vm_version_ppc.cpp
>
> + // Please, refer to commit 4b4fadba057c1af7689fc8fa182b13baL7
> Does this refer to an OpenJDK change? If yes, could you please instead
> mention the OpenJDK bug number instead?
>
>
> src/os/linux/vm/os_linux.cpp
>
> os::Linux::initialize_os_info()
>
> Please make this code more robust:
> - Check the return value of sscanf (must be 3, otherwise your assumption
> about the version format was wrong)
> - Could this happen: "3.2" ? If yes, could you please handle it too?
> - Please handle overflow - if any one of minor/fix is > 256, something
> sensible should happen (for major, this probably indicates an error).
> Possibly cap out at 256?
>
> If version cannot be read successfully, the VM should not abort imho but
> behave gracefully. Worst that should happen is that RTM gets deactivated.
>
>
> Kind Regards, Thomas
>
>
> On Thu, Feb 25, 2016 at 9:21 AM, David Holmes
> wrote:
>
>> On 25/02/2016 6:11 PM, Gustavo Romero wrote:
>>
>>> Hi David,
>>>
>>> OK, I'll fix that.
>>>
>>> Should I re-send the RFR with the right URL and abandon this one?
>>>
>>
>> I think you can just post the new URL to this one.
>>
>> In case a contribution is not so small, even so is it fine to include it
>>> inline?
>>>
>>
>> Well it's preferable, for larger contributions, to find someone to host
>> the webrev for you.
>>
>> Cheers,
>> David
>>
>>
>> Thank you.
>>>
>>> Regards,
>>> Gustavo
>>>
>>> On 25-02-2016 04:54, David Holmes wrote:
>>>
>>>> Hi Gustavo,
>>>>
>>>> Just a point of order. All contributions to the OpenJDK must be made
>>>> through OpenJDK infrastructure. So you must either get someone to host your
>>>> webrev on cr.openjdk.java.net, or include it inline in
>>>> email (attachments tend to get stripped).
>>>>
>>>> Sorry for the inconvenience.
>>>>
>>>> David
>>>>
>>>> On 25/02/2016 5:50 AM, Gustavo Romero wrote:
>>>>
>>>>> Hi Martin,
>>>>>
>>>>> Both little and big endian Linux kernel contain the syscall change, so
>>>>> I did not include:
>>>>>
>>>>> #if defined(COMPILER2) && (defined(AIX) || defined(VM_LITTLE_ENDIAN)
>>>>>
>>>>> in globalDefinitions_ppc.hpp.
>>>>>
>>>>> Please, could you review the following change?
>>>>>
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8150353
>>>>> Webrev (hotspot): http://81.de.7a9f.ip4.static.sl-reverse.com/webrev/
>>>>>
>>>>> Summary:
>>>>>
>>>>> * Enable RTM support for Linux on PPC64 (LE and BE).
>>>>> * Fix C2 compiler buffer size issue.
>>>>>
>>>>> Thank you.
>>>>>
>>>>> Regards,
>>>>> Gustavo
>>>>>
>>>>>
>>>>
>>>
>
From varming at gmail.com Mon Mar 7 01:51:21 2016
From: varming at gmail.com (Carsten Varming)
Date: Sun, 6 Mar 2016 20:51:21 -0500
Subject: RFR 8150013: ParNew: Prune nmethods scavengable list
In-Reply-To: <56D9D98A.8050407@oracle.com>
References:
<56D8CCBE.4040900@oracle.com>
<56D9D98A.8050407@oracle.com>
Message-ID:
Dear Jon,
Thank you for sponsoring.
I am not sure about your intended change to the patch. If fix_relocations,
then there are two cases where I remove the nmethod from the scavengable
list: 1. If the nmethod is not live. 2. If the nmethod is live and it does
not have scavengable roots. With your suggested code change I don't think I
can cover both cases without code duplication. So I think it is best to
leave the logic as is.
Regarding you proposed comment about the precision of
detect_scavenge_root_oops.
// Unless the relocations have been updated (fixed), the
// detect_scavenge_root_oops() will not be precise so skip
// the check to unlink. Note that not doing the unlinking
// is safe but less optimal.
I don't know what you mean when you say "detect_scavenge_root_oops() will
not be precise". The method fix_relocations() in every closure that might
move an object returns true (I carefully checked all collectors except G1
(which does not use the list)), so there should never be a time where an
nmethod is left in a state where detect_scavenge_root_oops is wrong. You
are right that non-scavengable nmethods on the list is fine, but I disagree
about it being less than optimal (see next comment).
The reason I chose to not prune nmethods when !fix_relocations is that I
don't expect to be able to prune any live nmethods. To prune a live nmethod
from the list all oops in the nmethod must be non-scavengable
(oops::is_scavengable() must return false). In all collectors today,
fix_relocations is true if an object might be moved. Hence the only time
the list might contain a non-scavengable nmethod is between line 663 and
668 in my patch and between an oop moved by a full collection and the prune
method called at the end of said collection. As every live nmethod on the
list is expected to be scavengable (with the exceptions already listed)
pruning the list when objects have not moved seems like a waste. What about
dead nmethods? I don't think pruning dead nmethods really makes a
difference, but I would be happy to change the code to prune them
regardless of the value of fix_relocations.
I added the following comment
// The scavengable nmethod list must contain all methods with
scavengable // oops. It is safe to include more nmethod on the
list, but we do not // expect any live non-scavengable nmethods on
the list.
I hope that covers your intention.
I updated the webrev at
http://cr.openjdk.java.net/~cvarming/scavenge_nmethods_auto_prune/2/ with
the comment.
Carsten
On Fri, Mar 4, 2016 at 1:52 PM, Jon Masamitsu
wrote:
> Carsten,
>
> There will be a couple of days delay in pushing this
> change. The runtime repository is closed at the
> moment but hopefully will be open again in a day
> or two.
>
> Jon
>
>
> On 03/04/2016 10:23 AM, Carsten Varming wrote:
>
> Dear Christian,
>
> Thank you for your review.
>
> Carsten
>
> On Fri, Mar 4, 2016 at 12:50 PM, Christian Thalinger <
> christian.thalinger at oracle.com> wrote:
>
>> Jon asked me to have a quick look over the code cache changes. Looks
>> good to me.
>>
>> > On Mar 3, 2016, at 1:46 PM, Jon Masamitsu <
>> jon.masamitsu at oracle.com> wrote:
>> >
>> > Carsten,
>> >
>> > Changes look good.
>> >
>> > A couple of suggestions.
>> >
>> >
>> http://cr.openjdk.java.net/~cvarming/scavenge_nmethods_auto_prune/2/src/share/vm/code/codeCache.cpp.frames.html
>> >
>> > 661 if (is_live) {
>> > 662 // Perform cur->oops_do(f), maybe just once per nmethod.
>> > 663 f->do_code_blob(cur);
>> > 664 }
>> > 665 nmethod* const next = cur->scavenge_root_link();
>> > 666 if (fix_relocations) {
>> > 667 if (!is_live || !cur->detect_scavenge_root_oops()) {
>> > 668 unlink_scavenge_root_nmethod(cur, prev);
>> > 669 } else {
>> > 670 prev = cur;
>> > 671 }
>> > 672 }
>> > 673 cur = next;
>> >
>> > Although this does not change the actions, I find this easier to
>> > read. You and Tony (and whoever else wants to) can vote
>> > on it.
>> >
>> > if (is_live) { ... } else {
>> > if (fix_relocations) { if (cur->detect_scavenge_root_oops()) { prev =
>> cur; } else { unlink_scavenge_root_nmethod(cur, prev);} } cur =
>> cur->scavenge_root_link(); }
>> >
>> > Also I'd suggest a comment before the if-test
>> > if you find it correct.
>> >
>> > // Unless the relocations have been updated (fixed), the //
>> detect_scavenge_root_oops() will not be precise so skip // the check to
>> unlink. Note that not doing the unlinking // is safe but less optimal. if
>> (fix_relocations) {
>> >
>> > The comment in the header file for fix_relocations helped
>> > but a comment here might be helpful.
>> >
>> > I'll sponsor.
>> >
>> > Jon
>> >
>> > On 2/28/2016 6:16 PM, Carsten Varming wrote:
>> >> Dear Hotspot developers,
>> >>
>> >> Any chance of a review of this patch? The patch cut between 7ms and
>> 10ms of every ParNew with one application at Twitter and I expect a 1-2ms
>> improvement for most applications.
>> >>
>> >> I touch the code cache and GenCollectedHeap, so I assume I need
>> reviews from both gc and compiler reviewers. Thank you Tony Printezis for
>> the review (posted on the hotspot-gc-dev list).
>> >>
>> >> I also need a sponsor.
>> >>
>> >> Carsten
>> >>
>> >> On Fri, Feb 19, 2016 at 10:52 AM, Carsten Varming > > wrote:
>> >>
>> >> Dear Hotspot developers,
>> >>
>> >> I would like to contribute a patch for JDK-8150013
>> >> . The current
>> >> webrev can be found here:
>> >>
>> http://cr.openjdk.java.net/~cvarming/scavenge_nmethods_auto_prune/2/
>> >> <
>> http://cr.openjdk.java.net/%7Ecvarming/scavenge_nmethods_auto_prune/2/>.
>> >>
>> >> Suggestions for improvements are very welcome.
>> >>
>> >> Carsten
>> >>
>> >>
>> >
>>
>>
>
>
From yasuenag at gmail.com Mon Mar 7 03:38:30 2016
From: yasuenag at gmail.com (Yasumasa Suenaga)
Date: Mon, 7 Mar 2016 12:38:30 +0900
Subject: RFR: 8151351: HotSpot build process should regard
--with-native-debug-symbols.
Message-ID: <56DCF7B6.7000404@gmail.com>
Hi all,
When I build fastdebug JDK (--enable-debug) with --with-native-debug-symbols=internal,
build process generated *.debuginfo for libjsig and libjvm.
I think that build process should regard --with-native-debug-symbols.
I've uploaded webrev. Could you review it?
http://cr.openjdk.java.net/~ysuenaga/JDK-8151351/webrev.00/
I cannot access JPRT. So I need a sponsor.
Thanks,
Yasumasa
From david.holmes at oracle.com Mon Mar 7 07:57:33 2016
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 7 Mar 2016 17:57:33 +1000
Subject: RFR: 8151351: HotSpot build process should regard
--with-native-debug-symbols.
In-Reply-To: <56DCF7B6.7000404@gmail.com>
References: <56DCF7B6.7000404@gmail.com>
Message-ID: <56DD346D.5010200@oracle.com>
Hi Yasumasa,
On 7/03/2016 1:38 PM, Yasumasa Suenaga wrote:
> Hi all,
>
> When I build fastdebug JDK (--enable-debug) with --with-native-debug-symbols=internal,
> build process generated *.debuginfo for libjsig and libjvm.
> I think that build process should regard --with-native-debug-symbols.
As I wrote in the bug report we are getting very close to the switch
over to the new hotspot build and I'm assuming/hoping this is already
addressed there. We are avoiding non-urgent changes to the hotspot build
in the meantime to ease the change over.
Thanks,
David
> I've uploaded webrev. Could you review it?
> http://cr.openjdk.java.net/~ysuenaga/JDK-8151351/webrev.00/
>
> I cannot access JPRT. So I need a sponsor.
>
>
> Thanks,
>
> Yasumasa
>
From yasuenag at gmail.com Mon Mar 7 09:34:44 2016
From: yasuenag at gmail.com (Yasumasa Suenaga)
Date: Mon, 7 Mar 2016 18:34:44 +0900
Subject: RFR: 8151351: HotSpot build process should regard
--with-native-debug-symbols.
In-Reply-To: <56DD346D.5010200@oracle.com>
References: <56DCF7B6.7000404@gmail.com>
<56DD346D.5010200@oracle.com>
Message-ID:
Hi David,
Does "new hotspot build" mean JEP 284?
If it so and this issue does not occur on JEP 284, I will close this issue.
Thanks,
Yasumasa
2016/03/07 16:57 "David Holmes" :
> Hi Yasumasa,
>
> On 7/03/2016 1:38 PM, Yasumasa Suenaga wrote:
> > Hi all,
> >
> > When I build fastdebug JDK (--enable-debug) with
> --with-native-debug-symbols=internal,
> > build process generated *.debuginfo for libjsig and libjvm.
> > I think that build process should regard --with-native-debug-symbols.
>
> As I wrote in the bug report we are getting very close to the switch
> over to the new hotspot build and I'm assuming/hoping this is already
> addressed there. We are avoiding non-urgent changes to the hotspot build
> in the meantime to ease the change over.
>
> Thanks,
> David
>
> > I've uploaded webrev. Could you review it?
> > http://cr.openjdk.java.net/~ysuenaga/JDK-8151351/webrev.00/
> >
> > I cannot access JPRT. So I need a sponsor.
> >
> >
> > Thanks,
> >
> > Yasumasa
> >
>
From erik.joelsson at oracle.com Mon Mar 7 09:54:33 2016
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Mon, 7 Mar 2016 10:54:33 +0100
Subject: RFR: 8151351: HotSpot build process should regard
--with-native-debug-symbols.
In-Reply-To:
References: <56DCF7B6.7000404@gmail.com> <56DD346D.5010200@oracle.com>
Message-ID: <56DD4FD9.1090600@oracle.com>
Hello Yasumasa,
Yes, it is indeed JEP 284 and I have verified that the new build there
works as expected with the "internal" setting.
If you like, you can take it for a spin yourself by cloning
http://hg.openjdk.java.net/build-infra/jdk9. It should be in a pretty
good shape right now on Linux.
/Erik
On 2016-03-07 10:34, Yasumasa Suenaga wrote:
> Hi David,
>
> Does "new hotspot build" mean JEP 284?
> If it so and this issue does not occur on JEP 284, I will close this issue.
>
> Thanks,
>
> Yasumasa
> 2016/03/07 16:57 "David Holmes" :
>
>> Hi Yasumasa,
>>
>> On 7/03/2016 1:38 PM, Yasumasa Suenaga wrote:
>>> Hi all,
>>>
>>> When I build fastdebug JDK (--enable-debug) with
>> --with-native-debug-symbols=internal,
>>> build process generated *.debuginfo for libjsig and libjvm.
>>> I think that build process should regard --with-native-debug-symbols.
>> As I wrote in the bug report we are getting very close to the switch
>> over to the new hotspot build and I'm assuming/hoping this is already
>> addressed there. We are avoiding non-urgent changes to the hotspot build
>> in the meantime to ease the change over.
>>
>> Thanks,
>> David
>>
>>> I've uploaded webrev. Could you review it?
>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8151351/webrev.00/
>>>
>>> I cannot access JPRT. So I need a sponsor.
>>>
>>>
>>> Thanks,
>>>
>>> Yasumasa
>>>
From martin.doerr at sap.com Mon Mar 7 10:29:13 2016
From: martin.doerr at sap.com (Doerr, Martin)
Date: Mon, 7 Mar 2016 10:29:13 +0000
Subject: RFR(M) 8150353: PPC64LE: Support RTM on linux
In-Reply-To: <56CFB72C.7030401@oracle.com>
References: <56CE0975.8060807@linux.vnet.ibm.com> <56CE42AE.7080605@oracle.com>
<10c9a1cb6d9b40618a094283ac838038@DEWDFE13DE14.global.corp.sap>
<56CFB72C.7030401@oracle.com>
Message-ID:
Hi Vladimir,
thank you very much for the detailed analysis.
I hope an #ifdef PPC64 is ok in the shared code?
I had written something to Gustavo about the performance problem we have with RTM in SPEC jbb2005:
> The following issue is important for performance work:
> RTM does not work with BiasedLocking. The latter gets switched off if RTM is activated which has a large performance impact (especially in jbb2005).
> I would disable it for a reference measurement:
> -XX:-UseBiasedLocking
>
> Unfortunately, RTM was slower than BiasedLocking but faster than the reference (without both) which tells me that there's room for improvement.
> There are basically 3 classes of locks:
> 1. no contention
> 2. contention on lock, low contention on data
> 3. high contention on data
>
> I believe the optimal treatment for the cases would be:
> 1. Biased Locking
> 2. Transactional Memory
> 3. classical locking with lock inflating
>
> I think it would be good if the JVM could optimize for all these cases in the future. But that would add additional complexity and code size.
Do you think this is something which should be improved in the future?
We could try e.g. the following approach
- try biased
- deoptimize if it doesn't work well, try transactional
- deoptimize if it doesn't work well, use classical locking (with inflating)
Best regards,
Martin
-----Original Message-----
From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com]
Sent: Freitag, 26. Februar 2016 03:24
To: Doerr, Martin ; Gustavo Romero ; hotspot-dev at openjdk.java.net
Cc: brenohl at br.ibm.com
Subject: Re: RFR(M) 8150353: PPC64LE: Support RTM on linux
The problem with increasing ScratchBufferBlob size is that with Tiered
compilation we scale number of compiler threads based on cpu count and
increase space in CodeCache accordingly:
code_buffers_size += c2_count * C2Compiler::initial_code_buffer_size();
I did experiment on Intel setting ON all RTM flags which can increase
size of lock code:
$ java -XX:+UnlockExperimentalVMOptions -XX:+UnlockDiagnosticVMOptions
-XX:+UseRTMLocking -XX:+UseRTMDeopt -XX:+UseRTMForStackLocks
-XX:+PrintPreciseRTMLockingStatistics -XX:+PrintFlagsFinal -version
|grep RTM
Java HotSpot(TM) 64-Bit Server VM warning: UseRTMLocking is only
available as experimental option on this platform.
bool PrintPreciseRTMLockingStatistics := true
{C2 diagnostic}
intx RTMAbortRatio = 50
{ARCH experimental}
intx RTMAbortThreshold = 1000
{ARCH experimental}
intx RTMLockingCalculationDelay = 0
{ARCH experimental}
intx RTMLockingThreshold = 10000
{ARCH experimental}
uintx RTMRetryCount = 5
{ARCH product}
intx RTMSpinLoopCount = 100
{ARCH experimental}
intx RTMTotalCountIncrRate = 64
{ARCH experimental}
bool UseRTMDeopt := true
{ARCH product}
bool UseRTMForStackLocks := true
{ARCH experimental}
bool UseRTMLocking := true
{ARCH product}
bool UseRTMXendForLockBusy = true
{ARCH experimental}
I added next lines to the end of Compile::scratch_emit_size() method:
if (n->is_Mach() && n->as_Mach()->ideal_Opcode() == Op_FastLock) {
tty->print_cr("======== FastLock size: %d ==========",
buf.total_content_size());
}
if (n->is_Mach() && n->as_Mach()->ideal_Opcode() == Op_FastUnlock) {
tty->print_cr("======== FastUnlock size: %d ==========",
buf.total_content_size());
}
and got:
======== FastLock size: 657 ==========
======== FastUnlock size: 175 ==========
Thanks,
Vladimir
On 2/25/16 3:43 AM, Doerr, Martin wrote:
> Hi Vladimir,
>
> thanks for taking a look.
>
> About version values:
> We are using a similar scheme for version checks on AIX where we know that the version values are less than 256.
> It makes comparisons much more convenient.
> But I agree that we should double-check if it is guaranteed for linux as well (and possibly add an assertion).
>
> About scratch buffer size:
> We only noticed that the scratch buffer was too small when we enable all RTM features:
> -XX:+UnlockExperimentalVMOptions -XX:+UseRTMLocking -XX:+UseRTMForStackLocks -XX:+UseRTMDeopt
> We have only tried on PPC64, but I wonder if the current size is sufficient for x86. I currently don't have access to a Skylake machine.
>
> I think adding 1024 bytes to the scratch buffer doesn't hurt.
> (It may also lead to larger CodeBuffers in output.cpp but I don't think this is problematic as long as the real content gets copied to nmethods.)
> Would you agree?
>
> Best regards,
> Martin
>
> -----Original Message-----
> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com]
> Sent: Donnerstag, 25. Februar 2016 00:54
> To: Gustavo Romero ; Doerr, Martin ; hotspot-dev at openjdk.java.net
> Cc: brenohl at br.ibm.com
> Subject: Re: RFR(M) 8150353: PPC64LE: Support RTM on linux
>
> My concern (but I am not export) is Linux version encoding. Is it true
> that each value in x.y.z is less then 256? Why not keep them as separate
> int values?
> I also thought we have OS versions in make files but we check only gcc
> version there.
>
> Do you have problem with ScratchBufferBlob only on PPC or on some other
> platforms too? May be we should make MAX_inst_size as platform specific
> value.
>
> Thanks,
> Vladimir
>
> On 2/24/16 11:50 AM, Gustavo Romero wrote:
>> Hi Martin,
>>
>> Both little and big endian Linux kernel contain the syscall change, so
>> I did not include:
>>
>> #if defined(COMPILER2) && (defined(AIX) || defined(VM_LITTLE_ENDIAN)
>>
>> in globalDefinitions_ppc.hpp.
>>
>> Please, could you review the following change?
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8150353
>> Webrev (hotspot): http://81.de.7a9f.ip4.static.sl-reverse.com/webrev/
>>
>> Summary:
>>
>> * Enable RTM support for Linux on PPC64 (LE and BE).
>> * Fix C2 compiler buffer size issue.
>>
>> Thank you.
>>
>> Regards,
>> Gustavo
>>
From yasuenag at gmail.com Mon Mar 7 14:29:12 2016
From: yasuenag at gmail.com (Yasumasa Suenaga)
Date: Mon, 7 Mar 2016 23:29:12 +0900
Subject: RFR: 8151351: HotSpot build process should regard
--with-native-debug-symbols.
In-Reply-To: <56DD4FD9.1090600@oracle.com>
References: <56DCF7B6.7000404@gmail.com> <56DD346D.5010200@oracle.com>
<56DD4FD9.1090600@oracle.com>
Message-ID: <56DD9038.6050106@gmail.com>
Hi Erik,
> If you like, you can take it for a spin yourself by cloning http://hg.openjdk.java.net/build-infra/jdk9. It should be in a pretty good shape right now on Linux.
Thanks! It looks good to me.
BTW, Does build-infra use hotspot/make/linux/makefiles/vm.make ?
vm.make have a bug in this issue yet.
However, build-infra seems to use make/common/NativeCompilation.gmk .
If so, I will close this issue.
(Will hotspot/make remove at JDK-8150601 ? )
Thanks,
Yasumasa
On 2016/03/07 18:54, Erik Joelsson wrote:
> Hello Yasumasa,
>
> Yes, it is indeed JEP 284 and I have verified that the new build there works as expected with the "internal" setting.
>
> If you like, you can take it for a spin yourself by cloning http://hg.openjdk.java.net/build-infra/jdk9. It should be in a pretty good shape right now on Linux.
>
> /Erik
>
> On 2016-03-07 10:34, Yasumasa Suenaga wrote:
>> Hi David,
>>
>> Does "new hotspot build" mean JEP 284?
>> If it so and this issue does not occur on JEP 284, I will close this issue.
>>
>> Thanks,
>>
>> Yasumasa
>> 2016/03/07 16:57 "David Holmes" :
>>
>>> Hi Yasumasa,
>>>
>>> On 7/03/2016 1:38 PM, Yasumasa Suenaga wrote:
>>>> Hi all,
>>>>
>>>> When I build fastdebug JDK (--enable-debug) with
>>> --with-native-debug-symbols=internal,
>>>> build process generated *.debuginfo for libjsig and libjvm.
>>>> I think that build process should regard --with-native-debug-symbols.
>>> As I wrote in the bug report we are getting very close to the switch
>>> over to the new hotspot build and I'm assuming/hoping this is already
>>> addressed there. We are avoiding non-urgent changes to the hotspot build
>>> in the meantime to ease the change over.
>>>
>>> Thanks,
>>> David
>>>
>>>> I've uploaded webrev. Could you review it?
>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8151351/webrev.00/
>>>>
>>>> I cannot access JPRT. So I need a sponsor.
>>>>
>>>>
>>>> Thanks,
>>>>
>>>> Yasumasa
>>>>
>
From erik.joelsson at oracle.com Mon Mar 7 14:36:48 2016
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Mon, 7 Mar 2016 15:36:48 +0100
Subject: RFR: 8151351: HotSpot build process should regard
--with-native-debug-symbols.
In-Reply-To: <56DD9038.6050106@gmail.com>
References: <56DCF7B6.7000404@gmail.com> <56DD346D.5010200@oracle.com>
<56DD4FD9.1090600@oracle.com> <56DD9038.6050106@gmail.com>
Message-ID: <56DD9200.7080008@oracle.com>
Hello Yasumasa,
In build-infra, we still have the old Hotspot build present for
reference in hotspot/make. The new build currently resides in
hotspot/makefiles. Basically no files in hotspot/make are used by the
new build. After we switch in JDK 9, we will have both build systems
available for a short while (1-2 weeks if we don't see any major
trouble) before we remove the old and move the new build into hotspot/make.
To be clear, we do not use vm.make.
/Erik
On 2016-03-07 15:29, Yasumasa Suenaga wrote:
> Hi Erik,
>
>> If you like, you can take it for a spin yourself by cloning
>> http://hg.openjdk.java.net/build-infra/jdk9. It should be in a pretty
>> good shape right now on Linux.
>
> Thanks! It looks good to me.
>
> BTW, Does build-infra use hotspot/make/linux/makefiles/vm.make ?
> vm.make have a bug in this issue yet.
> However, build-infra seems to use make/common/NativeCompilation.gmk .
> If so, I will close this issue.
> (Will hotspot/make remove at JDK-8150601 ? )
>
>
> Thanks,
>
> Yasumasa
>
>
> On 2016/03/07 18:54, Erik Joelsson wrote:
>> Hello Yasumasa,
>>
>> Yes, it is indeed JEP 284 and I have verified that the new build
>> there works as expected with the "internal" setting.
>>
>> If you like, you can take it for a spin yourself by cloning
>> http://hg.openjdk.java.net/build-infra/jdk9. It should be in a pretty
>> good shape right now on Linux.
>>
>> /Erik
>>
>> On 2016-03-07 10:34, Yasumasa Suenaga wrote:
>>> Hi David,
>>>
>>> Does "new hotspot build" mean JEP 284?
>>> If it so and this issue does not occur on JEP 284, I will close this
>>> issue.
>>>
>>> Thanks,
>>>
>>> Yasumasa
>>> 2016/03/07 16:57 "David Holmes" :
>>>
>>>> Hi Yasumasa,
>>>>
>>>> On 7/03/2016 1:38 PM, Yasumasa Suenaga wrote:
>>>>> Hi all,
>>>>>
>>>>> When I build fastdebug JDK (--enable-debug) with
>>>> --with-native-debug-symbols=internal,
>>>>> build process generated *.debuginfo for libjsig and libjvm.
>>>>> I think that build process should regard --with-native-debug-symbols.
>>>> As I wrote in the bug report we are getting very close to the switch
>>>> over to the new hotspot build and I'm assuming/hoping this is already
>>>> addressed there. We are avoiding non-urgent changes to the hotspot
>>>> build
>>>> in the meantime to ease the change over.
>>>>
>>>> Thanks,
>>>> David
>>>>
>>>>> I've uploaded webrev. Could you review it?
>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8151351/webrev.00/
>>>>>
>>>>> I cannot access JPRT. So I need a sponsor.
>>>>>
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Yasumasa
>>>>>
>>
From yasuenag at gmail.com Mon Mar 7 14:49:59 2016
From: yasuenag at gmail.com (Yasumasa Suenaga)
Date: Mon, 7 Mar 2016 23:49:59 +0900
Subject: RFR: 8151351: HotSpot build process should regard
--with-native-debug-symbols.
In-Reply-To: <56DD9200.7080008@oracle.com>
References: <56DCF7B6.7000404@gmail.com> <56DD346D.5010200@oracle.com>
<56DD4FD9.1090600@oracle.com> <56DD9038.6050106@gmail.com>
<56DD9200.7080008@oracle.com>
Message-ID: <56DD9517.6050206@gmail.com>
Thanks Erik, I understood.
I closed this issue with Won't Fix.
Yasumasa
On 2016/03/07 23:36, Erik Joelsson wrote:
> Hello Yasumasa,
>
> In build-infra, we still have the old Hotspot build present for reference in hotspot/make. The new build currently resides in hotspot/makefiles. Basically no files in hotspot/make are used by the new build. After we switch in JDK 9, we will have both build systems available for a short while (1-2 weeks if we don't see any major trouble) before we remove the old and move the new build into hotspot/make.
>
> To be clear, we do not use vm.make.
>
> /Erik
>
> On 2016-03-07 15:29, Yasumasa Suenaga wrote:
>> Hi Erik,
>>
>>> If you like, you can take it for a spin yourself by cloning http://hg.openjdk.java.net/build-infra/jdk9. It should be in a pretty good shape right now on Linux.
>>
>> Thanks! It looks good to me.
>>
>> BTW, Does build-infra use hotspot/make/linux/makefiles/vm.make ?
>> vm.make have a bug in this issue yet.
>> However, build-infra seems to use make/common/NativeCompilation.gmk .
>> If so, I will close this issue.
>> (Will hotspot/make remove at JDK-8150601 ? )
>>
>>
>> Thanks,
>>
>> Yasumasa
>>
>>
>> On 2016/03/07 18:54, Erik Joelsson wrote:
>>> Hello Yasumasa,
>>>
>>> Yes, it is indeed JEP 284 and I have verified that the new build there works as expected with the "internal" setting.
>>>
>>> If you like, you can take it for a spin yourself by cloning http://hg.openjdk.java.net/build-infra/jdk9. It should be in a pretty good shape right now on Linux.
>>>
>>> /Erik
>>>
>>> On 2016-03-07 10:34, Yasumasa Suenaga wrote:
>>>> Hi David,
>>>>
>>>> Does "new hotspot build" mean JEP 284?
>>>> If it so and this issue does not occur on JEP 284, I will close this issue.
>>>>
>>>> Thanks,
>>>>
>>>> Yasumasa
>>>> 2016/03/07 16:57 "David Holmes" :
>>>>
>>>>> Hi Yasumasa,
>>>>>
>>>>> On 7/03/2016 1:38 PM, Yasumasa Suenaga wrote:
>>>>>> Hi all,
>>>>>>
>>>>>> When I build fastdebug JDK (--enable-debug) with
>>>>> --with-native-debug-symbols=internal,
>>>>>> build process generated *.debuginfo for libjsig and libjvm.
>>>>>> I think that build process should regard --with-native-debug-symbols.
>>>>> As I wrote in the bug report we are getting very close to the switch
>>>>> over to the new hotspot build and I'm assuming/hoping this is already
>>>>> addressed there. We are avoiding non-urgent changes to the hotspot build
>>>>> in the meantime to ease the change over.
>>>>>
>>>>> Thanks,
>>>>> David
>>>>>
>>>>>> I've uploaded webrev. Could you review it?
>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8151351/webrev.00/
>>>>>>
>>>>>> I cannot access JPRT. So I need a sponsor.
>>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Yasumasa
>>>>>>
>>>
>
From gromero at linux.vnet.ibm.com Mon Mar 7 15:27:11 2016
From: gromero at linux.vnet.ibm.com (Gustavo Romero)
Date: Mon, 7 Mar 2016 12:27:11 -0300
Subject: RFR(M) 8150353: PPC64LE: Support RTM on linux
In-Reply-To:
References: <56CE0975.8060807@linux.vnet.ibm.com>
<56CEB349.1050102@oracle.com> <56CEB73D.8030904@linux.vnet.ibm.com>
<56CEB982.5030706@oracle.com>
<56DCAEB7.8010003@linux.vnet.ibm.com>
Message-ID: <56DD9DCF.8090703@linux.vnet.ibm.com>
Hi Martin
Sure, AIX is now included as well.
Could you please host and review this updated version?
Webrev:
http://81.de.7a9f.ip4.static.sl-reverse.com./8150353/webrev_v3.zip
src/cpu/ppc/vm/globalDefinitions_ppc.hpp:
I merged the defines as Thomas suggested.
src/cpu/ppc/vm/vm_version_ppc.cpp:
Thomas, sorry for the cryptic comment about the kernel change. It refers
to Linux kernel source tree and not to OpenJDK. I've improved the
comment to reflect it.
Regarding MAX_inst_size:
I assumed that the ScratchBufferBlob issue is present only on PPC64
and, as Vladmir and Martin suggested, I made MAX_inst_size a platform
specific value (changed only for PPC64 - AIX and Linux). Vladimir,
thanks for doing additional analysis on x64 architecture.
Regarding Linux version encoding:
Keeping the values x.y.z together the same form it was done on AIX is
more convenient, as Martin said, and besides that it's the way Linux
kernel itself handles the Linux kernel versions. Hence it defines
macro KERNEL_VERSION used whenever kernel version check/comparison is
necessary and it does exactly what we are doing for AIX and Linux on
PPC64:
#define KERNEL_VERSION(a,b,c) (((a) << 16) + ((b) << 8) + (c))
So I think it's not a problem to assume true that each value in x.y.z
is always less then 256 and also never something like 3.2 (x.y). To the
best of my knowledge there is no rigid standard for that but by looking
at mainline kernel versions we can trust this format too. However, as
any distro can change it at will (although very unlikely), making it
more robust in the sense Thomas and Martin commented is a good idea. I
did it and checked if the kernel version format is what we expect
(x.y.z format) and for x, y, and z less then 256.
Thomas, in case of a version is unknown I decided for bailing out
instead of just letting the VM continue with RTM disabled since it's the
behavior, for instance, when the CPU doesn't support Transactional
Memory and other similar conditions in the code around. But as method
os_version_is_known() exists (instead of assert()'s in os_linux.cpp),
it's possible to change this behavior easily in vm_version_ppc.cpp.
Regarding Hotspot jtreg tests:
No regression was observed. More 16 tests are passing now on Linux
(PP64 LE):
Passed: compiler/rtm/cli/TestPrintPreciseRTMLockingStatisticsOptionOnSupportedConfig.java
Passed: compiler/rtm/cli/TestRTMAbortRatioOptionOnSupportedConfig.java
Passed: compiler/rtm/cli/TestRTMTotalCountIncrRateOptionOnSupportedConfig.java
Passed: compiler/rtm/cli/TestUseRTMDeoptOptionOnSupportedConfig.java
Passed: compiler/rtm/cli/TestUseRTMForStackLocksOptionOnSupportedConfig.java
Passed: compiler/rtm/cli/TestUseRTMLockingOptionOnSupportedConfig.java
Passed: compiler/rtm/cli/TestUseRTMLockingOptionWithBiasedLocking.java
Passed: compiler/rtm/locking/TestRTMAbortRatio.java
Passed: compiler/rtm/locking/TestRTMAfterNonRTMDeopt.java
Passed: compiler/rtm/locking/TestRTMTotalCountIncrRate.java
Passed: compiler/rtm/locking/TestUseRTMDeopt.java
Passed: compiler/rtm/locking/TestUseRTMForInflatedLocks.java
Passed: compiler/rtm/locking/TestUseRTMForStackLocks.java
Passed: compiler/rtm/method_options/TestNoRTMLockElidingOption.java
Passed: compiler/rtm/method_options/TestUseRTMLockElidingOption.java
Passed: gc/ergonomics/TestDynamicNumberOfGCThreads.java
Kind regards,
Gustavo
On 07-03-2016 07:17, Doerr, Martin wrote:
> Hi Gustavo,
>
> I?m back from vacation and I can host the webrev. Thanks for doing this change. It?s quite some work to get it into openjdk.
>
> May I ask you to increase the scratch buffer size for AIX as well (e.g. make it only dependent on PPC64, not on the OS in compile.hpp)?
> We have the same problem there and we should try to make only one shared code change. We will have to ask someone from Oracle to push it (e.g. Vladimir Kozlov).
>
> Best regards,
> Martin
>
> From: Thomas St?fe [mailto:thomas.stuefe at gmail.com]
> Sent: Montag, 7. M?rz 2016 07:48
> To: Doerr, Martin
> Subject: Fwd: Re: RFR(M) 8150353: PPC64LE: Support RTM on linux
>
>
> Hi Martin, kannst Du ?bernehmen? Bin erst morgen wieder da.
>
> Gru? Thomas
> ---------- Forwarded message ----------
> From: "Gustavo Romero" >
> Date: Mar 6, 2016 23:27
> Subject: Re: RFR(M) 8150353: PPC64LE: Support RTM on linux
> To: "Thomas St?fe" >
> Cc: "Doerr, Martin" >, "hotspot-dev at openjdk.java.net" >, >
>
> Hi Thomas
>
> Thanks for offering the hosting. :-)
>
> Thomas, could you please host this updated version that incorporates the
> comments made by you, Martin, and Vladimir (Martin also kindly offered
> the hosting but probably is yet out of office - but I'm not sure).
>
> Webrev updated version:
> http://81.de.7a9f.ip4.static.sl-reverse.com./8150353/webrev.zip
>
> Thanks a lot.
>
> Best regards,
> Gustavo
>
> On 25-02-2016 07:57, Thomas St?fe wrote:
>> Hi Gustavo,
>>
>> I can host this for you, if you have no access to cr.openjdk.java.net. Just
>> send me the patch file.
>>
>> About your change:
>>
>> src/cpu/ppc/vm/globalDefinitions_ppc.hpp
>>
>> small nit: Could be probably be merged with the paragraph above where we do
>> the same thing for AIX, but I do not have strong emotions.
>>
>>
>> src/cpu/ppc/vm/vm_version_ppc.cpp
>>
>> + // Please, refer to commit 4b4fadba057c1af7689fc8fa182b13baL7
>> Does this refer to an OpenJDK change? If yes, could you please instead
>> mention the OpenJDK bug number instead?
>>
>>
>> src/os/linux/vm/os_linux.cpp
>>
>> os::Linux::initialize_os_info()
>>
>> Please make this code more robust:
>> - Check the return value of sscanf (must be 3, otherwise your assumption
>> about the version format was wrong)
>> - Could this happen: "3.2" ? If yes, could you please handle it too?
>> - Please handle overflow - if any one of minor/fix is > 256, something
>> sensible should happen (for major, this probably indicates an error).
>> Possibly cap out at 256?
>>
>> If version cannot be read successfully, the VM should not abort imho but
>> behave gracefully. Worst that should happen is that RTM gets deactivated.
>>
>>
>> Kind Regards, Thomas
>>
>>
>> On Thu, Feb 25, 2016 at 9:21 AM, David Holmes >
>> wrote:
>>
>>> On 25/02/2016 6:11 PM, Gustavo Romero wrote:
>>>
>>>> Hi David,
>>>>
>>>> OK, I'll fix that.
>>>>
>>>> Should I re-send the RFR with the right URL and abandon this one?
>>>>
>>>
>>> I think you can just post the new URL to this one.
>>>
>>> In case a contribution is not so small, even so is it fine to include it
>>>> inline?
>>>>
>>>
>>> Well it's preferable, for larger contributions, to find someone to host
>>> the webrev for you.
>>>
>>> Cheers,
>>> David
>>>
>>>
>>> Thank you.
>>>>
>>>> Regards,
>>>> Gustavo
>>>>
>>>> On 25-02-2016 04:54, David Holmes wrote:
>>>>
>>>>> Hi Gustavo,
>>>>>
>>>>> Just a point of order. All contributions to the OpenJDK must be made
>>>>> through OpenJDK infrastructure. So you must either get someone to host your
>>>>> webrev on cr.openjdk.java.net, or include it inline in
>>>>> email (attachments tend to get stripped).
>>>>>
>>>>> Sorry for the inconvenience.
>>>>>
>>>>> David
>>>>>
>>>>> On 25/02/2016 5:50 AM, Gustavo Romero wrote:
>>>>>
>>>>>> Hi Martin,
>>>>>>
>>>>>> Both little and big endian Linux kernel contain the syscall change, so
>>>>>> I did not include:
>>>>>>
>>>>>> #if defined(COMPILER2) && (defined(AIX) || defined(VM_LITTLE_ENDIAN)
>>>>>>
>>>>>> in globalDefinitions_ppc.hpp.
>>>>>>
>>>>>> Please, could you review the following change?
>>>>>>
>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8150353
>>>>>> Webrev (hotspot): http://81.de.7a9f.ip4.static.sl-reverse.com/webrev/
>>>>>>
>>>>>> Summary:
>>>>>>
>>>>>> * Enable RTM support for Linux on PPC64 (LE and BE).
>>>>>> * Fix C2 compiler buffer size issue.
>>>>>>
>>>>>> Thank you.
>>>>>>
>>>>>> Regards,
>>>>>> Gustavo
>>>>>>
>>>>>>
>>>>>
>>>>
>>
From martin.doerr at sap.com Mon Mar 7 16:00:33 2016
From: martin.doerr at sap.com (Doerr, Martin)
Date: Mon, 7 Mar 2016 16:00:33 +0000
Subject: RFR(M) 8150353: PPC64LE: Support RTM on linux
In-Reply-To: <56DD9DCF.8090703@linux.vnet.ibm.com>
References: <56CE0975.8060807@linux.vnet.ibm.com>
<56CEB349.1050102@oracle.com> <56CEB73D.8030904@linux.vnet.ibm.com>
<56CEB982.5030706@oracle.com>
<56DCAEB7.8010003@linux.vnet.ibm.com>
<56DD9DCF.8090703@linux.vnet.ibm.com>
Message-ID: <4866933cb0424052a3eec45b38a6ee45@DEWDFE13DE14.global.corp.sap>
Hi,
looks good. Thanks for making the requested changes.
The change modifies os_linux and shared C2 code.
Can somebody from Oracle review and sponsor, please?
The webrev is here:
http://cr.openjdk.java.net/~mdoerr/8150353_RTM_linux_ppc64/webrev.00/
It was tested in jdk9/dev/hotspot, but it applies to jdk9/hs-comp/hotspot as well.
Best regards,
Martin
-----Original Message-----
From: Gustavo Romero [mailto:gromero at linux.vnet.ibm.com]
Sent: Montag, 7. M?rz 2016 16:27
To: Doerr, Martin ; Vladimir Kozlov ; Thomas St?fe
Cc: hotspot-dev at openjdk.java.net; Breno Leitao
Subject: Re: RFR(M) 8150353: PPC64LE: Support RTM on linux
Hi Martin
Sure, AIX is now included as well.
Could you please host and review this updated version?
Webrev:
http://81.de.7a9f.ip4.static.sl-reverse.com./8150353/webrev_v3.zip
src/cpu/ppc/vm/globalDefinitions_ppc.hpp:
I merged the defines as Thomas suggested.
src/cpu/ppc/vm/vm_version_ppc.cpp:
Thomas, sorry for the cryptic comment about the kernel change. It refers
to Linux kernel source tree and not to OpenJDK. I've improved the
comment to reflect it.
Regarding MAX_inst_size:
I assumed that the ScratchBufferBlob issue is present only on PPC64
and, as Vladmir and Martin suggested, I made MAX_inst_size a platform
specific value (changed only for PPC64 - AIX and Linux). Vladimir,
thanks for doing additional analysis on x64 architecture.
Regarding Linux version encoding:
Keeping the values x.y.z together the same form it was done on AIX is
more convenient, as Martin said, and besides that it's the way Linux
kernel itself handles the Linux kernel versions. Hence it defines
macro KERNEL_VERSION used whenever kernel version check/comparison is
necessary and it does exactly what we are doing for AIX and Linux on
PPC64:
#define KERNEL_VERSION(a,b,c) (((a) << 16) + ((b) << 8) + (c))
So I think it's not a problem to assume true that each value in x.y.z
is always less then 256 and also never something like 3.2 (x.y). To the
best of my knowledge there is no rigid standard for that but by looking
at mainline kernel versions we can trust this format too. However, as
any distro can change it at will (although very unlikely), making it
more robust in the sense Thomas and Martin commented is a good idea. I
did it and checked if the kernel version format is what we expect
(x.y.z format) and for x, y, and z less then 256.
Thomas, in case of a version is unknown I decided for bailing out
instead of just letting the VM continue with RTM disabled since it's the
behavior, for instance, when the CPU doesn't support Transactional
Memory and other similar conditions in the code around. But as method
os_version_is_known() exists (instead of assert()'s in os_linux.cpp),
it's possible to change this behavior easily in vm_version_ppc.cpp.
Regarding Hotspot jtreg tests:
No regression was observed. More 16 tests are passing now on Linux
(PP64 LE):
Passed: compiler/rtm/cli/TestPrintPreciseRTMLockingStatisticsOptionOnSupportedConfig.java
Passed: compiler/rtm/cli/TestRTMAbortRatioOptionOnSupportedConfig.java
Passed: compiler/rtm/cli/TestRTMTotalCountIncrRateOptionOnSupportedConfig.java
Passed: compiler/rtm/cli/TestUseRTMDeoptOptionOnSupportedConfig.java
Passed: compiler/rtm/cli/TestUseRTMForStackLocksOptionOnSupportedConfig.java
Passed: compiler/rtm/cli/TestUseRTMLockingOptionOnSupportedConfig.java
Passed: compiler/rtm/cli/TestUseRTMLockingOptionWithBiasedLocking.java
Passed: compiler/rtm/locking/TestRTMAbortRatio.java
Passed: compiler/rtm/locking/TestRTMAfterNonRTMDeopt.java
Passed: compiler/rtm/locking/TestRTMTotalCountIncrRate.java
Passed: compiler/rtm/locking/TestUseRTMDeopt.java
Passed: compiler/rtm/locking/TestUseRTMForInflatedLocks.java
Passed: compiler/rtm/locking/TestUseRTMForStackLocks.java
Passed: compiler/rtm/method_options/TestNoRTMLockElidingOption.java
Passed: compiler/rtm/method_options/TestUseRTMLockElidingOption.java
Passed: gc/ergonomics/TestDynamicNumberOfGCThreads.java
Kind regards,
Gustavo
On 07-03-2016 07:17, Doerr, Martin wrote:
> Hi Gustavo,
>
> I?m back from vacation and I can host the webrev. Thanks for doing this change. It?s quite some work to get it into openjdk.
>
> May I ask you to increase the scratch buffer size for AIX as well (e.g. make it only dependent on PPC64, not on the OS in compile.hpp)?
> We have the same problem there and we should try to make only one shared code change. We will have to ask someone from Oracle to push it (e.g. Vladimir Kozlov).
>
> Best regards,
> Martin
>
> From: Thomas St?fe [mailto:thomas.stuefe at gmail.com]
> Sent: Montag, 7. M?rz 2016 07:48
> To: Doerr, Martin
> Subject: Fwd: Re: RFR(M) 8150353: PPC64LE: Support RTM on linux
>
>
> Hi Martin, kannst Du ?bernehmen? Bin erst morgen wieder da.
>
> Gru? Thomas
> ---------- Forwarded message ----------
> From: "Gustavo Romero" >
> Date: Mar 6, 2016 23:27
> Subject: Re: RFR(M) 8150353: PPC64LE: Support RTM on linux
> To: "Thomas St?fe" >
> Cc: "Doerr, Martin" >, "hotspot-dev at openjdk.java.net" >, >
>
> Hi Thomas
>
> Thanks for offering the hosting. :-)
>
> Thomas, could you please host this updated version that incorporates the
> comments made by you, Martin, and Vladimir (Martin also kindly offered
> the hosting but probably is yet out of office - but I'm not sure).
>
> Webrev updated version:
> http://81.de.7a9f.ip4.static.sl-reverse.com./8150353/webrev.zip
>
> Thanks a lot.
>
> Best regards,
> Gustavo
>
> On 25-02-2016 07:57, Thomas St?fe wrote:
>> Hi Gustavo,
>>
>> I can host this for you, if you have no access to cr.openjdk.java.net. Just
>> send me the patch file.
>>
>> About your change:
>>
>> src/cpu/ppc/vm/globalDefinitions_ppc.hpp
>>
>> small nit: Could be probably be merged with the paragraph above where we do
>> the same thing for AIX, but I do not have strong emotions.
>>
>>
>> src/cpu/ppc/vm/vm_version_ppc.cpp
>>
>> + // Please, refer to commit 4b4fadba057c1af7689fc8fa182b13baL7
>> Does this refer to an OpenJDK change? If yes, could you please instead
>> mention the OpenJDK bug number instead?
>>
>>
>> src/os/linux/vm/os_linux.cpp
>>
>> os::Linux::initialize_os_info()
>>
>> Please make this code more robust:
>> - Check the return value of sscanf (must be 3, otherwise your assumption
>> about the version format was wrong)
>> - Could this happen: "3.2" ? If yes, could you please handle it too?
>> - Please handle overflow - if any one of minor/fix is > 256, something
>> sensible should happen (for major, this probably indicates an error).
>> Possibly cap out at 256?
>>
>> If version cannot be read successfully, the VM should not abort imho but
>> behave gracefully. Worst that should happen is that RTM gets deactivated.
>>
>>
>> Kind Regards, Thomas
>>
>>
>> On Thu, Feb 25, 2016 at 9:21 AM, David Holmes >
>> wrote:
>>
>>> On 25/02/2016 6:11 PM, Gustavo Romero wrote:
>>>
>>>> Hi David,
>>>>
>>>> OK, I'll fix that.
>>>>
>>>> Should I re-send the RFR with the right URL and abandon this one?
>>>>
>>>
>>> I think you can just post the new URL to this one.
>>>
>>> In case a contribution is not so small, even so is it fine to include it
>>>> inline?
>>>>
>>>
>>> Well it's preferable, for larger contributions, to find someone to host
>>> the webrev for you.
>>>
>>> Cheers,
>>> David
>>>
>>>
>>> Thank you.
>>>>
>>>> Regards,
>>>> Gustavo
>>>>
>>>> On 25-02-2016 04:54, David Holmes wrote:
>>>>
>>>>> Hi Gustavo,
>>>>>
>>>>> Just a point of order. All contributions to the OpenJDK must be made
>>>>> through OpenJDK infrastructure. So you must either get someone to host your
>>>>> webrev on cr.openjdk.java.net, or include it inline in
>>>>> email (attachments tend to get stripped).
>>>>>
>>>>> Sorry for the inconvenience.
>>>>>
>>>>> David
>>>>>
>>>>> On 25/02/2016 5:50 AM, Gustavo Romero wrote:
>>>>>
>>>>>> Hi Martin,
>>>>>>
>>>>>> Both little and big endian Linux kernel contain the syscall change, so
>>>>>> I did not include:
>>>>>>
>>>>>> #if defined(COMPILER2) && (defined(AIX) || defined(VM_LITTLE_ENDIAN)
>>>>>>
>>>>>> in globalDefinitions_ppc.hpp.
>>>>>>
>>>>>> Please, could you review the following change?
>>>>>>
>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8150353
>>>>>> Webrev (hotspot): http://81.de.7a9f.ip4.static.sl-reverse.com/webrev/
>>>>>>
>>>>>> Summary:
>>>>>>
>>>>>> * Enable RTM support for Linux on PPC64 (LE and BE).
>>>>>> * Fix C2 compiler buffer size issue.
>>>>>>
>>>>>> Thank you.
>>>>>>
>>>>>> Regards,
>>>>>> Gustavo
>>>>>>
>>>>>>
>>>>>
>>>>
>>
From gromero at linux.vnet.ibm.com Mon Mar 7 16:17:31 2016
From: gromero at linux.vnet.ibm.com (Gustavo Romero)
Date: Mon, 7 Mar 2016 13:17:31 -0300
Subject: RFR(M) 8150353: PPC64LE: Support RTM on linux
In-Reply-To: <4866933cb0424052a3eec45b38a6ee45@DEWDFE13DE14.global.corp.sap>
References: <56CE0975.8060807@linux.vnet.ibm.com>
<56CEB349.1050102@oracle.com> <56CEB73D.8030904@linux.vnet.ibm.com>
<56CEB982.5030706@oracle.com>
<56DCAEB7.8010003@linux.vnet.ibm.com>
<56DD9DCF.8090703@linux.vnet.ibm.com>
<4866933cb0424052a3eec45b38a6ee45@DEWDFE13DE14.global.corp.sap>
Message-ID: <56DDA99B.4010205@linux.vnet.ibm.com>
Thank you Martin for all the guidelines, comments and reviews.
Best regards,
Gustavo
On 07-03-2016 13:00, Doerr, Martin wrote:
> Hi,
>
> looks good. Thanks for making the requested changes.
>
> The change modifies os_linux and shared C2 code.
> Can somebody from Oracle review and sponsor, please?
>
> The webrev is here:
> http://cr.openjdk.java.net/~mdoerr/8150353_RTM_linux_ppc64/webrev.00/
>
> It was tested in jdk9/dev/hotspot, but it applies to jdk9/hs-comp/hotspot as well.
>
> Best regards,
> Martin
>
> -----Original Message-----
> From: Gustavo Romero [mailto:gromero at linux.vnet.ibm.com]
> Sent: Montag, 7. M?rz 2016 16:27
> To: Doerr, Martin ; Vladimir Kozlov ; Thomas St?fe
> Cc: hotspot-dev at openjdk.java.net; Breno Leitao
> Subject: Re: RFR(M) 8150353: PPC64LE: Support RTM on linux
>
> Hi Martin
>
> Sure, AIX is now included as well.
>
> Could you please host and review this updated version?
>
> Webrev:
> http://81.de.7a9f.ip4.static.sl-reverse.com./8150353/webrev_v3.zip
>
> src/cpu/ppc/vm/globalDefinitions_ppc.hpp:
>
> I merged the defines as Thomas suggested.
>
>
> src/cpu/ppc/vm/vm_version_ppc.cpp:
>
> Thomas, sorry for the cryptic comment about the kernel change. It refers
> to Linux kernel source tree and not to OpenJDK. I've improved the
> comment to reflect it.
>
>
> Regarding MAX_inst_size:
> I assumed that the ScratchBufferBlob issue is present only on PPC64
> and, as Vladmir and Martin suggested, I made MAX_inst_size a platform
> specific value (changed only for PPC64 - AIX and Linux). Vladimir,
> thanks for doing additional analysis on x64 architecture.
>
>
> Regarding Linux version encoding:
> Keeping the values x.y.z together the same form it was done on AIX is
> more convenient, as Martin said, and besides that it's the way Linux
> kernel itself handles the Linux kernel versions. Hence it defines
> macro KERNEL_VERSION used whenever kernel version check/comparison is
> necessary and it does exactly what we are doing for AIX and Linux on
> PPC64:
>
> #define KERNEL_VERSION(a,b,c) (((a) << 16) + ((b) << 8) + (c))
>
> So I think it's not a problem to assume true that each value in x.y.z
> is always less then 256 and also never something like 3.2 (x.y). To the
> best of my knowledge there is no rigid standard for that but by looking
> at mainline kernel versions we can trust this format too. However, as
> any distro can change it at will (although very unlikely), making it
> more robust in the sense Thomas and Martin commented is a good idea. I
> did it and checked if the kernel version format is what we expect
> (x.y.z format) and for x, y, and z less then 256.
>
> Thomas, in case of a version is unknown I decided for bailing out
> instead of just letting the VM continue with RTM disabled since it's the
> behavior, for instance, when the CPU doesn't support Transactional
> Memory and other similar conditions in the code around. But as method
> os_version_is_known() exists (instead of assert()'s in os_linux.cpp),
> it's possible to change this behavior easily in vm_version_ppc.cpp.
>
>
> Regarding Hotspot jtreg tests:
> No regression was observed. More 16 tests are passing now on Linux
> (PP64 LE):
>
> Passed: compiler/rtm/cli/TestPrintPreciseRTMLockingStatisticsOptionOnSupportedConfig.java
> Passed: compiler/rtm/cli/TestRTMAbortRatioOptionOnSupportedConfig.java
> Passed: compiler/rtm/cli/TestRTMTotalCountIncrRateOptionOnSupportedConfig.java
> Passed: compiler/rtm/cli/TestUseRTMDeoptOptionOnSupportedConfig.java
> Passed: compiler/rtm/cli/TestUseRTMForStackLocksOptionOnSupportedConfig.java
> Passed: compiler/rtm/cli/TestUseRTMLockingOptionOnSupportedConfig.java
> Passed: compiler/rtm/cli/TestUseRTMLockingOptionWithBiasedLocking.java
> Passed: compiler/rtm/locking/TestRTMAbortRatio.java
> Passed: compiler/rtm/locking/TestRTMAfterNonRTMDeopt.java
> Passed: compiler/rtm/locking/TestRTMTotalCountIncrRate.java
> Passed: compiler/rtm/locking/TestUseRTMDeopt.java
> Passed: compiler/rtm/locking/TestUseRTMForInflatedLocks.java
> Passed: compiler/rtm/locking/TestUseRTMForStackLocks.java
> Passed: compiler/rtm/method_options/TestNoRTMLockElidingOption.java
> Passed: compiler/rtm/method_options/TestUseRTMLockElidingOption.java
> Passed: gc/ergonomics/TestDynamicNumberOfGCThreads.java
>
>
> Kind regards,
> Gustavo
>
> On 07-03-2016 07:17, Doerr, Martin wrote:
>> Hi Gustavo,
>>
>> I?m back from vacation and I can host the webrev. Thanks for doing this change. It?s quite some work to get it into openjdk.
>>
>> May I ask you to increase the scratch buffer size for AIX as well (e.g. make it only dependent on PPC64, not on the OS in compile.hpp)?
>> We have the same problem there and we should try to make only one shared code change. We will have to ask someone from Oracle to push it (e.g. Vladimir Kozlov).
>>
>> Best regards,
>> Martin
>>
>> From: Thomas St?fe [mailto:thomas.stuefe at gmail.com]
>> Sent: Montag, 7. M?rz 2016 07:48
>> To: Doerr, Martin
>> Subject: Fwd: Re: RFR(M) 8150353: PPC64LE: Support RTM on linux
>>
>>
>> Hi Martin, kannst Du ?bernehmen? Bin erst morgen wieder da.
>>
>> Gru? Thomas
>> ---------- Forwarded message ----------
>> From: "Gustavo Romero" >
>> Date: Mar 6, 2016 23:27
>> Subject: Re: RFR(M) 8150353: PPC64LE: Support RTM on linux
>> To: "Thomas St?fe" >
>> Cc: "Doerr, Martin" >, "hotspot-dev at openjdk.java.net" >, >
>>
>> Hi Thomas
>>
>> Thanks for offering the hosting. :-)
>>
>> Thomas, could you please host this updated version that incorporates the
>> comments made by you, Martin, and Vladimir (Martin also kindly offered
>> the hosting but probably is yet out of office - but I'm not sure).
>>
>> Webrev updated version:
>> http://81.de.7a9f.ip4.static.sl-reverse.com./8150353/webrev.zip
>>
>> Thanks a lot.
>>
>> Best regards,
>> Gustavo
>>
>> On 25-02-2016 07:57, Thomas St?fe wrote:
>>> Hi Gustavo,
>>>
>>> I can host this for you, if you have no access to cr.openjdk.java.net. Just
>>> send me the patch file.
>>>
>>> About your change:
>>>
>>> src/cpu/ppc/vm/globalDefinitions_ppc.hpp
>>>
>>> small nit: Could be probably be merged with the paragraph above where we do
>>> the same thing for AIX, but I do not have strong emotions.
>>>
>>>
>>> src/cpu/ppc/vm/vm_version_ppc.cpp
>>>
>>> + // Please, refer to commit 4b4fadba057c1af7689fc8fa182b13baL7
>>> Does this refer to an OpenJDK change? If yes, could you please instead
>>> mention the OpenJDK bug number instead?
>>>
>>>
>>> src/os/linux/vm/os_linux.cpp
>>>
>>> os::Linux::initialize_os_info()
>>>
>>> Please make this code more robust:
>>> - Check the return value of sscanf (must be 3, otherwise your assumption
>>> about the version format was wrong)
>>> - Could this happen: "3.2" ? If yes, could you please handle it too?
>>> - Please handle overflow - if any one of minor/fix is > 256, something
>>> sensible should happen (for major, this probably indicates an error).
>>> Possibly cap out at 256?
>>>
>>> If version cannot be read successfully, the VM should not abort imho but
>>> behave gracefully. Worst that should happen is that RTM gets deactivated.
>>>
>>>
>>> Kind Regards, Thomas
>>>
>>>
>>> On Thu, Feb 25, 2016 at 9:21 AM, David Holmes >
>>> wrote:
>>>
>>>> On 25/02/2016 6:11 PM, Gustavo Romero wrote:
>>>>
>>>>> Hi David,
>>>>>
>>>>> OK, I'll fix that.
>>>>>
>>>>> Should I re-send the RFR with the right URL and abandon this one?
>>>>>
>>>>
>>>> I think you can just post the new URL to this one.
>>>>
>>>> In case a contribution is not so small, even so is it fine to include it
>>>>> inline?
>>>>>
>>>>
>>>> Well it's preferable, for larger contributions, to find someone to host
>>>> the webrev for you.
>>>>
>>>> Cheers,
>>>> David
>>>>
>>>>
>>>> Thank you.
>>>>>
>>>>> Regards,
>>>>> Gustavo
>>>>>
>>>>> On 25-02-2016 04:54, David Holmes wrote:
>>>>>
>>>>>> Hi Gustavo,
>>>>>>
>>>>>> Just a point of order. All contributions to the OpenJDK must be made
>>>>>> through OpenJDK infrastructure. So you must either get someone to host your
>>>>>> webrev on cr.openjdk.java.net, or include it inline in
>>>>>> email (attachments tend to get stripped).
>>>>>>
>>>>>> Sorry for the inconvenience.
>>>>>>
>>>>>> David
>>>>>>
>>>>>> On 25/02/2016 5:50 AM, Gustavo Romero wrote:
>>>>>>
>>>>>>> Hi Martin,
>>>>>>>
>>>>>>> Both little and big endian Linux kernel contain the syscall change, so
>>>>>>> I did not include:
>>>>>>>
>>>>>>> #if defined(COMPILER2) && (defined(AIX) || defined(VM_LITTLE_ENDIAN)
>>>>>>>
>>>>>>> in globalDefinitions_ppc.hpp.
>>>>>>>
>>>>>>> Please, could you review the following change?
>>>>>>>
>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8150353
>>>>>>> Webrev (hotspot): http://81.de.7a9f.ip4.static.sl-reverse.com/webrev/
>>>>>>>
>>>>>>> Summary:
>>>>>>>
>>>>>>> * Enable RTM support for Linux on PPC64 (LE and BE).
>>>>>>> * Fix C2 compiler buffer size issue.
>>>>>>>
>>>>>>> Thank you.
>>>>>>>
>>>>>>> Regards,
>>>>>>> Gustavo
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>
>
From jon.masamitsu at oracle.com Mon Mar 7 17:02:15 2016
From: jon.masamitsu at oracle.com (Jon Masamitsu)
Date: Mon, 7 Mar 2016 09:02:15 -0800
Subject: RFR 8150013: ParNew: Prune nmethods scavengable list
In-Reply-To:
References:
<56D8CCBE.4040900@oracle.com>
<56D9D98A.8050407@oracle.com>
Message-ID: <56DDB417.4040604@oracle.com>
On 03/06/2016 05:51 PM, Carsten Varming wrote:
> Dear Jon,
>
> Thank you for sponsoring.
>
> I am not sure about your intended change to the patch. If
> fix_relocations, then there are two cases where I remove the nmethod
> from the scavengable list: 1. If the nmethod is not live. 2. If the
> nmethod is live and it does not have scavengable roots. With your
> suggested code change I don't think I can cover both cases without
> code duplication. So I think it is best to leave the logic as is.
Ok.
>
> Regarding you proposed comment about the precision of
> detect_scavenge_root_oops.
> // Unless the relocations have been updated (fixed), the
> // detect_scavenge_root_oops() will not be precise so skip
> // the check to unlink. Note that not doing the unlinking
> // is safe but less optimal.
>
> I don't know what you mean when you say "detect_scavenge_root_oops()
> will not be precise". The method fix_relocations() in every closure
> that might move an object returns true (I carefully checked all
> collectors except G1 (which does not use the list)), so there should
> never be a time where an nmethod is left in a state where
> detect_scavenge_root_oops is wrong. You are right that non-scavengable
> nmethods on the list is fine, but I disagree about it being less than
> optimal (see next comment).
>
> The reason I chose to not prune nmethods when !fix_relocations is that
> I don't expect to be able to prune any live nmethods. To prune a live
> nmethod from the list all oops in the nmethod must be non-scavengable
> (oops::is_scavengable() must return false). In all collectors today,
> fix_relocations is true if an object might be moved. Hence the only
> time the list might contain a non-scavengable nmethod is between line
> 663 and 668 in my patch and between an oop moved by a full collection
> and the prune method called at the end of said collection. As every
> live nmethod on the list is expected to be scavengable (with the
> exceptions already listed) pruning the list when objects have not
> moved seems like a waste. What about dead nmethods? I don't think
> pruning dead nmethods really makes a difference, but I would be happy
> to change the code to prune them regardless of the value of
> fix_relocations.
I think you are correct so no need to make a change.
>
> I added the following comment
> // The scavengable nmethod list must contain all methods with scavengable
> // oops. It is safe to include more nmethod on the list, but we do not
> // expect any live non-scavengable nmethods on the list.
> I hope that covers your intention.
Thanks for the added comment.
>
> I updated the webrev at
> http://cr.openjdk.java.net/~cvarming/scavenge_nmethods_auto_prune/2/
>
> with the comment.
I'll push this version.
Jon
>
> Carsten
>
> On Fri, Mar 4, 2016 at 1:52 PM, Jon Masamitsu
> > wrote:
>
> Carsten,
>
> There will be a couple of days delay in pushing this
> change. The runtime repository is closed at the
> moment but hopefully will be open again in a day
> or two.
>
> Jon
>
>
> On 03/04/2016 10:23 AM, Carsten Varming wrote:
>> Dear Christian,
>>
>> Thank you for your review.
>>
>> Carsten
>>
>> On Fri, Mar 4, 2016 at 12:50 PM, Christian Thalinger
>> > > wrote:
>>
>> Jon asked me to have a quick look over the code cache
>> changes. Looks good to me.
>>
>> > On Mar 3, 2016, at 1:46 PM, Jon Masamitsu
>> >
>> wrote:
>> >
>> > Carsten,
>> >
>> > Changes look good.
>> >
>> > A couple of suggestions.
>> >
>> >
>> http://cr.openjdk.java.net/~cvarming/scavenge_nmethods_auto_prune/2/src/share/vm/code/codeCache.cpp.frames.html
>>
>> >
>> > 661 if (is_live) {
>> > 662 // Perform cur->oops_do(f), maybe just once per
>> nmethod.
>> > 663 f->do_code_blob(cur);
>> > 664 }
>> > 665 nmethod* const next = cur->scavenge_root_link();
>> > 666 if (fix_relocations) {
>> > 667 if (!is_live || !cur->detect_scavenge_root_oops()) {
>> > 668 unlink_scavenge_root_nmethod(cur, prev);
>> > 669 } else {
>> > 670 prev = cur;
>> > 671 }
>> > 672 }
>> > 673 cur = next;
>> >
>> > Although this does not change the actions, I find this
>> easier to
>> > read. You and Tony (and whoever else wants to) can vote
>> > on it.
>> >
>> > if (is_live) { ... } else {
>> > if (fix_relocations) { if
>> (cur->detect_scavenge_root_oops()) { prev = cur; } else {
>> unlink_scavenge_root_nmethod(cur, prev);} } cur =
>> cur->scavenge_root_link(); }
>> >
>> > Also I'd suggest a comment before the if-test
>> > if you find it correct.
>> >
>> > // Unless the relocations have been updated (fixed), the //
>> detect_scavenge_root_oops() will not be precise so skip //
>> the check to unlink. Note that not doing the unlinking // is
>> safe but less optimal. if (fix_relocations) {
>> >
>> > The comment in the header file for fix_relocations helped
>> > but a comment here might be helpful.
>> >
>> > I'll sponsor.
>> >
>> > Jon
>> >
>> > On 2/28/2016 6:16 PM, Carsten Varming wrote:
>> >> Dear Hotspot developers,
>> >>
>> >> Any chance of a review of this patch? The patch cut
>> between 7ms and 10ms of every ParNew with one application at
>> Twitter and I expect a 1-2ms improvement for most applications.
>> >>
>> >> I touch the code cache and GenCollectedHeap, so I assume I
>> need reviews from both gc and compiler reviewers. Thank you
>> Tony Printezis for the review (posted on the hotspot-gc-dev
>> list).
>> >>
>> >> I also need a sponsor.
>> >>
>> >> Carsten
>> >>
>> >> On Fri, Feb 19, 2016 at 10:52 AM, Carsten Varming > > >> wrote:
>> >>
>> >> Dear Hotspot developers,
>> >>
>> >> I would like to contribute a patch for JDK-8150013
>> >> . The
>> current
>> >> webrev can be found here:
>> >>
>> http://cr.openjdk.java.net/~cvarming/scavenge_nmethods_auto_prune/2/
>>
>> >>
>> .
>> >>
>> >> Suggestions for improvements are very welcome.
>> >>
>> >> Carsten
>> >>
>> >>
>> >
>>
>>
>
>
From Guy.Delamarter at oracle.com Mon Mar 7 17:30:52 2016
From: Guy.Delamarter at oracle.com (Guy Delamarter)
Date: Mon, 7 Mar 2016 09:30:52 -0800
Subject: [9] RFR(S): 8144693: Intrinsify StringCoding.hasNegatives() on
SPARC
In-Reply-To: <56D7BFA6.1000401@oracle.com>
References: <56D77856.1020707@oracle.com> <56D7BFA6.1000401@oracle.com>
Message-ID: <56DDBACC.2020405@oracle.com>
Hi,
On 03/02/2016 08:37 PM, Vladimir Kozlov wrote:
> Why you are avoiding the same register for src and dst in
> instructions? For example:
>
> + add(t3, 0x80, t2);
>
> I think you can use less registers if you reuse registers. The less
> registers you use - less registers will be spilled on stack in the
> code which use your code.
Spilling doesn't appear to be a problem in actual hasNegatives use. In
the cases I've looked at, on entry the second parameter, size, is copied
from one register (e.g. %i3) to %g3 and both are preserved all the way
through the hasNegatives code, without prior spill. The former register
is then the one used after exit. If register pressure and resulting
spilling becomes an issue, hopefully there is some way to eliminate the
duplication.
>
>
> 'size' register is defined as 32-bit values in .ad file. It may have
> garbage in apper bits - I would suggest to sign extend it before using:
>
Good to know.
> signx(size);
>
> If size is small (t5 != 0 for unaligned header) may be we should just
> jump to tail code to do right shift (to mov(0, result); instruction).
> But I am not insisting on this.
If I understand correctly that replaces two instructions with three, one
of which is a branch, without providing additional function.
I made the other changes, and after I noticed the minor problem, fixed
it so unaligned array segments of size 0 won't perform any reads.
New Webrevs:
http://cr.openjdk.java.net/~thartmann/8144693/hotspot/webrev.01/
http://cr.openjdk.java.net/~thartmann/8144693/jdk/webrev.01/
Thanks,
Guy Delamarter
>
>
> Thanks,
> Vladimir
>
> On 3/2/16 3:33 PM, Guy Delamarter wrote:
>> Hi,
>>
>> Please review the following patch adding a SPARC intrinsic for
>> StringCoding.hasNegatives to hotspot and supporting changes.
>>
>> Tobias Hartmann (tobias.hartmann at oracle.com) has offered to
>> sponsor these changes.
>>
>>
>> Summary:
>>
>> hasNegatives is a utility method for encoding/decoding under the new
>> Compact Strings framework, returning whether the given byte array
>> (segment) contains any negative entries. hasNegatives is an intrinsic
>> candidate, emitted by hotspot as a node in the latest Java 9 builds,
>> but the SPARC node match and (inline assembly) implementation have
>> been missing up to now. This implementation checks aligned 8-byte
>> windows onto the array segment for negative bytes, carefully ignoring
>> bytes in the window that happen to be outside the segment.
>>
>> It was discovered that the private access of the hasNegatives method
>> prevented direct testing of the intrinsic from outside StringCoding,
>> so that was changed to public. Subsequent to this change a compiler
>> test class (TestHasNegatives) was added providing useful validation
>> coverage.
>>
>>
>> Webrevs:
>> http://cr.openjdk.java.net/~thartmann/8144693/hotspot/webrev.00/
>> http://cr.openjdk.java.net/~thartmann/8144693/jdk/webrev.00/
>>
>> Issue:
>> https://bugs.openjdk.java.net/browse/JDK-8144693
>>
>>
>> Thanks,
>> Guy Delamarter
>>
From vladimir.kozlov at oracle.com Mon Mar 7 17:43:46 2016
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Mon, 7 Mar 2016 09:43:46 -0800
Subject: RFR(M) 8150353: PPC64LE: Support RTM on linux
In-Reply-To: <4866933cb0424052a3eec45b38a6ee45@DEWDFE13DE14.global.corp.sap>
References: <56CE0975.8060807@linux.vnet.ibm.com>
<56CEB349.1050102@oracle.com> <56CEB73D.8030904@linux.vnet.ibm.com>
<56CEB982.5030706@oracle.com>
<56DCAEB7.8010003@linux.vnet.ibm.com>
<56DD9DCF.8090703@linux.vnet.ibm.com>
<4866933cb0424052a3eec45b38a6ee45@DEWDFE13DE14.global.corp.sap>
Message-ID: <56DDBDD2.90100@oracle.com>
Looks good. I will push it.
Thanks,
Vladimir
On 3/7/16 8:00 AM, Doerr, Martin wrote:
> Hi,
>
> looks good. Thanks for making the requested changes.
>
> The change modifies os_linux and shared C2 code.
> Can somebody from Oracle review and sponsor, please?
>
> The webrev is here:
> http://cr.openjdk.java.net/~mdoerr/8150353_RTM_linux_ppc64/webrev.00/
>
> It was tested in jdk9/dev/hotspot, but it applies to jdk9/hs-comp/hotspot as well.
>
> Best regards,
> Martin
>
> -----Original Message-----
> From: Gustavo Romero [mailto:gromero at linux.vnet.ibm.com]
> Sent: Montag, 7. M?rz 2016 16:27
> To: Doerr, Martin ; Vladimir Kozlov ; Thomas St?fe
> Cc: hotspot-dev at openjdk.java.net; Breno Leitao
> Subject: Re: RFR(M) 8150353: PPC64LE: Support RTM on linux
>
> Hi Martin
>
> Sure, AIX is now included as well.
>
> Could you please host and review this updated version?
>
> Webrev:
> http://81.de.7a9f.ip4.static.sl-reverse.com./8150353/webrev_v3.zip
>
> src/cpu/ppc/vm/globalDefinitions_ppc.hpp:
>
> I merged the defines as Thomas suggested.
>
>
> src/cpu/ppc/vm/vm_version_ppc.cpp:
>
> Thomas, sorry for the cryptic comment about the kernel change. It refers
> to Linux kernel source tree and not to OpenJDK. I've improved the
> comment to reflect it.
>
>
> Regarding MAX_inst_size:
> I assumed that the ScratchBufferBlob issue is present only on PPC64
> and, as Vladmir and Martin suggested, I made MAX_inst_size a platform
> specific value (changed only for PPC64 - AIX and Linux). Vladimir,
> thanks for doing additional analysis on x64 architecture.
>
>
> Regarding Linux version encoding:
> Keeping the values x.y.z together the same form it was done on AIX is
> more convenient, as Martin said, and besides that it's the way Linux
> kernel itself handles the Linux kernel versions. Hence it defines
> macro KERNEL_VERSION used whenever kernel version check/comparison is
> necessary and it does exactly what we are doing for AIX and Linux on
> PPC64:
>
> #define KERNEL_VERSION(a,b,c) (((a) << 16) + ((b) << 8) + (c))
>
> So I think it's not a problem to assume true that each value in x.y.z
> is always less then 256 and also never something like 3.2 (x.y). To the
> best of my knowledge there is no rigid standard for that but by looking
> at mainline kernel versions we can trust this format too. However, as
> any distro can change it at will (although very unlikely), making it
> more robust in the sense Thomas and Martin commented is a good idea. I
> did it and checked if the kernel version format is what we expect
> (x.y.z format) and for x, y, and z less then 256.
>
> Thomas, in case of a version is unknown I decided for bailing out
> instead of just letting the VM continue with RTM disabled since it's the
> behavior, for instance, when the CPU doesn't support Transactional
> Memory and other similar conditions in the code around. But as method
> os_version_is_known() exists (instead of assert()'s in os_linux.cpp),
> it's possible to change this behavior easily in vm_version_ppc.cpp.
>
>
> Regarding Hotspot jtreg tests:
> No regression was observed. More 16 tests are passing now on Linux
> (PP64 LE):
>
> Passed: compiler/rtm/cli/TestPrintPreciseRTMLockingStatisticsOptionOnSupportedConfig.java
> Passed: compiler/rtm/cli/TestRTMAbortRatioOptionOnSupportedConfig.java
> Passed: compiler/rtm/cli/TestRTMTotalCountIncrRateOptionOnSupportedConfig.java
> Passed: compiler/rtm/cli/TestUseRTMDeoptOptionOnSupportedConfig.java
> Passed: compiler/rtm/cli/TestUseRTMForStackLocksOptionOnSupportedConfig.java
> Passed: compiler/rtm/cli/TestUseRTMLockingOptionOnSupportedConfig.java
> Passed: compiler/rtm/cli/TestUseRTMLockingOptionWithBiasedLocking.java
> Passed: compiler/rtm/locking/TestRTMAbortRatio.java
> Passed: compiler/rtm/locking/TestRTMAfterNonRTMDeopt.java
> Passed: compiler/rtm/locking/TestRTMTotalCountIncrRate.java
> Passed: compiler/rtm/locking/TestUseRTMDeopt.java
> Passed: compiler/rtm/locking/TestUseRTMForInflatedLocks.java
> Passed: compiler/rtm/locking/TestUseRTMForStackLocks.java
> Passed: compiler/rtm/method_options/TestNoRTMLockElidingOption.java
> Passed: compiler/rtm/method_options/TestUseRTMLockElidingOption.java
> Passed: gc/ergonomics/TestDynamicNumberOfGCThreads.java
>
>
> Kind regards,
> Gustavo
>
> On 07-03-2016 07:17, Doerr, Martin wrote:
>> Hi Gustavo,
>>
>> I?m back from vacation and I can host the webrev. Thanks for doing this change. It?s quite some work to get it into openjdk.
>>
>> May I ask you to increase the scratch buffer size for AIX as well (e.g. make it only dependent on PPC64, not on the OS in compile.hpp)?
>> We have the same problem there and we should try to make only one shared code change. We will have to ask someone from Oracle to push it (e.g. Vladimir Kozlov).
>>
>> Best regards,
>> Martin
>>
>> From: Thomas St?fe [mailto:thomas.stuefe at gmail.com]
>> Sent: Montag, 7. M?rz 2016 07:48
>> To: Doerr, Martin
>> Subject: Fwd: Re: RFR(M) 8150353: PPC64LE: Support RTM on linux
>>
>>
>> Hi Martin, kannst Du ?bernehmen? Bin erst morgen wieder da.
>>
>> Gru? Thomas
>> ---------- Forwarded message ----------
>> From: "Gustavo Romero" >
>> Date: Mar 6, 2016 23:27
>> Subject: Re: RFR(M) 8150353: PPC64LE: Support RTM on linux
>> To: "Thomas St?fe" >
>> Cc: "Doerr, Martin" >, "hotspot-dev at openjdk.java.net" >, >
>>
>> Hi Thomas
>>
>> Thanks for offering the hosting. :-)
>>
>> Thomas, could you please host this updated version that incorporates the
>> comments made by you, Martin, and Vladimir (Martin also kindly offered
>> the hosting but probably is yet out of office - but I'm not sure).
>>
>> Webrev updated version:
>> http://81.de.7a9f.ip4.static.sl-reverse.com./8150353/webrev.zip
>>
>> Thanks a lot.
>>
>> Best regards,
>> Gustavo
>>
>> On 25-02-2016 07:57, Thomas St?fe wrote:
>>> Hi Gustavo,
>>>
>>> I can host this for you, if you have no access to cr.openjdk.java.net. Just
>>> send me the patch file.
>>>
>>> About your change:
>>>
>>> src/cpu/ppc/vm/globalDefinitions_ppc.hpp
>>>
>>> small nit: Could be probably be merged with the paragraph above where we do
>>> the same thing for AIX, but I do not have strong emotions.
>>>
>>>
>>> src/cpu/ppc/vm/vm_version_ppc.cpp
>>>
>>> + // Please, refer to commit 4b4fadba057c1af7689fc8fa182b13baL7
>>> Does this refer to an OpenJDK change? If yes, could you please instead
>>> mention the OpenJDK bug number instead?
>>>
>>>
>>> src/os/linux/vm/os_linux.cpp
>>>
>>> os::Linux::initialize_os_info()
>>>
>>> Please make this code more robust:
>>> - Check the return value of sscanf (must be 3, otherwise your assumption
>>> about the version format was wrong)
>>> - Could this happen: "3.2" ? If yes, could you please handle it too?
>>> - Please handle overflow - if any one of minor/fix is > 256, something
>>> sensible should happen (for major, this probably indicates an error).
>>> Possibly cap out at 256?
>>>
>>> If version cannot be read successfully, the VM should not abort imho but
>>> behave gracefully. Worst that should happen is that RTM gets deactivated.
>>>
>>>
>>> Kind Regards, Thomas
>>>
>>>
>>> On Thu, Feb 25, 2016 at 9:21 AM, David Holmes >
>>> wrote:
>>>
>>>> On 25/02/2016 6:11 PM, Gustavo Romero wrote:
>>>>
>>>>> Hi David,
>>>>>
>>>>> OK, I'll fix that.
>>>>>
>>>>> Should I re-send the RFR with the right URL and abandon this one?
>>>>>
>>>>
>>>> I think you can just post the new URL to this one.
>>>>
>>>> In case a contribution is not so small, even so is it fine to include it
>>>>> inline?
>>>>>
>>>>
>>>> Well it's preferable, for larger contributions, to find someone to host
>>>> the webrev for you.
>>>>
>>>> Cheers,
>>>> David
>>>>
>>>>
>>>> Thank you.
>>>>>
>>>>> Regards,
>>>>> Gustavo
>>>>>
>>>>> On 25-02-2016 04:54, David Holmes wrote:
>>>>>
>>>>>> Hi Gustavo,
>>>>>>
>>>>>> Just a point of order. All contributions to the OpenJDK must be made
>>>>>> through OpenJDK infrastructure. So you must either get someone to host your
>>>>>> webrev on cr.openjdk.java.net, or include it inline in
>>>>>> email (attachments tend to get stripped).
>>>>>>
>>>>>> Sorry for the inconvenience.
>>>>>>
>>>>>> David
>>>>>>
>>>>>> On 25/02/2016 5:50 AM, Gustavo Romero wrote:
>>>>>>
>>>>>>> Hi Martin,
>>>>>>>
>>>>>>> Both little and big endian Linux kernel contain the syscall change, so
>>>>>>> I did not include:
>>>>>>>
>>>>>>> #if defined(COMPILER2) && (defined(AIX) || defined(VM_LITTLE_ENDIAN)
>>>>>>>
>>>>>>> in globalDefinitions_ppc.hpp.
>>>>>>>
>>>>>>> Please, could you review the following change?
>>>>>>>
>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8150353
>>>>>>> Webrev (hotspot): http://81.de.7a9f.ip4.static.sl-reverse.com/webrev/
>>>>>>>
>>>>>>> Summary:
>>>>>>>
>>>>>>> * Enable RTM support for Linux on PPC64 (LE and BE).
>>>>>>> * Fix C2 compiler buffer size issue.
>>>>>>>
>>>>>>> Thank you.
>>>>>>>
>>>>>>> Regards,
>>>>>>> Gustavo
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>
>
From gromero at linux.vnet.ibm.com Mon Mar 7 17:53:30 2016
From: gromero at linux.vnet.ibm.com (Gustavo Romero)
Date: Mon, 7 Mar 2016 14:53:30 -0300
Subject: RFR(M) 8150353: PPC64LE: Support RTM on linux
In-Reply-To: <56DDBDD2.90100@oracle.com>
References: <56CE0975.8060807@linux.vnet.ibm.com>
<56CEB349.1050102@oracle.com> <56CEB73D.8030904@linux.vnet.ibm.com>
<56CEB982.5030706@oracle.com>
<56DCAEB7.8010003@linux.vnet.ibm.com>
<56DD9DCF.8090703@linux.vnet.ibm.com>
<4866933cb0424052a3eec45b38a6ee45@DEWDFE13DE14.global.corp.sap>
<56DDBDD2.90100@oracle.com>
Message-ID: <56DDC01A.9050105@linux.vnet.ibm.com>
Thanks a lot Vladimir.
Best regards,
Gustavo
On 07-03-2016 14:43, Vladimir Kozlov wrote:
> Looks good. I will push it.
>
> Thanks,
> Vladimir
>
> On 3/7/16 8:00 AM, Doerr, Martin wrote:
>> Hi,
>>
>> looks good. Thanks for making the requested changes.
>>
>> The change modifies os_linux and shared C2 code.
>> Can somebody from Oracle review and sponsor, please?
>>
>> The webrev is here:
>> http://cr.openjdk.java.net/~mdoerr/8150353_RTM_linux_ppc64/webrev.00/
>>
>> It was tested in jdk9/dev/hotspot, but it applies to jdk9/hs-comp/hotspot as well.
>>
>> Best regards,
>> Martin
>>
>> -----Original Message-----
>> From: Gustavo Romero [mailto:gromero at linux.vnet.ibm.com]
>> Sent: Montag, 7. M?rz 2016 16:27
>> To: Doerr, Martin ; Vladimir Kozlov ; Thomas St?fe
>> Cc: hotspot-dev at openjdk.java.net; Breno Leitao
>> Subject: Re: RFR(M) 8150353: PPC64LE: Support RTM on linux
>>
>> Hi Martin
>>
>> Sure, AIX is now included as well.
>>
>> Could you please host and review this updated version?
>>
>> Webrev:
>> http://81.de.7a9f.ip4.static.sl-reverse.com./8150353/webrev_v3.zip
>>
>> src/cpu/ppc/vm/globalDefinitions_ppc.hpp:
>>
>> I merged the defines as Thomas suggested.
>>
>>
>> src/cpu/ppc/vm/vm_version_ppc.cpp:
>>
>> Thomas, sorry for the cryptic comment about the kernel change. It refers
>> to Linux kernel source tree and not to OpenJDK. I've improved the
>> comment to reflect it.
>>
>>
>> Regarding MAX_inst_size:
>> I assumed that the ScratchBufferBlob issue is present only on PPC64
>> and, as Vladmir and Martin suggested, I made MAX_inst_size a platform
>> specific value (changed only for PPC64 - AIX and Linux). Vladimir,
>> thanks for doing additional analysis on x64 architecture.
>>
>>
>> Regarding Linux version encoding:
>> Keeping the values x.y.z together the same form it was done on AIX is
>> more convenient, as Martin said, and besides that it's the way Linux
>> kernel itself handles the Linux kernel versions. Hence it defines
>> macro KERNEL_VERSION used whenever kernel version check/comparison is
>> necessary and it does exactly what we are doing for AIX and Linux on
>> PPC64:
>>
>> #define KERNEL_VERSION(a,b,c) (((a) << 16) + ((b) << 8) + (c))
>>
>> So I think it's not a problem to assume true that each value in x.y.z
>> is always less then 256 and also never something like 3.2 (x.y). To the
>> best of my knowledge there is no rigid standard for that but by looking
>> at mainline kernel versions we can trust this format too. However, as
>> any distro can change it at will (although very unlikely), making it
>> more robust in the sense Thomas and Martin commented is a good idea. I
>> did it and checked if the kernel version format is what we expect
>> (x.y.z format) and for x, y, and z less then 256.
>>
>> Thomas, in case of a version is unknown I decided for bailing out
>> instead of just letting the VM continue with RTM disabled since it's the
>> behavior, for instance, when the CPU doesn't support Transactional
>> Memory and other similar conditions in the code around. But as method
>> os_version_is_known() exists (instead of assert()'s in os_linux.cpp),
>> it's possible to change this behavior easily in vm_version_ppc.cpp.
>>
>>
>> Regarding Hotspot jtreg tests:
>> No regression was observed. More 16 tests are passing now on Linux
>> (PP64 LE):
>>
>> Passed: compiler/rtm/cli/TestPrintPreciseRTMLockingStatisticsOptionOnSupportedConfig.java
>> Passed: compiler/rtm/cli/TestRTMAbortRatioOptionOnSupportedConfig.java
>> Passed: compiler/rtm/cli/TestRTMTotalCountIncrRateOptionOnSupportedConfig.java
>> Passed: compiler/rtm/cli/TestUseRTMDeoptOptionOnSupportedConfig.java
>> Passed: compiler/rtm/cli/TestUseRTMForStackLocksOptionOnSupportedConfig.java
>> Passed: compiler/rtm/cli/TestUseRTMLockingOptionOnSupportedConfig.java
>> Passed: compiler/rtm/cli/TestUseRTMLockingOptionWithBiasedLocking.java
>> Passed: compiler/rtm/locking/TestRTMAbortRatio.java
>> Passed: compiler/rtm/locking/TestRTMAfterNonRTMDeopt.java
>> Passed: compiler/rtm/locking/TestRTMTotalCountIncrRate.java
>> Passed: compiler/rtm/locking/TestUseRTMDeopt.java
>> Passed: compiler/rtm/locking/TestUseRTMForInflatedLocks.java
>> Passed: compiler/rtm/locking/TestUseRTMForStackLocks.java
>> Passed: compiler/rtm/method_options/TestNoRTMLockElidingOption.java
>> Passed: compiler/rtm/method_options/TestUseRTMLockElidingOption.java
>> Passed: gc/ergonomics/TestDynamicNumberOfGCThreads.java
>>
>>
>> Kind regards,
>> Gustavo
>>
>> On 07-03-2016 07:17, Doerr, Martin wrote:
>>> Hi Gustavo,
>>>
>>> I?m back from vacation and I can host the webrev. Thanks for doing this change. It?s quite some work to get it into openjdk.
>>>
>>> May I ask you to increase the scratch buffer size for AIX as well (e.g. make it only dependent on PPC64, not on the OS in compile.hpp)?
>>> We have the same problem there and we should try to make only one shared code change. We will have to ask someone from Oracle to push it (e.g. Vladimir Kozlov).
>>>
>>> Best regards,
>>> Martin
>>>
>>> From: Thomas St?fe [mailto:thomas.stuefe at gmail.com]
>>> Sent: Montag, 7. M?rz 2016 07:48
>>> To: Doerr, Martin
>>> Subject: Fwd: Re: RFR(M) 8150353: PPC64LE: Support RTM on linux
>>>
>>>
>>> Hi Martin, kannst Du ?bernehmen? Bin erst morgen wieder da.
>>>
>>> Gru? Thomas
>>> ---------- Forwarded message ----------
>>> From: "Gustavo Romero" >
>>> Date: Mar 6, 2016 23:27
>>> Subject: Re: RFR(M) 8150353: PPC64LE: Support RTM on linux
>>> To: "Thomas St?fe" >
>>> Cc: "Doerr, Martin" >, "hotspot-dev at openjdk.java.net"
>>> >, >
>>>
>>> Hi Thomas
>>>
>>> Thanks for offering the hosting. :-)
>>>
>>> Thomas, could you please host this updated version that incorporates the
>>> comments made by you, Martin, and Vladimir (Martin also kindly offered
>>> the hosting but probably is yet out of office - but I'm not sure).
>>>
>>> Webrev updated version:
>>> http://81.de.7a9f.ip4.static.sl-reverse.com./8150353/webrev.zip
>>>
>>> Thanks a lot.
>>>
>>> Best regards,
>>> Gustavo
>>>
>>> On 25-02-2016 07:57, Thomas St?fe wrote:
>>>> Hi Gustavo,
>>>>
>>>> I can host this for you, if you have no access to cr.openjdk.java.net. Just
>>>> send me the patch file.
>>>>
>>>> About your change:
>>>>
>>>> src/cpu/ppc/vm/globalDefinitions_ppc.hpp
>>>>
>>>> small nit: Could be probably be merged with the paragraph above where we do
>>>> the same thing for AIX, but I do not have strong emotions.
>>>>
>>>>
>>>> src/cpu/ppc/vm/vm_version_ppc.cpp
>>>>
>>>> + // Please, refer to commit 4b4fadba057c1af7689fc8fa182b13baL7
>>>> Does this refer to an OpenJDK change? If yes, could you please instead
>>>> mention the OpenJDK bug number instead?
>>>>
>>>>
>>>> src/os/linux/vm/os_linux.cpp
>>>>
>>>> os::Linux::initialize_os_info()
>>>>
>>>> Please make this code more robust:
>>>> - Check the return value of sscanf (must be 3, otherwise your assumption
>>>> about the version format was wrong)
>>>> - Could this happen: "3.2" ? If yes, could you please handle it too?
>>>> - Please handle overflow - if any one of minor/fix is > 256, something
>>>> sensible should happen (for major, this probably indicates an error).
>>>> Possibly cap out at 256?
>>>>
>>>> If version cannot be read successfully, the VM should not abort imho but
>>>> behave gracefully. Worst that should happen is that RTM gets deactivated.
>>>>
>>>>
>>>> Kind Regards, Thomas
>>>>
>>>>
>>>> On Thu, Feb 25, 2016 at 9:21 AM, David Holmes >
>>>> wrote:
>>>>
>>>>> On 25/02/2016 6:11 PM, Gustavo Romero wrote:
>>>>>
>>>>>> Hi David,
>>>>>>
>>>>>> OK, I'll fix that.
>>>>>>
>>>>>> Should I re-send the RFR with the right URL and abandon this one?
>>>>>>
>>>>>
>>>>> I think you can just post the new URL to this one.
>>>>>
>>>>> In case a contribution is not so small, even so is it fine to include it
>>>>>> inline?
>>>>>>
>>>>>
>>>>> Well it's preferable, for larger contributions, to find someone to host
>>>>> the webrev for you.
>>>>>
>>>>> Cheers,
>>>>> David
>>>>>
>>>>>
>>>>> Thank you.
>>>>>>
>>>>>> Regards,
>>>>>> Gustavo
>>>>>>
>>>>>> On 25-02-2016 04:54, David Holmes wrote:
>>>>>>
>>>>>>> Hi Gustavo,
>>>>>>>
>>>>>>> Just a point of order. All contributions to the OpenJDK must be made
>>>>>>> through OpenJDK infrastructure. So you must either get someone to host your
>>>>>>> webrev on cr.openjdk.java.net, or include it inline in
>>>>>>> email (attachments tend to get stripped).
>>>>>>>
>>>>>>> Sorry for the inconvenience.
>>>>>>>
>>>>>>> David
>>>>>>>
>>>>>>> On 25/02/2016 5:50 AM, Gustavo Romero wrote:
>>>>>>>
>>>>>>>> Hi Martin,
>>>>>>>>
>>>>>>>> Both little and big endian Linux kernel contain the syscall change, so
>>>>>>>> I did not include:
>>>>>>>>
>>>>>>>> #if defined(COMPILER2) && (defined(AIX) || defined(VM_LITTLE_ENDIAN)
>>>>>>>>
>>>>>>>> in globalDefinitions_ppc.hpp.
>>>>>>>>
>>>>>>>> Please, could you review the following change?
>>>>>>>>
>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8150353
>>>>>>>> Webrev (hotspot): http://81.de.7a9f.ip4.static.sl-reverse.com/webrev/
>>>>>>>>
>>>>>>>> Summary:
>>>>>>>>
>>>>>>>> * Enable RTM support for Linux on PPC64 (LE and BE).
>>>>>>>> * Fix C2 compiler buffer size issue.
>>>>>>>>
>>>>>>>> Thank you.
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Gustavo
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>
>>
>
From vladimir.kozlov at oracle.com Mon Mar 7 18:17:43 2016
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Mon, 7 Mar 2016 10:17:43 -0800
Subject: RFR(M) 8150353: PPC64LE: Support RTM on linux
In-Reply-To:
References: <56CE0975.8060807@linux.vnet.ibm.com> <56CE42AE.7080605@oracle.com>
<10c9a1cb6d9b40618a094283ac838038@DEWDFE13DE14.global.corp.sap>
<56CFB72C.7030401@oracle.com>
Message-ID: <56DDC5C7.3000105@oracle.com>
RTM's assumption is: "RTM locking is most useful when there is high lock
contention and low data contention. With high lock contention the lock
is usually inflated and biased locking is not suitable for that case
anyway." It is not the case with jbb2005. And that is why RTM is off by
default.
First RTM implementation used BiasedLocking bits in object's markword.
Later it was implemented differently but there was still a concern that
to make them work together we may need more changes. We thought that we
will do that as separate project later. But currently we don't have a
plan for doing this.
Regards,
Vladimir
On 3/7/16 2:29 AM, Doerr, Martin wrote:
> Hi Vladimir,
>
> thank you very much for the detailed analysis.
> I hope an #ifdef PPC64 is ok in the shared code?
>
> I had written something to Gustavo about the performance problem we have with RTM in SPEC jbb2005:
>
>> The following issue is important for performance work:
>> RTM does not work with BiasedLocking. The latter gets switched off if RTM is activated which has a large performance impact (especially in jbb2005).
>> I would disable it for a reference measurement:
>> -XX:-UseBiasedLocking
>>
>> Unfortunately, RTM was slower than BiasedLocking but faster than the reference (without both) which tells me that there's room for improvement.
>> There are basically 3 classes of locks:
>> 1. no contention
>> 2. contention on lock, low contention on data
>> 3. high contention on data
>>
>> I believe the optimal treatment for the cases would be:
>> 1. Biased Locking
>> 2. Transactional Memory
>> 3. classical locking with lock inflating
>>
>> I think it would be good if the JVM could optimize for all these cases in the future. But that would add additional complexity and code size.
>
> Do you think this is something which should be improved in the future?
> We could try e.g. the following approach
> - try biased
> - deoptimize if it doesn't work well, try transactional
> - deoptimize if it doesn't work well, use classical locking (with inflating)
>
> Best regards,
> Martin
>
>
> -----Original Message-----
> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com]
> Sent: Freitag, 26. Februar 2016 03:24
> To: Doerr, Martin ; Gustavo Romero ; hotspot-dev at openjdk.java.net
> Cc: brenohl at br.ibm.com
> Subject: Re: RFR(M) 8150353: PPC64LE: Support RTM on linux
>
> The problem with increasing ScratchBufferBlob size is that with Tiered
> compilation we scale number of compiler threads based on cpu count and
> increase space in CodeCache accordingly:
>
> code_buffers_size += c2_count * C2Compiler::initial_code_buffer_size();
>
> I did experiment on Intel setting ON all RTM flags which can increase
> size of lock code:
>
> $ java -XX:+UnlockExperimentalVMOptions -XX:+UnlockDiagnosticVMOptions
> -XX:+UseRTMLocking -XX:+UseRTMDeopt -XX:+UseRTMForStackLocks
> -XX:+PrintPreciseRTMLockingStatistics -XX:+PrintFlagsFinal -version
> |grep RTM
> Java HotSpot(TM) 64-Bit Server VM warning: UseRTMLocking is only
> available as experimental option on this platform.
> bool PrintPreciseRTMLockingStatistics := true
> {C2 diagnostic}
> intx RTMAbortRatio = 50
> {ARCH experimental}
> intx RTMAbortThreshold = 1000
> {ARCH experimental}
> intx RTMLockingCalculationDelay = 0
> {ARCH experimental}
> intx RTMLockingThreshold = 10000
> {ARCH experimental}
> uintx RTMRetryCount = 5
> {ARCH product}
> intx RTMSpinLoopCount = 100
> {ARCH experimental}
> intx RTMTotalCountIncrRate = 64
> {ARCH experimental}
> bool UseRTMDeopt := true
> {ARCH product}
> bool UseRTMForStackLocks := true
> {ARCH experimental}
> bool UseRTMLocking := true
> {ARCH product}
> bool UseRTMXendForLockBusy = true
> {ARCH experimental}
>
>
> I added next lines to the end of Compile::scratch_emit_size() method:
>
> if (n->is_Mach() && n->as_Mach()->ideal_Opcode() == Op_FastLock) {
> tty->print_cr("======== FastLock size: %d ==========",
> buf.total_content_size());
> }
> if (n->is_Mach() && n->as_Mach()->ideal_Opcode() == Op_FastUnlock) {
> tty->print_cr("======== FastUnlock size: %d ==========",
> buf.total_content_size());
> }
>
> and got:
>
> ======== FastLock size: 657 ==========
> ======== FastUnlock size: 175 ==========
>
> Thanks,
> Vladimir
>
> On 2/25/16 3:43 AM, Doerr, Martin wrote:
>> Hi Vladimir,
>>
>> thanks for taking a look.
>>
>> About version values:
>> We are using a similar scheme for version checks on AIX where we know that the version values are less than 256.
>> It makes comparisons much more convenient.
>> But I agree that we should double-check if it is guaranteed for linux as well (and possibly add an assertion).
>>
>> About scratch buffer size:
>> We only noticed that the scratch buffer was too small when we enable all RTM features:
>> -XX:+UnlockExperimentalVMOptions -XX:+UseRTMLocking -XX:+UseRTMForStackLocks -XX:+UseRTMDeopt
>> We have only tried on PPC64, but I wonder if the current size is sufficient for x86. I currently don't have access to a Skylake machine.
>>
>> I think adding 1024 bytes to the scratch buffer doesn't hurt.
>> (It may also lead to larger CodeBuffers in output.cpp but I don't think this is problematic as long as the real content gets copied to nmethods.)
>> Would you agree?
>>
>> Best regards,
>> Martin
>>
>> -----Original Message-----
>> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com]
>> Sent: Donnerstag, 25. Februar 2016 00:54
>> To: Gustavo Romero ; Doerr, Martin ; hotspot-dev at openjdk.java.net
>> Cc: brenohl at br.ibm.com
>> Subject: Re: RFR(M) 8150353: PPC64LE: Support RTM on linux
>>
>> My concern (but I am not export) is Linux version encoding. Is it true
>> that each value in x.y.z is less then 256? Why not keep them as separate
>> int values?
>> I also thought we have OS versions in make files but we check only gcc
>> version there.
>>
>> Do you have problem with ScratchBufferBlob only on PPC or on some other
>> platforms too? May be we should make MAX_inst_size as platform specific
>> value.
>>
>> Thanks,
>> Vladimir
>>
>> On 2/24/16 11:50 AM, Gustavo Romero wrote:
>>> Hi Martin,
>>>
>>> Both little and big endian Linux kernel contain the syscall change, so
>>> I did not include:
>>>
>>> #if defined(COMPILER2) && (defined(AIX) || defined(VM_LITTLE_ENDIAN)
>>>
>>> in globalDefinitions_ppc.hpp.
>>>
>>> Please, could you review the following change?
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8150353
>>> Webrev (hotspot): http://81.de.7a9f.ip4.static.sl-reverse.com/webrev/
>>>
>>> Summary:
>>>
>>> * Enable RTM support for Linux on PPC64 (LE and BE).
>>> * Fix C2 compiler buffer size issue.
>>>
>>> Thank you.
>>>
>>> Regards,
>>> Gustavo
>>>
From jon.masamitsu at oracle.com Mon Mar 7 18:46:25 2016
From: jon.masamitsu at oracle.com (Jon Masamitsu)
Date: Mon, 7 Mar 2016 10:46:25 -0800
Subject: RFR 8150013: ParNew: Prune nmethods scavengable list
In-Reply-To: <56DDB417.4040604@oracle.com>
References:
<56D8CCBE.4040900@oracle.com>
<56D9D98A.8050407@oracle.com>
<56DDB417.4040604@oracle.com>
Message-ID: <56DDCC81.4030700@oracle.com>
Carsten,
Just to you.
You have author status so you could commit the patch in
mercurial and send me the patch for the changeset. That
would then list you as the user who submitted the change.
Or I could commit the patch and list you as the contributer.
Which would you like to do.
Jon
On 03/07/2016 09:02 AM, Jon Masamitsu wrote:
>
>
> On 03/06/2016 05:51 PM, Carsten Varming wrote:
>> Dear Jon,
>>
>> Thank you for sponsoring.
>>
>> I am not sure about your intended change to the patch. If
>> fix_relocations, then there are two cases where I remove the nmethod
>> from the scavengable list: 1. If the nmethod is not live. 2. If the
>> nmethod is live and it does not have scavengable roots. With your
>> suggested code change I don't think I can cover both cases without
>> code duplication. So I think it is best to leave the logic as is.
>
> Ok.
>
>>
>> Regarding you proposed comment about the precision of
>> detect_scavenge_root_oops.
>> // Unless the relocations have been updated (fixed), the
>> // detect_scavenge_root_oops() will not be precise so skip
>> // the check to unlink. Note that not doing the unlinking
>> // is safe but less optimal.
>>
>> I don't know what you mean when you say "detect_scavenge_root_oops()
>> will not be precise". The method fix_relocations() in every closure
>> that might move an object returns true (I carefully checked all
>> collectors except G1 (which does not use the list)), so there should
>> never be a time where an nmethod is left in a state where
>> detect_scavenge_root_oops is wrong. You are right that
>> non-scavengable nmethods on the list is fine, but I disagree about it
>> being less than optimal (see next comment).
>>
>> The reason I chose to not prune nmethods when !fix_relocations is
>> that I don't expect to be able to prune any live nmethods. To prune a
>> live nmethod from the list all oops in the nmethod must be
>> non-scavengable (oops::is_scavengable() must return false). In all
>> collectors today, fix_relocations is true if an object might be
>> moved. Hence the only time the list might contain a non-scavengable
>> nmethod is between line 663 and 668 in my patch and between an oop
>> moved by a full collection and the prune method called at the end of
>> said collection. As every live nmethod on the list is expected to be
>> scavengable (with the exceptions already listed) pruning the list
>> when objects have not moved seems like a waste. What about dead
>> nmethods? I don't think pruning dead nmethods really makes a
>> difference, but I would be happy to change the code to prune them
>> regardless of the value of fix_relocations.
>
> I think you are correct so no need to make a change.
>
>>
>> I added the following comment
>> // The scavengable nmethod list must contain all methods with
>> scavengable
>> // oops. It is safe to include more nmethod on the list, but we do not
>> // expect any live non-scavengable nmethods on the list.
>> I hope that covers your intention.
>
> Thanks for the added comment.
>>
>> I updated the webrev at
>> http://cr.openjdk.java.net/~cvarming/scavenge_nmethods_auto_prune/2/
>>
>> with the comment.
>
> I'll push this version.
>
> Jon
>
>>
>> Carsten
>>
>> On Fri, Mar 4, 2016 at 1:52 PM, Jon Masamitsu
>> > wrote:
>>
>> Carsten,
>>
>> There will be a couple of days delay in pushing this
>> change. The runtime repository is closed at the
>> moment but hopefully will be open again in a day
>> or two.
>>
>> Jon
>>
>>
>> On 03/04/2016 10:23 AM, Carsten Varming wrote:
>>> Dear Christian,
>>>
>>> Thank you for your review.
>>>
>>> Carsten
>>>
>>> On Fri, Mar 4, 2016 at 12:50 PM, Christian Thalinger
>>> >> > wrote:
>>>
>>> Jon asked me to have a quick look over the code cache
>>> changes. Looks good to me.
>>>
>>> > On Mar 3, 2016, at 1:46 PM, Jon Masamitsu
>>> >
>>> wrote:
>>> >
>>> > Carsten,
>>> >
>>> > Changes look good.
>>> >
>>> > A couple of suggestions.
>>> >
>>> >
>>> http://cr.openjdk.java.net/~cvarming/scavenge_nmethods_auto_prune/2/src/share/vm/code/codeCache.cpp.frames.html
>>>
>>> >
>>> > 661 if (is_live) {
>>> > 662 // Perform cur->oops_do(f), maybe just once per
>>> nmethod.
>>> > 663 f->do_code_blob(cur);
>>> > 664 }
>>> > 665 nmethod* const next = cur->scavenge_root_link();
>>> > 666 if (fix_relocations) {
>>> > 667 if (!is_live || !cur->detect_scavenge_root_oops()) {
>>> > 668 unlink_scavenge_root_nmethod(cur, prev);
>>> > 669 } else {
>>> > 670 prev = cur;
>>> > 671 }
>>> > 672 }
>>> > 673 cur = next;
>>> >
>>> > Although this does not change the actions, I find this
>>> easier to
>>> > read. You and Tony (and whoever else wants to) can vote
>>> > on it.
>>> >
>>> > if (is_live) { ... } else {
>>> > if (fix_relocations) { if
>>> (cur->detect_scavenge_root_oops()) { prev = cur; } else {
>>> unlink_scavenge_root_nmethod(cur, prev);} } cur =
>>> cur->scavenge_root_link(); }
>>> >
>>> > Also I'd suggest a comment before the if-test
>>> > if you find it correct.
>>> >
>>> > // Unless the relocations have been updated (fixed), the //
>>> detect_scavenge_root_oops() will not be precise so skip //
>>> the check to unlink. Note that not doing the unlinking // is
>>> safe but less optimal. if (fix_relocations) {
>>> >
>>> > The comment in the header file for fix_relocations helped
>>> > but a comment here might be helpful.
>>> >
>>> > I'll sponsor.
>>> >
>>> > Jon
>>> >
>>> > On 2/28/2016 6:16 PM, Carsten Varming wrote:
>>> >> Dear Hotspot developers,
>>> >>
>>> >> Any chance of a review of this patch? The patch cut
>>> between 7ms and 10ms of every ParNew with one application at
>>> Twitter and I expect a 1-2ms improvement for most applications.
>>> >>
>>> >> I touch the code cache and GenCollectedHeap, so I assume I
>>> need reviews from both gc and compiler reviewers. Thank you
>>> Tony Printezis for the review (posted on the hotspot-gc-dev
>>> list).
>>> >>
>>> >> I also need a sponsor.
>>> >>
>>> >> Carsten
>>> >>
>>> >> On Fri, Feb 19, 2016 at 10:52 AM, Carsten Varming
>>> >> >> >> wrote:
>>> >>
>>> >> Dear Hotspot developers,
>>> >>
>>> >> I would like to contribute a patch for JDK-8150013
>>> >> . The
>>> current
>>> >> webrev can be found here:
>>> >>
>>> http://cr.openjdk.java.net/~cvarming/scavenge_nmethods_auto_prune/2/
>>>
>>> >>
>>> .
>>> >>
>>> >> Suggestions for improvements are very welcome.
>>> >>
>>> >> Carsten
>>> >>
>>> >>
>>> >
>>>
>>>
>>
>>
>
From stefan.karlsson at oracle.com Tue Mar 8 10:33:30 2016
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Tue, 8 Mar 2016 11:33:30 +0100
Subject: RFR: 8151436: Leaner ArrayAllocator and BitMaps
Message-ID: <56DEAA7A.1000200@oracle.com>
Hi all,
Please review this patch to remove the state variables from
ArrayAllocator and make it an AllStatic class instead. The main
motivation for this patch is to cleanup the BitMaps data structure and
make the instances smaller.
The patch builds on the fact that the current code invokes AllocateHeap
with the default value AllocFailEnum:EXIT_OOM, and therefore never
returns NULL. This means that use_malloc will never be reset and the
allocation strategy used (malloc or mmap) can be determined by simply
looking at the size input parameter. Instead of changing the code to use
AllocateHeap with AllocFailEnum::RETURN_NULL, I chose to keep the
current behavior so that we could cleanup and minimize the size of our
BitMaps.
http://cr.openjdk.java.net/~stefank/8151436/webrev/
https://bugs.openjdk.java.net/browse/JDK-8151436
Thanks,
StefanK
From stefan.karlsson at oracle.com Tue Mar 8 10:52:16 2016
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Tue, 8 Mar 2016 11:52:16 +0100
Subject: RFR: 8151439: Inline the BitMap constructor
Message-ID: <56DEAEE0.5020708@oracle.com>
Hi all,
Please review this patch to inline the BitMap constructor. This will
allow us to efficiently use temporary, stack-allocated BitMaps.
http://cr.openjdk.java.net/~stefank/8151439/webrev.00/
https://bugs.openjdk.java.net/browse/JDK-8151439
A code example of why we want to inline the BitMap constructor:
void MyClass::set_bit(idx_t x) {
BitMap(&_bits, BitsPerWord).par_set_bit(x).
}
We could have used an instance of a BitMap in MyClass, but that would
store both a bm_word_t* and the size of the bitmap storage in MyClass.
Since the size is a compile-time constant, we can use the above
construct to only store a bm_word_t field in MyClass, and thereby reduce
the size of MyClass. By inlining the constructor, we get rid of the
extra overhead of creating a BitMap.
Thanks,
StefanK
From thomas.schatzl at oracle.com Tue Mar 8 11:09:44 2016
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Tue, 08 Mar 2016 12:09:44 +0100
Subject: RFR: 8151439: Inline the BitMap constructor
In-Reply-To: <56DEAEE0.5020708@oracle.com>
References: <56DEAEE0.5020708@oracle.com>
Message-ID: <1457435384.2272.9.camel@oracle.com>
Hi Stefan,
On Tue, 2016-03-08 at 11:52 +0100, Stefan Karlsson wrote:
> Hi all,
>
> Please review this patch to inline the BitMap constructor. This will
> allow us to efficiently use temporary, stack-allocated BitMaps.
>
> http://cr.openjdk.java.net/~stefank/8151439/webrev.00/
> https://bugs.openjdk.java.net/browse/JDK-8151439
>
> A code example of why we want to inline the BitMap constructor:
> void MyClass::set_bit(idx_t x) {
> BitMap(&_bits, BitsPerWord).par_set_bit(x).
> }
>
> We could have used an instance of a BitMap in MyClass, but that would
> store both a bm_word_t* and the size of the bitmap storage in
> MyClass.
> Since the size is a compile-time constant, we can use the above
> construct to only store a bm_word_t field in MyClass, and thereby
> reduce
> the size of MyClass. By inlining the constructor, we get rid of the
> extra overhead of creating a BitMap.
looks good.
Thanks,
Thomas
From thomas.schatzl at oracle.com Tue Mar 8 11:10:55 2016
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Tue, 08 Mar 2016 12:10:55 +0100
Subject: RFR: 8151436: Leaner ArrayAllocator and BitMaps
In-Reply-To: <56DEAA7A.1000200@oracle.com>
References: <56DEAA7A.1000200@oracle.com>
Message-ID: <1457435455.2272.10.camel@oracle.com>
Hi Stefan,
On Tue, 2016-03-08 at 11:33 +0100, Stefan Karlsson wrote:
> Hi all,
>
> Please review this patch to remove the state variables from
> ArrayAllocator and make it an AllStatic class instead. The main
> motivation for this patch is to cleanup the BitMaps data structure
> and
> make the instances smaller.
>
> The patch builds on the fact that the current code invokes
> AllocateHeap
> with the default value AllocFailEnum:EXIT_OOM, and therefore never
> returns NULL. This means that use_malloc will never be reset and the
> allocation strategy used (malloc or mmap) can be determined by simply
> looking at the size input parameter. Instead of changing the code to
> use
> AllocateHeap with AllocFailEnum::RETURN_NULL, I chose to keep the
> current behavior so that we could cleanup and minimize the size of
> our
> BitMaps.
>
> http://cr.openjdk.java.net/~stefank/8151436/webrev/
> https://bugs.openjdk.java.net/browse/JDK-8151436
looks good.
Thomas
From stefan.karlsson at oracle.com Tue Mar 8 11:15:51 2016
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Tue, 8 Mar 2016 12:15:51 +0100
Subject: RFR: 8151440: Move BitMap verfication inline functions out from
bitMap.hpp
In-Reply-To: <56DEB3FF.1020200@oracle.com>
References: <56DEB3FF.1020200@oracle.com>
Message-ID: <56DEB467.3040807@oracle.com>
This was intended to go to the hotspot-dev list. BCC:ing hotspot-gc-dev.
Please reply to this mail to review this patch.
StefanK
On 2016-03-08 12:14, Stefan Karlsson wrote:
> Hi all,
>
> Please review to fix include problems with the bitMap files.
>
> http://cr.openjdk.java.net/~stefank/8151440/webrev.00/
> https://bugs.openjdk.java.net/browse/JDK-8151440
>
> Some verification code in bitMap.inline.hpp is used from bitMap.hpp.
> This adds a requirement that bitMap.inline.hpp always have to be
> included when bitMap.hpp is included, otherwise the compiler will
> complain.
>
> The patch fixes this by moving the verification/debugging code to the
> cpp file, and the move some inlined functions from bitMap.hpp to
> bitMap.inline.hpp.
>
> Thanks,
> StefanK
From thomas.schatzl at oracle.com Tue Mar 8 11:19:13 2016
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Tue, 08 Mar 2016 12:19:13 +0100
Subject: RFR: 8151440: Move BitMap verfication inline functions out from
bitMap.hpp
In-Reply-To: <56DEB467.3040807@oracle.com>
References: <56DEB3FF.1020200@oracle.com> <56DEB467.3040807@oracle.com>
Message-ID: <1457435953.2272.11.camel@oracle.com>
Hi,
On Tue, 2016-03-08 at 12:15 +0100, Stefan Karlsson wrote:
> This was intended to go to the hotspot-dev list. BCC:ing hotspot-gc
> -dev.
>
> Please reply to this mail to review this patch.
>
looks good.
Thomas
From martin.doerr at sap.com Tue Mar 8 11:33:01 2016
From: martin.doerr at sap.com (Doerr, Martin)
Date: Tue, 8 Mar 2016 11:33:01 +0000
Subject: RFR(M) 8150353: PPC64LE: Support RTM on linux
In-Reply-To: <56DDC5C7.3000105@oracle.com>
References: <56CE0975.8060807@linux.vnet.ibm.com> <56CE42AE.7080605@oracle.com>
<10c9a1cb6d9b40618a094283ac838038@DEWDFE13DE14.global.corp.sap>
<56CFB72C.7030401@oracle.com>
<56DDC5C7.3000105@oracle.com>
Message-ID:
Hi Vladimir,
thanks for the explanation and for sponsoring the change.
We have noticed that jbb2005 benefits from both, RTM stack locking (with RTM deopt) and from Biased Locking so we thought it would be nice to have both. But UseRTMForStackLocks is still experimental. Seems like there are plenty of things people could play with in the future.
Best regards,
Martin
-----Original Message-----
From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com]
Sent: Montag, 7. M?rz 2016 19:18
To: Doerr, Martin ; Gustavo Romero ; hotspot-dev at openjdk.java.net
Cc: brenohl at br.ibm.com
Subject: Re: RFR(M) 8150353: PPC64LE: Support RTM on linux
RTM's assumption is: "RTM locking is most useful when there is high lock
contention and low data contention. With high lock contention the lock
is usually inflated and biased locking is not suitable for that case
anyway." It is not the case with jbb2005. And that is why RTM is off by
default.
First RTM implementation used BiasedLocking bits in object's markword.
Later it was implemented differently but there was still a concern that
to make them work together we may need more changes. We thought that we
will do that as separate project later. But currently we don't have a
plan for doing this.
Regards,
Vladimir
On 3/7/16 2:29 AM, Doerr, Martin wrote:
> Hi Vladimir,
>
> thank you very much for the detailed analysis.
> I hope an #ifdef PPC64 is ok in the shared code?
>
> I had written something to Gustavo about the performance problem we have with RTM in SPEC jbb2005:
>
>> The following issue is important for performance work:
>> RTM does not work with BiasedLocking. The latter gets switched off if RTM is activated which has a large performance impact (especially in jbb2005).
>> I would disable it for a reference measurement:
>> -XX:-UseBiasedLocking
>>
>> Unfortunately, RTM was slower than BiasedLocking but faster than the reference (without both) which tells me that there's room for improvement.
>> There are basically 3 classes of locks:
>> 1. no contention
>> 2. contention on lock, low contention on data
>> 3. high contention on data
>>
>> I believe the optimal treatment for the cases would be:
>> 1. Biased Locking
>> 2. Transactional Memory
>> 3. classical locking with lock inflating
>>
>> I think it would be good if the JVM could optimize for all these cases in the future. But that would add additional complexity and code size.
>
> Do you think this is something which should be improved in the future?
> We could try e.g. the following approach
> - try biased
> - deoptimize if it doesn't work well, try transactional
> - deoptimize if it doesn't work well, use classical locking (with inflating)
>
> Best regards,
> Martin
>
>
> -----Original Message-----
> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com]
> Sent: Freitag, 26. Februar 2016 03:24
> To: Doerr, Martin ; Gustavo Romero ; hotspot-dev at openjdk.java.net
> Cc: brenohl at br.ibm.com
> Subject: Re: RFR(M) 8150353: PPC64LE: Support RTM on linux
>
> The problem with increasing ScratchBufferBlob size is that with Tiered
> compilation we scale number of compiler threads based on cpu count and
> increase space in CodeCache accordingly:
>
> code_buffers_size += c2_count * C2Compiler::initial_code_buffer_size();
>
> I did experiment on Intel setting ON all RTM flags which can increase
> size of lock code:
>
> $ java -XX:+UnlockExperimentalVMOptions -XX:+UnlockDiagnosticVMOptions
> -XX:+UseRTMLocking -XX:+UseRTMDeopt -XX:+UseRTMForStackLocks
> -XX:+PrintPreciseRTMLockingStatistics -XX:+PrintFlagsFinal -version
> |grep RTM
> Java HotSpot(TM) 64-Bit Server VM warning: UseRTMLocking is only
> available as experimental option on this platform.
> bool PrintPreciseRTMLockingStatistics := true
> {C2 diagnostic}
> intx RTMAbortRatio = 50
> {ARCH experimental}
> intx RTMAbortThreshold = 1000
> {ARCH experimental}
> intx RTMLockingCalculationDelay = 0
> {ARCH experimental}
> intx RTMLockingThreshold = 10000
> {ARCH experimental}
> uintx RTMRetryCount = 5
> {ARCH product}
> intx RTMSpinLoopCount = 100
> {ARCH experimental}
> intx RTMTotalCountIncrRate = 64
> {ARCH experimental}
> bool UseRTMDeopt := true
> {ARCH product}
> bool UseRTMForStackLocks := true
> {ARCH experimental}
> bool UseRTMLocking := true
> {ARCH product}
> bool UseRTMXendForLockBusy = true
> {ARCH experimental}
>
>
> I added next lines to the end of Compile::scratch_emit_size() method:
>
> if (n->is_Mach() && n->as_Mach()->ideal_Opcode() == Op_FastLock) {
> tty->print_cr("======== FastLock size: %d ==========",
> buf.total_content_size());
> }
> if (n->is_Mach() && n->as_Mach()->ideal_Opcode() == Op_FastUnlock) {
> tty->print_cr("======== FastUnlock size: %d ==========",
> buf.total_content_size());
> }
>
> and got:
>
> ======== FastLock size: 657 ==========
> ======== FastUnlock size: 175 ==========
>
> Thanks,
> Vladimir
>
> On 2/25/16 3:43 AM, Doerr, Martin wrote:
>> Hi Vladimir,
>>
>> thanks for taking a look.
>>
>> About version values:
>> We are using a similar scheme for version checks on AIX where we know that the version values are less than 256.
>> It makes comparisons much more convenient.
>> But I agree that we should double-check if it is guaranteed for linux as well (and possibly add an assertion).
>>
>> About scratch buffer size:
>> We only noticed that the scratch buffer was too small when we enable all RTM features:
>> -XX:+UnlockExperimentalVMOptions -XX:+UseRTMLocking -XX:+UseRTMForStackLocks -XX:+UseRTMDeopt
>> We have only tried on PPC64, but I wonder if the current size is sufficient for x86. I currently don't have access to a Skylake machine.
>>
>> I think adding 1024 bytes to the scratch buffer doesn't hurt.
>> (It may also lead to larger CodeBuffers in output.cpp but I don't think this is problematic as long as the real content gets copied to nmethods.)
>> Would you agree?
>>
>> Best regards,
>> Martin
>>
>> -----Original Message-----
>> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com]
>> Sent: Donnerstag, 25. Februar 2016 00:54
>> To: Gustavo Romero ; Doerr, Martin ; hotspot-dev at openjdk.java.net
>> Cc: brenohl at br.ibm.com
>> Subject: Re: RFR(M) 8150353: PPC64LE: Support RTM on linux
>>
>> My concern (but I am not export) is Linux version encoding. Is it true
>> that each value in x.y.z is less then 256? Why not keep them as separate
>> int values?
>> I also thought we have OS versions in make files but we check only gcc
>> version there.
>>
>> Do you have problem with ScratchBufferBlob only on PPC or on some other
>> platforms too? May be we should make MAX_inst_size as platform specific
>> value.
>>
>> Thanks,
>> Vladimir
>>
>> On 2/24/16 11:50 AM, Gustavo Romero wrote:
>>> Hi Martin,
>>>
>>> Both little and big endian Linux kernel contain the syscall change, so
>>> I did not include:
>>>
>>> #if defined(COMPILER2) && (defined(AIX) || defined(VM_LITTLE_ENDIAN)
>>>
>>> in globalDefinitions_ppc.hpp.
>>>
>>> Please, could you review the following change?
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8150353
>>> Webrev (hotspot): http://81.de.7a9f.ip4.static.sl-reverse.com/webrev/
>>>
>>> Summary:
>>>
>>> * Enable RTM support for Linux on PPC64 (LE and BE).
>>> * Fix C2 compiler buffer size issue.
>>>
>>> Thank you.
>>>
>>> Regards,
>>> Gustavo
>>>
From per.liden at oracle.com Tue Mar 8 12:35:54 2016
From: per.liden at oracle.com (Per Liden)
Date: Tue, 8 Mar 2016 13:35:54 +0100
Subject: RFR: 8151436: Leaner ArrayAllocator and BitMaps
In-Reply-To: <56DEAA7A.1000200@oracle.com>
References: <56DEAA7A.1000200@oracle.com>
Message-ID: <56DEC72A.6010102@oracle.com>
Looks good!
/Per
On 2016-03-08 11:33, Stefan Karlsson wrote:
> Hi all,
>
> Please review this patch to remove the state variables from
> ArrayAllocator and make it an AllStatic class instead. The main
> motivation for this patch is to cleanup the BitMaps data structure and
> make the instances smaller.
>
> The patch builds on the fact that the current code invokes AllocateHeap
> with the default value AllocFailEnum:EXIT_OOM, and therefore never
> returns NULL. This means that use_malloc will never be reset and the
> allocation strategy used (malloc or mmap) can be determined by simply
> looking at the size input parameter. Instead of changing the code to use
> AllocateHeap with AllocFailEnum::RETURN_NULL, I chose to keep the
> current behavior so that we could cleanup and minimize the size of our
> BitMaps.
>
> http://cr.openjdk.java.net/~stefank/8151436/webrev/
> https://bugs.openjdk.java.net/browse/JDK-8151436
>
> Thanks,
> StefanK
From per.liden at oracle.com Tue Mar 8 12:37:37 2016
From: per.liden at oracle.com (Per Liden)
Date: Tue, 8 Mar 2016 13:37:37 +0100
Subject: RFR: 8151440: Move BitMap verfication inline functions out from
bitMap.hpp
In-Reply-To: <56DEB467.3040807@oracle.com>
References: <56DEB3FF.1020200@oracle.com> <56DEB467.3040807@oracle.com>
Message-ID: <56DEC791.6040108@oracle.com>
Looks good!
/Per
On 2016-03-08 12:15, Stefan Karlsson wrote:
> This was intended to go to the hotspot-dev list. BCC:ing hotspot-gc-dev.
>
> Please reply to this mail to review this patch.
>
> StefanK
>
> On 2016-03-08 12:14, Stefan Karlsson wrote:
>> Hi all,
>>
>> Please review to fix include problems with the bitMap files.
>>
>> http://cr.openjdk.java.net/~stefank/8151440/webrev.00/
>> https://bugs.openjdk.java.net/browse/JDK-8151440
>>
>> Some verification code in bitMap.inline.hpp is used from bitMap.hpp.
>> This adds a requirement that bitMap.inline.hpp always have to be
>> included when bitMap.hpp is included, otherwise the compiler will
>> complain.
>>
>> The patch fixes this by moving the verification/debugging code to the
>> cpp file, and the move some inlined functions from bitMap.hpp to
>> bitMap.inline.hpp.
>>
>> Thanks,
>> StefanK
>
From per.liden at oracle.com Tue Mar 8 12:38:42 2016
From: per.liden at oracle.com (Per Liden)
Date: Tue, 8 Mar 2016 13:38:42 +0100
Subject: RFR: 8151439: Inline the BitMap constructor
In-Reply-To: <56DEAEE0.5020708@oracle.com>
References: <56DEAEE0.5020708@oracle.com>
Message-ID: <56DEC7D2.3020108@oracle.com>
Looks good!
/Per
On 2016-03-08 11:52, Stefan Karlsson wrote:
> Hi all,
>
> Please review this patch to inline the BitMap constructor. This will
> allow us to efficiently use temporary, stack-allocated BitMaps.
>
> http://cr.openjdk.java.net/~stefank/8151439/webrev.00/
> https://bugs.openjdk.java.net/browse/JDK-8151439
>
> A code example of why we want to inline the BitMap constructor:
> void MyClass::set_bit(idx_t x) {
> BitMap(&_bits, BitsPerWord).par_set_bit(x).
> }
>
> We could have used an instance of a BitMap in MyClass, but that would
> store both a bm_word_t* and the size of the bitmap storage in MyClass.
> Since the size is a compile-time constant, we can use the above
> construct to only store a bm_word_t field in MyClass, and thereby reduce
> the size of MyClass. By inlining the constructor, we get rid of the
> extra overhead of creating a BitMap.
>
> Thanks,
> StefanK
From paul.sandoz at oracle.com Tue Mar 8 13:06:37 2016
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 8 Mar 2016 14:06:37 +0100
Subject: RFR 8151163 All Buffer implementations should leverage Unsafe
unaligned accessors
Message-ID: <142D9ABF-C144-42E6-9FA2-48A90A51C3A9@oracle.com>
Hi,
Please pre-emptively review a fix to update the buffer implementations to leverage the Unsafe unaligned accessors:
http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8151163-buffer-unsafe-unaligned-access/webrev/
http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8151163-buffer-unsafe-unaligned-access-hotspot/webrev/
The JDK changes depend on those for the following which is in CCC review:
https://bugs.openjdk.java.net/browse/JDK-8149469
ByteBuffer API and implementation enhancements for VarHandles
http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8149469-byte-buffer-align-and-unifying-enhancements/webrev/
The changes in this webrev take advantage of those for JDK-8149469 and apply the unsafe double addressing scheme so certain byte buffer view implementations can work across heap and direct buffers. This should improve the performance on x86 for:
1) direct ByteBuffers using the wider unit size method accessors; and
2) wider unit size views over heap ByteBuffers.
As a consequence Bits.java has greatly reduced in size :-)
The HotSpot changes update the test that was originally added when the heap ByteBuffer method accessors were updated to utilise unsafe unaligned access. I split the test out so as to reduce the execution time, since I doubled the amount of tests. These tests could be improved for views at various unaligned/unaligned positions in the byte buffer, but i left that for now.
I plan to push through hs-comp since JDK-8149469 will go through hs-comp.
Later on today i will kick of a JPRT hotspot test run.
?
This is a small step towards unifying the buffer implementations using the unsafe double addressing scheme:
https://bugs.openjdk.java.net/browse/JDK-6509032
Thanks,
Paul.
From aleksey.shipilev at oracle.com Tue Mar 8 13:37:39 2016
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Tue, 8 Mar 2016 16:37:39 +0300
Subject: RFR 8151163 All Buffer implementations should leverage Unsafe
unaligned accessors
In-Reply-To: <142D9ABF-C144-42E6-9FA2-48A90A51C3A9@oracle.com>
References: <142D9ABF-C144-42E6-9FA2-48A90A51C3A9@oracle.com>
Message-ID: <56DED5A3.8030603@oracle.com>
On 03/08/2016 04:06 PM, Paul Sandoz wrote:
> Please pre-emptively review a fix to update the buffer implementations to leverage the Unsafe unaligned accessors:
>
> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8151163-buffer-unsafe-unaligned-access/webrev/
*) My concern with using double-register Unsafe calls is that compilers
are unable to speculate on (hb == null) value, which means you will have
the additional field read on the fast path. See:
https://bugs.openjdk.java.net/browse/JDK-8150921
http://cr.openjdk.java.net/~shade/8150921/notes.txt
So, while I agree that using double-register unaligned accessors are
cleaner, I'd try to special-case (bb.hb == null) case for Heap* buffers.
Current patch might still be better than going through Bits though.
> The changes in this webrev take advantage of those for JDK-8149469
> and apply the unsafe double addressing scheme so certain byte buffer
> view implementations can work across heap and direct buffers. This
> should improve the performance on x86 for:
I understand the idea, but I think we would need to verify this before
pushing.
Thanks,
-Aleksey
From paul.sandoz at oracle.com Tue Mar 8 18:27:33 2016
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 8 Mar 2016 19:27:33 +0100
Subject: RFR 8151163 All Buffer implementations should leverage Unsafe
unaligned accessors
In-Reply-To: <56DED5A3.8030603@oracle.com>
References: <142D9ABF-C144-42E6-9FA2-48A90A51C3A9@oracle.com>
<56DED5A3.8030603@oracle.com>
Message-ID:
> On 8 Mar 2016, at 14:37, Aleksey Shipilev wrote:
>
> On 03/08/2016 04:06 PM, Paul Sandoz wrote:
>> Please pre-emptively review a fix to update the buffer implementations to leverage the Unsafe unaligned accessors:
>>
>> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8151163-buffer-unsafe-unaligned-access/webrev/
>
> *) My concern with using double-register Unsafe calls is that compilers
> are unable to speculate on (hb == null) value, which means you will have
> the additional field read on the fast path. See:
> https://bugs.openjdk.java.net/browse/JDK-8150921
> http://cr.openjdk.java.net/~shade/8150921/notes.txt
>
> So, while I agree that using double-register unaligned accessors are
> cleaner, I'd try to special-case (bb.hb == null) case for Heap* buffers.
> Current patch might still be better than going through Bits though.
>
The fix is conservative. I did not change anything in direct buffer that currently uses the single addressing mode, that?s a much larger change of course, and as you point out requires deeper investigation.
To clarify there are two kinds of change:
1) The access methods of direct ByteBuffer, such as getInt etc now use the unaligned accessors.
Direct-X-Buffer-bin.java.template
?
private $type$ get$Type$(long a) {
- if (unaligned) {
- $memtype$ x = unsafe.get$Memtype$(a);
- return $fromBits$(nativeByteOrder ? x : Bits.swap(x));
- }
- return Bits.get$Type$(a, bigEndian);
+ $memtype$ x = unsafe.get$Memtype$Unaligned(null, a, bigEndian);
+ return $fromBits$(x);
}
public $type$ get$Type$() {
@@ -51,12 +48,8 @@
private ByteBuffer put$Type$(long a, $type$ x) {
#if[rw]
- if (unaligned) {
- $memtype$ y = $toBits$(x);
- unsafe.put$Memtype$(a, (nativeByteOrder ? y : Bits.swap(y)));
- } else {
- Bits.put$Type$(a, x, bigEndian);
- }
+ $memtype$ y = $toBits$(x);
+ unsafe.put$Memtype$Unaligned(null, a, y, bigEndian);
return this;
#else[rw]
throw new ReadOnlyBufferException();
Note the use of null here, so we should fine for this case.
2) Changes to the view implementations used by heap buffer for aligned and misaligned access and direct byte buffer for misaligned access. This is where we replace the singular call to bits:
ByteBufferAs-X-Buffer.java.template
?
public $type$ get() {
- return Bits.get$Type$$BO$(bb, ix(nextGetIndex()));
+ $memtype$ x = unsafe.get$Memtype$Unaligned(bb.hb, bb.address + ix(nextGetIndex()),
+ {#if[boB]?true:false});
+ return $fromBits$(x);
}
public $type$ get(int i) {
- return Bits.get$Type$$BO$(bb, ix(checkIndex(i)));
+ $memtype$ x = unsafe.get$Memtype$Unaligned(bb.hb, bb.address + ix(checkIndex(i)),
+ {#if[boB]?true:false});
+ return $fromBits$(x);
}
This should be an improvement when used by heap ByteBuffer implementations, much the same way it was when previously changing the heap ByteBuffer accessors to use Unsafe unaligned access.
So that leaves the direct ByteBuffer case:
DirectByteBuffer
?
public IntBuffer asIntBuffer() {
int off = this.position();
int lim = this.limit();
assert (off <= lim);
int rem = (off <= lim ? lim - off : 0);
int size = rem >> 2;
if (!unaligned && ((address + off) % (1 << 2) != 0)) {
return (bigEndian
? (IntBuffer)(new ByteBufferAsIntBufferB(this,
-1,
0,
size,
size,
off))
: (IntBuffer)(new ByteBufferAsIntBufferL(this,
-1,
0,
size,
size,
off)));
Specially the same implementations used by heap ByteBuffers are used here for misaligned view access. In this case it?s Bits (with N ByteBuffer.get/put calls + composition to/from the wider unit) vs. Unsafe unaligned access + field read of hb (which is null), where the latter Unsafe access might be an intrinsic. On x86 that should be a win.
One goal here is to consistently use the Unsafe unaligned access to leverage any intrinsification now, or in the future, on other platforms e.g. SPARC.
>> The changes in this webrev take advantage of those for JDK-8149469
>> and apply the unsafe double addressing scheme so certain byte buffer
>> view implementations can work across heap and direct buffers. This
>> should improve the performance on x86 for:
>
> I understand the idea, but I think we would need to verify this before
> pushing.
>
Admittedly i am leaning on the rational/motivation for the previous changes to use Unsafe unaligned accessors.
I less confident about the impact on non-x86 platforms.
I have some VarHandles related benchmark code [*] i can use to get some numbers.
Paul.
[*] But getting side-tracked with a VH perf regressions i observed when running the test, something has changed underneath me in hs-comp that is causing the linkage to not wire up optimally :-(
From kim.barrett at oracle.com Tue Mar 8 19:31:46 2016
From: kim.barrett at oracle.com (Kim Barrett)
Date: Tue, 8 Mar 2016 14:31:46 -0500
Subject: RFR: 8151436: Leaner ArrayAllocator and BitMaps
In-Reply-To: <56DEAA7A.1000200@oracle.com>
References: <56DEAA7A.1000200@oracle.com>
Message-ID: <81BAD17B-729E-4591-9073-1D3579DF4439@oracle.com>
> On Mar 8, 2016, at 5:33 AM, Stefan Karlsson wrote:
>
> Hi all,
>
> Please review this patch to remove the state variables from ArrayAllocator and make it an AllStatic class instead. The main motivation for this patch is to cleanup the BitMaps data structure and make the instances smaller.
>
> The patch builds on the fact that the current code invokes AllocateHeap with the default value AllocFailEnum:EXIT_OOM, and therefore never returns NULL. This means that use_malloc will never be reset and the allocation strategy used (malloc or mmap) can be determined by simply looking at the size input parameter. Instead of changing the code to use AllocateHeap with AllocFailEnum::RETURN_NULL, I chose to keep the current behavior so that we could cleanup and minimize the size of our BitMaps.
>
> http://cr.openjdk.java.net/~stefank/8151436/webrev/
> https://bugs.openjdk.java.net/browse/JDK-8151436
>
> Thanks,
> StefanK
Looks good.
From kim.barrett at oracle.com Tue Mar 8 19:32:24 2016
From: kim.barrett at oracle.com (Kim Barrett)
Date: Tue, 8 Mar 2016 14:32:24 -0500
Subject: RFR: 8151440: Move BitMap verfication inline functions out from
bitMap.hpp
In-Reply-To: <56DEB467.3040807@oracle.com>
References: <56DEB3FF.1020200@oracle.com> <56DEB467.3040807@oracle.com>
Message-ID:
> On Mar 8, 2016, at 6:15 AM, Stefan Karlsson wrote:
>
> This was intended to go to the hotspot-dev list. BCC:ing hotspot-gc-dev.
>
> Please reply to this mail to review this patch.
>
> StefanK
>
> On 2016-03-08 12:14, Stefan Karlsson wrote:
>> Hi all,
>>
>> Please review to fix include problems with the bitMap files.
>>
>> http://cr.openjdk.java.net/~stefank/8151440/webrev.00/
>> https://bugs.openjdk.java.net/browse/JDK-8151440
>>
>> Some verification code in bitMap.inline.hpp is used from bitMap.hpp. This adds a requirement that bitMap.inline.hpp always have to be included when bitMap.hpp is included, otherwise the compiler will complain.
>>
>> The patch fixes this by moving the verification/debugging code to the cpp file, and the move some inlined functions from bitMap.hpp to bitMap.inline.hpp.
>>
>> Thanks,
>> StefanK
Looks good.
From kim.barrett at oracle.com Tue Mar 8 19:39:02 2016
From: kim.barrett at oracle.com (Kim Barrett)
Date: Tue, 8 Mar 2016 14:39:02 -0500
Subject: RFR: 8151439: Inline the BitMap constructor
In-Reply-To: <56DEAEE0.5020708@oracle.com>
References: <56DEAEE0.5020708@oracle.com>
Message-ID:
> On Mar 8, 2016, at 5:52 AM, Stefan Karlsson wrote:
>
> Hi all,
>
> Please review this patch to inline the BitMap constructor. This will allow us to efficiently use temporary, stack-allocated BitMaps.
>
> http://cr.openjdk.java.net/~stefank/8151439/webrev.00/
> https://bugs.openjdk.java.net/browse/JDK-8151439
>
> A code example of why we want to inline the BitMap constructor:
> void MyClass::set_bit(idx_t x) {
> BitMap(&_bits, BitsPerWord).par_set_bit(x).
> }
>
> We could have used an instance of a BitMap in MyClass, but that would store both a bm_word_t* and the size of the bitmap storage in MyClass. Since the size is a compile-time constant, we can use the above construct to only store a bm_word_t field in MyClass, and thereby reduce the size of MyClass. By inlining the constructor, we get rid of the extra overhead of creating a BitMap.
>
> Thanks,
> StefanK
Looks good.
------------------------------------------------------------------------------
src/share/vm/utilities/bitMap.cpp
37 assert(sizeof(bm_word_t) == BytesPerWord, "Implementation assumption.");
This assert can be removed too, due to the new STATIC_ASSERT.
------------------------------------------------------------------------------
From dmitry.dmitriev at oracle.com Wed Mar 9 10:58:03 2016
From: dmitry.dmitriev at oracle.com (Dmitry Dmitriev)
Date: Wed, 9 Mar 2016 13:58:03 +0300
Subject: RFR(XS): 8151304: Remove unused develop
options(ClearInterpreterLocals and others)
Message-ID: <56E001BB.1050300@oracle.com>
Hello,
Please, review this small patch which removes 4 unused develop options.
Code for these options was removed some time ago(additional details can
be found in the JBS).
JBS: https://bugs.openjdk.java.net/browse/JDK-8151304
webrev.00: http://cr.openjdk.java.net/~ddmitriev/8151304/webrev.00/
Testing: jprt
Thanks,
Dmitry
From stefan.karlsson at oracle.com Wed Mar 9 11:36:55 2016
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Wed, 9 Mar 2016 12:36:55 +0100
Subject: RFR: 8151439: Inline the BitMap constructor
In-Reply-To: <1457435384.2272.9.camel@oracle.com>
References: <56DEAEE0.5020708@oracle.com> <1457435384.2272.9.camel@oracle.com>
Message-ID: <56E00AD7.3050200@oracle.com>
Thanks, Thomas.
StefanK
On 2016-03-08 12:09, Thomas Schatzl wrote:
> Hi Stefan,
>
> On Tue, 2016-03-08 at 11:52 +0100, Stefan Karlsson wrote:
>> Hi all,
>>
>> Please review this patch to inline the BitMap constructor. This will
>> allow us to efficiently use temporary, stack-allocated BitMaps.
>>
>> http://cr.openjdk.java.net/~stefank/8151439/webrev.00/
>> https://bugs.openjdk.java.net/browse/JDK-8151439
>>
>> A code example of why we want to inline the BitMap constructor:
>> void MyClass::set_bit(idx_t x) {
>> BitMap(&_bits, BitsPerWord).par_set_bit(x).
>> }
>>
>> We could have used an instance of a BitMap in MyClass, but that would
>> store both a bm_word_t* and the size of the bitmap storage in
>> MyClass.
>> Since the size is a compile-time constant, we can use the above
>> construct to only store a bm_word_t field in MyClass, and thereby
>> reduce
>> the size of MyClass. By inlining the constructor, we get rid of the
>> extra overhead of creating a BitMap.
> looks good.
>
> Thanks,
> Thomas
From stefan.karlsson at oracle.com Wed Mar 9 11:37:12 2016
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Wed, 9 Mar 2016 12:37:12 +0100
Subject: RFR: 8151439: Inline the BitMap constructor
In-Reply-To: <56DEC7D2.3020108@oracle.com>
References: <56DEAEE0.5020708@oracle.com> <56DEC7D2.3020108@oracle.com>
Message-ID: <56E00AE8.5010807@oracle.com>
Thanks, Per.
StefanK
On 2016-03-08 13:38, Per Liden wrote:
> Looks good!
>
> /Per
>
> On 2016-03-08 11:52, Stefan Karlsson wrote:
>> Hi all,
>>
>> Please review this patch to inline the BitMap constructor. This will
>> allow us to efficiently use temporary, stack-allocated BitMaps.
>>
>> http://cr.openjdk.java.net/~stefank/8151439/webrev.00/
>> https://bugs.openjdk.java.net/browse/JDK-8151439
>>
>> A code example of why we want to inline the BitMap constructor:
>> void MyClass::set_bit(idx_t x) {
>> BitMap(&_bits, BitsPerWord).par_set_bit(x).
>> }
>>
>> We could have used an instance of a BitMap in MyClass, but that would
>> store both a bm_word_t* and the size of the bitmap storage in MyClass.
>> Since the size is a compile-time constant, we can use the above
>> construct to only store a bm_word_t field in MyClass, and thereby reduce
>> the size of MyClass. By inlining the constructor, we get rid of the
>> extra overhead of creating a BitMap.
>>
>> Thanks,
>> StefanK
From stefan.karlsson at oracle.com Wed Mar 9 11:37:40 2016
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Wed, 9 Mar 2016 12:37:40 +0100
Subject: RFR: 8151439: Inline the BitMap constructor
In-Reply-To:
References: <56DEAEE0.5020708@oracle.com>
Message-ID: <56E00B04.7020807@oracle.com>
On 2016-03-08 20:39, Kim Barrett wrote:
>> On Mar 8, 2016, at 5:52 AM, Stefan Karlsson wrote:
>>
>> Hi all,
>>
>> Please review this patch to inline the BitMap constructor. This will allow us to efficiently use temporary, stack-allocated BitMaps.
>>
>> http://cr.openjdk.java.net/~stefank/8151439/webrev.00/
>> https://bugs.openjdk.java.net/browse/JDK-8151439
>>
>> A code example of why we want to inline the BitMap constructor:
>> void MyClass::set_bit(idx_t x) {
>> BitMap(&_bits, BitsPerWord).par_set_bit(x).
>> }
>>
>> We could have used an instance of a BitMap in MyClass, but that would store both a bm_word_t* and the size of the bitmap storage in MyClass. Since the size is a compile-time constant, we can use the above construct to only store a bm_word_t field in MyClass, and thereby reduce the size of MyClass. By inlining the constructor, we get rid of the extra overhead of creating a BitMap.
>>
>> Thanks,
>> StefanK
> Looks good.
Thanks.
>
> ------------------------------------------------------------------------------
> src/share/vm/utilities/bitMap.cpp
> 37 assert(sizeof(bm_word_t) == BytesPerWord, "Implementation assumption.");
>
> This assert can be removed too, due to the new STATIC_ASSERT.
>
> ------------------------------------------------------------------------------
>
I'll remove this before pushing.
StefanK
From stefan.karlsson at oracle.com Wed Mar 9 11:38:26 2016
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Wed, 9 Mar 2016 12:38:26 +0100
Subject: RFR: 8151440: Move BitMap verfication inline functions out from
bitMap.hpp
In-Reply-To: <1457435953.2272.11.camel@oracle.com>
References: <56DEB3FF.1020200@oracle.com> <56DEB467.3040807@oracle.com>
<1457435953.2272.11.camel@oracle.com>
Message-ID: <56E00B32.1010003@oracle.com>
Thanks, Thomas.
StefanK
On 2016-03-08 12:19, Thomas Schatzl wrote:
> Hi,
>
> On Tue, 2016-03-08 at 12:15 +0100, Stefan Karlsson wrote:
>> This was intended to go to the hotspot-dev list. BCC:ing hotspot-gc
>> -dev.
>>
>> Please reply to this mail to review this patch.
>>
> looks good.
>
> Thomas
From stefan.karlsson at oracle.com Wed Mar 9 11:38:40 2016
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Wed, 9 Mar 2016 12:38:40 +0100
Subject: RFR: 8151440: Move BitMap verfication inline functions out from
bitMap.hpp
In-Reply-To: <56DEC791.6040108@oracle.com>
References: <56DEB3FF.1020200@oracle.com> <56DEB467.3040807@oracle.com>
<56DEC791.6040108@oracle.com>
Message-ID: <56E00B40.5010500@oracle.com>
Thanks, Per.
StefanK
On 2016-03-08 13:37, Per Liden wrote:
> Looks good!
>
> /Per
>
> On 2016-03-08 12:15, Stefan Karlsson wrote:
>> This was intended to go to the hotspot-dev list. BCC:ing hotspot-gc-dev.
>>
>> Please reply to this mail to review this patch.
>>
>> StefanK
>>
>> On 2016-03-08 12:14, Stefan Karlsson wrote:
>>> Hi all,
>>>
>>> Please review to fix include problems with the bitMap files.
>>>
>>> http://cr.openjdk.java.net/~stefank/8151440/webrev.00/
>>> https://bugs.openjdk.java.net/browse/JDK-8151440
>>>
>>> Some verification code in bitMap.inline.hpp is used from bitMap.hpp.
>>> This adds a requirement that bitMap.inline.hpp always have to be
>>> included when bitMap.hpp is included, otherwise the compiler will
>>> complain.
>>>
>>> The patch fixes this by moving the verification/debugging code to the
>>> cpp file, and the move some inlined functions from bitMap.hpp to
>>> bitMap.inline.hpp.
>>>
>>> Thanks,
>>> StefanK
>>
From stefan.karlsson at oracle.com Wed Mar 9 11:38:53 2016
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Wed, 9 Mar 2016 12:38:53 +0100
Subject: RFR: 8151440: Move BitMap verfication inline functions out from
bitMap.hpp
In-Reply-To:
References: <56DEB3FF.1020200@oracle.com> <56DEB467.3040807@oracle.com>
Message-ID: <56E00B4D.4090808@oracle.com>
Thanks, Kim.
StefanK
On 2016-03-08 20:32, Kim Barrett wrote:
>> On Mar 8, 2016, at 6:15 AM, Stefan Karlsson wrote:
>>
>> This was intended to go to the hotspot-dev list. BCC:ing hotspot-gc-dev.
>>
>> Please reply to this mail to review this patch.
>>
>> StefanK
>>
>> On 2016-03-08 12:14, Stefan Karlsson wrote:
>>> Hi all,
>>>
>>> Please review to fix include problems with the bitMap files.
>>>
>>> http://cr.openjdk.java.net/~stefank/8151440/webrev.00/
>>> https://bugs.openjdk.java.net/browse/JDK-8151440
>>>
>>> Some verification code in bitMap.inline.hpp is used from bitMap.hpp. This adds a requirement that bitMap.inline.hpp always have to be included when bitMap.hpp is included, otherwise the compiler will complain.
>>>
>>> The patch fixes this by moving the verification/debugging code to the cpp file, and the move some inlined functions from bitMap.hpp to bitMap.inline.hpp.
>>>
>>> Thanks,
>>> StefanK
> Looks good.
>
From stefan.karlsson at oracle.com Wed Mar 9 11:39:11 2016
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Wed, 9 Mar 2016 12:39:11 +0100
Subject: RFR: 8151436: Leaner ArrayAllocator and BitMaps
In-Reply-To: <1457435455.2272.10.camel@oracle.com>
References: <56DEAA7A.1000200@oracle.com> <1457435455.2272.10.camel@oracle.com>
Message-ID: <56E00B5F.2040504@oracle.com>
Thanks, Thomas.
StefanK
On 2016-03-08 12:10, Thomas Schatzl wrote:
> Hi Stefan,
>
> On Tue, 2016-03-08 at 11:33 +0100, Stefan Karlsson wrote:
>> Hi all,
>>
>> Please review this patch to remove the state variables from
>> ArrayAllocator and make it an AllStatic class instead. The main
>> motivation for this patch is to cleanup the BitMaps data structure
>> and
>> make the instances smaller.
>>
>> The patch builds on the fact that the current code invokes
>> AllocateHeap
>> with the default value AllocFailEnum:EXIT_OOM, and therefore never
>> returns NULL. This means that use_malloc will never be reset and the
>> allocation strategy used (malloc or mmap) can be determined by simply
>> looking at the size input parameter. Instead of changing the code to
>> use
>> AllocateHeap with AllocFailEnum::RETURN_NULL, I chose to keep the
>> current behavior so that we could cleanup and minimize the size of
>> our
>> BitMaps.
>>
>> http://cr.openjdk.java.net/~stefank/8151436/webrev/
>> https://bugs.openjdk.java.net/browse/JDK-8151436
> looks good.
>
> Thomas
>
From stefan.karlsson at oracle.com Wed Mar 9 11:39:24 2016
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Wed, 9 Mar 2016 12:39:24 +0100
Subject: RFR: 8151436: Leaner ArrayAllocator and BitMaps
In-Reply-To: <56DEC72A.6010102@oracle.com>
References: <56DEAA7A.1000200@oracle.com> <56DEC72A.6010102@oracle.com>
Message-ID: <56E00B6C.4030505@oracle.com>
Thanks, Per.
StefanK
On 2016-03-08 13:35, Per Liden wrote:
> Looks good!
>
> /Per
>
> On 2016-03-08 11:33, Stefan Karlsson wrote:
>> Hi all,
>>
>> Please review this patch to remove the state variables from
>> ArrayAllocator and make it an AllStatic class instead. The main
>> motivation for this patch is to cleanup the BitMaps data structure and
>> make the instances smaller.
>>
>> The patch builds on the fact that the current code invokes AllocateHeap
>> with the default value AllocFailEnum:EXIT_OOM, and therefore never
>> returns NULL. This means that use_malloc will never be reset and the
>> allocation strategy used (malloc or mmap) can be determined by simply
>> looking at the size input parameter. Instead of changing the code to use
>> AllocateHeap with AllocFailEnum::RETURN_NULL, I chose to keep the
>> current behavior so that we could cleanup and minimize the size of our
>> BitMaps.
>>
>> http://cr.openjdk.java.net/~stefank/8151436/webrev/
>> https://bugs.openjdk.java.net/browse/JDK-8151436
>>
>> Thanks,
>> StefanK
From stefan.karlsson at oracle.com Wed Mar 9 11:39:37 2016
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Wed, 9 Mar 2016 12:39:37 +0100
Subject: RFR: 8151436: Leaner ArrayAllocator and BitMaps
In-Reply-To: <81BAD17B-729E-4591-9073-1D3579DF4439@oracle.com>
References: <56DEAA7A.1000200@oracle.com>
<81BAD17B-729E-4591-9073-1D3579DF4439@oracle.com>
Message-ID: <56E00B79.9080602@oracle.com>
Thanks, Kim.
StefanK
On 2016-03-08 20:31, Kim Barrett wrote:
>> On Mar 8, 2016, at 5:33 AM, Stefan Karlsson wrote:
>>
>> Hi all,
>>
>> Please review this patch to remove the state variables from ArrayAllocator and make it an AllStatic class instead. The main motivation for this patch is to cleanup the BitMaps data structure and make the instances smaller.
>>
>> The patch builds on the fact that the current code invokes AllocateHeap with the default value AllocFailEnum:EXIT_OOM, and therefore never returns NULL. This means that use_malloc will never be reset and the allocation strategy used (malloc or mmap) can be determined by simply looking at the size input parameter. Instead of changing the code to use AllocateHeap with AllocFailEnum::RETURN_NULL, I chose to keep the current behavior so that we could cleanup and minimize the size of our BitMaps.
>>
>> http://cr.openjdk.java.net/~stefank/8151436/webrev/
>> https://bugs.openjdk.java.net/browse/JDK-8151436
>>
>> Thanks,
>> StefanK
> Looks good.
>
From jesper.wilhelmsson at oracle.com Wed Mar 9 13:12:46 2016
From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson)
Date: Wed, 9 Mar 2016 14:12:46 +0100
Subject: RFR(XS): 8151304: Remove unused develop
options(ClearInterpreterLocals and others)
In-Reply-To: <56E001BB.1050300@oracle.com>
References: <56E001BB.1050300@oracle.com>
Message-ID: <56E0214E.8050206@oracle.com>
Looks good!
/Jesper
Den 9/3/16 kl. 11:58, skrev Dmitry Dmitriev:
> Hello,
>
> Please, review this small patch which removes 4 unused develop options. Code for
> these options was removed some time ago(additional details can be found in the
> JBS).
>
> JBS: https://bugs.openjdk.java.net/browse/JDK-8151304
> webrev.00: http://cr.openjdk.java.net/~ddmitriev/8151304/webrev.00/
>
> Testing: jprt
>
> Thanks,
> Dmitry
From coleen.phillimore at oracle.com Wed Mar 9 13:20:52 2016
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Wed, 9 Mar 2016 08:20:52 -0500
Subject: RFR(XS): 8151304: Remove unused develop
options(ClearInterpreterLocals and others)
In-Reply-To: <56E0214E.8050206@oracle.com>
References: <56E001BB.1050300@oracle.com> <56E0214E.8050206@oracle.com>
Message-ID: <56E02334.90304@oracle.com>
Looks good!
Coleen
On 3/9/16 8:12 AM, Jesper Wilhelmsson wrote:
> Looks good!
> /Jesper
>
> Den 9/3/16 kl. 11:58, skrev Dmitry Dmitriev:
>> Hello,
>>
>> Please, review this small patch which removes 4 unused develop
>> options. Code for
>> these options was removed some time ago(additional details can be
>> found in the
>> JBS).
>>
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8151304
>> webrev.00: http://cr.openjdk.java.net/~ddmitriev/8151304/webrev.00/
>>
>> Testing: jprt
>>
>> Thanks,
>> Dmitry
From stefan.karlsson at oracle.com Wed Mar 9 14:28:02 2016
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Wed, 9 Mar 2016 15:28:02 +0100
Subject: RFR: 8151436: Leaner ArrayAllocator and BitMaps
In-Reply-To: <56DEAA7A.1000200@oracle.com>
References: <56DEAA7A.1000200@oracle.com>
Message-ID: <56E032F2.4050405@oracle.com>
Hi all,
I found a bug in the ArrayAllocator code. ArrayAllocator::free
incorrectly calls should_use_malloc(size_for_malloc(length)) when the
call should be should_use_malloc(length).
There is an -XX:+ExecuteInternalVMTests that exercises this code path,
and try to find these kinds of bugs. The test actually manages to call
allocate_malloc and then tries to free the memory with free_mmap, but
the JVM doesn't crash. One reason why it doesn't crash is that
os::release_memory, which is used by free_mmap, fails to unmap the
malloced memory and we silently ignores that.
This patch:
1) Adds an assert to ensure that the os::release_memory call succeeds.
This immediately shows the problem when we execute our internal vm tests.
2) Moves the implementation of should_use_malloc to the inline file, so
that it can reuse size_for_malloc.
3) Fix the bug.
http://cr.openjdk.java.net/~stefank/8151436/webrev.01.delta/
http://cr.openjdk.java.net/~stefank/8151436/webrev.01/
Thanks,
StefanK
On 2016-03-08 11:33, Stefan Karlsson wrote:
> Hi all,
>
> Please review this patch to remove the state variables from
> ArrayAllocator and make it an AllStatic class instead. The main
> motivation for this patch is to cleanup the BitMaps data structure and
> make the instances smaller.
>
> The patch builds on the fact that the current code invokes
> AllocateHeap with the default value AllocFailEnum:EXIT_OOM, and
> therefore never returns NULL. This means that use_malloc will never be
> reset and the allocation strategy used (malloc or mmap) can be
> determined by simply looking at the size input parameter. Instead of
> changing the code to use AllocateHeap with AllocFailEnum::RETURN_NULL,
> I chose to keep the current behavior so that we could cleanup and
> minimize the size of our BitMaps.
>
> http://cr.openjdk.java.net/~stefank/8151436/webrev/
> https://bugs.openjdk.java.net/browse/JDK-8151436
>
> Thanks,
> StefanK
From dmitry.dmitriev at oracle.com Wed Mar 9 15:21:40 2016
From: dmitry.dmitriev at oracle.com (Dmitry Dmitriev)
Date: Wed, 9 Mar 2016 18:21:40 +0300
Subject: RFR(XS): 8151304: Remove unused develop
options(ClearInterpreterLocals and others)
In-Reply-To: <56E0214E.8050206@oracle.com>
References: <56E001BB.1050300@oracle.com> <56E0214E.8050206@oracle.com>
Message-ID: <56E03F84.9070600@oracle.com>
Jesper, thank you for the review!
Dmitry
On 09.03.2016 16:12, Jesper Wilhelmsson wrote:
> Looks good!
> /Jesper
>
> Den 9/3/16 kl. 11:58, skrev Dmitry Dmitriev:
>> Hello,
>>
>> Please, review this small patch which removes 4 unused develop
>> options. Code for
>> these options was removed some time ago(additional details can be
>> found in the
>> JBS).
>>
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8151304
>> webrev.00: http://cr.openjdk.java.net/~ddmitriev/8151304/webrev.00/
>>
>> Testing: jprt
>>
>> Thanks,
>> Dmitry
From dmitry.dmitriev at oracle.com Wed Mar 9 15:22:34 2016
From: dmitry.dmitriev at oracle.com (Dmitry Dmitriev)
Date: Wed, 9 Mar 2016 18:22:34 +0300
Subject: RFR(XS): 8151304: Remove unused develop
options(ClearInterpreterLocals and others)
In-Reply-To: <56E02334.90304@oracle.com>
References: <56E001BB.1050300@oracle.com> <56E0214E.8050206@oracle.com>
<56E02334.90304@oracle.com>
Message-ID: <56E03FBA.6050903@oracle.com>
Coleen, thank you for the review!
Dmitry
On 09.03.2016 16:20, Coleen Phillimore wrote:
> Looks good!
> Coleen
>
> On 3/9/16 8:12 AM, Jesper Wilhelmsson wrote:
>> Looks good!
>> /Jesper
>>
>> Den 9/3/16 kl. 11:58, skrev Dmitry Dmitriev:
>>> Hello,
>>>
>>> Please, review this small patch which removes 4 unused develop
>>> options. Code for
>>> these options was removed some time ago(additional details can be
>>> found in the
>>> JBS).
>>>
>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8151304
>>> webrev.00: http://cr.openjdk.java.net/~ddmitriev/8151304/webrev.00/
>>>
>>> Testing: jprt
>>>
>>> Thanks,
>>> Dmitry
>
From per.liden at oracle.com Wed Mar 9 15:26:42 2016
From: per.liden at oracle.com (Per Liden)
Date: Wed, 9 Mar 2016 16:26:42 +0100
Subject: RFR: 8151436: Leaner ArrayAllocator and BitMaps
In-Reply-To: <56E032F2.4050405@oracle.com>
References: <56DEAA7A.1000200@oracle.com> <56E032F2.4050405@oracle.com>
Message-ID: <56E040B2.3070605@oracle.com>
On 2016-03-09 15:28, Stefan Karlsson wrote:
> Hi all,
>
> I found a bug in the ArrayAllocator code. ArrayAllocator::free
> incorrectly calls should_use_malloc(size_for_malloc(length)) when the
> call should be should_use_malloc(length).
>
> There is an -XX:+ExecuteInternalVMTests that exercises this code path,
> and try to find these kinds of bugs. The test actually manages to call
> allocate_malloc and then tries to free the memory with free_mmap, but
> the JVM doesn't crash. One reason why it doesn't crash is that
> os::release_memory, which is used by free_mmap, fails to unmap the
> malloced memory and we silently ignores that.
>
> This patch:
> 1) Adds an assert to ensure that the os::release_memory call succeeds.
> This immediately shows the problem when we execute our internal vm tests.
> 2) Moves the implementation of should_use_malloc to the inline file, so
> that it can reuse size_for_malloc.
> 3) Fix the bug.
>
> http://cr.openjdk.java.net/~stefank/8151436/webrev.01.delta/
> http://cr.openjdk.java.net/~stefank/8151436/webrev.01/
Looks good.
/Per
>
> Thanks,
> StefanK
>
> On 2016-03-08 11:33, Stefan Karlsson wrote:
>> Hi all,
>>
>> Please review this patch to remove the state variables from
>> ArrayAllocator and make it an AllStatic class instead. The main
>> motivation for this patch is to cleanup the BitMaps data structure and
>> make the instances smaller.
>>
>> The patch builds on the fact that the current code invokes
>> AllocateHeap with the default value AllocFailEnum:EXIT_OOM, and
>> therefore never returns NULL. This means that use_malloc will never be
>> reset and the allocation strategy used (malloc or mmap) can be
>> determined by simply looking at the size input parameter. Instead of
>> changing the code to use AllocateHeap with AllocFailEnum::RETURN_NULL,
>> I chose to keep the current behavior so that we could cleanup and
>> minimize the size of our BitMaps.
>>
>> http://cr.openjdk.java.net/~stefank/8151436/webrev/
>> https://bugs.openjdk.java.net/browse/JDK-8151436
>>
>> Thanks,
>> StefanK
>
From stefan.karlsson at oracle.com Wed Mar 9 15:50:33 2016
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Wed, 9 Mar 2016 16:50:33 +0100
Subject: RFR: 8151436: Leaner ArrayAllocator and BitMaps
In-Reply-To: <56E040B2.3070605@oracle.com>
References: <56DEAA7A.1000200@oracle.com> <56E032F2.4050405@oracle.com>
<56E040B2.3070605@oracle.com>
Message-ID: <56E04649.8060301@oracle.com>
Thanks, Per.
StefanK
On 2016-03-09 16:26, Per Liden wrote:
> On 2016-03-09 15:28, Stefan Karlsson wrote:
>> Hi all,
>>
>> I found a bug in the ArrayAllocator code. ArrayAllocator::free
>> incorrectly calls should_use_malloc(size_for_malloc(length)) when the
>> call should be should_use_malloc(length).
>>
>> There is an -XX:+ExecuteInternalVMTests that exercises this code path,
>> and try to find these kinds of bugs. The test actually manages to call
>> allocate_malloc and then tries to free the memory with free_mmap, but
>> the JVM doesn't crash. One reason why it doesn't crash is that
>> os::release_memory, which is used by free_mmap, fails to unmap the
>> malloced memory and we silently ignores that.
>>
>> This patch:
>> 1) Adds an assert to ensure that the os::release_memory call succeeds.
>> This immediately shows the problem when we execute our internal vm
>> tests.
>> 2) Moves the implementation of should_use_malloc to the inline file, so
>> that it can reuse size_for_malloc.
>> 3) Fix the bug.
>>
>> http://cr.openjdk.java.net/~stefank/8151436/webrev.01.delta/
>> http://cr.openjdk.java.net/~stefank/8151436/webrev.01/
>
> Looks good.
>
> /Per
>
>>
>> Thanks,
>> StefanK
>>
>> On 2016-03-08 11:33, Stefan Karlsson wrote:
>>> Hi all,
>>>
>>> Please review this patch to remove the state variables from
>>> ArrayAllocator and make it an AllStatic class instead. The main
>>> motivation for this patch is to cleanup the BitMaps data structure and
>>> make the instances smaller.
>>>
>>> The patch builds on the fact that the current code invokes
>>> AllocateHeap with the default value AllocFailEnum:EXIT_OOM, and
>>> therefore never returns NULL. This means that use_malloc will never be
>>> reset and the allocation strategy used (malloc or mmap) can be
>>> determined by simply looking at the size input parameter. Instead of
>>> changing the code to use AllocateHeap with AllocFailEnum::RETURN_NULL,
>>> I chose to keep the current behavior so that we could cleanup and
>>> minimize the size of our BitMaps.
>>>
>>> http://cr.openjdk.java.net/~stefank/8151436/webrev/
>>> https://bugs.openjdk.java.net/browse/JDK-8151436
>>>
>>> Thanks,
>>> StefanK
>>
From thomas.schatzl at oracle.com Wed Mar 9 15:56:39 2016
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Wed, 09 Mar 2016 16:56:39 +0100
Subject: RFR: 8151436: Leaner ArrayAllocator and BitMaps
In-Reply-To: <56E032F2.4050405@oracle.com>
References: <56DEAA7A.1000200@oracle.com> <56E032F2.4050405@oracle.com>
Message-ID: <1457538999.2275.47.camel@oracle.com>
Hi,
On Wed, 2016-03-09 at 15:28 +0100, Stefan Karlsson wrote:
> Hi all,
>
> I found a bug in the ArrayAllocator code. ArrayAllocator::free
> incorrectly calls should_use_malloc(size_for_malloc(length)) when the
> call should be should_use_malloc(length).
>
> There is an -XX:+ExecuteInternalVMTests that exercises this code
> path,
> and try to find these kinds of bugs. The test actually manages to
> call
> allocate_malloc and then tries to free the memory with free_mmap, but
> the JVM doesn't crash. One reason why it doesn't crash is that
> os::release_memory, which is used by free_mmap, fails to unmap the
> malloced memory and we silently ignores that.
>
> This patch:
> 1) Adds an assert to ensure that the os::release_memory call
> succeeds.
> This immediately shows the problem when we execute our internal vm
> tests.
> 2) Moves the implementation of should_use_malloc to the inline file,
> so
> that it can reuse size_for_malloc.
> 3) Fix the bug.
>
> http://cr.openjdk.java.net/~stefank/8151436/webrev.01.delta/
> http://cr.openjdk.java.net/~stefank/8151436/webrev.01/
looks good.
Thomas
From stefan.karlsson at oracle.com Wed Mar 9 15:58:43 2016
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Wed, 9 Mar 2016 16:58:43 +0100
Subject: RFR: 8151436: Leaner ArrayAllocator and BitMaps
In-Reply-To: <1457538999.2275.47.camel@oracle.com>
References: <56DEAA7A.1000200@oracle.com> <56E032F2.4050405@oracle.com>
<1457538999.2275.47.camel@oracle.com>
Message-ID: <56E04833.9030809@oracle.com>
Thanks, Thomas.
StefanK
On 2016-03-09 16:56, Thomas Schatzl wrote:
> Hi,
>
> On Wed, 2016-03-09 at 15:28 +0100, Stefan Karlsson wrote:
>> Hi all,
>>
>> I found a bug in the ArrayAllocator code. ArrayAllocator::free
>> incorrectly calls should_use_malloc(size_for_malloc(length)) when the
>> call should be should_use_malloc(length).
>>
>> There is an -XX:+ExecuteInternalVMTests that exercises this code
>> path,
>> and try to find these kinds of bugs. The test actually manages to
>> call
>> allocate_malloc and then tries to free the memory with free_mmap, but
>> the JVM doesn't crash. One reason why it doesn't crash is that
>> os::release_memory, which is used by free_mmap, fails to unmap the
>> malloced memory and we silently ignores that.
>>
>> This patch:
>> 1) Adds an assert to ensure that the os::release_memory call
>> succeeds.
>> This immediately shows the problem when we execute our internal vm
>> tests.
>> 2) Moves the implementation of should_use_malloc to the inline file,
>> so
>> that it can reuse size_for_malloc.
>> 3) Fix the bug.
>>
>> http://cr.openjdk.java.net/~stefank/8151436/webrev.01.delta/
>> http://cr.openjdk.java.net/~stefank/8151436/webrev.01/
> looks good.
>
> Thomas
>
From stefan.karlsson at oracle.com Wed Mar 9 16:25:07 2016
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Wed, 9 Mar 2016 17:25:07 +0100
Subject: RFR: 8151534: Refactor ArrayAllocator for easier reuse
Message-ID: <56E04E63.9050405@oracle.com>
Hi all,
Please review this patch to refactor the ArrayAllocator code.
http://cr.openjdk.java.net/~stefank/8151534/webrev.00
https://bugs.openjdk.java.net/browse/JDK-8151534
ArrayAllocator is used to either allocate an array with malloc or mmap.
This patch extracts the allocation code into two separate classes:
MmapArrayAllocator and MallocArrayAllocator. ArrayAllocator will
dispatch to one of these classes depending on the size of the
allocation. The main motivation for this patch is to allow the fix for
JDK-8077144 to reuse the code in MmapArrayAllocator.
Thanks,
StefanK
From stefan.karlsson at oracle.com Wed Mar 9 16:44:19 2016
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Wed, 9 Mar 2016 17:44:19 +0100
Subject: RFR: 8151539: Remove duplicate AlwaysTrueClosures
Message-ID: <56E052E3.2040209@oracle.com>
Hi all,
Please review this patch to remove a bunch of redundant
AlwaysTrueClosure classes.
http://cr.openjdk.java.net/~stefank/8151539/webrev.00/
https://bugs.openjdk.java.net/browse/JDK-8151539
I've created an overloaded JNIHandles::weak_oops_do that uses its own
AlwaysTrueClosure classes. This way callers of JNIHandles::weak_oops_do,
that don't want to filter out any oops, can call the overloaded version
without providing an instance of BoolObjectClosure.
Thanks,
StefanK
From matthias.baesken at sap.com Wed Mar 9 17:01:07 2016
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Wed, 9 Mar 2016 17:01:07 +0000
Subject: jdk9 : forcing inlining in src/share/vm/oops/instanceKlass.inline.hpp
for xlc
Message-ID: <63dad1e5ed7945439306b95a7ac48571@DEWDFE13DE02.global.corp.sap>
Hello ,
CR 8075955: "Replace the macro based implementation of oop_oop_iterate with a template based solution"
changed src/share/vm/oops/instanceKlass.inline.hpp
and replaced macro based oop iteration by templates.
For performance reason, the change (and a follow up change for Oracle Studio) introduced forcing of inlining for some places in
src/share/vm/oops/instanceKlass.inline.hpp , see
http://hg.openjdk.java.net/jdk9/dev/hotspot/file/797e6aac6d53/src/share/vm/oops/instanceKlass.inline.hpp
....
// The iteration over the oops in objects is a hot path in the GC code.
// By force inlining the following functions, we get similar GC performance
// as the previous macro based implementation.
#ifdef TARGET_COMPILER_visCPP
#define INLINE __forceinline
#elif defined(TARGET_COMPILER_sparcWorks)
#define INLINE __attribute__((always_inline))
#else
#define INLINE inline
#endif
....
(which is compiler dependent)
Should we do this for the AIX port too ?
http://www.ibm.com/support/knowledgecenter/SSGH2K_12.1.0/com.ibm.xlc121.aix.doc/language_ref/function_attributes.html?lang=en
describes the function attributes of xlc which can be used.
Diff to instanceKlass.inline.hpp :
43,44d42
< #elif defined(TARGET_COMPILER_xlc)
< #define INLINE __attribute__((always_inline))
Regards, Matthias
From mikael.gerdin at oracle.com Wed Mar 9 19:39:56 2016
From: mikael.gerdin at oracle.com (Mikael Gerdin)
Date: Wed, 9 Mar 2016 20:39:56 +0100
Subject: RFR: 8151539: Remove duplicate AlwaysTrueClosures
In-Reply-To: <56E052E3.2040209@oracle.com>
References: <56E052E3.2040209@oracle.com>
Message-ID: <56E07C0C.5000804@oracle.com>
Hi Stefan,
On 2016-03-09 17:44, Stefan Karlsson wrote:
> Hi all,
>
> Please review this patch to remove a bunch of redundant
> AlwaysTrueClosure classes.
>
> http://cr.openjdk.java.net/~stefank/8151539/webrev.00/
There is still
2128 // This should be moved to the shared markSweep code!
2129 class PSAlwaysTrueClosure: public BoolObjectClosure {
2130 public:
2131 bool do_object_b(oop p) { return true; }
2132 };
2133 static PSAlwaysTrueClosure always_true;
in psParallelCompact.cpp
Otherwise the change looks good, I don't need to see an updated webrev.
/Mikael
> https://bugs.openjdk.java.net/browse/JDK-8151539
>
> I've created an overloaded JNIHandles::weak_oops_do that uses its own
> AlwaysTrueClosure classes. This way callers of JNIHandles::weak_oops_do,
> that don't want to filter out any oops, can call the overloaded version
> without providing an instance of BoolObjectClosure.
>
> Thanks,
> StefanK
From stefan.karlsson at oracle.com Wed Mar 9 20:01:27 2016
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Wed, 9 Mar 2016 21:01:27 +0100
Subject: RFR: 8151539: Remove duplicate AlwaysTrueClosures
In-Reply-To: <56E07C0C.5000804@oracle.com>
References: <56E052E3.2040209@oracle.com> <56E07C0C.5000804@oracle.com>
Message-ID: <56E08117.1090706@oracle.com>
Hi Mikael,
On 2016-03-09 20:39, Mikael Gerdin wrote:
> Hi Stefan,
>
> On 2016-03-09 17:44, Stefan Karlsson wrote:
>> Hi all,
>>
>> Please review this patch to remove a bunch of redundant
>> AlwaysTrueClosure classes.
>>
>> http://cr.openjdk.java.net/~stefank/8151539/webrev.00/
>
> There is still
> 2128 // This should be moved to the shared markSweep code!
> 2129 class PSAlwaysTrueClosure: public BoolObjectClosure {
> 2130 public:
> 2131 bool do_object_b(oop p) { return true; }
> 2132 };
> 2133 static PSAlwaysTrueClosure always_true;
> in psParallelCompact.cpp
>
> Otherwise the change looks good, I don't need to see an updated webrev.
Great that you saw this!
I've uploaded a new webrev, to make it easier for the second reviewer:
http://cr.openjdk.java.net/~stefank/8151539/webrev.01/
Thanks,
StefanK
>
> /Mikael
>
>> https://bugs.openjdk.java.net/browse/JDK-8151539
>>
>> I've created an overloaded JNIHandles::weak_oops_do that uses its own
>> AlwaysTrueClosure classes. This way callers of JNIHandles::weak_oops_do,
>> that don't want to filter out any oops, can call the overloaded version
>> without providing an instance of BoolObjectClosure.
>>
>> Thanks,
>> StefanK
From thomas.schatzl at oracle.com Wed Mar 9 20:26:05 2016
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Wed, 09 Mar 2016 21:26:05 +0100
Subject: RFR: 8151539: Remove duplicate AlwaysTrueClosures
In-Reply-To: <56E08117.1090706@oracle.com>
References: <56E052E3.2040209@oracle.com> <56E07C0C.5000804@oracle.com>
<56E08117.1090706@oracle.com>
Message-ID: <1457555165.2695.5.camel@oracle.com>
Hi,
On Wed, 2016-03-09 at 21:01 +0100, Stefan Karlsson wrote:
> Hi Mikael,
>
> On 2016-03-09 20:39, Mikael Gerdin wrote:
> > Hi Stefan,
> >
> > On 2016-03-09 17:44, Stefan Karlsson wrote:
> > > Hi all,
> > >
> > > Please review this patch to remove a bunch of redundant
> > > AlwaysTrueClosure classes.
> > >
> > > http://cr.openjdk.java.net/~stefank/8151539/webrev.00/
> >
> > There is still
> > 2128 // This should be moved to the shared markSweep code!
> > 2129 class PSAlwaysTrueClosure: public BoolObjectClosure {
> > 2130 public:
> > 2131 bool do_object_b(oop p) { return true; }
> > 2132 };
> > 2133 static PSAlwaysTrueClosure always_true;
> > in psParallelCompact.cpp
> >
> > Otherwise the change looks good, I don't need to see an updated
> > webrev.
>
> Great that you saw this!
>
> I've uploaded a new webrev, to make it easier for the second
> reviewer:
> http://cr.openjdk.java.net/~stefank/8151539/webrev.01/
looks good.
Thomas
From stefan.karlsson at oracle.com Wed Mar 9 20:36:08 2016
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Wed, 9 Mar 2016 21:36:08 +0100
Subject: RFR: 8151539: Remove duplicate AlwaysTrueClosures
In-Reply-To: <1457555165.2695.5.camel@oracle.com>
References: <56E052E3.2040209@oracle.com> <56E07C0C.5000804@oracle.com>
<56E08117.1090706@oracle.com> <1457555165.2695.5.camel@oracle.com>
Message-ID: <56E08938.4090307@oracle.com>
Thanks, Thomas.
StefanK
On 2016-03-09 21:26, Thomas Schatzl wrote:
> Hi,
>
> On Wed, 2016-03-09 at 21:01 +0100, Stefan Karlsson wrote:
>> Hi Mikael,
>>
>> On 2016-03-09 20:39, Mikael Gerdin wrote:
>>> Hi Stefan,
>>>
>>> On 2016-03-09 17:44, Stefan Karlsson wrote:
>>>> Hi all,
>>>>
>>>> Please review this patch to remove a bunch of redundant
>>>> AlwaysTrueClosure classes.
>>>>
>>>> http://cr.openjdk.java.net/~stefank/8151539/webrev.00/
>>> There is still
>>> 2128 // This should be moved to the shared markSweep code!
>>> 2129 class PSAlwaysTrueClosure: public BoolObjectClosure {
>>> 2130 public:
>>> 2131 bool do_object_b(oop p) { return true; }
>>> 2132 };
>>> 2133 static PSAlwaysTrueClosure always_true;
>>> in psParallelCompact.cpp
>>>
>>> Otherwise the change looks good, I don't need to see an updated
>>> webrev.
>> Great that you saw this!
>>
>> I've uploaded a new webrev, to make it easier for the second
>> reviewer:
>> http://cr.openjdk.java.net/~stefank/8151539/webrev.01/
> looks good.
>
> Thomas
>
From kim.barrett at oracle.com Wed Mar 9 23:11:17 2016
From: kim.barrett at oracle.com (Kim Barrett)
Date: Wed, 9 Mar 2016 18:11:17 -0500
Subject: RFR: 8151539: Remove duplicate AlwaysTrueClosures
In-Reply-To: <56E08117.1090706@oracle.com>
References: <56E052E3.2040209@oracle.com> <56E07C0C.5000804@oracle.com>
<56E08117.1090706@oracle.com>
Message-ID:
> On Mar 9, 2016, at 3:01 PM, Stefan Karlsson wrote:
>
> Hi Mikael,
>
> On 2016-03-09 20:39, Mikael Gerdin wrote:
>> Hi Stefan,
>>
>> On 2016-03-09 17:44, Stefan Karlsson wrote:
>>> Hi all,
>>>
>>> Please review this patch to remove a bunch of redundant
>>> AlwaysTrueClosure classes.
>>>
>>> http://cr.openjdk.java.net/~stefank/8151539/webrev.00/
>>
>> There is still
>> 2128 // This should be moved to the shared markSweep code!
>> 2129 class PSAlwaysTrueClosure: public BoolObjectClosure {
>> 2130 public:
>> 2131 bool do_object_b(oop p) { return true; }
>> 2132 };
>> 2133 static PSAlwaysTrueClosure always_true;
>> in psParallelCompact.cpp
>>
>> Otherwise the change looks good, I don't need to see an updated webrev.
>
> Great that you saw this!
>
> I've uploaded a new webrev, to make it easier for the second reviewer:
> http://cr.openjdk.java.net/~stefank/8151539/webrev.01/
A couple of things below; otherwise looks good. I don't need a new
webrev for these.
------------------------------------------------------------------------------
src/share/vm/runtime/jniHandles.cpp
136 static AlwaysTrueClosure always_true;
Function-scoped static initialization is not thread-safe in C++03.
I don't think there's any noticable benefit to a static here even with
thread-safe initialization, as the construction is probably pretty
simple. (It might be simple enough that there's no actual
thread-safety issue, but why take that chance.)
------------------------------------------------------------------------------
src/share/vm/gc/shared/referenceProcessor.cpp
269 class AlwaysAliveClosure: public BoolObjectClosure {
This local class can go away too.
------------------------------------------------------------------------------
src/share/vm/gc/shared/genCollectedHeap.cpp
[removed]
688 class AlwaysTrueClosure: public BoolObjectClosure {
src/share/vm/gc/parallel/psMarkSweep.cpp
[removed]
574 class PSAlwaysTrueClosure: public BoolObjectClosure {
src/share/vm/gc/parallel/psParallelCompact.cpp
[removed]
2129 class PSAlwaysTrueClosure: public BoolObjectClosure {
Nice! Fortunately, these aren't technically ODR violations, since the
same-named definitions are identical.
------------------------------------------------------------------------------
From derek.white at oracle.com Wed Mar 9 23:46:44 2016
From: derek.white at oracle.com (Derek White)
Date: Wed, 9 Mar 2016 18:46:44 -0500
Subject: RFR: 8151539: Remove duplicate AlwaysTrueClosures
In-Reply-To:
References: <56E052E3.2040209@oracle.com> <56E07C0C.5000804@oracle.com>
<56E08117.1090706@oracle.com>
Message-ID: <56E0B5E4.4040106@oracle.com>
Looks nice!
Are there ever enough weak JNI handles that it would pay off to
re-implement JNIHandles::weak_oops_do(OopClosure* f) so it doesn't even
do the callback? I'd guess not, but thought I'd ask!
- Derek
On 3/9/16 6:11 PM, Kim Barrett wrote:
>> On Mar 9, 2016, at 3:01 PM, Stefan Karlsson wrote:
>>
>> Hi Mikael,
>>
>> On 2016-03-09 20:39, Mikael Gerdin wrote:
>>> Hi Stefan,
>>>
>>> On 2016-03-09 17:44, Stefan Karlsson wrote:
>>>> Hi all,
>>>>
>>>> Please review this patch to remove a bunch of redundant
>>>> AlwaysTrueClosure classes.
>>>>
>>>> http://cr.openjdk.java.net/~stefank/8151539/webrev.00/
>>> There is still
>>> 2128 // This should be moved to the shared markSweep code!
>>> 2129 class PSAlwaysTrueClosure: public BoolObjectClosure {
>>> 2130 public:
>>> 2131 bool do_object_b(oop p) { return true; }
>>> 2132 };
>>> 2133 static PSAlwaysTrueClosure always_true;
>>> in psParallelCompact.cpp
>>>
>>> Otherwise the change looks good, I don't need to see an updated webrev.
>> Great that you saw this!
>>
>> I've uploaded a new webrev, to make it easier for the second reviewer:
>> http://cr.openjdk.java.net/~stefank/8151539/webrev.01/
> A couple of things below; otherwise looks good. I don't need a new
> webrev for these.
>
> ------------------------------------------------------------------------------
> src/share/vm/runtime/jniHandles.cpp
> 136 static AlwaysTrueClosure always_true;
>
> Function-scoped static initialization is not thread-safe in C++03.
>
> I don't think there's any noticable benefit to a static here even with
> thread-safe initialization, as the construction is probably pretty
> simple. (It might be simple enough that there's no actual
> thread-safety issue, but why take that chance.)
>
> ------------------------------------------------------------------------------
> src/share/vm/gc/shared/referenceProcessor.cpp
> 269 class AlwaysAliveClosure: public BoolObjectClosure {
>
> This local class can go away too.
>
> ------------------------------------------------------------------------------
> src/share/vm/gc/shared/genCollectedHeap.cpp
> [removed]
> 688 class AlwaysTrueClosure: public BoolObjectClosure {
>
> src/share/vm/gc/parallel/psMarkSweep.cpp
> [removed]
> 574 class PSAlwaysTrueClosure: public BoolObjectClosure {
>
> src/share/vm/gc/parallel/psParallelCompact.cpp
> [removed]
> 2129 class PSAlwaysTrueClosure: public BoolObjectClosure {
>
> Nice! Fortunately, these aren't technically ODR violations, since the
> same-named definitions are identical.
>
> ------------------------------------------------------------------------------
>
From volker.simonis at gmail.com Thu Mar 10 08:12:53 2016
From: volker.simonis at gmail.com (Volker Simonis)
Date: Thu, 10 Mar 2016 09:12:53 +0100
Subject: jdk9 : forcing inlining in
src/share/vm/oops/instanceKlass.inline.hpp for xlc
In-Reply-To: <63dad1e5ed7945439306b95a7ac48571@DEWDFE13DE02.global.corp.sap>
References: <63dad1e5ed7945439306b95a7ac48571@DEWDFE13DE02.global.corp.sap>
Message-ID:
Hi Matthias,
thanks for reporting this. I've opened "8151593: AIX: add support for
xlC 'always_inline' compiler attribute"
(https://bugs.openjdk.java.net/browse/JDK-8151593) to track this
issue.
Regards,
Volker
On Wed, Mar 9, 2016 at 6:01 PM, Baesken, Matthias
wrote:
> Hello ,
>
> CR 8075955: "Replace the macro based implementation of oop_oop_iterate with
> a template based solution"
>
>
>
> changed src/share/vm/oops/instanceKlass.inline.hpp
>
>
>
> and replaced macro based oop iteration by templates.
>
> For performance reason, the change (and a follow up change for Oracle
> Studio) introduced forcing of inlining for some places in
>
> src/share/vm/oops/instanceKlass.inline.hpp , see
>
>
>
>
>
> http://hg.openjdk.java.net/jdk9/dev/hotspot/file/797e6aac6d53/src/share/vm/oops/instanceKlass.inline.hpp
>
>
>
> ....
>
> // The iteration over the oops in objects is a hot path in the GC code.
>
> // By force inlining the following functions, we get similar GC performance
>
> // as the previous macro based implementation.
>
> #ifdef TARGET_COMPILER_visCPP
>
> #define INLINE __forceinline
>
> #elif defined(TARGET_COMPILER_sparcWorks)
>
> #define INLINE __attribute__((always_inline))
>
> #else
>
> #define INLINE inline
>
> #endif
>
> ....
>
>
>
> (which is compiler dependent)
>
> Should we do this for the AIX port too ?
>
>
>
> http://www.ibm.com/support/knowledgecenter/SSGH2K_12.1.0/com.ibm.xlc121.aix.doc/language_ref/function_attributes.html?lang=en
>
>
>
>
>
> describes the function attributes of xlc which can be used.
>
> Diff to instanceKlass.inline.hpp :
>
>
>
> 43,44d42
>
> < #elif defined(TARGET_COMPILER_xlc)
>
> < #define INLINE __attribute__((always_inline))
>
>
>
>
>
> Regards, Matthias
From stefan.karlsson at oracle.com Thu Mar 10 08:58:43 2016
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Thu, 10 Mar 2016 09:58:43 +0100
Subject: RFR: 8151539: Remove duplicate AlwaysTrueClosures
In-Reply-To:
References: <56E052E3.2040209@oracle.com> <56E07C0C.5000804@oracle.com>
<56E08117.1090706@oracle.com>
Message-ID: <56E13743.4030802@oracle.com>
Hi Kim,
Updated webrevs:
http://cr.openjdk.java.net/~stefank/8151539/webrev.02.delta/
http://cr.openjdk.java.net/~stefank/8151539/webrev.02/
I moved the AlwaysTrueClosure to iterator.hpp, and created a stack local
instance in jniHandles.cpp.
I also found that there's an AlwaysFalseClosure, so I took the liberty
of moving this to iterator.hpp as well.
Just a few comments inlined:
On 2016-03-10 00:11, Kim Barrett wrote:
>> On Mar 9, 2016, at 3:01 PM, Stefan Karlsson wrote:
>>
>> Hi Mikael,
>>
>> On 2016-03-09 20:39, Mikael Gerdin wrote:
>>> Hi Stefan,
>>>
>>> On 2016-03-09 17:44, Stefan Karlsson wrote:
>>>> Hi all,
>>>>
>>>> Please review this patch to remove a bunch of redundant
>>>> AlwaysTrueClosure classes.
>>>>
>>>> http://cr.openjdk.java.net/~stefank/8151539/webrev.00/
>>> There is still
>>> 2128 // This should be moved to the shared markSweep code!
>>> 2129 class PSAlwaysTrueClosure: public BoolObjectClosure {
>>> 2130 public:
>>> 2131 bool do_object_b(oop p) { return true; }
>>> 2132 };
>>> 2133 static PSAlwaysTrueClosure always_true;
>>> in psParallelCompact.cpp
>>>
>>> Otherwise the change looks good, I don't need to see an updated webrev.
>> Great that you saw this!
>>
>> I've uploaded a new webrev, to make it easier for the second reviewer:
>> http://cr.openjdk.java.net/~stefank/8151539/webrev.01/
> A couple of things below; otherwise looks good. I don't need a new
> webrev for these.
>
> ------------------------------------------------------------------------------
> src/share/vm/runtime/jniHandles.cpp
> 136 static AlwaysTrueClosure always_true;
>
> Function-scoped static initialization is not thread-safe in C++03.
Thanks for pointing that out. It's not a problem here though, but I'll
clean this out to prevent future bugs our questions.
>
> I don't think there's any noticable benefit to a static here even with
> thread-safe initialization, as the construction is probably pretty
> simple. (It might be simple enough that there's no actual
> thread-safety issue, but why take that chance.)
I agree. I've changed it to a stack instance.
>
> ------------------------------------------------------------------------------
> src/share/vm/gc/shared/referenceProcessor.cpp
> 269 class AlwaysAliveClosure: public BoolObjectClosure {
>
> This local class can go away too.
Done.
Thanks,
StefanK
>
> ------------------------------------------------------------------------------
> src/share/vm/gc/shared/genCollectedHeap.cpp
> [removed]
> 688 class AlwaysTrueClosure: public BoolObjectClosure {
>
> src/share/vm/gc/parallel/psMarkSweep.cpp
> [removed]
> 574 class PSAlwaysTrueClosure: public BoolObjectClosure {
>
> src/share/vm/gc/parallel/psParallelCompact.cpp
> [removed]
> 2129 class PSAlwaysTrueClosure: public BoolObjectClosure {
>
> Nice! Fortunately, these aren't technically ODR violations, since the
> same-named definitions are identical.
>
> ------------------------------------------------------------------------------
>
From stefan.karlsson at oracle.com Thu Mar 10 09:27:33 2016
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Thu, 10 Mar 2016 10:27:33 +0100
Subject: RFR: 8151539: Remove duplicate AlwaysTrueClosures
In-Reply-To: <56E0B5E4.4040106@oracle.com>
References: <56E052E3.2040209@oracle.com> <56E07C0C.5000804@oracle.com>
<56E08117.1090706@oracle.com>
<56E0B5E4.4040106@oracle.com>
Message-ID: <56E13E05.7070901@oracle.com>
Hi Derek,
On 2016-03-10 00:46, Derek White wrote:
> Looks nice!
Thanks.
>
> Are there ever enough weak JNI handles that it would pay off to
> re-implement JNIHandles::weak_oops_do(OopClosure* f) so it doesn't
> even do the callback? I'd guess not, but thought I'd ask!
It might be worth optimizing this for some workloads, especially since
this is called from single-threaded code at the moment. If it's really
important, then we might also want to devirtualize the do_oop calls
inside JNIHandles::weak_oops_do.
I think we would need a benchmark that shows that this is a problem,
before we start to optimize this.
Thanks,
StefanK
>
> - Derek
>
> On 3/9/16 6:11 PM, Kim Barrett wrote:
>>> On Mar 9, 2016, at 3:01 PM, Stefan Karlsson
>>> wrote:
>>>
>>> Hi Mikael,
>>>
>>> On 2016-03-09 20:39, Mikael Gerdin wrote:
>>>> Hi Stefan,
>>>>
>>>> On 2016-03-09 17:44, Stefan Karlsson wrote:
>>>>> Hi all,
>>>>>
>>>>> Please review this patch to remove a bunch of redundant
>>>>> AlwaysTrueClosure classes.
>>>>>
>>>>> http://cr.openjdk.java.net/~stefank/8151539/webrev.00/
>>>> There is still
>>>> 2128 // This should be moved to the shared markSweep code!
>>>> 2129 class PSAlwaysTrueClosure: public BoolObjectClosure {
>>>> 2130 public:
>>>> 2131 bool do_object_b(oop p) { return true; }
>>>> 2132 };
>>>> 2133 static PSAlwaysTrueClosure always_true;
>>>> in psParallelCompact.cpp
>>>>
>>>> Otherwise the change looks good, I don't need to see an updated
>>>> webrev.
>>> Great that you saw this!
>>>
>>> I've uploaded a new webrev, to make it easier for the second reviewer:
>>> http://cr.openjdk.java.net/~stefank/8151539/webrev.01/
>> A couple of things below; otherwise looks good. I don't need a new
>> webrev for these.
>>
>> ------------------------------------------------------------------------------
>>
>> src/share/vm/runtime/jniHandles.cpp
>> 136 static AlwaysTrueClosure always_true;
>>
>> Function-scoped static initialization is not thread-safe in C++03.
>>
>> I don't think there's any noticable benefit to a static here even with
>> thread-safe initialization, as the construction is probably pretty
>> simple. (It might be simple enough that there's no actual
>> thread-safety issue, but why take that chance.)
>>
>> ------------------------------------------------------------------------------
>>
>> src/share/vm/gc/shared/referenceProcessor.cpp
>> 269 class AlwaysAliveClosure: public BoolObjectClosure {
>>
>> This local class can go away too.
>>
>> ------------------------------------------------------------------------------
>>
>> src/share/vm/gc/shared/genCollectedHeap.cpp
>> [removed]
>> 688 class AlwaysTrueClosure: public BoolObjectClosure {
>>
>> src/share/vm/gc/parallel/psMarkSweep.cpp
>> [removed]
>> 574 class PSAlwaysTrueClosure: public BoolObjectClosure {
>>
>> src/share/vm/gc/parallel/psParallelCompact.cpp
>> [removed]
>> 2129 class PSAlwaysTrueClosure: public BoolObjectClosure {
>>
>> Nice! Fortunately, these aren't technically ODR violations, since the
>> same-named definitions are identical.
>>
>> ------------------------------------------------------------------------------
>>
>>
>
From thomas.schatzl at oracle.com Thu Mar 10 11:41:20 2016
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Thu, 10 Mar 2016 12:41:20 +0100
Subject: RFR: 8151534: Refactor ArrayAllocator for easier reuse
In-Reply-To: <56E04E63.9050405@oracle.com>
References: <56E04E63.9050405@oracle.com>
Message-ID: <1457610080.2780.6.camel@oracle.com>
Hi,
On Wed, 2016-03-09 at 17:25 +0100, Stefan Karlsson wrote:
> Hi all,
>
> Please review this patch to refactor the ArrayAllocator code.
>
> http://cr.openjdk.java.net/~stefank/8151534/webrev.00
> https://bugs.openjdk.java.net/browse/JDK-8151534
>
> ArrayAllocator is used to either allocate an array with malloc or
> mmap.
> This patch extracts the allocation code into two separate classes:
> MmapArrayAllocator and MallocArrayAllocator. ArrayAllocator will
> dispatch to one of these classes depending on the size of the
> allocation. The main motivation for this patch is to allow the fix
> for
> JDK-8077144 to reuse the code in MmapArrayAllocator.
looks good. I will put MmapArrayAllocator to good use :)
Thanks,
Thomas
From vladimir.x.ivanov at oracle.com Thu Mar 10 14:02:36 2016
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Thu, 10 Mar 2016 17:02:36 +0300
Subject: [9] RFR (S): 8141420: Compiler runtime entries don't hold Klass* from
being GCed
Message-ID: <56E17E7C.3010304@oracle.com>
http://cr.openjdk.java.net/~vlivanov/8141420/webrev.01/
https://bugs.openjdk.java.net/browse/JDK-8141420
Though compiler runtime entries use raw Klass*, they don't ensure the
classes can't be unloaded. It causes rare crashes when Full GC and class
unloading happens when freshly loaded class is being constructed and the
only live reference to it is the Klass* passed into the runtime call.
There are KlassHandles/instanceKlassHandles, but they don't do anything
after PermGen was removed.
The fix is to add mirror handles to keep classes alive across safepoints
during the runtime calls. FTR handles aren't needed for primitive
arrays.
I chose the conservative fix, since I plan to backport it into 8u. Filed
JDK-8141420 [1] to refactor the code to use mirrors instead. It should
simplify the logic to track class liveness.
No regression test provided, since I wasn't able to write one w/o
instrumenting the JVM.
Testing: manual (instrumented build which triggers class unloading from
runtime entries), JPRT.
Thanks!
Best regards,
Vladimir Ivanov
[1] https://bugs.openjdk.java.net/browse/JDK-8141420
From coleen.phillimore at oracle.com Thu Mar 10 14:45:40 2016
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Thu, 10 Mar 2016 09:45:40 -0500
Subject: [9] RFR (S): 8141420: Compiler runtime entries don't hold Klass*
from being GCed
In-Reply-To: <56E17E7C.3010304@oracle.com>
References: <56E17E7C.3010304@oracle.com>
Message-ID: <56E18894.6070206@oracle.com>
http://cr.openjdk.java.net/~vlivanov/8141420/webrev.01/src/share/vm/opto/runtime.cpp.udiff.html
In new_instance_C, why not put the holder at the top at line 220 and be
done with it? It's a nice cleanup of the logic though.
Otherwise, looks good. Thank you for diagnosing this problem!
Coleen
On 3/10/16 9:02 AM, Vladimir Ivanov wrote:
> http://cr.openjdk.java.net/~vlivanov/8141420/webrev.01/
> https://bugs.openjdk.java.net/browse/JDK-8141420
>
> Though compiler runtime entries use raw Klass*, they don't ensure the
> classes can't be unloaded. It causes rare crashes when Full GC and
> class unloading happens when freshly loaded class is being constructed
> and the only live reference to it is the Klass* passed into the
> runtime call.
>
> There are KlassHandles/instanceKlassHandles, but they don't do
> anything after PermGen was removed.
>
> The fix is to add mirror handles to keep classes alive across
> safepoints during the runtime calls. FTR handles aren't needed for
> primitive arrays.
>
> I chose the conservative fix, since I plan to backport it into 8u.
> Filed JDK-8141420 [1] to refactor the code to use mirrors instead. It
> should simplify the logic to track class liveness.
>
> No regression test provided, since I wasn't able to write one w/o
> instrumenting the JVM.
>
> Testing: manual (instrumented build which triggers class unloading
> from runtime entries), JPRT.
>
> Thanks!
>
> Best regards,
> Vladimir Ivanov
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8141420
From paul.sandoz at oracle.com Thu Mar 10 17:06:05 2016
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Thu, 10 Mar 2016 18:06:05 +0100
Subject: RFR 8151163 All Buffer implementations should leverage Unsafe
unaligned accessors
In-Reply-To:
References: <142D9ABF-C144-42E6-9FA2-48A90A51C3A9@oracle.com>
<56DED5A3.8030603@oracle.com>
Message-ID: <98B79CA5-4B34-443D-A921-B33390E165B9@oracle.com>
> On 8 Mar 2016, at 19:27, Paul Sandoz wrote:
>
>>> The changes in this webrev take advantage of those for JDK-8149469
>>> and apply the unsafe double addressing scheme so certain byte buffer
>>> view implementations can work across heap and direct buffers. This
>>> should improve the performance on x86 for:
>>
>> I understand the idea, but I think we would need to verify this before
>> pushing.
>>
>
> Admittedly i am leaning on the rational/motivation for the previous changes to use Unsafe unaligned accessors.
>
> I less confident about the impact on non-x86 platforms.
>
> I have some VarHandles related benchmark code [*] i can use to get some numbers.
>
Here is some prelimiary perf numbers for x86 so far:
http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8151163-buffer-unsafe-unaligned-access/perf/ArrayViewTest.java
Observations:
- no regression for aligned and misaligned access
- big performance boost for LongBuffer view accesses over a managed ByteBuffer.
- there are some curious smaller differences between ByteBuffer.getLong, LongBuffer.get, direct and managed [*], which may come down to the addressing mode used for access in unrolled loops (and how variables are hoisted out of the loop). Need to analyse the generated code. Those are not blockers and could be swept up in another issue.
I need to run this on SPARC, but so far it is looking good.
Paul.
[*] bb_direct_long_view < bb_direct_long = bb_managed_long < bb_managed_long_view
From volker.simonis at gmail.com Thu Mar 10 17:10:12 2016
From: volker.simonis at gmail.com (Volker Simonis)
Date: Thu, 10 Mar 2016 18:10:12 +0100
Subject: RFR(S): 8151593: Cleanup definition/usage of INLINE/NOINLINE macros
and add xlC support
Message-ID:
Hi,
can I please have a review and a sponsor for the following clean-up change:
http://cr.openjdk.java.net/~simonis/webrevs/2016/8151593/
https://bugs.openjdk.java.net/browse/JDK-8151593
First I only wanted to implement the INLINE macro for xlC in
instanceKlass.inline.hpp. But then I realized that we also define
NOINLINE in various other files so I decided to do it "the right way"
and clean up the code a little bit.
I've now moved the definition of the INLINE/NOINLINE macros to
globalDefinitions_.hpp. In the case where there is no
compiler-specific definition, globalDefinitions.hpp defines empty
defaults for the macros.
I've also renamed INLINE to ALWAYSINLINE to match its intention more clearly.
Currently NOINLINE is really only defined on Linux. This is the same
behavior we had before the change. Following some more details:
os_linux.cpp
- removed the handling for gcc < 3 (even we at SAP don't use this anymore :)
objectMonitor.cpp, synchronizer.cpp
- completely removed the annotation with NOINLNE which is there since
pre-OpenJDK times already. The comment mentions that this was required
to prevent build-time failures with 'older' versions of GCC. But we
already build without 'NOINLINE' on Linux/ppc64 since years and I've
also tested that it still works on Linux/x86.
I've Build and smoke-tested on Linux/amd64 and Linux/ppc64,
Solaris/SPARC, MacOS X, AIX and Windows.
Regards,
Volker
From christian.thalinger at oracle.com Thu Mar 10 17:11:58 2016
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Thu, 10 Mar 2016 07:11:58 -1000
Subject: [9] RFR (S): 8141420: Compiler runtime entries don't hold Klass*
from being GCed
In-Reply-To: <56E17E7C.3010304@oracle.com>
References: <56E17E7C.3010304@oracle.com>
Message-ID: <11092161-DC6B-4CB9-9C11-5D21CE78FD58@oracle.com>
Looks good.
> On Mar 10, 2016, at 4:02 AM, Vladimir Ivanov wrote:
>
> http://cr.openjdk.java.net/~vlivanov/8141420/webrev.01/
> https://bugs.openjdk.java.net/browse/JDK-8141420
>
> Though compiler runtime entries use raw Klass*, they don't ensure the classes can't be unloaded. It causes rare crashes when Full GC and class unloading happens when freshly loaded class is being constructed and the only live reference to it is the Klass* passed into the runtime call.
>
> There are KlassHandles/instanceKlassHandles, but they don't do anything after PermGen was removed.
>
> The fix is to add mirror handles to keep classes alive across safepoints during the runtime calls. FTR handles aren't needed for primitive arrays.
>
> I chose the conservative fix, since I plan to backport it into 8u. Filed JDK-8141420 [1] to refactor the code to use mirrors instead. It should simplify the logic to track class liveness.
>
> No regression test provided, since I wasn't able to write one w/o instrumenting the JVM.
>
> Testing: manual (instrumented build which triggers class unloading from runtime entries), JPRT.
>
> Thanks!
>
> Best regards,
> Vladimir Ivanov
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8141420
From aleksey.shipilev at oracle.com Thu Mar 10 17:14:57 2016
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Thu, 10 Mar 2016 20:14:57 +0300
Subject: RFR 8151163 All Buffer implementations should leverage Unsafe
unaligned accessors
In-Reply-To: <98B79CA5-4B34-443D-A921-B33390E165B9@oracle.com>
References: <142D9ABF-C144-42E6-9FA2-48A90A51C3A9@oracle.com>
<56DED5A3.8030603@oracle.com>
<98B79CA5-4B34-443D-A921-B33390E165B9@oracle.com>
Message-ID: <56E1AB91.2090801@oracle.com>
On 03/10/2016 08:06 PM, Paul Sandoz wrote:
>> On 8 Mar 2016, at 19:27, Paul Sandoz wrote:
>>
>>>> The changes in this webrev take advantage of those for JDK-8149469
>>>> and apply the unsafe double addressing scheme so certain byte buffer
>>>> view implementations can work across heap and direct buffers. This
>>>> should improve the performance on x86 for:
>>>
>>> I understand the idea, but I think we would need to verify this before
>>> pushing.
>>>
>>
>> Admittedly i am leaning on the rational/motivation for the previous changes to use Unsafe unaligned accessors.
>>
>> I less confident about the impact on non-x86 platforms.
>>
>> I have some VarHandles related benchmark code [*] i can use to get some numbers.
>>
>
> Here is some prelimiary perf numbers for x86 so far:
>
> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8151163-buffer-unsafe-unaligned-access/perf/ArrayViewTest.java
Okay, the performance data looks good. This addresses my concerns for
this issue, thanks!
Cheers,
-Aleksey
From daniel.daugherty at oracle.com Thu Mar 10 17:56:34 2016
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Thu, 10 Mar 2016 10:56:34 -0700
Subject: RFR(S): 8151593: Cleanup definition/usage of INLINE/NOINLINE
macros and add xlC support
In-Reply-To:
References:
Message-ID: <56E1B552.6080400@oracle.com>
Hi Volker,
The objectMonitor.cpp and synchronizer.cpp NOINLINE issue is tracked via:
JDK-8049103 investigate whether inlining still needs to be inhibited in
objectMonitor.cpp and synchronizer.cpp
https://bugs.openjdk.java.net/browse/JDK-8049103
Feel free use both bug IDs in your changeset.
Dan
On 3/10/16 10:10 AM, Volker Simonis wrote:
> Hi,
>
> can I please have a review and a sponsor for the following clean-up change:
>
> http://cr.openjdk.java.net/~simonis/webrevs/2016/8151593/
> https://bugs.openjdk.java.net/browse/JDK-8151593
>
> First I only wanted to implement the INLINE macro for xlC in
> instanceKlass.inline.hpp. But then I realized that we also define
> NOINLINE in various other files so I decided to do it "the right way"
> and clean up the code a little bit.
>
> I've now moved the definition of the INLINE/NOINLINE macros to
> globalDefinitions_.hpp. In the case where there is no
> compiler-specific definition, globalDefinitions.hpp defines empty
> defaults for the macros.
>
> I've also renamed INLINE to ALWAYSINLINE to match its intention more clearly.
>
> Currently NOINLINE is really only defined on Linux. This is the same
> behavior we had before the change. Following some more details:
>
> os_linux.cpp
>
> - removed the handling for gcc < 3 (even we at SAP don't use this anymore :)
>
> objectMonitor.cpp, synchronizer.cpp
>
> - completely removed the annotation with NOINLNE which is there since
> pre-OpenJDK times already. The comment mentions that this was required
> to prevent build-time failures with 'older' versions of GCC. But we
> already build without 'NOINLINE' on Linux/ppc64 since years and I've
> also tested that it still works on Linux/x86.
>
> I've Build and smoke-tested on Linux/amd64 and Linux/ppc64,
> Solaris/SPARC, MacOS X, AIX and Windows.
>
> Regards,
> Volker
From vladimir.x.ivanov at oracle.com Thu Mar 10 18:55:23 2016
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Thu, 10 Mar 2016 21:55:23 +0300
Subject: [9] RFR (XS): 8151623: Zap freed Metaspace chunks in non-product
binaries
Message-ID: <56E1C31B.8070008@oracle.com>
http://cr.openjdk.java.net/~vlivanov/8151623/webrev.00
https://bugs.openjdk.java.net/browse/JDK-8151623
Zap freed Metaspace chunks in non-product binaries to catch stray
accesses to unloaded classes.
Testing: JPRT, RBT (in progress): hotspot/test:hotspot_all,
jdk/test:tier1 & tier2, vm.parallel_class_loading.testlist,
vm.gc.testlist, BigApps w/ fastdebug binaries.
Thanks!
Best regards,
Vladimir Ivanov
From vladimir.kozlov at oracle.com Thu Mar 10 19:10:31 2016
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Thu, 10 Mar 2016 11:10:31 -0800
Subject: [9] RFR (S): 8141420: Compiler runtime entries don't hold Klass*
from being GCed
In-Reply-To: <56E17E7C.3010304@oracle.com>
References: <56E17E7C.3010304@oracle.com>
Message-ID: <56E1C6A7.8020709@oracle.com>
Looks good.
> Filed JDK-8141420 [1] to refactor the code to use mirrors instead.
Should be https://bugs.openjdk.java.net/browse/JDK-8151620
Thanks,
Vladimir K
On 3/10/16 6:02 AM, Vladimir Ivanov wrote:
> http://cr.openjdk.java.net/~vlivanov/8141420/webrev.01/
> https://bugs.openjdk.java.net/browse/JDK-8141420
>
> Though compiler runtime entries use raw Klass*, they don't ensure the
> classes can't be unloaded. It causes rare crashes when Full GC and class
> unloading happens when freshly loaded class is being constructed and the
> only live reference to it is the Klass* passed into the runtime call.
>
> There are KlassHandles/instanceKlassHandles, but they don't do anything
> after PermGen was removed.
>
> The fix is to add mirror handles to keep classes alive across safepoints
> during the runtime calls. FTR handles aren't needed for primitive arrays.
>
> I chose the conservative fix, since I plan to backport it into 8u. Filed
> JDK-8141420 [1] to refactor the code to use mirrors instead. It should
> simplify the logic to track class liveness.
>
> No regression test provided, since I wasn't able to write one w/o
> instrumenting the JVM.
>
> Testing: manual (instrumented build which triggers class unloading from
> runtime entries), JPRT.
>
> Thanks!
>
> Best regards,
> Vladimir Ivanov
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8141420
From thomas.stuefe at gmail.com Thu Mar 10 19:22:22 2016
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Thu, 10 Mar 2016 20:22:22 +0100
Subject: RFR(S): 8151593: Cleanup definition/usage of INLINE/NOINLINE
macros and add xlC support
In-Reply-To:
References:
Message-ID: