Being able to do better here is very impressive.
I took a quick look and found two things that a paranoid benchmarker like
myself would not have done:
- write the benchmark in scala instead of boring java
- use jdk8 instead of "head" (i.e. jdk10)
I would also have benchmarked against the intrinsi
Please review this doc-only change [2] for [1] at your convenience with
reference to [3].
Thanks,
Brian
[1] https://bugs.openjdk.java.net/browse/JDK-8179662
[2] diff
--- a/src/java.base/share/classes/java/io/OutputStreamWriter.java
+++ b/src/java.base/share/classes/java/io/OutputStreamWriter.j
On 5/9/17 4:56 AM, David Holmes wrote:
If the bootlib files were simply moved then no update to their
copyright year is needed.
Cheers,
David
Got it. Thank you David!
Thanks,
Amy
On 5/9/17 1:33 AM, Paul Sandoz wrote:
The changes look good.
Would you mind re-basing this fix for JDK 10 instead? At this point we should
be more conservative with such changes (even for tests).
Sure, I'll re-base and push this to JDK 10.
Thank you for reviewing.
Thanks,
Amy
I agree. I would opt for (A) and be done with it.
On May 8, 2017, at 6:38 PM, Brian Goetz wrote:
> Given that this went unnoticed for 18 years, the urgency seems low. Either
> (a) or (b) sound fine to me. (c) sounds like a recipe for spending more time
> talking about the bug than actually f
Given that this went unnoticed for 18 years, the urgency seems low. Either (a)
or (b) sound fine to me. (c) sounds like a recipe for spending more time
talking about the bug than actually fixing it.
> On May 8, 2017, at 5:24 PM, Brian Burkhalter
> wrote:
>
> This issue [1] does in fact
Hello,
To strengthen Brian' point, running faster on at least one platform is a
necessary but not sufficient condition for a change like this since it
is possible the change could run slower on a different platform. To
guard against that being the case, with data points across more
platforms
Thanks for running the numbers.
On May 8, 2017, at 5:42 PM, Isaac Levy wrote:
> bitCountInt avgt 10 44550.630 ± 2670.294 ns/op
[41880, 47221]
> bitCountIntNew avgt 10 33904.058 ± 1108.438 ns/op
[32796, 35012]
> bitCountLong avgt 10 58638.138 ± 3736.014 ns/op
[54902, 6
Another way to think about transition to a new JDK is to treat the new
release JDK N as a "better JDK N-1". You still target JDK N-1 at build
time but get performance and quality improvements from the JDK N runtime,
running along with JDK N-1 for years. Then every small incompatibility is
a big n
On Tue, May 2, 2017 at 2:40 AM, Andrew Dinn wrote:
>
> Just wanted to post a heads-up that this fall-back behaviour has now
> been implemented in Byteman release 4.0.0-BETA5.
Thanks - I can confirm 4.0.0-BETA5 works for me.
jmh:run -t1 -f 1 -wi 5 -i 10 BitCountTest
bitCountInt avgt 10 44550.630 ± 2670.294 ns/op
bitCountIntNew avgt 10 33904.058 ± 1108.438 ns/op
bitCountLong avgt 10 58638.138 ± 3736.014 ns/op
bitCountLongNew avgt 10 38700.601 ± 526.648 ns/op
JDK 1.8.0_131, 2.3ghz Core i7,
Reasons to add UTF-16 versions of the JNI_CreateJavaVM and
JNI_GetDefaultJavaVMInitArgs APIs include the following:
* The arguments passed into the wmain and wWinMain functions use UTF-16-encoded
strings instead of UTF-8 strings.
* The arguments passed into the main and WinMain functions on Wind
On May 8, 2017, at 5:07 PM, Joseph D. Darcy wrote:
> This is a case of "jmh results or it isn't faster." [1]
>
> It is challenging to evaluate such changes as being universally faster
> without benchmark results, especially for small methods like this. Without
> compelling performance support
AMD started shipping popcnt instruction in 2007, and intel in 2008.
Does the OpenJDK runtime include a bitCount intrinsic? I can't speak
much to relevance in this regard.
But in terms of performance,
http://dalkescientific.com/writings/diary/archive/2011/11/02/faster_popcount_update.html
gives a
On 5/8/2017 1:29 PM, Doug Lea wrote:
On 05/08/2017 02:14 PM, Isaac Levy wrote:
Original message below:
The JDK impl of bitCount can be improved -- though most users will get
the hotspot intrinsic. The best source I could find for the suggestion
below is page 195: http://support.amd.com/techdocs
Hi John,
Responding back on the mailing lists. There are people on the mailing
lists who are in a better position to evaluate the merits of the
proposal. I searched the bug database and could not see this issue being
raised in the past.
On 9/05/2017 8:46 AM, John Platts wrote:
The real reas
Hi all,
I've been cleaning up code that I work on to be Java 9 compatible, but have
ran into a blocker due to limitations of the Naming API. I could work
around the blocker with an --add-opens, but I'd rather find a proper
solution.
*** Background
Currently the javax.naming.spi.NamingManager a
This issue [1] does in fact appear to be a bug. It could be fixed in one of
three ways:
A) Remove the fallacious sentence "The size of this buffer may be specified,
but by default it is large enough for most purposes.” from the second paragraph
of the class documentation. This would at least ma
Kumar,
The nature of CSS is such that there is generally no one single definition.
The descriptive comments are just before the shared/common parts of the
definitions.
If I grouped the comment and class definition, someone else would point
out that I could be
sharing common properties.
The b
Hi Jon,
I looked at the stylesheet can the descriptive comments for each of the
classes be moved closer to the class itself, ie. just before the
definition ?
Kumar
This is an updated review for the changes to improve tables in java.base.
The changes incorporate earlier review feedback, an
> On 7 May 2017, at 22:30, David Holmes wrote:
>
> Hi Ron,
>
> On 6/05/2017 5:27 AM, Ron Pressler wrote:
>> Hi,
>> Please review the following core/hotspot change:
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8159995
>> core webrev:
>> http://cr.openjdk.java.net/~psandoz/jdk10/JDK-81599
Hi Kumar,
On 9/05/2017 12:27 AM, Kumar Srinivasan wrote:
Hi David,
Hi Kumar,
On 7/05/2017 1:21 AM, Kumar Srinivasan wrote:
Hello,
Please review the changes to remove the java launcher's data model
options -d32/-d64, these options existed to support Solaris dual-mode
operation, however for
Hi Amy,
Not a review ...
On 8/05/2017 7:00 PM, Amy Lu wrote:
Please review this test-only change to move the test library
jdk/test/java/util/stream/bootlib
to
jdk/test/lib/testlibrary/bootlib
to make it formally easier for tests to depend on.
There is no change to the functionality of the test
Hi Roman,
I made a pass through the webrev and have the following feedback:
src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/StaxLazySourceBridge.java
and several files - which follow in the webrev, have formatting issues with
the newly added @override and existing @over
On 05/08/2017 02:14 PM, Isaac Levy wrote:
Original message below:
The JDK impl of bitCount can be improved -- though most users will get
the hotspot intrinsic. The best source I could find for the suggestion
below is page 195: http://support.amd.com/techdocs/25112.pdf
The int version differs
Il lun 8 mag 2017, 18:38 Remi Forax ha scritto:
>
>
> - Mail original -
> > De: "Roger Riggs"
> > À: core-libs-dev@openjdk.java.net
> > Envoyé: Lundi 8 Mai 2017 17:45:25
> > Objet: Re: Accessing UNIX FileDescriptor id without reflection
>
> > Hi,
> >
> > I would be very cautious about gi
On Mon, May 8, 2017 at 5:54 AM, dalibor topic
wrote:
> On 05.05.2017 08:39, Jeremy Manson wrote:
>
>> Mostly, I'm telling you all because I think it makes an interesting case
>> study - a large Java installation and the issues it faces trying to roll
>> out JDK 9.
>>
>
> Indeed - thank you for pr
+1
> On May 8, 2017, at 2:17 PM, huizhe wang wrote:
>
> Hi,
>
> Please review removing three unused classes from the jaxp repo.
> JBS: https://bugs.openjdk.java.net/browse/JDK-8150256
> Webrevs: http://cr.openjdk.java.net/~joehw/jdk9/8150256/webrev/
> Tests: passed
>
> Refer to the jaxp change
Hi,
Please review removing three unused classes from the jaxp repo.
JBS: https://bugs.openjdk.java.net/browse/JDK-8150256
Webrevs: http://cr.openjdk.java.net/~joehw/jdk9/8150256/webrev/
Tests: passed
Refer to the jaxp change history [1], the following changes in particular:
- - protected XPoint
Original message below:
The JDK impl of bitCount can be improved -- though most users will get
the hotspot intrinsic. The best source I could find for the suggestion
below is page 195: http://support.amd.com/techdocs/25112.pdf
Cheers,
Isaac Levy
Proposed Long.bitCount and Integer.bitCount:
pu
Thanks for the patch. The correct forum is core-libs-dev@openjdk.java.net,
which I have CCed.
Brian
On May 7, 2017, at 5:16 PM, Isaac Levy wrote:
> Apologies if this is the wrong forum, I'm new to the OpenJDK project.
Hi Amy,
The changes look good.
Would you mind re-basing this fix for JDK 10 instead? At this point we should
be more conservative with such changes (even for tests).
Thanks,
Paul.
> On 8 May 2017, at 02:00, Amy Lu wrote:
>
> Please review this test-only change to move the test library
> jdk/
- Mail original -
> De: "Roger Riggs"
> À: core-libs-dev@openjdk.java.net
> Envoyé: Lundi 8 Mai 2017 17:45:25
> Objet: Re: Accessing UNIX FileDescriptor id without reflection
> Hi,
>
> I would be very cautious about giving out fds for arbitrary FileDescriptors.
> With concurrency and t
Hi,
I would be very cautious about giving out fds for arbitrary FileDescriptors.
With concurrency and threading, how do you make sure that it does not
not get closed
and someone's code still has the fd and uses it later? Or worse yet,
the fd gets re-used
and then it is possible to operate on
Hi Enrico,
java.io.FileDescriptor is a public class, part of public API. There's
one version for JVMs running on UNIX-based OSes and another for JVMs
running on Windows. Both contain int field 'fd'. But you already know
that if you access this field using reflection. Now instead of doing
this
Hi David,
Hi Kumar,
On 7/05/2017 1:21 AM, Kumar Srinivasan wrote:
Hello,
Please review the changes to remove the java launcher's data model
options -d32/-d64, these options existed to support Solaris dual-mode
operation, however for uniformity, these options were accepted by other
platforms
I agree that a method getFd should be great, we will need this kind of value if
we want to use Panama.
Did you try to serializing the FileDescriptor in memory and extract the int
corresponding to the file descriptor ?
cheers,
Rémi
- Mail original -
> De: "Enrico Olivelli"
> À: core-li
Hi,
I am trying to port a project (Apache BookKeeper) to Java9, actually
this code uses reflection in order to access the 'fd' field of the
FileDescriptor class.
We have to access that ID in order to call low level native functions
See
https://github.com/apache/bookkeeper/blob/master/bookkeeper-s
On 05.05.2017 08:39, Jeremy Manson wrote:
Mostly, I'm telling you all because I think it makes an interesting case
study - a large Java installation and the issues it faces trying to roll
out JDK 9.
Indeed - thank you for providing valuable insight into your concerns and
experiences.
If oth
Hi Martin,
As I said, you need to report that to IBM, they will guide you.
Cheers,
Mario
On Mon 8. May 2017 at 14:37, Martin T wrote:
> On Mon, May 8, 2017 at 3:07 PM, Mario Torre
> wrote:
> > 2017-05-08 13:45 GMT+02:00 dalibor topic :
> >> Hi Martin,
> >>
> >> we don't provide OpenJDK binari
On Mon, May 8, 2017 at 3:07 PM, Mario Torre
wrote:
> 2017-05-08 13:45 GMT+02:00 dalibor topic :
>> Hi Martin,
>>
>> we don't provide OpenJDK binaries in Linux distributions.
>>
>> I'd suggest reporting it to the provider of your binaries directly (Debian
>> in this case), as we don't provide a bro
2017-05-08 13:45 GMT+02:00 dalibor topic :
> Hi Martin,
>
> we don't provide OpenJDK binaries in Linux distributions.
>
> I'd suggest reporting it to the provider of your binaries directly (Debian
> in this case), as we don't provide a browser plugin implementation, either.
> Alternatively, you may
Hi Martin,
we don't provide OpenJDK binaries in Linux distributions.
I'd suggest reporting it to the provider of your binaries directly
(Debian in this case), as we don't provide a browser plugin
implementation, either. Alternatively, you may want to give the
distro-pkg-dev mailing list a try
Hi,
first of all, I hope that this is a correct mailing list.
I have an IBM server with Remote Supervisor Adapter II out-of-band
card which provides a remote console function using an Java applet. It
works fine with Java version 1.7.0_121 provided by
openjdk-7-jre-headless package under Debian an
Please review this test-only change to move the test library
jdk/test/java/util/stream/bootlib
to
jdk/test/lib/testlibrary/bootlib
to make it formally easier for tests to depend on.
There is no change to the functionality of the tests.
This patch also removed NullArgsTestCase.java which is an ab
45 matches
Mail list logo
