Hi All,
File.getCanonicalPath() is a very time-consuming method, we observed
significant performance degradation from some application's startup stage
with java.io.FilePermission. However, lazying load the calls to
getCanonicalPath() from java.ioFilePermission is straightforward and solve
this
Do you need some kind of synchronization on the get_dir_rec() method?
--Max
On Dec 1, 2014, at 16:06, deven you youd...@linux.vnet.ibm.com wrote:
Hi All,
File.getCanonicalPath() is a very time-consuming method, we observed
significant performance degradation from some application's startup
On 01/12/2014 08:06, deven you wrote:
Hi All,
Our current NIO2 file system support to AIX is very limited, hence I took
some time to try to complete it. Openjdk bug[1] tracks this bug and here is
my patch[2] which enhances the AIX file system especially by adding the
support by Implementing
On 01/12/2014 00:09, David Holmes wrote:
:
Compact Profiles support was added in 8, but only for the Linux
platform. I've now generalized this support to all the other
platforms. This is an 8u only change, targetting 8u60, as soon as the
jdk8u/dev starts accepting things for 8u60.
Just to
Hello David,
Most of it looks good, but profile-includes.txt could certainly benefit
from some reduction in duplication. (Aside from the extension of the
file itself, which I find a bit weird, but it's already there.) The two
common structures that I can see are:
1. Expanding debuginfo files
Hi Igor,
This looks ok.
I like how you have factored out things into TimeLimitedRunner. Do you plan in
a future patch to update lambda form test code that uses similar functionality?
Is the adjustment timeout *= 0.9 necessary? does reduction by 10% make a
difference?
Paul.
On Nov 29, 2014,
On 12/1/14, 2:46 PM, Paul Sandoz wrote:
Hi Igor,
This looks ok.
I like how you have factored out things into TimeLimitedRunner. Do you plan in
a future patch to update lambda form test code that uses similar functionality?
Is the adjustment timeout *= 0.9 necessary? does reduction by 10%
On Mon, Dec 01, 2014 at 01:10:29PM +0100, Jan Lahoda wrote:
Hi,
In a preparation for JDK-8061549, I'd like to rename all uses of '_'
as a one-character identifier in the jaxp and jdk repositories. All
the uses I was able to find are in tests, and the identifier is used
as a name of a catch
I know this is descending into bike shedding - but I like that split of
definition, shamelessly stealing for my future projects, thanks!
Cheers,
Martijn
On 1 December 2014 at 13:01, Andreas Lundblad andreas.lundb...@oracle.com
wrote:
On Mon, Dec 01, 2014 at 01:10:29PM +0100, Jan Lahoda wrote:
On 01/12/2014 12:10, Jan Lahoda wrote:
Hi,
In a preparation for JDK-8061549, I'd like to rename all uses of '_'
as a one-character identifier in the jaxp and jdk repositories. All
the uses I was able to find are in tests, and the identifier is used
as a name of a catch parameter. The
Thanks, makes sense. I've updated the patches so that in cases where (I
think) the exception is expected, the name is expected. I used
unused in other cases where the fact that an exception was thrown is
not ignored, but where the value of the exception parameter is not used.
I've forgot
On 1.12.2014 14:20, Alan Bateman wrote:
On 01/12/2014 12:10, Jan Lahoda wrote:
Hi,
In a preparation for JDK-8061549, I'd like to rename all uses of '_'
as a one-character identifier in the jaxp and jdk repositories. All
the uses I was able to find are in tests, and the identifier is used
as a
The changes looks fine to me Jan.
-Chris.
On 01/12/14 13:25, Jan Lahoda wrote:
Thanks, makes sense. I've updated the patches so that in cases where (I
think) the exception is expected, the name is expected. I used
unused in other cases where the fact that an exception was thrown is
not
Hi all,
Looking for a reviewer for this trivial typo in Connection.isValid
hg diff
diff -r f619341171c0 src/java.sql/share/classes/java/sql/Connection.java
--- a/src/java.sql/share/classes/java/sql/Connection.java Sat Nov 29
11:14:20 2014 -0500
+++
Looks good Lance.
I had to stare at the diff for a while before seeing it ;-)
best regards,
-- daniel
On 01/12/14 17:04, Lance Andersen wrote:
Hi all,
Looking for a reviewer for this trivial typo in Connection.isValid
hg diff
diff -r f619341171c0
Hi,
Please find below a patch for:
8065552: setAccessible(true) on fields of Class may throw
a SecurityException
webrev:
http://cr.openjdk.java.net/~dfuchs/webrev_8065552/webrev.00/
Description of the problem:
The following test case passes on 8u20 but fails on 8u40 and above:
Thank you Daniel.
Yes, it is easy to miss (which is probably why it was not caught before :-) )
Best,
Lance
On Dec 1, 2014, at 11:25 AM, Daniel Fuchs daniel.fu...@oracle.com wrote:
Looks good Lance.
I had to stare at the diff for a while before seeing it ;-)
best regards,
-- daniel
Hi all,
Looking for a review for this change to DriverManager to reduce the possibility
on a deadlock on clinit. that I have been discussing with Mandy.
The change removes the static initializer block as well as the synchronized
keyword from registerDriver.
The webrev can be found at
Am Dienstag, 25. November 2014, 11:15:36 schrieb Hans Boehm:
I'm no hardware architect, but fundamentally it seems to me that
load x
acquire_fence
imposes a much more stringent constraint than
load_acquire x
Consider the case in which the load from x is an L1 hit, but a preceding
To be concrete here, on Power, loads can normally be ordered by an address
dependency or light-weight fence (lwsync). However, neither is enough to
prevent the questionable outcome for IRIW, since it doesn't ensure that the
stores in T1 and T2 will be made visible to other threads in a consistent
I see time to time comments in the jvm sources referencing membars and fences.
Would you say that they are used interchangeably ? Having the same meaning but
for different CPU arch.
Sent from my iPhone
On Nov 25, 2014, at 6:04 AM, Paul Sandoz paul.san...@oracle.com wrote:
Hi Martin,
memory_order_release meaningful, but somewhat different from the
non-fence
it would be nice to have release fence with an artificial dependency
to define a set of actually release stores and not constraining other
subsequent stores (and the order of release stores with respect to
each other),
It allows to manipulate two (related) bits of info atomically without
needing a lock and when efficient double CAS is not available (which it
isn't on supported archs).
Sent from my phone
On Dec 1, 2014 12:23 PM, Alex Yursha alexyur...@gmail.com wrote:
Hi all,
According to javadoc current
The only way to use atomic compare and set is to pack all your state
into a single primitive unit. The largest we have is long. So we
regularly pack what the C folks would call bitfields into longs.
On Sat, Nov 29, 2014 at 8:13 AM, Alex Yursha alexyur...@gmail.com wrote:
Hi all,
According to
Thanks a lot.
Seems like i need to look deeper into the JVM and hardware intrinsics to
understand some pecularities of core libs class designs.
Sent from my iPhone
On Dec 1, 2014, at 20:27, Vitaly Davidovich vita...@gmail.com wrote:
It allows to manipulate two (related) bits of info
1. Do you mean 'the only way', except using a lock?
2. I also cant imagine how we can use long primitive type for CAS atomicity
without a lock if only its not an AtomicLong. Any hint here, please?
Thanks
Sent from my iPhone
On Dec 1, 2014, at 20:27, Martin Buchholz marti...@google.com
Looks fine to me Daniel. Thanks for handling it. I can work on the 7u
backport if necessary.
on the test side would it be worth testing all public classes available
(e.g in rt.jar ?) to ensure that
Field.setAccessible works as expected and that we don't hit this issue
again ? It might be some
Hi Jan,
The changes look good to me; thanks,
-Joe
On 12/1/2014 5:37 AM, Jan Lahoda wrote:
On 1.12.2014 14:20, Alan Bateman wrote:
On 01/12/2014 12:10, Jan Lahoda wrote:
Hi,
In a preparation for JDK-8061549, I'd like to rename all uses of '_'
as a one-character identifier in the jaxp and
http://cr.openjdk.java.net/~vlivanov/8057020/webrev.00/
https://bugs.openjdk.java.net/browse/JDK-8057020
There are 2 major LambdaForm caches: LambdaFormEditor-based and
MethodTypeForm. The former is per-LambdaForm and the latter is per
method type erased to basic types. The problem is that
There's a whole set of invariant tests that should be applied to the entire jdk.
Find all the classes that can be loaded, load them, and check all the
invariants you can think of!
On Mon, Dec 1, 2014 at 9:42 AM, Alan Bateman alan.bate...@oracle.com wrote:
On 01/12/2014 08:06, deven you wrote:
Hi All,
Hi Deven,
thank you for your contribution. Please find my comments inline:
Our current NIO2 file system support to AIX is very limited, hence I took
some time to try
Hi all, any reviewers for this one?
s'marks
On 11/24/14 6:26 PM, Stuart Marks wrote:
Hi all,
Here's another test cleanup fix. Basically this normalizes the shutdown/destroy
policy for rmid processes that are started by RMI's test library in support of a
few dozen of the RMI activation tests.
On 12/1/14 8:29 AM, Daniel Fuchs wrote:
8065552: setAccessible(true) on fields of Class may throw
a SecurityException
webrev:
http://cr.openjdk.java.net/~dfuchs/webrev_8065552/webrev.00/
Thanks for taking this on. Looks okay in general. The comment on
Class.classLoader field -
Hi Seán,
On 01/12/14 18:48, Seán Coffey wrote:
Looks fine to me Daniel. Thanks for handling it. I can work on the 7u
backport if necessary.
Thanks :-)
on the test side would it be worth testing all public classes available
(e.g in rt.jar ?) to ensure that
Field.setAccessible works as
Sorry Stuart, I looked at this last week but guess I forgot to reply.
It looks fine and a nice clean up :-)
Best
Lance
On Dec 1, 2014, at 1:50 PM, Stuart Marks stuart.ma...@oracle.com wrote:
Hi all, any reviewers for this one?
s'marks
On 11/24/14 6:26 PM, Stuart Marks wrote:
Hi all,
http://cr.openjdk.java.net/~iignatyev/8039953/webrev.01/
to have TimeLimitedRunner more general, I've added 'factor' argument to
its ctor.
Thanks,
Igor
On 12/01/2014 02:39 PM, Igor Ignatyev wrote:
Paul/Vladimir,
thanks for review.
On 12/01/2014 01:29 PM, Vladimir Ivanov wrote:
On
Looks good.
Best regards,
Vladimir Ivanov
On 12/1/14, 10:58 PM, Igor Ignatyev wrote:
http://cr.openjdk.java.net/~iignatyev/8039953/webrev.01/
to have TimeLimitedRunner more general, I've added 'factor' argument to
its ctor.
Thanks,
Igor
On 12/01/2014 02:39 PM, Igor Ignatyev wrote:
On 12/1/14 10:54 AM, Daniel Fuchs wrote:
on the test side would it be worth testing all public classes available
(e.g in rt.jar ?) to ensure that
Field.setAccessible works as expected and that we don't hit this issue
again ? It might be some
what of a heavy test for jtreg inclusion though.
Hi Mandy,
Thanks for the review!
The new webrev is here:
http://cr.openjdk.java.net/~dfuchs/webrev_8065552/webrev.01/
The compiler doesn't want the diamond operator at line 86.
It says that it cannot infer the type argument.
So I left it unchanged. The rest of your comments are in.
best
Hi Miran,
I'm pretty distant from the JAX-WS code, but I looked through all of the files
and most of the changes seem sensible. There are a few things that are
questionable though.
**
src/java.xml.ws/share/classes/com/sun/xml/internal/ws/api/streaming/XMLStreamReaderFactory.java
The
On 12/1/14 11:34 AM, Daniel Fuchs wrote:
Hi Mandy,
Thanks for the review!
The new webrev is here:
http://cr.openjdk.java.net/~dfuchs/webrev_8065552/webrev.01/
Looks good.
Mandy
Looking at Peter's work here is still on my long TODO list, but I was
hoping first to get in my concurrency correctness fixes for core
reflection, which conflicts slightly...
On Sun, Nov 30, 2014 at 1:48 PM, Peter Levart peter.lev...@gmail.com wrote:
Hi Joel,
I managed to find some time to
On Mon, Nov 24, 2014 at 1:29 PM, Aleksey Shipilev
aleksey.shipi...@oracle.com wrote:
I think implies the effect of C++11 is too strong wording. related
might be more appropriate.
I've been struggling to come up with better wording. The latest webrev says
+ * Corresponds to C11
Hi Lance,
to me it's irritating, why there are 2 methods:
- initDriversIfNeeded()
- loadInitialDrivers()
I would combine both to one method.
In lines 90 + 92 there are double spaces.
-Ulf
Am 01.12.2014 um 17:52 schrieb Lance Andersen:
Hi all,
Looking for a review for this change to
Hi Ulf,
thank you for the input and suggestion
On Dec 1, 2014, at 3:27 PM, Ulf Zibis ulf.zi...@cosoco.de wrote:
Hi Lance,
to me it's irritating, why there are 2 methods:
- initDriversIfNeeded()
- loadInitialDrivers()
I would combine both to one method.
Mandy had asked me previously
Hans,
(Thanks for your excellent work on C/C++ 11 and your eternal patience)
On Tue, Nov 25, 2014 at 11:15 AM, Hans Boehm bo...@acm.org wrote:
It seems to me that a (dubiuously named) loadFence is intended to have
essentially the same semantics as the (perhaps slightly less dubiously
named)
David, Paul (i.e. Reviewers) and Doug,
I'd like to commit corrections so we make progress.
I think the current webrev is simple progress with the exception of my
attempt to translate volatiles into fences, which is marginal (but was
a good learning exercise for me).
On 01/12/2014 18:54, Daniel Fuchs wrote:
on the test side would it be worth testing all public classes available
(e.g in rt.jar ?) to ensure that
Field.setAccessible works as expected and that we don't hit this issue
again ? It might be some
what of a heavy test for jtreg inclusion though.
It
Needless to say, I would clearly also like to see a simple correspondence.
But this does raise the interesting question of whether put/get and
store(..., memory_order_relaxed)/load(memory_order_relaxed) are intended to
have similar semantics. I would guess not, in that the former don't
satisfy
On 12/01/2014 09:09 PM, Martin Buchholz wrote:
Looking at Peter's work here is still on my long TODO list, but I was
hoping first to get in my concurrency correctness fixes for core
reflection, which conflicts slightly...
No problem. I can rebase the patch after your fixes are in.
Regards,
Thanks Lance, I knew you'd come through. :-)
On 12/1/14 10:53 AM, Lance Andersen wrote:
Sorry Stuart, I looked at this last week but guess I forgot to reply.
It looks fine and a nice clean up :-)
Best
Lance
On Dec 1, 2014, at 1:50 PM, Stuart Marks stuart.ma...@oracle.com
On 12/01/2014 03:46 PM, Martin Buchholz wrote:
David, Paul (i.e. Reviewers) and Doug,
I'd like to commit corrections so we make progress.
The current one looks OK to me.
(http://cr.openjdk.java.net/~martin/webrevs/openjdk9/fence-intrinsics/)
-Doug
I think the current webrev is simple
On Mon, Dec 1, 2014 at 1:51 PM, Hans Boehm bo...@acm.org wrote:
Needless to say, I would clearly also like to see a simple correspondence.
But this does raise the interesting question of whether put/get and
store(..., memory_order_relaxed)/load(memory_order_relaxed) are intended to
have
I think that requiring coherence for ordinary Java accesses would be a
performance problem. The pre-2005 Java memory model actually promised it,
but implementations ignored that requirement. That was one significant
motivation of the 2005 memory model overhaul.
The basic problem is that if you
On 2/12/2014 3:44 AM, Alex Yursha wrote:
1. Do you mean 'the only way', except using a lock?
2. I also cant imagine how we can use long primitive type for CAS atomicity
without a lock if only its not an AtomicLong. Any hint here, please?
AtomicFieldUpdater can apply atomic operations to
Sorry about the long delay in getting back to this. I ran into two
separate JPRT issues that were preventing me from testing these changes,
plus I was on vacation last week. Here's an updated webrev. I'm not sure
where we left things, so I'll just say what's changed since the original
version:
Roman, thank you. As it has been mentioned before from practical
perspective its quite difficult to incorporate. Though as I understood ,
can be wrong of course that volatile variables and immutable objects
represent lineariazable objects because they satisfy those concurrent
conditions.
Hi, Joe and All
We are working on moving internal jaxp functional tests to open jdk repo.
This is the parsers suite. Would you please review these test? Any comment
will be appreciated.
bug: https://bugs.openjdk.java.net/browse/JDK-8051536
webrev:
Erik,
Many thanks for the makefile macro wizardry! I will incorporate, test
and return with an updated webreb.
David
On 1/12/2014 7:19 PM, Erik Joelsson wrote:
Hello David,
Most of it looks good, but profile-includes.txt could certainly benefit
from some reduction in duplication. (Aside
59 matches
Mail list logo
