On 2014-11-20, at 7:45 AM, Staffan Friberg 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 on both big- and littl
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 wrote:
> Hi David,
>
> I played a little with the idea of having a hash tabl
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 f
On 2014-11-08, at 10:07 AM, Peter Levart 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 resolved so intern
details)
And it continues to pass the previously-failing tests, as well as the new test
which has been added to hotspot/test/compiler/jsr292 .
David
On 2014-11-04, at 3:54 PM, David Chase wrote:
> I’m working on the initial benchmarking, and so far this arrangement (with
> synchronization
that it allows is desirable.
David
On 2014-11-04, at 11:48 AM, Peter Levart wrote:
> On 11/04/2014 04:19 PM, David Chase wrote:
>> On 2014-11-04, at 5:07 AM, Peter Levart wrote:
>>> Are you thinking of an IdentityHashMap type of hash table (no linked-list
>>> of ele
On 2014-11-04, at 5:07 AM, Peter Levart 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 can’t be an identityH
On 2014-11-03, at 3:09 PM, Peter Levart 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 of adding a simple:
On 2014-11-03, at 11:42 AM, Peter Levart 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 Unsafe.storeFence() b
>> 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?
>
On 2014-11-02, at 10:49 PM, David Holmes 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 spec+implementation.
On 2014-10-17, at 5:22 PM, Staffan Friberg wrote:
>
> The polynomial used for multiplication is different so while, as with all
> CRCs, the algorithm is similar, but a different polynomial is used and the
> final checksum will be different.
Yes, I was misled by the comments. Wikipedia makes
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 wrote:
>
> On 2014-10-17, at 2:53 PM, Staffan Friberg wrote:
>
>> F
On 2014-10-17, at 2:53 PM, Staffan Friberg 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 IntBuffer and LongBuffer i
On 2014-01-15, at 10:31 AM, Vladimir Ivanov
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 incorporated into one of the
On 2013-11-27, at 6:53 AM, Peter Levart 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 okay. This fix was a
On 2013-11-26, at 8:12 AM, David Chase wrote:
> On 2013-11-26, at 7:32 AM, David Holmes wrote:
>> On 26/11/2013 10:16 PM, David Chase wrote:
>>>
>>> On 2013-11-26, at 7:12 AM, David Holmes wrote:
>>>> On 26/11/2013 9:56 PM, David Chase wrote:
>&g
On 2013-11-26, at 7:32 AM, David Holmes wrote:
> On 26/11/2013 10:16 PM, David Chase wrote:
>>
>> On 2013-11-26, at 7:12 AM, David Holmes wrote:
>>> On 26/11/2013 9:56 PM, David Chase wrote:
>>>>
>>>> On 2013-11-25, at 9:18 PM, David Holmes wr
On 2013-11-26, at 7:12 AM, David Holmes wrote:
> On 26/11/2013 9:56 PM, David Chase wrote:
>>
>> On 2013-11-25, at 9:18 PM, David Holmes wrote:
>>> We do have the jdk.internal namespace. But I think Unsafe is as good a
>>> place as any - though maybe
On 2013-11-25, at 9:18 PM, David Holmes 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 to the hotspot commit
I wasn't 100% clear on the desire to not add another preloaded class, and I was
under the impression that if s.m.Unsafe could not load, then things were hosed
indeed. If there's another already preloaded class that would be a good
choice, it is an easy change to make; MethodHandleNatives, or ot
On 2013-11-22, at 2:56 PM, Karen Kinnear 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.
>
> Couple of m
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 an
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
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
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"
> conta
-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 wrote:
> On Sep 12, 2013, at 5:44 PM, David Chase wrote:
>
>> Do these sibling bugs have numbers?
>
>
; causes that the JVM may include.
>
> Thanks for untangling this!
>
> — John
>
> On Sep 12, 2013, at 12:17 PM, David Chase wrote:
>
>> The test is adapted from the test in the bug report.
>> The headline on the bug report is wrong -- because it uses reflection
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 wrote:
> On Sep 12, 2013, at 1:00 PM, David Chase wrote:
>
>> On 2013-09-12, at 1:17 AM,
On 2013-09-12, at 1:17 AM, Dmitry Nadezhin 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 refers to the
decimal rep
, Christian Thalinger
wrote:
> + // err.initCause(ex);
>
> Why is this commented?
>
> -- Chris
>
> On Sep 6, 2013, at 4:59 PM, David Chase wrote:
>
>> new, improved webrev: http://cr.openjdk.java.net/~drchase/8022701/webrev.02/
>> Same small
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
wrote:
>
> On Sep 12, 2013, at 11:28 AM, David Chase wrote:
>
>> New webrev, commented line r
New webrev, commented line removed:
http://cr.openjdk.java.net/~drchase/8022701/webrev.03/
On 2013-09-12, at 1:53 PM, David Chase wrote:
> I believe it produced extraneous output -- it was not clear to me that it was
> either necessary or useful to fully describe all the converted exce
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 wrote:
> I think the reason you use 1075 digits is because
ng, if your input 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 wrote:
> On 2013-09-12, at 8:18 AM, Dmitry Nadezh
hu, Sep 12, 2013 at 3:57 PM, David Chase wrote:
>
>> 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
>&
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 Na
[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
testi
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 wi
On 2013-09-08, at 10:39 PM, David Holmes 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 w
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
testing:
verif
On 2013-09-06, at 11:28 AM, Alan Bateman 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 Ill
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 fails to be thrown.
Question #1, is this a corelibs bug? It was filed against compiler, but the
fix is in the jdk classe
On 2013-07-19, at 2:00 PM, Mike Duigou wrote:
> Attempting to use SecureRandom will likely encounter order of initialization
> issues as it is loaded from security providers and is only
> functional/available very late in the VM boot process. Solutions which use
> lousy seeding until SecureRan
On 2013-07-15, at 9:02 AM, Aleksey Shipilev 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 on most scenarios.
I t
On 2013-06-20, at 4:53 PM, Martin Buchholz 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 contributions to openjdk,
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
fencep
I'm not a reviewer, but I am happy to see that you always print the random
seed, and not just in the case of graceful test failure -- because otherwise if
the VM crashes, too bad for the poor fool who has to try to reproduce that.
David
On 2013-06-18, at 8:59 PM, Mike Duigou wrote:
> I have n
For sufficiently large strings, indexOf can also be profitably parallelized.
David
On 2013-06-17, at 2:14 AM, Martin Buchholz 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 brute-force algori
On 2013-06-14, at 8:41 AM, Remi Forax 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 ?
>
> List l = n
On 2013-06-13, at 7:30 AM, Doug Lea 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
On 2013-06-10, at 11:53 AM, Aleksey Shipilev
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 clock rate.
Have most bee
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 cons
On 2013-05-31, at 1:43 PM, Vladimir Kozlov 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
On 2013-05-31, at 9:52 AM, Alan Bateman 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 it) but there i
-27, at 11:29 AM, David Chase wrote:
>
> On 2013-05-27, at 9:27 AM, David Chase 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/jav
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 t
On 2013-05-27, at 9:27 AM, David Chase 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...
On 2013-05-27, at 12:38 AM, David Holmes 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;
> 151 fo
t the exciting details).
David
On 2013-05-21, at 5:15 PM, David Chase wrote:
>
> http://cr.openjdk.java.net/~drchase/7088419/webrev.03/
>
> Newer, slimmer webrev. No fork/join, the related code is removed (except the
> native init routine still returns a boolean, which
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&
disabling this optimization for Windows.
David
On 2013-05-20, at 1:14 PM, David Chase wrote:
>
> On 2013-05-20, at 11:28 AM, Vladimir Kozlov
> 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-accelera
On 2013-05-20, at 11:28 AM, Vladimir Kozlov 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 h
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 b
On 2013-05-20, at 3:33 AM, Alan Bateman 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
> like -Djdk.enable
On 2013-05-19, at 12:50 PM, Alan Bateman 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 s
On 2013-05-17, at 12:13 PM, Paul Sandoz wrote:
> On May 17, 2013, at 4:45 PM, David Chase 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, and in
>> general
On 2013-05-17, at 10:07 AM, Paul Sandoz 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
>> decision?
>>
>
On 2013-05-17, at 9:55 AM, Doug Lea 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 threshold w
There's been a little pushback against that use of forkjoin, though (as the
author of the CRC/Adler work it seems like a reasonable idea to me). One worry
I have had is that in a larger context we are worried not just about speed, but
also about efficiency; using 4 threads for a 3x speedup is i
On 2013-05-17, at 4:28 AM, Paul Sandoz wrote:
>
> On May 17, 2013, at 12:09 AM, David Chase wrote:
>
>>
>> On 2013-05-16, at 5:27 PM, Alan Bateman wrote:
>>> The current proposal doesn't change the API at this time but I wonder if
>>> you have
On 2013-05-16, at 11:06 PM, David Holmes 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
>&
On 2013-05-16, at 10:15 PM, David Holmes 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?
The values are wel
On 2013-05-16, at 9:26 PM, David Holmes 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
Are you referring to the #ifdefs and #defines?
I just want to be sure, because that's what I see at 2
On 2013-05-16, at 9:26 PM, David Holmes 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, I'll do my best. I
On 2013-05-16, at 6:16 PM, Mike Duigou 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
> also support EMT
On 2013-05-16, at 5:27 PM, Alan Bateman 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 in parallel for
suffi
On 2013-05-16, at 12:17 PM, Mike Duigou 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
> "sun.hotspot.x64.clmulSupported
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.
See
Thanks, I'll bring it up to date.
On 2013-05-15, at 10:43 AM, Alan Bateman wrote:
> The core-libs-dev is best for the java.util.zip code.
>
> You can push changes to the zip code via any of the integration forests but I
> think it would be best if you used jdk8/tl/jdk as that is the route for a
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 per
On 2013-05-10, at 2:47 AM, David Holmes 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
> obscure corner ca
83 matches
Mail list logo
