Primitive integer types have well-specified value ranges
byte [ -pow(2,7) , pow(2,7) )
short [ -pow(2,15) , pow(2,15) )
int [ -pow(2,31) , pow(2,31) )
long [ -pow(2,63) , pow(2,63) ) .
Primitive operations on these types wrap-around in case of overflow,
but there are methods which throws Arith
Correction.
The unrestricted BigInteger range is
( -pow(2, (pow(2,31) - 1)*32) , pow(2, (pow(2,31) - 1)*32) )
instead of
( -pow(2, pow(2,31) + 31) , pow(2, pow(2,31) + 31).
The restricted BigInteger range
[ -pow(2, pow(2,31) - 1), pow(2, pow(2,31) - 1) )
is ok.
On Tue, Jun 25, 2013 at 11:48 AM,
On 06/25/2013 03:53 AM, Brian Burkhalter wrote:
> http://cr.openjdk.java.net/~bpb/8017540/
Thanks! Looks good to me.
Rather minor silly nit:
cacheLine = Arrays.copyOf(cacheLine, exponent + 1);
for (int i = oldSize; i <= exponent; i++) {
...is probably more consistent as:
cacheLine
On 06/17/2013 01:00 PM, Aleksey Shipilev wrote:
> This is the respin of the RFE filed a month ago:
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-May/016754.html
>
> The webrev is here:
> http://cr.openjdk.java.net/~shade/8014233/webrev.02/
The changeset is here:
http://cr.open
Hi Mandy,
I noticed the @CallerSensitive annotation and machinery behind it has
been back-ported to JDK7. That was when one of my apps using
sun.reflect.Reflection.getCallerClass(int) failed. The native method
taking "int" was deprecated, but it also changed the behavior. If I run
the followi
Known issue, Mandy has a fix in progress [1].
-Chris.
[1] http://mail.openjdk.java.net/pipermail/jdk7u-dev/2013-June/006791.html
On 06/25/2013 11:06 AM, Peter Levart wrote:
Hi Mandy,
I noticed the @CallerSensitive annotation and machinery behind it has
been back-ported to JDK7. That was when
On 25/06/2013 11:06, Peter Levart wrote:
:
It seems that with 7u25 the result is "shifted" for one calling
frame. Is that behavior change intentional to encourage people to "get
off that wagon"?
Right, there is an additional frame that means that getClassClass is out
by one. This change wa
Hi Chris,
I see it now, thanks.
Regards, Peter
On 06/25/2013 12:14 PM, Chris Hegarty wrote:
Known issue, Mandy has a fix in progress [1].
-Chris.
[1]
http://mail.openjdk.java.net/pipermail/jdk7u-dev/2013-June/006791.html
On 06/25/2013 11:06 AM, Peter Levart wrote:
Hi Mandy,
I noticed th
Hi,
I know that @CallerSensitive annotation was introduced to bring some
order to JDK internal plumbings. It's scope was to support JDK internal
usage, so it's use is limited to classes loaded by bootstrap or
extension class-loaders. In JDK-internal code it is used mainly for
implementing sec
On 25/06/2013 01:17, Dan Xu wrote:
HiAll,
The fix of JDK-8013827 added an unnecessary "read" permission
requirement in File.createTempFile methods. This change is going to
fix this issue. Please help review it. Thanks!
webrev: http://cr.openjdk.java.net/~dxu/8017212/webrev.00/
bug: http://b
On 25/06/2013 00:53, Brian Burkhalter wrote:
Branching off from this thread
http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-June/018244.html
I filed this issue (should be public tomorrow)
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8017540
for the getRadixConversionCache() en
Changeset: 01fcca3d2b8c
Author:bpb
Date: 2013-06-20 12:15 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/01fcca3d2b8c
4641897: Faster string conversion of large integers
Summary: Accelerate conversion to string by means of Schoenhage recursive base
conversion.
Reviewed-by: b
Changeset: 4a4d910e1504
Author:alanb
Date: 2013-06-25 13:53 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4a4d910e1504
8017570: jfr.jar should not be in compact3 (for now)
Reviewed-by: erikj
! makefiles/profile-includes.txt
Changeset: 89631a384ee6
Author:weijun
Date: 2013-06-25 21:51 +0800
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/89631a384ee6
8016051: Possible ClassCastException in KdcComm
Reviewed-by: weijun
Contributed-by: Artem Smotrakov
! src/share/classes/sun/security/krb5/KdcComm.java
Hello,
Please review this simple patch which updates regression test
langtools/tools/javac/T6725036.java to offset the time returned by
JavaFileObject.getLastModified() with the local time to UTC delta.
Please note that this patch is intended to address the test failures,
and that I will be immed
On Jun 24, 2013, at 9:25 PM, Joe Darcy wrote:
>> "Requires the output to be padded with leading zeros to the minimum field
>> width following any sign or radix indicator except when converting NaN or
>> infinity. If the width is not provided, then a MissingFormatWidthException
>> will be throw
Changeset: 831467c4c6a7
Author:vromero
Date: 2013-06-25 16:12 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/831467c4c6a7
8017104: javac should have a class for primitive types that inherits from Type
Reviewed-by: jjg
! src/share/classes/com/sun/tools/javac/api/JavacTr
On 25/06/2013 00:53, Brian Burkhalter wrote:
Branching off from this thread
http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-June/018244.html
I filed this issue (should be public tomorrow)
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8017540
for the getRadixConversionCache() en
Changeset: aceae9ceebbe
Author:kizune
Date: 2013-06-25 20:08 +0400
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/aceae9ceebbe
8006973: jtreg test fails:
test/tools/javac/warnings/AuxiliaryClass/SelfClassWithAux.java
Reviewed-by: ksrini
! test/tools/javac/warnings/Auxiliary
Hi Aleksey,
On Jun 25, 2013, at 1:40 AM, Aleksey Shipilev wrote:
> Thanks! Looks good to me.
Cool!
> Rather minor silly nit:
>
>cacheLine = Arrays.copyOf(cacheLine, exponent + 1);
>for (int i = oldSize; i <= exponent; i++) {
>
> ...is probably more consistent as:
>
>cacheLine = A
Max,
Can you explain how to use your test library to run a simple test such
as the one attached with a 3rd party jar on bootclasspath?
e.g.
Proc pc = Proc.create("Test")
.args("-Xbootclasspath/p:"+pathtoXercesImpljar)
.start();
is that how 3rd party jar file can be put on t
This is fine to be a workaround for the test case for now. It probably will
need to be
undo-ed after the propose change for #8015666 get integrated.
http://cr.openjdk.java.net/~sherman/8015666/webrev/
The proposal for #8015666 is to keep the "existing" behavior of
ZipEntry.getTime()
to return
I am sympathetic to this naming issue (actually "indifferent" is more accurate)
but it will have to wait until I return from vacation. I have tagged this
thread and will follow up when I am back in the office. Please be patient, it
will be addressed.
Mike
On Jun 20 2013, at 07:10 , Remi Forax
Looks good. Only a few minor nits.
A few places (BiOperator) where it says "Constructs" rather than "Returns". If
it is important that it constructs a new instance for consistency you may wish
to say "Returns a new ..."
There are a few places of incorrect capitalization in @return and @param ta
On 06/22/2013 12:54 PM, Aleksey Shipilev wrote:
T get(int index1, index2) {
T[][] lc = cache;
if (index1 >= lc.length) { // needs resizing
lc = ((index1 << 1) + 1);
cache = lc;
}
T[] lt = lc[*index2*];
if (index2 >= lt.length) { // needs resizin
Is this a capital-R review?
On 06/25/13 13:50, Xueming Shen wrote:
> This is fine to be a workaround for the test case for now. It probably
> will need to be
> undo-ed after the propose change for #8015666 get integrated.
>
> http://cr.openjdk.java.net/~sherman/8015666/webrev/
>
> The proposal f
It is intended to be an opinion. I would assume you would like a reviewer from
the langtool team to push the change, given the changset is for the lang repo.
You may want to update the "check()" method as well to low the granularity
to 2-second before comparing the equality. The timestamp from t
On 06/25/2013 10:13 PM, Peter Levart wrote:
>
> On 06/22/2013 12:54 PM, Aleksey Shipilev wrote:
>> T get(int index1, index2) {
>> T[][] lc = cache;
>> if (index1 >= lc.length) { // needs resizing
>> lc = ((index1 << 1) + 1);
>> cache = lc;
>> }
>> T[] lt = lc[
On 6/25/13 3:24 AM, Alan Bateman wrote:
On 25/06/2013 11:06, Peter Levart wrote:
:
It seems that with 7u25 the result is "shifted" for one calling
frame. Is that behavior change intentional to encourage people to
"get off that wagon"?
Right, there is an additional frame that means that get
Changeset: ac61efd8c593
Author:shade
Date: 2013-06-25 20:06 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ac61efd8c593
8014233: java.lang.Thread should have @Contended on TLR fields
Summary: add the @Contended over three TLR fields.
Reviewed-by: psandoz, chegar, dholmes, dl
On 06/25/2013 12:13 PM, Peter Levart wrote:
> else { // resizing
> // increase by factor of 1.5 (like ArrayList)
> int newLength = oldLength + (oldLength >> 1);
We probably don't ever want to extend any row of this cache any more
than we need to. The
On 06/25/2013 08:29 PM, Brian Burkhalter wrote:
> Hi Aleksey,
>
> On Jun 25, 2013, at 1:40 AM, Aleksey Shipilev wrote:
>
>> Thanks! Looks good to me.
>
> Cool!
Hold on now. Similar to what Peter suggests in the separate thread,
there is the data race between 3458 and 3466:
3455 private sta
On 6/25/13 3:50 AM, Peter Levart wrote:
Hi,
I know that @CallerSensitive annotation was introduced to bring some
order to JDK internal plumbings. It's scope was to support JDK
internal usage, so it's use is limited to classes loaded by bootstrap
or extension class-loaders. In JDK-internal cod
Does the fix for 8015666 stop the error from happening? If so, then
I'll withdraw this RFR.
On 06/25/13 13:50, Xueming Shen wrote:
> This is fine to be a workaround for the test case for now. It probably
> will need to be
> undo-ed after the propose change for #8015666 get integrated.
>
> http:/
On 06/25/2013 01:53 AM, Brian Burkhalter wrote:
Branching off from this thread
http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-June/018244.html
I filed this issue (should be public tomorrow)
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8017540
for the getRadixConversionCache(
What about such code ?
BigInteger getRadixConversionCache(int radix, int exponent) {
BigInteger retVal = null;
BigInteger[][] pc = powerCache; // volatile read
BigInteger[] cacheLine = pc[radix];
int oldSize = cacheLine.length;
if (exponent >= oldSize) {
cacheLine = Arrays.copyOf(c
On 06/25/2013 09:12 PM, Aleksey Shipilev wrote:
It might be a good idea to turn $powerCache final, not volatile, since
the code will recover anyway. The trouble I'm seeing is weak enough
hardware, which will never see the updated value of cacheLine, always
falling back. Hence, I'm keen to keep "
The proposed change for 8015666 is supposed to stop this test failure. But as I
said
last time that it may take a while for it to get into the repo. I will start
the CCC process
shortly, if there is no objection.
-Sherman
On 06/25/2013 12:27 PM, Eric McCorkle wrote:
Does the fix for 8015666 s
On 06/25/2013 11:38 PM, Peter Levart wrote:
>
> On 06/25/2013 09:12 PM, Aleksey Shipilev wrote:
>> It might be a good idea to turn $powerCache final, not volatile, since
>> the code will recover anyway. The trouble I'm seeing is weak enough
>> hardware, which will never see the updated value of ca
On 06/25/2013 11:36 PM, Dmitry Nadezhin wrote:
> What about such code ?
>
> BigInteger getRadixConversionCache(int radix, int exponent) {
> BigInteger retVal = null;
> BigInteger[][] pc = powerCache; // volatile read
> BigInteger[] cacheLine = pc[radix];
> int oldSize = cacheLine.length;
>
On 06/25/2013 09:24 PM, Mandy Chung wrote:
I'm asking here, to hear any arguments against making such API
supported and public. Are there any security or other issues? If
there aren't, what steps should be taken to introduce such API in the
JDK8 timeframe? I'm thinking of a no-arg method, say
On 06/25/2013 08:45 PM, Xueming Shen wrote:
The proposed change for 8015666 is supposed to stop this test failure.
But as I said
last time that it may take a while for it to get into the repo. I will
start the CCC process
shortly, if there is no objection.
There is no problem here. If 8015666 w
Please do; this test has been failing for almost a month now.
On 06/25/13 15:45, Xueming Shen wrote:
> The proposed change for 8015666 is supposed to stop this test failure.
> But as I said
> last time that it may take a while for it to get into the repo. I will
> start the CCC process
> shortly,
On 06/25/2013 09:50 PM, Aleksey Shipilev wrote:
On 06/25/2013 11:38 PM, Peter Levart wrote:
On 06/25/2013 09:12 PM, Aleksey Shipilev wrote:
It might be a good idea to turn $powerCache final, not volatile, since
the code will recover anyway. The trouble I'm seeing is weak enough
hardware, which
On 06/26/2013 12:34 AM, Peter Levart wrote:
>
> On 06/25/2013 09:50 PM, Aleksey Shipilev wrote:
>> On 06/25/2013 11:38 PM, Peter Levart wrote:
>>> On 06/25/2013 09:12 PM, Aleksey Shipilev wrote:
It might be a good idea to turn $powerCache final, not volatile, since
the code will recover
On 06/25/2013 10:34 PM, Peter Levart wrote:
On 06/25/2013 09:50 PM, Aleksey Shipilev wrote:
On 06/25/2013 11:38 PM, Peter Levart wrote:
On 06/25/2013 09:12 PM, Aleksey Shipilev wrote:
It might be a good idea to turn $powerCache final, not volatile, since
the code will recover anyway. The tro
On 06/26/2013 12:56 AM, Peter Levart wrote:
> Sorry, you are storing back when resizing. And you are resizing for
> every exponent that is bigger that previous requested (cached). This can
> lead to many resizings.
Dmitry had suggested going back to square one with his approach. I'll
let him post
On Jun 25, 2013, at 1:56 PM, Peter Levart wrote:
>
> Sorry, you are storing back when resizing. And you are resizing for every
> exponent that is bigger that previous requested (cached). This can lead to
> many resizings.
Hi everyone,
Apologies to butt in, and maybe this is a very stupid su
On 06/25/2013 10:54 PM, Aleksey Shipilev wrote:
Trying to improve this yields the code very similar to
http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-June/018368.html,
although not as effective on slow path:
private static final BigInteger[][] powerCache;
BigInteger getRadixConversi
Changeset: 757290440a2f
Author:juh
Date: 2013-06-25 14:31 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/757290440a2f
8017325: Cleanup of the javadoc tag in java.security.cert
Summary: Convert javadoc ... and ... tags to {@code ...}
Reviewed-by: darcy
! src/share/classes/ja
Changeset: 3700bb58c9a2
Author:juh
Date: 2013-06-25 14:41 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3700bb58c9a2
8017326: Cleanup of the javadoc tag in java.security.spec
Summary: Convert javadoc and tags to {@code ...}
Reviewed-by: darcy
! src/share/classes/java/sec
On 06/25/2013 09:09 PM, Alan Eliasen wrote:
On 06/25/2013 12:13 PM, Peter Levart wrote:
else { // resizing
// increase by factor of 1.5 (like ArrayList)
int newLength = oldLength + (oldLength >> 1);
We probably don't ever want to extend any ro
On 06/25/2013 09:09 PM, Alan Eliasen wrote:
On 06/25/2013 12:13 PM, Peter Levart wrote:
else { // resizing
// increase by factor of 1.5 (like ArrayList)
int newLength = oldLength + (oldLength >> 1);
We probably don't ever want to extend any ro
On 6/25/13 3:04 PM, David Lloyd wrote:
We have a use case within our security manager implementation that *can* be
solved with the existing getClassContext method, which returns the whole stack,
except we don't *need* the whole stack, just one specific frame. Maybe
SecurityManager is a good
That should be enough. Then you only need to waitFor it.
--Max
在 Jun 26, 2013，1:10 AM，huizhe wang 写道：
> Max,
>
> Can you explain how to use your test library to run a simple test such as the
> one attached with a 3rd party jar on bootclasspath?
>
> e.g.
> Proc pc = Proc.create("Test")
>
On Jun 25, 2013, at 5:50 AM, Peter Levart wrote:
> Hi,
>
> I know that @CallerSensitive annotation was introduced to bring some order to
> JDK internal plumbings. It's scope was to support JDK internal usage, so it's
> use is limited to classes loaded by bootstrap or extension class-loaders. I
The test case in the description of this issue
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7019078
passes after the integration of this changeset
http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a88f6f4d279f
except when the exponent has the value -1074. Here is the pertinent code from
the tes
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 static final Logger log = Logger.getLogger(SomeClass.class);
we could inst
This request for comment regards this issue
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6910473
BigInteger.bigLength() may return negative value for large numbers
but more importantly Dmitry's thread
http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-June/018345.html
What is the ra
Thanks! I'll give it a try. Do you plan to backport this to jdk7?
-Joe
On 6/25/2013 4:31 PM, Wang Weijun wrote:
> That should be enough. Then you only need to waitFor it.
>
> --Max
>
> 在 Jun 26, 2013，1:10 AM，huizhe wang 写道：
>
>> Max,
>>
>> Can you explain how to use your test library to run a si
On 6/26/13 9:32 AM, huizhe wang wrote:
> Thanks! I'll give it a try. Do you plan to backport this to jdk7?
No, but you can smuggle it there inside your test.
--Max
>
> -Joe
>
> On 6/25/2013 4:31 PM, Wang Weijun wrote:
>> That should be enough. Then you only need to waitFor it.
>>
>> --Max
>>
Oh, there is another test library with similar purpose at
https://jbs.oracle.com/bugs/browse/JDK-8007142
and it is already on all versions of java.
It can launch a Java process, wait for it to finish, and collect all the
output (stdout and stderr). Mine takes care of stdin and focus on
inter-p
We have two versions after private discussion with Aleksey.
BigInteger getRadixConversionCache(int radix, int exponent) {
BigInteger[][] pc = powerCache; // volatile read
BigInteger[] cacheLine = pc[radix];
if (exponent < cacheLine.length)
return cacheLine[exponent];
int oldSize = c
Changeset: 510035b7
Author:yhuang
Date: 2013-06-25 21:03 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/510035b7
8013836: getFirstDayOfWeek reports wrong day for pt-BR locale
Reviewed-by: naoto
+ src/share/classes/sun/util/resources/pt/CalendarData_pt_BR.properties
!
On 26.06.2013, at 7:31, Dmitry Nadezhin wrote:
> We have two versions after private discussion with Aleksey.
>
> BigInteger getRadixConversionCache(int radix, int exponent) {
> BigInteger[][] pc = powerCache; // volatile read
> BigInteger[] cacheLine = pc[radix];
> if (exponent < cacheLine.le
> We could check for the existing cacheLine.length right before installing
the new one
Do you mean something like this ?
BigInteger getRadixConversionCache(int radix, int exponent) {
BigInteger[] cacheLine = powerCache[radix]; // volatile read
if (exponent < cacheLine.length)
return cach
66 matches
Mail list logo
