The only usage today of the DTrace macros under the USDT1 define is the SDT
provider on linux. This can be changed to use the USDT2 style by preprocessing
the .d files into .h files with the dtrace utility in the same way as we do on
solaris and OS X.
I have also moved the provider definition f
Looks good!
Thanks,
/Staffan
On 22 jan 2014, at 18:43, Kevin Walls wrote:
> Hi,
>
> Can I just get a review of this jtreg tag change in a testcase. The testcase
> specifically contains a utf8 character and to make sure it compiles
> everywhere we need to specify -encoding on the @compile li
On 22/01/2014 11:07 PM, Jaroslav Bachorik wrote:
Updated webrev with no "arrive()" calls dangling.
- http://cr.openjdk.java.net/~jbachorik/6309226/webrev.07
Thanks looks okay. The proof as always is in the running of the test.
David
-JB-
On 22.1.2014 09:12, Jaroslav Bachorik wrote:
Argh.
Changeset: 57c26829deb6
Author:mullan
Date: 2014-01-22 19:06 -0500
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/57c26829deb6
8031825: OCSP client can't find responder cert if it uses a different subject
key id algorithm than responderID
Reviewed-by: vinnie, xuelei
! src/share/c
Kevin,
Looks good for me.
-Dmitry
On 2014-01-22 21:43, Kevin Walls wrote:
> Hi,
>
> Can I just get a review of this jtreg tag change in a testcase. The
> testcase specifically contains a utf8 character and to make sure it
> compiles everywhere we need to specify -encoding on the @compile line,
Hi,
Can I just get a review of this jtreg tag change in a testcase. The
testcase specifically contains a utf8 character and to make sure it
compiles everywhere we need to specify -encoding on the @compile line,
and then add an @run line:
webrev
http://cr.openjdk.java.net/~kevinw/8032466/web
Hi Shanliang,
This looks reasonable to me.
I'm not sure that using freeMemory() will always work - but at
the worst it means that there are still some cases where
the test that used to fail will continue to fail ;-)
We have both seen that it fixes the original issue which
was encountered on Mac
Here is the new version:
http://cr.openjdk.java.net/~sjiang/JDK-6980984/01/
with the modifications for:
1) synchronization issues raised by Daniel
2) "setUsatgeThreshold" -> "setUsageThreshold"
The odd issue about getting slower with:
chunkSize = 1M;
maybe was from the "old gen" behavior,
Hi Staffan,
the change looks good now :)
Thanks,
Erik
On 2014-01-22 16:02, Staffan Larsen wrote:
Erik discovered that I used traced events with signed values for some unsigned
flag types.
So, new revision: http://cr.openjdk.java.net/~sla/8032250/webrev.02/
Thanks,
/Staffan
On 22 jan 2014,
Looks good.
Erik
Staffan Larsen skrev 2014-01-22 16:02:
Erik discovered that I used traced events with signed values for some unsigned
flag types.
So, new revision: http://cr.openjdk.java.net/~sla/8032250/webrev.02/
Thanks,
/Staffan
On 22 jan 2014, at 15:08, Staffan Larsen wrote:
Erik He
Erik discovered that I used traced events with signed values for some unsigned
flag types.
So, new revision: http://cr.openjdk.java.net/~sla/8032250/webrev.02/
Thanks,
/Staffan
On 22 jan 2014, at 15:08, Staffan Larsen wrote:
> Erik Helin suggested using template functions instead of macros
Hi Shanliang,
I just notice that there are some synchronization
issues in the test as well: all static variables
used by the allocator thread should be declared
volatile (chunkSize, mpool ...).
-- daniel
On 1/22/14 2:27 PM, shanliang wrote:
Hi,
The bug was reproduced only on jdk6 on my Mac, b
Hi Jesper,
On Tuesday 21 January 2014 22.49.19 Jesper Wilhelmsson wrote:
> Hi,
>
> Could I have a few reviews of this change?
>
> Summary:
> To allow applications a more fine grained control over the GC over time,
> we'll make the flags MinHeapFreeRatio and MaxHeapFreeRatio manageable.
>
> The
On 1/22/14 3:32 PM, shanliang wrote:
Jaroslav Bachorik wrote:
Hi Shanliang,
On 22.1.2014 14:27, shanliang wrote:
Hi,
The bug was reproduced only on jdk6 on my Mac, but well passed on 7/8/9.
We can have several solutions, like to use:
Runtime.getRuntime().maxMemory()
Runtime.getRuntime
Jaroslav Bachorik wrote:
On 22.1.2014 15:32, shanliang wrote:
Jaroslav Bachorik wrote:
Hi Shanliang,
On 22.1.2014 14:27, shanliang wrote:
Hi,
The bug was reproduced only on jdk6 on my Mac, but well passed on
7/8/9.
We can have several solutions, like to use:
Runtime.getRuntime().maxMem
On 22.1.2014 15:32, shanliang wrote:
Jaroslav Bachorik wrote:
Hi Shanliang,
On 22.1.2014 14:27, shanliang wrote:
Hi,
The bug was reproduced only on jdk6 on my Mac, but well passed on 7/8/9.
We can have several solutions, like to use:
Runtime.getRuntime().maxMemory()
Runtime.getRuntime
Jaroslav Bachorik wrote:
Hi Shanliang,
On 22.1.2014 14:27, shanliang wrote:
Hi,
The bug was reproduced only on jdk6 on my Mac, but well passed on 7/8/9.
We can have several solutions, like to use:
Runtime.getRuntime().maxMemory()
Runtime.getRuntime().totalMemory;
MemoryUsage.getCo
Hi Shanliang,
On 22.1.2014 14:27, shanliang wrote:
Hi,
The bug was reproduced only on jdk6 on my Mac, but well passed on 7/8/9.
We can have several solutions, like to use:
Runtime.getRuntime().maxMemory()
Runtime.getRuntime().totalMemory;
MemoryUsage.getCommitted()
You were also
Erik Helin suggested using template functions instead of macros which makes the
code a little more type safe.
Also added a missing #include in globals.cpp.
Here is a new version of the webrev:
http://cr.openjdk.java.net/~sla/8032250/webrev.01/
Thanks,
/Staffan
On 21 jan 2014, at 14:47, Staffa
Ok.
/Staffan
On 22 jan 2014, at 14:49, Dmitry Samersoff wrote:
> Staffan,
>
> On 2014-01-22 17:30, Staffan Larsen wrote:
>> Looks good!
>>
>> Should we perhaps add the output of ‘ls -l $HOME/jdb.ini’ when it fails?
>
> I would prefer not to load test with diagnostic code (actually, check
>
Staffan,
On 2014-01-22 17:30, Staffan Larsen wrote:
> Looks good!
>
> Should we perhaps add the output of ‘ls -l $HOME/jdb.ini’ when it fails?
I would prefer not to load test with diagnostic code (actually, check
for root is also redundant).
There are plenty of reason for file to being readable
Looks good!
Should we perhaps add the output of ‘ls -l $HOME/jdb.ini’ when it fails?
Thanks,
/Staffan
On 22 jan 2014, at 14:18, Dmitry Samersoff wrote:
> Staffan,
>
> http://cr.openjdk.java.net/~dsamersoff/JDK-8002116/webrev.02/
>
> Updated webrev - test will continue fail but with meaningf
Hi,
The bug was reproduced only on jdk6 on my Mac, but well passed on 7/8/9.
We can have several solutions, like to use:
Runtime.getRuntime().maxMemory()
Runtime.getRuntime().totalMemory;
MemoryUsage.getCommitted()
or hard-code chunkSize to be 1M.
I found that the test ran much faste
Staffan,
http://cr.openjdk.java.net/~dsamersoff/JDK-8002116/webrev.02/
Updated webrev - test will continue fail but with meaningful diagnostic.
-Dmitry
On 2014-01-21 18:49, Staffan Larsen wrote:
> Should we really be skipping the test if this fail? Isn’t it an
> infrastructure bug if we can’t
Updated webrev with no "arrive()" calls dangling.
- http://cr.openjdk.java.net/~jbachorik/6309226/webrev.07
-JB-
On 22.1.2014 09:12, Jaroslav Bachorik wrote:
Argh. Sorry. Probably messed up when restoring my crashed HDD. I will go
through the patch to see if there are any other omissions.
Th
Mattias,
We don't use totallines anymore so need not to increment it:
{ totallines++; print $0 }
otherwise looks good.
-Dmitry
On 2014-01-21 16:32, Mattias Tobiasson wrote:
> Hi,
> Could you please review this test fix. The current test is unstable and fails
> intermittently.
>
> The test
On 2014-01-22 14:38, David Holmes wrote:
> On 22/01/2014 7:57 PM, Dmitry Samersoff wrote:
>> On 2014-01-22 10:39, David Holmes wrote:
>>> On 22/01/2014 12:00 AM, Dmitry Samersoff wrote:
Missed CR in subject. Sorry!
http://cr.openjdk.java.net/~dsamersoff/JDK-8002116/webrev.01/
>>>
>>>
Looks good! I can sponsor this.
Thanks,
/Staffan
On 21 jan 2014, at 13:32, Mattias Tobiasson
wrote:
> Hi,
> Could you please review this test fix. The current test is unstable and fails
> intermittently.
>
> The test parses output from jstat.
> It verifies number of header lines, data lines
Changeset: ff56039c4870
Author:erikj
Date: 2014-01-22 12:13 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ff56039c4870
8032217: failure in man page processing
Reviewed-by: dholmes, tbell
! make/Images.gmk
On 22/01/2014 7:57 PM, Dmitry Samersoff wrote:
On 2014-01-22 10:39, David Holmes wrote:
On 22/01/2014 12:00 AM, Dmitry Samersoff wrote:
Missed CR in subject. Sorry!
http://cr.openjdk.java.net/~dsamersoff/JDK-8002116/webrev.01/
You already create the file with mkFiles so no need to echo somet
Hi Jesper,
The calculation in
PSAdaptiveSizePolicy::calculated_old_free_size_in_bytes() looks wrong to
me. I would have expected this:
86 // free = (live*ratio) / (1-ratio)
87 size_t max_free = (size_t)((heap->old_gen()->used_in_bytes() *
mhfr_as_percent) / (1.0 - mhfr_as_percen
On 2014-01-22 10:39, David Holmes wrote:
> On 22/01/2014 12:00 AM, Dmitry Samersoff wrote:
>> Missed CR in subject. Sorry!
>>
>> http://cr.openjdk.java.net/~dsamersoff/JDK-8002116/webrev.01/
>
> You already create the file with mkFiles so no need to echo something
> into it, a simple cat will suff
Jesper,
This looks ok from a serviceability perspective. Long term we should probably
have a more pluggable way to verify values of manageable flags so we can avoid
some of the duplication.
I have a slight problem with is_within() and is_min() in that it is not obvious
from the call site if th
Jesper,
This looks ok from a serviceability perspective. Long term we should probably
have a more pluggable way to verify values of manageable flags so we can avoid
some of the duplication.
I have a slight problem with is_within() and is_min() in that it is not obvious
from the call site if th
Argh. Sorry. Probably messed up when restoring my crashed HDD. I will go
through the patch to see if there are any other omissions.
Thanks,
-JB-
David Holmes wrote:
>Hi Jaroslav,
>
>I still see some suspect uses of p.arrive() instead of
>p.arriveAndAwaitAdvance().
>
>David
>
>On 21/01/2014 11:1
35 matches
Mail list logo
