On Tue, 16 Nov 2021 13:22:46 GMT, kabutz wrote:
> BigInteger currently uses three different algorithms for multiply. The simple
> quadratic algorithm, then the slightly better Karatsuba if we exceed a bit
> count and then Toom Cook 3 once we go into the several thousands of bits.
>
On Tue, 16 Nov 2021 20:53:26 GMT, kabutz wrote:
>> This is a draft proposal for how we could improve stream performance for the
>> case where the streams are empty. Empty collections are common-place. If we
>> iterate over them with an Iterator, we would have to create one
> "may use more memory" even if the current implementation doesn't actually
>> use more memory. If there are any "contraindications" on when to use the
>> method, they could be listed here too.
>
> @kabutz I approved, but can you address Joe's comment, then i will update the
> CSR.
Done.
-
PR: https://git.openjdk.java.net/jdk/pull/6409
On Wed, 9 Feb 2022 22:48:57 GMT, Paul Sandoz wrote:
> > A question about wording of the @implNote. In multiply() they say: "An
> > implementation may offer better algorithmic ...", but we changed this to
> > "This implementation may offer better algorithmic ..." I've kept it as
> > "This
l, and that the last 3
> calculations would dominate, 2.7x faster should probably be considered quite
> good on a 1-6-2 machine.
kabutz has updated the pull request incrementally with one additional commit
since the last revision:
Made comment more general to cover other implementations of para
On Thu, 3 Feb 2022 05:29:51 GMT, kabutz wrote:
>> BigInteger currently uses three different algorithms for multiply. The
>> simple quadratic algorithm, then the slightly better Karatsuba if we exceed
>> a bit count and then Toom Cook 3 once we go into the several thousands
l, and that the last 3
> calculations would dominate, 2.7x faster should probably be considered quite
> good on a 1-6-2 machine.
kabutz has updated the pull request incrementally with one additional commit
since the last revision:
Updated comment to include information about performance
On Fri, 28 Jan 2022 18:59:56 GMT, kabutz wrote:
>> BigInteger currently uses three different algorithms for multiply. The
>> simple quadratic algorithm, then the slightly better Karatsuba if we exceed
>> a bit count and then Toom Cook 3 once we go into the several thousands
l, and that the last 3
> calculations would dominate, 2.7x faster should probably be considered quite
> good on a 1-6-2 machine.
kabutz has updated the pull request incrementally with one additional commit
since the last revision:
Benchmark for testing the effectiveness of BigInteger.parallel
On Fri, 14 Jan 2022 09:15:37 GMT, kabutz wrote:
>>> > embarrassingly parallelizable
>>>
>>> Having looked at [embarrassingly
>>> parallel](https://en.wikipedia.org/wiki/Embarrassingly_parallel), I'm not
>>> certain that this particu
On Sat, 15 Jan 2022 18:03:33 GMT, Paul Sandoz wrote:
>> kabutz has updated the pull request incrementally with one additional commit
>> since the last revision:
>>
>> Changed depth type to byte to save 8 bytes on each RecursiveSquare instance
>
>
l, and that the last 3
> calculations would dominate, 2.7x faster should probably be considered quite
> good on a 1-6-2 machine.
kabutz has updated the pull request incrementally with one additional commit
since the last revision:
Removed unnecessary output from the test
-
On Thu, 16 Dec 2021 21:54:43 GMT, Paul Sandoz wrote:
>>> > embarrassingly parallelizable
>>>
>>> Having looked at [embarrassingly
>>> parallel](https://en.wikipedia.org/wiki/Embarrassingly_parallel), I'm not
>>> certain that this particular problem would qualify. The algorithm is easy
>>> to
On Tue, 16 Nov 2021 20:53:26 GMT, kabutz wrote:
>> This is a draft proposal for how we could improve stream performance for the
>> case where the streams are empty. Empty collections are common-place. If we
>> iterate over them with an Iterator, we would have to create one
On Thu, 16 Dec 2021 21:37:26 GMT, kabutz wrote:
> > embarrassingly parallelizable
>
> Having looked at [embarrassingly
> parallel](https://en.wikipedia.org/wiki/Embarrassingly_parallel), I'm not
> certain that this particular problem would qualify. The algorithm is easy
On Thu, 16 Dec 2021 21:30:21 GMT, kabutz wrote:
> embarrassingly parallelizable
Having looked at [embarrassingly
parallel](https://en.wikipedia.org/wiki/Embarrassingly_parallel), I'm not
certain that this particular problem would qualify. The algorithm is easy to
parallelize, but in the
On Thu, 16 Dec 2021 21:22:02 GMT, Paul Sandoz wrote:
> > "embarrassingly parallel when employing recursive" -> "embarrassingly
> > non-parallel when employing recursive" (?)
>
> I corrected to "embarrassingly parallelizable" (i believe that is a common
> phrase we as software engineers use in
On Thu, 16 Dec 2021 19:46:19 GMT, Paul Sandoz wrote:
> > Terribly sorry to ask this, but where would I see the CSR? I don't have
> > access to the JIRA in the backend.
>
> You should be able to view it but not edit:
>
> https://bugs.openjdk.java.net/browse/JDK-8278886
>
> (To get
On Thu, 16 Dec 2021 06:07:29 GMT, kabutz wrote:
>> BigInteger currently uses three different algorithms for multiply. The
>> simple quadratic algorithm, then the slightly better Karatsuba if we exceed
>> a bit count and then Toom Cook 3 once we go into the several thousands
On Thu, 16 Dec 2021 05:55:14 GMT, kabutz wrote:
>> This is looking good. I will create the CSR and propose it. Since the
>> holiday season is imminent it's likely no approval of the CSR will happen on
>> until the new year.
>
>> This is looking good. I will create th
l, and that the last 3
> calculations would dominate, 2.7x faster should probably be considered quite
> good on a 1-6-2 machine.
kabutz has updated the pull request incrementally with one additional commit
since the last revision:
Changed depth type to byte to save 8 bytes on each RecursiveS
On Thu, 16 Dec 2021 01:01:33 GMT, Paul Sandoz wrote:
>> Inside the constructor would not work, since we do not construct RecursiveOp
>> for all the tasks. However, I have incremented the parameter depth. I don't
>> like changing parameters inside methods, but since I'm doing it where it is
>>
On Thu, 16 Dec 2021 01:33:46 GMT, Paul Sandoz wrote:
> This is looking good. I will create the CSR and propose it. Since the holiday
> season is imminent it's likely no approval of the CSR will happen on until
> the new year.
Thank you so much Paul.
-
PR:
l, and that the last 3
> calculations would dominate, 2.7x faster should probably be considered quite
> good on a 1-6-2 machine.
kabutz has updated the pull request incrementally with four additional commits
since the last revision:
- Made RecursiveOp fields package-private so that we do not nee
On Wed, 24 Nov 2021 15:20:42 GMT, kabutz wrote:
>> BigInteger currently uses three different algorithms for multiply. The
>> simple quadratic algorithm, then the slightly better Karatsuba if we exceed
>> a bit count and then Toom Cook 3 once we go into the several thousands
On Tue, 30 Nov 2021 23:18:21 GMT, Paul Sandoz wrote:
>> kabutz has updated the pull request incrementally with one additional commit
>> since the last revision:
>>
>> Made forkOrInvoke() method protected to avoid strange compiler error
>
> src/jav
On Tue, 30 Nov 2021 23:19:37 GMT, Paul Sandoz wrote:
>> kabutz has updated the pull request incrementally with one additional commit
>> since the last revision:
>>
>> Made forkOrInvoke() method protected to avoid strange compiler error
>
> src/jav
On Tue, 30 Nov 2021 23:45:02 GMT, Paul Sandoz wrote:
>> kabutz has updated the pull request incrementally with one additional commit
>> since the last revision:
>>
>> Made forkOrInvoke() method protected to avoid strange compiler error
>
> src/jav
On Tue, 30 Nov 2021 23:16:20 GMT, Paul Sandoz wrote:
>> kabutz has updated the pull request incrementally with one additional commit
>> since the last revision:
>>
>> Made forkOrInvoke() method protected to avoid strange compiler error
>
> src/jav
On Tue, 30 Nov 2021 23:10:39 GMT, Paul Sandoz wrote:
>> kabutz has updated the pull request incrementally with one additional commit
>> since the last revision:
>>
>> Made forkOrInvoke() method protected to avoid strange compiler error
>
> src/jav
On Tue, 30 Nov 2021 23:03:48 GMT, Paul Sandoz wrote:
>> kabutz has updated the pull request incrementally with one additional commit
>> since the last revision:
>>
>> Made forkOrInvoke() method protected to avoid strange compiler error
>
> src/jav
On Tue, 16 Nov 2021 20:53:26 GMT, kabutz wrote:
>> This is a draft proposal for how we could improve stream performance for the
>> case where the streams are empty. Empty collections are common-place. If we
>> iterate over them with an Iterator, we would have to create one
On Thu, 18 Nov 2021 07:26:45 GMT, David Holmes wrote:
>> kabutz has updated the pull request incrementally with one additional commit
>> since the last revision:
>>
>> Removed JVM flags from benchmark
>
> To add my 2c IMO a parallel version of this type
On Thu, 18 Nov 2021 07:26:45 GMT, David Holmes wrote:
>> kabutz has updated the pull request incrementally with one additional commit
>> since the last revision:
>>
>> Removed JVM flags from benchmark
>
> To add my 2c IMO a parallel version of this type
On Wed, 24 Nov 2021 15:20:42 GMT, kabutz wrote:
>> BigInteger currently uses three different algorithms for multiply. The
>> simple quadratic algorithm, then the slightly better Karatsuba if we exceed
>> a bit count and then Toom Cook 3 once we go into the several thousands
l, and that the last 3
> calculations would dominate, 2.7x faster should probably be considered quite
> good on a 1-6-2 machine.
kabutz has updated the pull request incrementally with one additional commit
since the last revision:
Made forkOrInvoke() method protected to avoid strange compiler
l, and that the last 3
> calculations would dominate, 2.7x faster should probably be considered quite
> good on a 1-6-2 machine.
kabutz has updated the pull request incrementally with one additional commit
since the last revision:
Added limit on the number of recursive tasks based on number of
On Wed, 17 Nov 2021 19:48:25 GMT, kabutz wrote:
>> BigInteger currently uses three different algorithms for multiply. The
>> simple quadratic algorithm, then the slightly better Karatsuba if we exceed
>> a bit count and then Toom Cook 3 once we go into the several thousands
On Thu, 18 Nov 2021 07:26:45 GMT, David Holmes wrote:
> To add my 2c IMO a parallel version of this type absolutely **must** be
> opt-in. There are simply far too many side-effects of using the FJP and
> multiple threads to perform the calculation in parallel as if it is just a
> minor
On Wed, 17 Nov 2021 19:48:25 GMT, kabutz wrote:
>> BigInteger currently uses three different algorithms for multiply. The
>> simple quadratic algorithm, then the slightly better Karatsuba if we exceed
>> a bit count and then Toom Cook 3 once we go into the several thousands
On Wed, 17 Nov 2021 19:11:35 GMT, Paul Sandoz wrote:
> > I also do not like potentially non-obvious default behavior, nor a command
> > line flag, nor a (static) setting on `BigInteger`. Thus I think the
> > original `parallelMultiply()` (or perhaps `multiplyParallel()`) would be
> >
On Wed, 17 Nov 2021 17:51:03 GMT, Erik Österlund wrote:
> > I would be wary to make any API use multiple threads behind the scenes
> > without the user explicitly asking for it. While latency of the given
> > operation might improve in isolation, parallelization always incur some
> > (often
On Wed, 17 Nov 2021 17:51:03 GMT, Erik Österlund wrote:
> I would be wary to make any API use multiple threads behind the scenes
> without the user explicitly asking for it. While latency of the given
> operation might improve in isolation, parallelization always incur some
> (often
l, and that the last 3
> calculations would dominate, 2.7x faster should probably be considered quite
> good on a 1-6-2 machine.
kabutz has updated the pull request incrementally with one additional commit
since the last revision:
Removed JVM flags from benchmark
-
Changes:
On Wed, 17 Nov 2021 17:14:32 GMT, Brian Burkhalter wrote:
>> kabutz has updated the pull request incrementally with one additional commit
>> since the last revision:
>>
>> Reordered import statements to be consistent with canonical order
>
> src/jav
l, and that the last 3
> calculations would dominate, 2.7x faster should probably be considered quite
> good on a 1-6-2 machine.
kabutz has updated the pull request incrementally with one additional commit
since the last revision:
Reordered import statements to be consistent with canonical
On Tue, 16 Nov 2021 20:45:05 GMT, Simon Roberts
wrote:
> Is there not also an architectural consideration here? I'm inclined to think
> that just because execution in parallel finishes in less wall time does not
> mean that's the right thing to do. Those CPUs will be unavailable for other
>
e to a much smaller object allocation rate. This PR includes
> the code for the change, unit tests and also a JMH benchmark to demonstrate
> the improvement.
kabutz has updated the pull request incrementally with one additional commit
since the last revision:
Refactored empty str
On Fri, 5 Nov 2021 12:53:46 GMT, kabutz wrote:
> This is a draft proposal for how we could improve stream performance for the
> case where the streams are empty. Empty collections are common-place. If we
> iterate over them with an Iterator, we would have to create one small
> Ite
On Tue, 16 Nov 2021 19:59:49 GMT, Joe Darcy wrote:
> As you cite, there are a few other cases in the JDK API were a second
> "parallelFoo" method is exposed. However, I don't think those precedents
> would necessarily mandate a parallelMultiply method in BigInteger. Without a
> separate
On Tue, 16 Nov 2021 18:42:42 GMT, Joe Darcy wrote:
> It isn't clear to me that parallelMultiply should be a public method as
> opposed to an implementation detail.
Hi Joe, thanks for responding. I would have preferred for it to be an
implementation detail, but I thought it best to keep things
BigInteger currently uses three different algorithms for multiply. The simple
quadratic algorithm, then the slightly better Karatsuba if we exceed a bit
count and then Toom Cook 3 once we go into the several thousands of bits. Since
Toom Cook 3 is a recursive algorithm, it is trivial to
On Tue, 16 Nov 2021 12:48:03 GMT, kabutz wrote:
>> BigInteger currently uses three different algorithms for multiply. The
>> simple quadratic algorithm, then the slightly better Karatsuba if we exceed
>> a bit count and then Toom Cook 3 once we go into the several thousands
On Tue, 16 Nov 2021 12:48:03 GMT, kabutz wrote:
>> BigInteger currently uses three different algorithms for multiply. The
>> simple quadratic algorithm, then the slightly better Karatsuba if we exceed
>> a bit count and then Toom Cook 3 once we go into the several thousands
On Mon, 15 Nov 2021 15:50:39 GMT, kabutz wrote:
> BigInteger currently uses three different algorithms for multiply. The simple
> quadratic algorithm, then the slightly better Karatsuba if we exceed a bit
> count and then Toom Cook 3 once we go into the several thousands of bits.
>
for your ideas about this idea.
Regards
Heinz
--
Dr Heinz M. Kabutz (PhD CompSci)
Author of "The Java™ Specialists' Newsletter" - www.javaspecialists.eu
Java Champion - www.javachampions.org
JavaOne Rock Star Speaker
Tel: +30 69 75 595 262
Skype: kabutz
2
> ± 22,368 ms/op
> BigIntegerParallelMultiply.parallelMultiply 1000ss4536,193
> ± 37,393 ms/op
> BigIntegerParallelMultiply.parallelMultiply 1ss4 9274,657
> ± 826,197 ms/op
kabutz has updated the pull request with a new target b
2
> ± 22,368 ms/op
> BigIntegerParallelMultiply.parallelMultiply 1000ss4536,193
> ± 37,393 ms/op
> BigIntegerParallelMultiply.parallelMultiply 1ss4 9274,657
> ± 826,197 ms/op
kabutz has updated the pull request with a new target base du
2
> ± 22,368 ms/op
> BigIntegerParallelMultiply.parallelMultiply 1000ss4536,193
> ± 37,393 ms/op
> BigIntegerParallelMultiply.parallelMultiply 1ss4 9274,657
> ± 826,197 ms/op
kabutz has updated the pull request with a new target base du
On Mon, 15 Nov 2021 15:50:39 GMT, kabutz wrote:
> BigInteger currently uses three different algorithms for multiply. The simple
> quadratic algorithm, then the slightly better Karatsuba if we exceed a bit
> count and then Toom Cook 3 once we go into the several thousands of bits.
>
BigInteger currently uses three different algorithms for multiply. The simple
quadratic algorithm, then the slightly better Karatsuba if we exceed a bit
count and then Toom Cook 3 once we go into the several thousands of bits. Since
Toom Cook 3 is a recursive algorithm, it is trivial to
On Mon, 15 Nov 2021 18:23:16 GMT, Philippe Marschall
wrote:
> > ```
> > 3. I made many methods just return `this` after checking for operated on
> > and closed:
> > ```
>
> Reading the Javadoc again I'm not sure this is allowed. The method Javadoc
> doesn't clearly say it but the package
On Mon, 15 Nov 2021 18:08:22 GMT, Philippe Marschall
wrote:
> I have a similar project at
> [empty-streams](https://github.com/marschall/empty-streams). A couple of
> notes:
>
> 1. I found the need for streams to be stateful. I had need for the following
> state:
>
>1. closed
>
On Wed, 10 Nov 2021 07:45:27 GMT, Anthony Vanelverdinghe
wrote:
>> @kabutz I agree that i wouldn't consider it clean code to use a stream like
>> i put into the example. I only brought it up because it might break existing
>> code, since i think streams are expected to be
On Sun, 7 Nov 2021 06:26:22 GMT, kabutz wrote:
>> (immutable collections could override stream() instead, since they don't
>> have that problem)
>
>> The net effect of this change might depend on your workload. If you call
>> stream() on empty collections that have c
On Sun, 7 Nov 2021 04:26:13 GMT, Michael Bien wrote:
>> wouldn't this make streams no longer lazy if the collection is empty?
>>
>> List list = new ArrayList<>();
>> Stream stream = list.stream();
>>
>> list.addAll(List.of("one", "two", "three"));
>>
>>
On Sat, 13 Nov 2021 16:59:10 GMT, liach wrote:
>> This is a draft proposal for how we could improve stream performance for the
>> case where the streams are empty. Empty collections are common-place. If we
>> iterate over them with an Iterator, we would have to create one small
>> Iterator
On Fri, 5 Nov 2021 12:53:46 GMT, kabutz wrote:
> This is a draft proposal for how we could improve stream performance for the
> case where the streams are empty. Empty collections are common-place. If we
> iterate over them with an Iterator, we would have to create one small
> Ite
On Sat, 6 Nov 2021 17:23:34 GMT, Pavel Rappo wrote:
> Streams are closeable, and a terminal operation may be invoked on a given
> stream only once. Thus, shouldn't the third line in both of the examples
> below throw `IllegalStateException`?
>
> ```
> Stream empty = Stream.empty();
>
This is a draft proposal for how we could improve stream performance for the
case where the streams are empty. Empty collections are common-place. If we
iterate over them with an Iterator, we would have to create one small Iterator
object (which could often be eliminated) and if it is empty we
ince documentation on that is scarce, I would
appreciate a bit of guidance on how to fix those.
Regards
Heinz
--
Dr Heinz M. Kabutz (PhD CompSci)
Author of "The Java™ Specialists' Newsletter" - www.javaspecialists.eu
Java Champion - www.javachampions.org
JavaOne Rock Star Speaker
Tel: +30
to, whereas the
filter() method seems to suggest that it would be a new stream objects,
but it also does not prescribe that it absolutely has to be.
How important is the white-box testing with the streams? And could we
perhaps make special cases for empty streams?
Regards
Heinz
--
Dr Heinz M. Kab
On Fri, 10 Sep 2021 14:08:05 GMT, Claes Redestad wrote:
> > This looks good. @cl4es might want to confirm that change was not
> > intentional.
>
> Completely unintentional, and perplexing since it's not a simple copy-paste
> error..
The thread priorities in Java are the wrong way round,
On Thu, 9 Sep 2021 10:14:48 GMT, kabutz
wrote:
> …of MAX_PRIORITY-2 during refactoring
>
> Appears in Java 17 for the first time.
>
> During refactoring, the priority was changed from Thread.MAX_PRIORITY - 2 to
> instead state Thread.MIN_PRIORITY - 2, which results in a
On Thu, 9 Sep 2021 15:36:08 GMT, Lance Andersen wrote:
>> src/java.base/share/classes/jdk/internal/ref/CleanerImpl.java line 228:
>>
>>> 226: super(cleaner, cleaner);
>>> 227: }
>>> 228: java
>>
>> Stray change.
>
> Not sure what the "java" is for here seems like a typo
On Thu, 9 Sep 2021 10:14:48 GMT, kabutz
wrote:
> …of MAX_PRIORITY-2 during refactoring
>
> Appears in Java 17 for the first time.
>
> During refactoring, the priority was changed from Thread.MAX_PRIORITY - 2 to
> instead state Thread.MIN_PRIORITY - 2, which results in a
On Thu, 9 Sep 2021 13:38:32 GMT, Aleksey Shipilev wrote:
>> …of MAX_PRIORITY-2 during refactoring
>>
>> Appears in Java 17 for the first time.
>>
>> During refactoring, the priority was changed from Thread.MAX_PRIORITY - 2
>> to instead state Thread.MIN_PRIORITY - 2, which results in a
…of MAX_PRIORITY-2 during refactoring
Appears in Java 17 for the first time.
During refactoring, the priority was changed from Thread.MAX_PRIORITY - 2 to
instead state Thread.MIN_PRIORITY - 2, which results in a negative priority,
and is thus set to Thread.NORM_PRIORITY. Thus the Cleaner by
Vladimir Ivanov wrote:
On 4/14/16 7:37 AM, Dr Heinz M. Kabutz wrote:
in previous versions of Java, escape analysis did not seem to work
particularly
well with Integer.valueOf(int) values, since the objects of course
could come
from the Integer Cache. Thus if the Integer object did not escape
of years, so it's entirely possible that it is a non-issue now :)
Regards
Heinz
--
Dr Heinz M. Kabutz (PhD CompSci)
Author of "The Java(tm) Specialists' Newsletter"
Sun/Oracle Java Champion since 2005
JavaOne Rock Star Speaker 2012
http://www.javaspecialists.eu
Tel: +30 69 75 595 262
Sky
On 04/03/2014, David Holmes david.hol...@oracle.com wrote:
On 3/03/2014 10:56 PM, David M. Lloyd wrote:
Yes, that would necessarily be the contract of a Monitors class, just as
it is part of the contract of Lock today. If your argument is that it
shouldn't be allowed because it might be used
With a curious 9 months old crawling around the house, I've just moved
the sharp knives to the top draw in the kitchen - out of reach. I don't
think we should be encouraging people to use monitor.tryLock() for
various reasons:
1. We have a richer interface with Lock/ReentrantLock, including
of reach of most programmers.
Regards
Heinz
--
Dr Heinz M. Kabutz (PhD CompSci)
Author of The Java(tm) Specialists' Newsletter
Oracle Java Champion 2005-2013
JavaOne Rock Star Speaker 2012
http://www.javaspecialists.eu
Tel: +30 69 75 595 262
Skype: kabutz
Paul Sandoz wrote:
Hi,
Out of all
Plus, monitors can get optimized beautifully when there is no
contention, although that falls away for the code that uses
monitorEnter/monitorExit calls directly as far as I could tell.
Regards
Heinz
--
Dr Heinz M. Kabutz (PhD CompSci)
Author of The Java(tm) Specialists' Newsletter
Oracle
Alan Bateman wrote:
On 25/05/2013 12:35, Alan Bateman wrote:
On 24/05/2013 19:14, Martin Buchholz wrote:
:
Alan, you're telling everyone there's no need for Thread.stop, but
you are replacing usages in tests with calls to Unsafe, which is not
available to normal code. So you have a kind of
in the reverse order in which they
are opened and an exception in the middle of the creation chain does not
prevent the earlier resources from being closed.
Regards
Heinz
--
Dr Heinz M. Kabutz (PhD CompSci)
Author of The Java(tm) Specialists' Newsletter
Oracle Java Champion 2005-2013
JavaOne Rock
Tom Hawtin wrote:
On 09/10/2013 19:00, Dr Heinz M. Kabutz wrote:
That way, the resources are closed in the reverse order in which they
are opened and an exception in the middle of the creation chain does not
prevent the earlier resources from being closed.
But there is only one resource
Remi Forax wrote:
On 06/26/2013 03:10 AM, Dr Heinz M. Kabutz wrote:
Hi Peter,
here is another use case, where someone might want to use this:
3 - in a static context, find out what the class is that you are in.
For example, if you want to create a logger, instead of doing this:
private
:-)
Regards
Heinz
--
Dr Heinz M. Kabutz (PhD CompSci)
Author of The Java(tm) Specialists' Newsletter
Oracle Java Champion 2005-2013
JavaOne Rock Star Speaker 2012
http://www.javaspecialists.eu
Tel: +30 69 75 595 262
Skype: kabutz
Peter Levart wrote:
Hi,
I know that @CallerSensitive annotation
I know 7u6 was the first version of JDK to fully support OS X.
I think that's the key to the puzzle, David! It is definitely an OS X
issue. I didn't see this happen on any other platform.
Regards
Heinz
--
Dr Heinz M. Kabutz (PhD CompSci)
Author of The Java(tm) Specialists' Newsletter
Sun
hundreds of gigabytes of test cases through it
(repeatedly,) taking many days, and cross-checked my multiplication
routines against several other packages including GMP and previous
versions of BigInteger.
--
Dr Heinz M. Kabutz (PhD CompSci)
Author of The Java(tm) Specialists' Newsletter
Sun
Doug Lea wrote:
On 01/14/13 17:58, Chris Hegarty wrote:
I'm not sure what we are saving here. Since new TLR is a singleton, we
save ~64 bytes per classloader. Worth messing with advanced
serialization mechanics? Probably not. I'll publish a revised webrev
soon.
serialPersistentFields is
in the original implementation.
-Alan.
--
Dr Heinz M. Kabutz (PhD CompSci)
Author of The Java(tm) Specialists' Newsletter
Sun Java Champion
IEEE Certified Software Development Professional
http://www.javaspecialists.eu
Tel: +30 69 75 595 262
Skype: kabutz
the SUID with the previous value.
-Aleksey.
--
Dr Heinz M. Kabutz (PhD CompSci)
Author of The Java(tm) Specialists' Newsletter
Sun Java Champion
IEEE Certified Software Development Professional
http://www.javaspecialists.eu
Tel: +30 69 75 595 262
Skype: kabutz
, and will help avoid
any potential issues like this in the future. I can help implement
this on top of your patch if you like.
Oh, please go ahead. That's the learning opportunity for me (never used
sPF before, ready to learn from masters).
-Aleksey.
--
Dr Heinz M. Kabutz (PhD CompSci)
Author
one, but I forgot to
reply and without Martijn's prompting it would have escaped into the
mists of time.
Regards
Heinz
--
Dr Heinz M. Kabutz (PhD CompSci)
Author of The Java(tm) Specialists' Newsletter
Sun Java Champion
IEEE Certified Software Development Professional
http
96 matches
Mail list logo
