Ha
On 09/10/2015 02:17 AM, David Holmes wrote:
> On 10/09/2015 12:01 AM, Andrew Haley wrote:
>> On 09/09/2015 02:55 PM, David M. Lloyd wrote:
>>> On 09/09/2015 08:17 AM, Andrew Haley wrote:
On 09/09/2015 02:13 PM, David M. Lloyd wrote:
> How would you hook into the safepoint to perform the
On 10 Sep 2015, at 00:07, Stuart Marks wrote:
>
>
> On 9/9/15 2:32 PM, Stuart Marks wrote:
>> I'll change the occurrences of "pipeline execution" to "stream pipeline
>> execution" per your exchange with Paul. Looks like there are two such
>> occurrences in each of the tokens() and findAll() me
The safepoint happiness is unfortunately a separate issue in Hotspot, and
it's definitely not happy times :). Part of the problem is the
piggybacking of various operations on a safepoint - the safepoint time
alone (not counting GC, say) keeps growing. You probably could piggyback
this on Guarante
On 09/10/2015 12:25 PM, Vitaly Davidovich wrote:
> The safepoint happiness is unfortunately a separate issue in
> Hotspot, and it's definitely not happy times :). Part of the
> problem is the piggybacking of various operations on a safepoint -
> the safepoint time alone (not counting GC, say) kee
Hi Joe,
I think adjusting the timeouts is already covered.
The test uses Process.waitFor(timeout) to wait for the process to exit,
but only up to the timeout value.
The "Utils.adjustTimeout(5)", performs the desired adjustment based on
the jtreg timeoutFactor.
Utils is in the testlibrary.
Rog
Roger,
The timeouts, in this test, are just to ensure that the test does not block
indefinitely, if it encounters a bug in the JDK, right? If a timeout is ever
triggered then there is a bug, right?
If this is the case then, we have used larger timeouts in other areas ( net,
concurrency ) to c
Hi Stephen,
I can take it up but probably won't get to it until after JavaOne.
(Early Nov)
Roger
On 9/8/2015 2:53 PM, Stephen Colebourne wrote:
Anyone like to take this on please?
Stephen
On 28 Aug 2015 00:07, "Stephen Colebourne" wrote:
External question sites indicate that users have d
On 09/10/2015 08:22 AM, Andrew Haley wrote:
On 09/10/2015 12:25 PM, Vitaly Davidovich wrote:
The safepoint happiness is unfortunately a separate issue in
Hotspot, and it's definitely not happy times :). Part of the
problem is the piggybacking of various operations on a safepoint -
the safepoin
Hi Chris,
ok, updated the webrev with the 30 sec timeouts.
I also expect that the timeoutFactor on slow systems would be applied by
jtreg.
Roger
On 9/10/2015 9:43 AM, Chris Hegarty wrote:
Roger,
The timeouts, in this test, are just to ensure that the test does not block
indefinitely, if i
Hello!
Would you please approve the *almost* direct backport of the fix from
jdk 9 to 8u?
The patch didn't apply automatically due to renaming of a function.
Bug: https://bugs.openjdk.java.net/browse/JDK-8080115
Jdk9 change: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/fe002a83ba79
Jdk9 review
On 10 Sep 2015, at 14:49, Roger Riggs wrote:
> Hi Chris,
>
> ok, updated the webrev with the 30 sec timeouts.
Thanks Roger.
I remember going many rounds on false timeouts from tests in other areas a few
years back. We came to a consensus that 30 secs as a timeout, that should never
be trig
On 09/10/2015 02:48 PM, David M. Lloyd wrote:
> On 09/10/2015 08:22 AM, Andrew Haley wrote:
>> On 09/10/2015 12:25 PM, Vitaly Davidovich wrote:
>>
>>> The safepoint happiness is unfortunately a separate issue in
>>> Hotspot, and it's definitely not happy times :). Part of the
>>> problem is the pi
Shall I just open a number of these with things to be changed, so you
can deal with them in a batch then?
Stephen
On 10 September 2015 at 14:42, Roger Riggs wrote:
> Hi Stephen,
>
> I can take it up but probably won't get to it until after JavaOne. (Early
> Nov)
>
> Roger
>
>
>
> On 9/8/2015 2:5
Looks fine. Approved.
Regards,
Sean.
On 10/09/2015 14:54, Ivan Gerasimov wrote:
Hello!
Would you please approve the *almost* direct backport of the fix from
jdk 9 to 8u?
The patch didn't apply automatically due to renaming of a function.
Bug: https://bugs.openjdk.java.net/browse/JDK-8080115
Hi Stephen,
Yes, things that logically go together can be in the same bug/issue and
be handled with a single
review cycle to keep the overhead down.
Thanks, Roger
On 9/10/2015 10:08 AM, Stephen Colebourne wrote:
Shall I just open a number of these with things to be changed, so you
can deal
So what happens after safepoint is done and thread accesses the mapping (it
would need protection NONE, not just write)? JVM is then going to trap the
signal and convert to an exception?
sent from my phone
On Sep 10, 2015 10:06 AM, "Andrew Haley" wrote:
> On 09/10/2015 02:48 PM, David M. Lloyd w
Please review a couple of clarifications to the
Process/ProcessHandle.allChildren methods.
8132883: Should not specify that non-alive processes have zero children.
That is OS specific and cannot/should not be guaranteed by the spec
8131763:
1. Requests a definition of 'direct' and 'indi
Whether biased locking being enabled by default is up for debate; my
opinion is it should be off on modern CPUs. If you're not contending, CAS
isn't much of an issue. If you are contending, then you'll get revocations
which is more expensive than the CAS. Biased locking would be profitable
on ha
On 09/10/2015 03:13 PM, Vitaly Davidovich wrote:
> So what happens after safepoint is done and thread accesses the
> mapping (it would need protection NONE, not just write)? JVM is then
> going to trap the signal and convert to an exception?
One of us is missing something, and I don't think it's
Yes, so what happens when that guard page is accessed by a thread after
safepoint? The safepoint does nothing, as you said, it just ensures no
thread is actively working against the mapping but it may still be
reachable.
sent from my phone
On Sep 10, 2015 10:22 AM, "Andrew Haley" wrote:
> On 09/
On 09/10/2015 03:26 PM, Vitaly Davidovich wrote:
> Yes, so what happens when that guard page is accessed by a thread after
> safepoint?
A segfault and a null pointer exception.
Andrew.
Well, you'd probably want something other than NPE here -- perhaps a new
dedicated exception to signal this condition. And this means the segfault
handling now needs to know about this type of situation as well, rather
than just NPEs.
On Thu, Sep 10, 2015 at 10:32 AM, Andrew Haley wrote:
> On 0
These spec clarifications look ok to me.
Being pedantic, should the ProcessHandle changes say 'the process’, rather than
'this process’?
-Chris.
On 10 Sep 2015, at 15:17, Roger Riggs wrote:
> Please review a couple of clarifications to the
> Process/ProcessHandle.allChildren methods.
>
> 81
Or, the Java methods which wrap this access can just catch NPE and throw
the new exception type.
On 09/10/2015 09:35 AM, Vitaly Davidovich wrote:
Well, you'd probably want something other than NPE here -- perhaps a new
dedicated exception to signal this condition. And this means the segfault
h
Sure, if we're comfortable saying that the only cause of NPE there is due
to this and not something else.
On Thu, Sep 10, 2015 at 10:37 AM, David M. Lloyd
wrote:
> Or, the Java methods which wrap this access can just catch NPE and throw
> the new exception type.
>
>
> On 09/10/2015 09:35 AM, Vit
Hi Chris,
Corrected, 'the' reads better than 'this' and avoids potential confusion.
Thanks, Roger
On 9/10/2015 10:34 AM, Chris Hegarty wrote:
These spec clarifications look ok to me.
Being pedantic, should the ProcessHandle changes say 'the process’, rather than
'this process’?
-Chris.
O
On 09/10/2015 03:35 PM, Vitaly Davidovich wrote:
> Well, you'd probably want something other than NPE here -- perhaps a
> new dedicated exception to signal this condition.
Sure, if you like, but that's a detail. We are arguing about what
colour to paint the bike shed. :)
> And this means the
On 10 Sep 2015, at 15:43, Roger Riggs wrote:
> Hi Chris,
>
> Corrected, 'the' reads better than 'this' and avoids potential confusion.
Looks good.
-Chris.
> Thanks, Roger
>
>
> On 9/10/2015 10:34 AM, Chris Hegarty wrote:
>> These spec clarifications look ok to me.
>>
>> Being pedantic, sh
>
> Sure, if you like, but that's a detail. We are arguing about what
> colour to paint the bike shed. :)
The reason it may be more than just a bikeshed is because if this requires
more cleverness in the segfault handler, then it's yet more work to make
this happen. I agree it's an implementat
On 09/10/2015 03:56 PM, Vitaly Davidovich wrote:
> Sure, if you like, but that's a detail. We are arguing about what
> colour to paint the bike shed. :)
>
> The reason it may be more than just a bikeshed is because if this requires
> more cleverness in the segfault handler, then it's y
On Wed, Sep 9, 2015 at 11:49 PM, Roger Riggs wrote:
> Hi,
>
> Please review this update to extract the uid on from the owner of the
> /proc/ file.
> It should be more reliable than using the owner of the /proc//cmdline
> file.
>
> Webrev:
> http://cr.openjdk.java.net/~rriggs/webrev-info-813355
Hi Volker,
Thanks for the review, I added the code you provided to use the correct
length.
Updated the webrev:
http://cr.openjdk.java.net/~rriggs/webrev-info-8133552/
Roger
On 9/10/2015 11:52 AM, Volker Simonis wrote:
On Wed, Sep 9, 2015 at 11:49 PM, Roger Riggs wrote:
Hi,
Please re
> there're already ways to bring down the JVM (e.g. JNI, existing Unsafe usage,
> etc),
If you can somehow pass switches to the JVM, this one wins my personal
beauty contest (from globals.hpp):
product(intx, SelfDestructTimer, 0, \
"Will cause VM t
To be fair, this one sounds like it would initiate an orderly/graceful
shutdown whereas a bug in JNI/Unsafe kills it almost instantly (modulo
error reporting/core dumping) :)
On Thu, Sep 10, 2015 at 2:47 PM, Dawid Weiss wrote:
> > there're already ways to bring down the JVM (e.g. JNI, existing U
On 9/9/15 3:51 PM, Xueming Shen wrote:
One more comment regarding the CME check.
2829 if (expectedCount != modCount) {
2830 throw new ConcurrentModificationException();
2831 }
While it definitely serves the purpose of "fail-fast"
On 10 Sep 2015, at 22:22, Stuart Marks wrote:
>>> It'd be better to initialize expectedCount to modCount in constrocutor?
>
> That's how I had it initially, but at Paul Sandoz' suggestion I delayed the
> initialization to the first call to tryAdvance().
Yes, it’s preferable to have a "late-bind
On 09/10/2015 01:22 PM, Stuart Marks wrote:
On 9/9/15 3:51 PM, Xueming Shen wrote:
One more comment regarding the CME check.
2829 if (expectedCount != modCount) {
2830 throw new ConcurrentModificationException();
2831 }
While it
On 09/10/2015 01:55 PM, Paul Sandoz wrote:
On 10 Sep 2015, at 22:22, Stuart Marks wrote:
It'd be better to initialize expectedCount to modCount in constrocutor?
That's how I had it initially, but at Paul Sandoz' suggestion I delayed the
initialization to the first call to tryAdvance().
Yes,
Hi guys,
Perhaps there's no need for this protection/trap dance. If the situation
is never tripped in correct programs (that unmap only after noone is
using the buffers any more), then checking for address and throwing in
case it is equal to some guard value is a never taken branch that is
pr
There's still a race condition since someone may have passed the guard,
entered a safepoint, and then proceeded to access the memory.
sent from my phone
On Sep 10, 2015 6:29 PM, "Peter Levart" wrote:
> Hi guys,
>
> Perhaps there's no need for this protection/trap dance. If the situation
> is nev
On 11/09/2015 12:56 AM, Vitaly Davidovich wrote:
Sure, if you like, but that's a detail. We are arguing about what
colour to paint the bike shed. :)
The reason it may be more than just a bikeshed is because if this requires
more cleverness in the segfault handler, then it's yet more work to
41 matches
Mail list logo
