On 2014-11-20, at 7:45 AM, Staffan Friberg staffan.frib...@oracle.com wrote:
Hi,
Anyone who can be the second Reviewer?
Thanks,
Staffan
I can review, but I am not a Reviewer.
CRC32C.java:
56 /**
57 * CRC-32C Polynom
58 */
“Polynomial”, perhaps?
You did test this
Hello Peter,
I was looking at this (thinking it would be a useful thing to benchmark,
looking for possible improvements)
and noticed that you rely on the hashed objects having a sensible
value-dependent hashcode (as opposed
to the default Object hashcode). Sadly, this seems not to be the case
Hello Peter,
Sadly, this seems not to be the case for MemberNames or for “Types”.
That statement is inoperative. Mistakes were made.
It’s compareTo that they lack.
David
On 2014-11-09, at 7:55 AM, Peter Levart peter.lev...@gmail.com wrote:
Hi David,
I played a little with the idea of
On 2014-11-08, at 10:07 AM, Peter Levart peter.lev...@gmail.com wrote:
Now let's take for example one of the MemberName.make() methods that return
interned MemberNames:
206 public static MemberName make(Method m, boolean wantSpecial) {
207 // Unreflected member names are
On 2014-11-04, at 5:07 AM, Peter Levart peter.lev...@gmail.com wrote:
Are you thinking of an IdentityHashMap type of hash table (no linked-list of
elements for same bucket, just search for 1st free slot on insert)? The
problem would be how to pre-size the array. Count declared members?
It
that it allows is desirable.
David
On 2014-11-04, at 11:48 AM, Peter Levart peter.lev...@gmail.com wrote:
On 11/04/2014 04:19 PM, David Chase wrote:
On 2014-11-04, at 5:07 AM, Peter Levart peter.lev...@gmail.com wrote:
Are you thinking of an IdentityHashMap type of hash table (no linked-list
On 2014-11-02, at 10:49 PM, David Holmes david.hol...@oracle.com wrote:
The change is to load the volatile size for the loop bound; this stops the
stores
in the loop from moving earlier, right?
Treating volatile accesses like memory barriers is playing a bit
fast-and-loose with the
My main concern is that the compiler is inhibited from any peculiar code
motion; I assume that taking a safe point has a bit of barrier built into it
anyway, especially given that the worry case is safepoint + JVMTI.
Given the worry, what’s the best way to spell “barrier” here?
I could
On 2014-11-03, at 11:42 AM, Peter Levart peter.lev...@gmail.com wrote:
You're worried that writes moving array elements up for one slot would
bubble up before write of size = size+1, right? If that happens, VM could
skip an existing (last) element and not update it.
It seems that
On 2014-11-03, at 3:09 PM, Peter Levart peter.lev...@gmail.com wrote:
Hi David,
I was thinking about the fact that java.lang.invoke code is leaking into
java.lang.Class. Perhaps, If you don't mind rewriting the code, a better code
structure would be, if j.l.Class changes only consisted
On 2014-10-17, at 2:53 PM, Staffan Friberg staffan.frib...@oracle.com wrote:
Fully agree that using Unsafe makes one sad.
I'm just about to send out a new webrev with Alan's and Peter's comments,
once I have that done I will give using the NIO-Buffer API a second try to
see if using
to an intrinsic. There’s a certain amount of brain-hurt involved in the
fork/join code, but it works.
I’m still trying to figure out if the whole thing is just bit-flipped.
David
On 2014-10-17, at 4:50 PM, David Chase david.r.ch...@oracle.com wrote:
On 2014-10-17, at 2:53 PM, Staffan Friberg
On 2014-01-15, at 10:31 AM, Vladimir Ivanov vladimir.x.iva...@oracle.com
wrote:
The fix is targeted for 8. Will be also integrated into 9.
Testing: regression test, jdk/test/java/lang/invoke, vm.mlvm.testlist,
nashorn, jruby.
Vladimir,
Did you test also on defmeth, or has that been
On 2013-11-27, at 6:53 AM, Peter Levart peter.lev...@gmail.com wrote:
Ah, I have misunderstood the back-porting issue. It was not about not having
new class but about which existing class to use as a host that might not
exist in older version of platform...
Sorry for noise.
Noise is
On 2013-11-25, at 9:18 PM, David Holmes david.hol...@oracle.com wrote:
We do have the jdk.internal namespace. But I think Unsafe is as good a place
as any - though maybe sun.misc.VM is marginally better?
Does anyone have any problems with sun.misc.VM as a choice?
I have to do a minor revision
On 2013-11-26, at 7:12 AM, David Holmes david.hol...@oracle.com wrote:
On 26/11/2013 9:56 PM, David Chase wrote:
On 2013-11-25, at 9:18 PM, David Holmes david.hol...@oracle.com wrote:
We do have the jdk.internal namespace. But I think Unsafe is as good a
place as any - though maybe
On 2013-11-26, at 7:32 AM, David Holmes david.hol...@oracle.com wrote:
On 26/11/2013 10:16 PM, David Chase wrote:
On 2013-11-26, at 7:12 AM, David Holmes david.hol...@oracle.com wrote:
On 26/11/2013 9:56 PM, David Chase wrote:
On 2013-11-25, at 9:18 PM, David Holmes david.hol
On 2013-11-26, at 8:12 AM, David Chase david.r.ch...@oracle.com wrote:
On 2013-11-26, at 7:32 AM, David Holmes david.hol...@oracle.com wrote:
On 26/11/2013 10:16 PM, David Chase wrote:
On 2013-11-26, at 7:12 AM, David Holmes david.hol...@oracle.com wrote:
On 26/11/2013 9:56 PM, David Chase
Updated request.
This is for a bug that it deferred by compilers,
but runtime really wants it fixed because they
are working in the same area and don't like it at all.
In particular, they want it committed to hotspot-rt ASAP
(don't want to wait for the multiweek turnaround)
and thus the diffs and
On 2013-11-22, at 2:56 PM, Karen Kinnear karen.kinn...@oracle.com wrote:
David,
Thank you so much for finding a way to do this. We do think this is important
to get in for 8.
And thank you for a way to check the hotspot changes in without waiting for
the jdk changes.
Code looks good.
webrev: http://cr.openjdk.java.net/~drchase/8026818/webrev.01/
bug: https://bugs.openjdk.java.net/browse/JDK-8026818
problem:
The report describes a number of problems, cause by 3 separate bugs.
The first is a dupe of https://bugs.openjdk.java.net/browse/JDK-8016839 .
The second is a fault in
Further revised after consulting with John Rose on details of fix:
webrev: http://cr.openjdk.java.net/~drchase/8022718/webrev.02/
tests:
jtreg of jdk/lambda java/lang/invoke java/util/stream
defmeth (a/b testing)
jprt in progress (assuming I got the incantation right)
David
bug: https://bugs.openjdk.java.net/browse/JDK-8022718
webrev: http://cr.openjdk.java.net/~drchase/8022718/webrev.00/
Problem: Needed implementation for change to the spec for JVM behavior (from
the bug report):
JSR 335 spec, chapter 15.28.2 Run-time Evaluation of Method References
contains
How about this one?
http://cr.openjdk.java.net/~drchase/8022718/webrev.01/
This version tests both versions of the modifiers for public --
ref.getModifiers apparently sets public in some cases where the other one does
not.
Not 100% sure what those cases are, I suspect arrays from the cryptic
-referencing methodhandle,
but did not test it because there's no syntax for these in Java, nor is their
creation
well-documented.
David
On 2013-09-13, at 12:02 AM, John Rose john.r.r...@oracle.com wrote:
On Sep 12, 2013, at 5:44 PM, David Chase david.r.ch...@oracle.com wrote:
Do these sibling bugs
This explanation seems to combine numbers of binary digits (1075)
and numbers of decimal digits (17), and therefore makes me a little
nervous, though I think 1100 is a conservative choice that, even if not
100% correct, will be 99.(over 700 9s)% correct.
David
On 2013-09-12, at 1:17 AM, Dmitry
12, 2013 at 3:57 PM, David Chase david.r.ch...@oracle.comwrote:
This explanation seems to combine numbers of binary digits (1075)
and numbers of decimal digits (17), and therefore makes me a little
nervous, though I think 1100 is a conservative choice that, even if not
100% correct, will be 99
is
decimal_rep_of_half_ulp + a billion zeroes + 1, then the answer is 1 ulp
(2^-1074), if the trailing one is missing, then the answer is zero (which is
even in the mantissa).
David
On 2013-09-12, at 10:37 AM, David Chase david.r.ch...@oracle.com wrote:
On 2013-09-12, at 8:18 AM, Dmitry Nadezhin dmitry.nadez
Never mind, this is in the context of FloatingDecimal and any trailing zeroes
are properly discarded.
Carry on, this code looks correct, despite my misunderstanding the explanation.
David
On 2013-09-12, at 12:32 PM, David Chase david.r.ch...@oracle.com wrote:
I think the reason you use 1075
New webrev, commented line removed:
http://cr.openjdk.java.net/~drchase/8022701/webrev.03/
On 2013-09-12, at 1:53 PM, David Chase david.r.ch...@oracle.com wrote:
I believe it produced extraneous output -- it was not clear to me that it was
either necessary or useful to fully describe all
, Christian Thalinger christian.thalin...@oracle.com
wrote:
+ // err.initCause(ex);
Why is this commented?
-- Chris
On Sep 6, 2013, at 4:59 PM, David Chase david.r.ch...@oracle.com wrote:
new, improved webrev: http://cr.openjdk.java.net/~drchase/8022701/webrev.02/
Same small
to substitute the borked bytecodes
necessary to get
the error, so it is not only shell-free, it can also be run outside jtreg.
On 2013-09-12, at 2:34 PM, Christian Thalinger christian.thalin...@oracle.com
wrote:
On Sep 12, 2013, at 11:28 AM, David Chase david.r.ch...@oracle.com wrote:
New
On 2013-09-12, at 1:17 AM, Dmitry Nadezhin dmitry.nadez...@gmail.com wrote:
The optimal constant for double conversion could be 768 ,
the optimal constant for float conversion could be 142,
but I leave this optimization to JDK 9.
It would be helpful to mention in the proof/comment, that 768
Careful, I don't think I'm a Reviewer.
I merely had the misfortune to care a whole lot about this stuff once long long
ago.
David
On 2013-09-12, at 4:49 PM, Brian Burkhalter brian.burkhal...@oracle.com wrote:
On Sep 12, 2013, at 1:00 PM, David Chase wrote:
On 2013-09-12, at 1:17 AM, Dmitry
, David Chase david.r.ch...@oracle.com wrote:
New webrev, commented line removed:
http://cr.openjdk.java.net/~drchase/8022701/webrev.03/
I think the change is good given that the tests work now. Is your test
derived from the test in the bug report?
And it would be good if John could
[repeat]
new, improved webrev: http://cr.openjdk.java.net/~drchase/8022701/webrev.02/
Same small changes to the sources, plus a test.
bug: wrong exception was thrown in call of methodhandle to private method
fix: detect special case of IllegalAccessException, convert to
IllegalAccessError
On 2013-09-08, at 10:39 PM, David Holmes david.hol...@oracle.com wrote:
On 7/09/2013 1:28 AM, Alan Bateman wrote:
On 06/09/2013 15:18, David Chase wrote:
webrev: http://cr.openjdk.java.net/~drchase/8022701/webrev.00/
Question #2, what's the best way to write a jtreg test suite
Take this lightly informed suggestion with a grain of salt, but why not, for
purposes of performance and security,
change the logging-specific getCallerClass methods so that their class
references are instead wrapped in some sort of proxy object that only forwards
certain operations quickly
On 2013-09-06, at 11:28 AM, Alan Bateman alan.bate...@oracle.com wrote:
On 06/09/2013 15:18, David Chase wrote:
webrev: http://cr.openjdk.java.net/~drchase/8022701/webrev.00/
bug: The bug report is not correct, but there is nonetheless a related
underlying bug where IllegalAccessError
On 2013-07-15, at 9:02 AM, Aleksey Shipilev aleksey.shipi...@oracle.com wrote:
The conclusion is: SR is a reasonable alternative with no obvious
performance show-stoppers. That said, TLR is also reasonably fast at
this point, and further improvements to TLR will probably beat the SR or
tie it
Not a reviewer, but depressingly much experience hacking Java FP.
It all looks right to me (i.e., exponent extraction and rounding modes
including the round-up carry to the next higher power of two) and I like the
comments explaining the little hacks, and I trust the testing to smoke out
On 2013-06-20, at 4:53 PM, Martin Buchholz marti...@google.com wrote:
I am an openjdk Reviewer, and this change Looks Good To Me.
Thanks Louis, David, Brian.
Again I suggest we make it easier to give out reviewer bits. For example,
David may not have been making many direct
For sufficiently large strings, indexOf can also be profitably parallelized.
David
On 2013-06-17, at 2:14 AM, Martin Buchholz marti...@google.com wrote:
You are not the first person to have this idea.
It is unlikely that you will succeed in changing the algorithm, because the
jit-optimized
On 2013-06-14, at 8:41 AM, Remi Forax fo...@univ-mlv.fr wrote:
In the codes I was referring to, there was always a way to know that the
remove was done at the end by example by knowing that the last element was a
special sentinel or by using a counter.
So is the following program bugged ?
On 2013-06-13, at 7:30 AM, Doug Lea d...@cs.oswego.edu wrote:
On 13/06/2013 10:30, Chris Hegarty wrote:
On 06/12/2013 05:07 PM, Alan Bateman wrote:
On 12/06/2013 15:50, Chris Hegarty wrote:
...
Is the name final? Just curious if other names such as parallelScan
have
been considered (and
On 2013-06-10, at 11:53 AM, Aleksey Shipilev aleksey.shipi...@oracle.com
wrote:
o.b.ClassBench.generic_getGenericSuperclass avgt 1 51
5.3000.008 nsec/op
Am I reading this correctly? 0.008 nsec/op means 125 times 10-to-the-9th ops
per second.
That's a high
Wouldn't be more efficient to do the following, assuming that the full Java
compilation chain respects the trickiness of 0 vs -0:
if (d == 0.0) {
d=0.0 // Jam -0 == +0 to +0, per
http://www.w3.org/TR/xpath/#function-string
}
Division's plenty more expensive than assigning a
On 2013-05-31, at 9:52 AM, Alan Bateman alan.bate...@oracle.com wrote:
On 31/05/2013 03:17, David Chase wrote:
Not sure where this stands, given that Vladimir K has a grand plan to turn
the assembly language into an intrinsic (this is not how I would normally
approach
On 2013-05-31, at 1:43 PM, Vladimir Kozlov vladimir.koz...@oracle.com wrote:
On 5/31/13 7:42 AM, David Chase wrote:
The current plumbing for the XX option does affect code flow in the compiled
C; that was pretty much the entire point of it. Vladimir has a plan, I
think his attitude
-27, at 11:29 AM, David Chase david.r.ch...@oracle.com wrote:
On 2013-05-27, at 9:27 AM, David Chase david.r.ch...@oracle.com wrote:
Here, seeing is believing (oh, but look, I trashed the output format on the
warmup, I should fix that):
FIRST, WITH SHORT WARMUP:
dr2chase:zip $ $BB/java
It looks like there's no way to set the random seed from the command line.
That's going to make Heisenbugs even less fun than they already are. Ideally,
if a VM crashes, that random seed could get mentioned somewhere in the crash,
and someone who is debugging might then be able to specify it
On 2013-05-27, at 12:38 AM, David Holmes david.hol...@oracle.com wrote:
Hi David,
That said I still have an issue with this code:
147 if (buf) {
148 /* Don't know for sure how big an unsigned long is, therefore
149 copy one at a time. */
150 int i;
On 2013-05-27, at 9:27 AM, David Chase david.r.ch...@oracle.com wrote:
Here, seeing is believing (oh, but look, I trashed the output format on the
warmup, I should fix that):
FIRST, WITH SHORT WARMUP:
dr2chase:zip $ $BB/java TimeChecksum
-- Adler32 --
Warmup
, Alan Bateman wrote:
On 20/05/2013 14:49, David Chase wrote:
Suppose I split this bug (i.e., file a new bug) into the
Intel-acceleration part and the fork-join part.
:
This make sense.
I agree.
I also don't have an issue with eliding the optimization on Windows for the
time being
On 2013-05-20, at 3:33 AM, Alan Bateman alan.bate...@oracle.com wrote:
I think we need to get more experience with parallel operations before
considering changing the default behavior of long standing methods. This it
why I am suggesting this should be opt-in, meaning you run with something
Suppose I split this bug (i.e., file a new bug) into the Intel-acceleration
part and the fork-join part.
Does that makes this a hair easier? It will still contain the assembly
language, and I am still attempting to get anywhere at all on Windows (our
official instructions don't work, largely
On 2013-05-20, at 11:28 AM, Vladimir Kozlov vladimir.koz...@oracle.com wrote:
On 5/20/13 6:49 AM, David Chase wrote:
Suppose I split this bug (i.e., file a new bug) into the Intel-acceleration
part and the fork-join part.
Yes, please, do that.
And, before I waste more time tearing my
disabling this optimization for Windows.
David
On 2013-05-20, at 1:14 PM, David Chase david.r.ch...@oracle.com wrote:
On 2013-05-20, at 11:28 AM, Vladimir Kozlov vladimir.koz...@oracle.com
wrote:
On 5/20/13 6:49 AM, David Chase wrote:
Suppose I split this bug (i.e., file a new bug
On 2013-05-19, at 12:50 PM, Alan Bateman alan.bate...@oracle.com wrote:
On 16/05/2013 15:50, David Chase wrote:
webrev: http://cr.openjdk.java.net/~drchase/7088419/webrev.01/
problem: Some applications spend a surprising amount of time computing CRC32s
(Not sure I'm supposed to be precise
On 2013-05-17, at 4:28 AM, Paul Sandoz paul.san...@oracle.com wrote:
On May 17, 2013, at 12:09 AM, David Chase david.r.ch...@oracle.com wrote:
On 2013-05-16, at 5:27 PM, Alan Bateman alan.bate...@oracle.com wrote:
The current proposal doesn't change the API at this time but I wonder
On 2013-05-17, at 9:55 AM, Doug Lea d...@cs.oswego.edu wrote:
A quick note while travelling...
[*] In JDK 8 the Arrays.parallelSort methods use an array length
threshold of 2^13, arrays = to that length will be sorted sequentially
and arrays than will be sorted in parallel. IIUC the
On 2013-05-17, at 10:07 AM, Paul Sandoz paul.san...@oracle.com wrote:
Baking it in as a static decision is just kicking the can down the road --
once some module that computes CRCs as part of its larger work chooses
serial or parallel, what then, if that module's client doesn't like that
On 2013-05-17, at 12:13 PM, Paul Sandoz paul.san...@oracle.com wrote:
On May 17, 2013, at 4:45 PM, David Chase david.r.ch...@oracle.com wrote:
That is, turning the parallelism option into a static choice of method name
is not a good way to go; it only works for programming in the small
webrev: http://cr.openjdk.java.net/~drchase/7088419/webrev.01/
problem: Some applications spend a surprising amount of time computing CRC32s
(Not sure I'm supposed to be precise on an open mailing list). Recent Intel
architectures provide instructions that might be useful in addressing this.
On 2013-05-16, at 12:17 PM, Mike Duigou mike.dui...@oracle.com wrote:
I haven't looked at the details for the PCLMULQDQ instruction but a caryless
multiply could be of use to some of the crypto primitives as well (GHASH,
GMAC and probably others). Perhaps the property could be
On 2013-05-16, at 5:27 PM, Alan Bateman alan.bate...@oracle.com wrote:
The current proposal doesn't change the API at this time but I wonder if you
have considered adding parallelUpdate methods to complement the serial
methods?
I'm not sure I understand. Right now, the update methods run
On 2013-05-16, at 6:16 PM, Mike Duigou mike.dui...@oracle.com wrote:
Note that the instruction also works on 32-bit, and once the builds all use
sufficiently modern compilers, the same source code works for both.
Understood, but it's only going to be available on processors that support
On 2013-05-16, at 9:26 PM, David Holmes david.hol...@oracle.com wrote:
Dave,
This is certainly significant work!
To get the mundane issues out of the way:
- C code uses indent of 2 in places instead of 4
Okey-doke, I will reformat.
There is a lot to try and digest here.
Ask away,
On 2013-05-16, at 10:15 PM, David Holmes david.hol...@oracle.com wrote:
BTW while at this code I don't understand the issue with size of long and
copying one at a time. Where are the unsigned longs? and should we be
using them if we don't even know they will be larger than unsigned ints?
On 2013-05-16, at 11:06 PM, David Holmes david.hol...@oracle.com wrote:
On 17/05/2013 12:26 PM, David Chase wrote:
They're stored in unsigned long (that is how zlib declares them) and at
least on a Mac that is 8 bytes, not 4, so memmove/memcpy are not a good
idea. When the fast-path
The changed files are these:
M src/share/classes/java/util/zip/Adler32.java
M src/share/classes/java/util/zip/CRC32.java
M src/share/classes/sun/misc/VM.java
M src/share/native/java/util/zip/CRC32.c
M test/java/util/zip/TimeChecksum.java
A test/java/util/zip/CRCandAdlerTest.java
This is for a
On 2013-05-10, at 2:47 AM, David Holmes david.hol...@oracle.com wrote:
Right this was our first thought too, but the specification for toString
states that a new String is created. So to go this path we'd also have to
push through a spec change for StringBuilder/StringBuffer. Given this is an
72 matches
Mail list logo
