Hi Deven,
I've just realized that you still use the Linux functions fgetxattr,
fsetxattr, ... I don't think this will ever work on AIX. Please use
the corresponding functions from sys/ea.h (i.e. getea, setea,
removeea).
Thanks,
Volker
On Mon, Dec 1, 2014 at 7:38 PM, Volker Simonis
Finally got the time to search thru the JDK codebase - at the moment JDK8 due
the lack of a working Netbeans Project for JDK9 (I will try to make that
working again)
What usage would you actually search in the OpenJDK code base?
We're talking about copying with provided buffer, right?
On 2/12/2014 4:51 PM, Alex Yursha wrote:
Thanks for all responses. All this is much clearer now.
Am I right that all this state packing is for better performance only and the
same behaviour can be achieved by using explicit locks?
Sure.
David
On Dec 2, 2014, at 05:32, David Holmes
On Nov 25, 2014, at 3:06 AM, Martin Buchholz marti...@google.com wrote:
I tried to address all the known problems in sun/reflect (except for
the performance ones), including the ones in Peter's webrev (although
it now looks quite different).
I broke down and switched to using
Hi,
Please find below a patch to remove the networking code computing a seed in
ThreadLocal/SplittableRandom.
We thought it a good idea at the time :-) but subsequently on certain platforms
this results in very high initalization costs that can propagate to other
classes such as
On 02/12/2014 10:02, Paul Sandoz wrote:
Hi,
Please find below a patch to remove the networking code computing a seed in
ThreadLocal/SplittableRandom.
We thought it a good idea at the time :-) but subsequently on certain platforms
this results in very high initalization costs that can
On 01/12/2014 13:37, Jan Lahoda wrote:
:
In TypeCheckMicroBenchmark then ignore is might be a misleading too
given that the ArrayStoreException causes a CCE to be thrown.
I've updated the patch to use expected where the exception appears
to be expected and unused where exception appears to
On 01/12/2014 21:09, Seán Coffey wrote:
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
On Dec 2, 2014, at 11:10 AM, Alan Bateman alan.bate...@oracle.com wrote:
On 02/12/2014 10:02, Paul Sandoz wrote:
Hi,
Please find below a patch to remove the networking code computing a seed in
ThreadLocal/SplittableRandom.
We thought it a good idea at the time :-) but subsequently on
On Dec 2, 2014, at 1:58 AM, Doug Lea d...@cs.oswego.edu wrote:
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.
On 12/02/2014 05:02 AM, Paul Sandoz wrote:
Hi,
Please find below a patch to remove the networking code computing a seed in
ThreadLocal/SplittableRandom.
Thanks for pushing this through.
(I also adjusted 166 sources accordingly.)
One more touch-up for SplittableRandom is to remove mention
of
On Dec 2, 2014, at 1:17 PM, Doug Lea d...@cs.oswego.edu wrote:
On 12/02/2014 05:02 AM, Paul Sandoz wrote:
Hi,
Please find below a patch to remove the networking code computing a seed in
ThreadLocal/SplittableRandom.
Thanks for pushing this through.
(I also adjusted 166 sources
Hi Stuart,
minor stuff like invalid characters and copyright years I can fix before
push, the rest will leave for next integration which should be soon.
Thanks!
Miran
On 01/12/14 20:35, Stuart Marks wrote:
Hi Miran,
I'm pretty distant from the JAX-WS code, but I looked through all of
the
Thanks to all for the comments!
Jan
On 2.12.2014 11:15, Alan Bateman wrote:
On 01/12/2014 13:37, Jan Lahoda wrote:
:
In TypeCheckMicroBenchmark then ignore is might be a misleading too
given that the ArrayStoreException causes a CCE to be thrown.
I've updated the patch to use expected
Thanks, Paul!
Updated webrev in place.
On Dec 1, 2014, at 5:58 PM, Vladimir Ivanov vladimir.x.iva...@oracle.com
wrote:
http://cr.openjdk.java.net/~vlivanov/8057020/webrev.00/
https://bugs.openjdk.java.net/browse/JDK-8057020
That LambdaFormEditor.putInCache method just got more gnarly :-)
On Dec 2, 2014, at 5:42 PM, Peter Levart peter.lev...@gmail.com wrote:
On 12/02/2014 11:02 AM, Paul Sandoz wrote:
Hi,
Please find below a patch to remove the networking code computing a seed in
ThreadLocal/SplittableRandom.
We thought it a good idea at the time :-) but subsequently on
Thanks for all responses. All this is much clearer now.
Am I right that all this state packing is for better performance only and the
same behaviour can be achieved by using explicit locks?
On Dec 2, 2014, at 05:32, David Holmes david.hol...@oracle.com wrote:
On 2/12/2014 3:44 AM, Alex
On Dec 2, 2014, at 5:20 PM, Vladimir Ivanov vladimir.x.iva...@oracle.com
wrote:
Thanks, Paul!
Updated webrev in place.
+1.
Paul.
On 02/12/2014 16:42, Peter Levart wrote:
:
Here's a proof of concept for an API that just delegates to
system-provided cryptographically secure (as declared by the
system(s)) pseudo random number generator:
http://cr.openjdk.java.net/~plevart/jdk9-dev/SystemRandom/webrev.01/
The API looks
Great, this sounds fine.
s'marks
On 12/2/14 6:03 AM, Miroslav Kos wrote:
Hi Stuart,
minor stuff like invalid characters and copyright years I can fix before push,
the rest will leave for next integration which should be soon.
Thanks!
Miran
On 01/12/14 20:35, Stuart Marks wrote:
Hi Miran,
Hi Lance,
Overall, looks fine.
Typo earleir at line 569.
I agree with having two separate init methods, since initDriversIfNeeded()
conveniently separates the (safe) double-checked locking idiom from the actual
initialization legwork in loadInitialDrivers().
I'm not entirely convinced,
Hi Stuart,
On Dec 2, 2014, at 1:35 PM, Stuart Marks stuart.ma...@oracle.com wrote:
Hi Lance,
Overall, looks fine.
Thank you for the review
Typo earleir at line 569.
fixed
I agree with having two separate init methods, since initDriversIfNeeded()
conveniently separates the (safe)
Hi Daniel,
On 11/26/14 9:11 AM, Daniel Fuchs wrote:
Hi,
Please find below a patch for:
8065991: LogManager unecessarily calls JavaAWTAccess from within
a critical section
https://bugs.openjdk.java.net/browse/JDK-8065991
Webrev:
On 12/1/14 8:52 AM, Lance Andersen wrote:
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
Hi Mandy,
On 02/12/14 20:24, Mandy Chung wrote:
Hi Daniel,
On 11/26/14 9:11 AM, Daniel Fuchs wrote:
Hi,
Please find below a patch for:
8065991: LogManager unecessarily calls JavaAWTAccess from within
a critical section
https://bugs.openjdk.java.net/browse/JDK-8065991
Webrev:
Hi Mandy,
Thank you for the review, please see below
On Dec 2, 2014, at 2:56 PM, Mandy Chung mandy.ch...@oracle.com wrote:
On 12/1/14 8:52 AM, Lance Andersen wrote:
Hi all,
Looking for a review for this change to DriverManager to reduce the
possibility on a deadlock on clinit. that I
Hello core libs developers!
I am Ivan from the Bulgarian Java User Group. We are adopting OpenJDK for
quite some time in our JUG. So far we have done some sessions in our
community as well as on conferences in Bulgaria and neighboring countries,
where we just talked about the project and the
On 12/2/14 12:26 PM, Daniel Fuchs wrote:
Hi Mandy,
On 02/12/14 20:24, Mandy Chung wrote:
Hi Daniel,
On 11/26/14 9:11 AM, Daniel Fuchs wrote:
Hi,
Please find below a patch for:
8065991: LogManager unecessarily calls JavaAWTAccess from within
a critical section
On 12/2/14 12:30 PM, Lance Andersen wrote:
So it may be better to have a getter method to ensure driver classes are
loaded as well as return the registeredDrivers copy-on-write-arraylist.
i.e. you could rename initDriversIfNeeded to getRegisteredDrivers and
replace
for(DriverInfo aDriver :
On Dec 2, 2014, at 4:12 PM, Mandy Chung mandy.ch...@oracle.com wrote:
On 12/2/14 12:30 PM, Lance Andersen wrote:
So it may be better to have a getter method to ensure driver classes are
loaded as well as return the registeredDrivers copy-on-write-arraylist.
i.e. you could rename
Hello,
just want to add two somewhat related observations:
we have a virtual JDBC driver which maps back to an real driver (or to
an Pool/Datasource which uses a real driver. This is to allow
JDBC URLs to work in different environments with no config. (Thats is
not the nices solution, but after
Hi,
As you may already know, we are looking into more memory efficient
representation for Strings:
https://bugs.openjdk.java.net/browse/JDK-8054307
As part of preliminary performance work for this JEP, we have to collect
the empirical data on usual characteristics of Strings and char[]-s
normal
Hi Bernd,
On 12/2/14 1:49 PM, Bernd Eckenfels wrote:
Hello,
just want to add two somewhat related observations:
we have a virtual JDBC driver which maps back to an real driver (or to
an Pool/Datasource which uses a real driver. This is to allow
JDBC URLs to work in different environments with
Bernd,
Thank you for your input
On Dec 2, 2014, at 4:49 PM, Bernd Eckenfels e...@zusammenkunft.net wrote:
Hello,
just want to add two somewhat related observations:
we have a virtual JDBC driver which maps back to an real driver (or to
an Pool/Datasource which uses a real driver. This
Any consideration towards removing the char[] (or byte[]) indirection
altogether? .NET for example stores the bytes inline with the instance.
Sent from my phone
On Dec 2, 2014 4:59 PM, Aleksey Shipilev aleksey.shipi...@oracle.com
wrote:
Hi,
As you may already know, we are looking into more
Hi Vitaly,
Please read the JEP proposal. String/char[] fusion (that's what you are
describing) is out of scope for this work. Baby steps. Careful baby steps.
-Aleksey.
On 03.12.2014 01:13, Vitaly Davidovich wrote:
Any consideration towards removing the char[] (or byte[]) indirection
Hi Mandy,
On Dec 2, 2014, at 5:10 PM, Mandy Chung mandy.ch...@oracle.com wrote:
Hi Bernd,
On 12/2/14 1:49 PM, Bernd Eckenfels wrote:
Hello,
just want to add two somewhat related observations:
we have a virtual JDBC driver which maps back to an real driver (or to
an Pool/Datasource
I support Peter's initiative and am willing to help review if we have
general consensus about the direction.
From superficial review:
+int nread = randomStream.read(bytes);
+if (nread != bytes.length) {
+throw new InternalError(Short read from:
String construction is a big performance issue for JDBC drivers. Most
queries return some number of Strings. The overwhelming majority of
those Strings will be short lived. The cost of constructing these
Strings from network bytes is a large fraction of total execution
time. Any increase in
Hello Mandy and Lance,
(sorry, not a full quote for more focused answers, inline)
Am Tue, 02 Dec 2014 14:10:06 -0800
schrieb Mandy Chung mandy.ch...@oracle.com:
Would you be able to try this patch and see if the deadlocks are
reproducible? Lance has been trying to get customers to verify
Hi,
I have encountered a bug in FilterOutputStream under Java 8. The bug is that
calling close() on the same stream twice can now result in an exception,
whereas under Java 7 it did not. The reason is that FilterOutputStream.close()
calls flush() before calling close() on the underlying
Hi Douglas,
On 12/03/2014 02:24 AM, Douglas Surber wrote:
String construction is a big performance issue for JDBC drivers. Most
queries return some number of Strings. The overwhelming majority of
those Strings will be short lived. The cost of constructing these
Strings from network bytes is a
The most common operation on most Strings in query results is to do
nothing. Just construct the String, hold onto it while the rest of
the transaction completes, then drop it on the floor. Probably the
next most common is to encode the chars to write them to an
OutputStream or send them back
On 12/02/2014 04:42 PM, Douglas Surber wrote:
The most common operation on most Strings in query results is to do nothing.
Just construct the String, hold onto it while the rest of the transaction
completes, then drop it on the floor. Probably the next most common is to
encode the chars to
I agree with Lance's suggestion on utilizing the @BeforeMethod methods
to instantiate factories, or DocumentBuilder where there's no change in
state on the DocumentBuilderFactory (that is, no set** in any of the
tests, such as DocumentBuilderImpl01), or using DataProvider.
However, if you do
On 12/2/2014 1:47 PM, Lance Andersen wrote:
The revised webrev is here
http://cr.openjdk.java.net/~lancea/8060068/webrev.03/
http://cr.openjdk.java.net/%7Elancea/8060068/webrev.03/
Looks good. Nit: line 443 and a few places in the getConnection need a
space in for(, if(
Note, I also
Reviewed.
I sympathize with Paul's gnarly comment.
Nice bit of stream-ology (rheology) in the test code.
Regarding:
On Dec 2, 2014, at 8:20 AM, Vladimir Ivanov vladimir.x.iva...@oracle.com
wrote:
In src/java.base/share/classes/java/lang/invoke/LambdaFormEditor.java
366
The fix still looks good to me.
Thanks,
Serguei
On 12/1/14 6:39 PM, Chris Plummer wrote:
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.
48 matches
Mail list logo
