Except when I run it through our test system ReservedStackTest is still
failing :(
I tested it initially when Fred proposed it and that went fine. It also
passes for me locally on Linux.
David
On 24/09/2019 12:20 pm, David Holmes wrote:
Hi Martin,
That all seems fine to me.
Thanks,
David
Hi Martin,
That all seems fine to me.
Thanks,
David
On 24/09/2019 3:43 am, Martin Buchholz wrote:
We now have a fix-up integration that removes all the previously
excluded tests from their exclude lists.
https://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/overview.html
That looks fine to me.
Thanks,
David
On 20/09/2019 7:14 pm, Baesken, Matthias wrote:
Hi David , I adjusted the test (
test/jdk/tools/launcher/TestSpecialArgs.java ) and removed the comments in
os_bsd.cpp (suggested by you) .
New webrev :
anup .
Best regards, Matthias
-Original Message-
From: David Holmes
Sent: Mittwoch, 18. September 2019 03:16
To: Baesken, Matthias ; 'hotspot-
d...@openjdk.java.net'
Subject: Re: sun.java.launcher.pid property usage
Hi Matthias,
On 18/09/2019 12:18 am, Baesken, Matthias wrote:
Hello, w
regards, Matthias
Hi David, thanks for the additional information .
I opened
https://bugs.openjdk.java.net/browse/JDK-8231171
8231171: remove reamining sun.java.launcher.pid references
to do the additional cleanup .
Best regards, Matthias
-Original Message-
From: David Holmes
Re-directing to core-libs-dev mailing list.
David
On 18/09/2019 5:45 am, Keith Turner wrote:
The javadoc for ConcurrentHashMap.computeIfAbsent() states the
remapping function is applied at most once. The functions
computeIfPresent() and compute() do not explicitly state if the
remapping
Thanks Joe. Will push once CI testing is verified.
David
On 16/09/2019 9:54 am, Joe Darcy wrote:
Looks fine David; thanks,
-Joe
On 9/15/2019 4:49 PM, David Holmes wrote:
Bugs: https://bugs.openjdk.java.net/browse/JDK-8231033
https://bugs.openjdk.java.net/browse/JDK-8231034
webrev
Bugs: https://bugs.openjdk.java.net/browse/JDK-8231033
https://bugs.openjdk.java.net/browse/JDK-8231034
webrev: http://cr.openjdk.java.net/~dholmes/8231033-8231034/webrev/
(inline below)
A bunch of mainly management tests (mostly in hotspot repo) are failing
after the JSR-166 refresh to
Hi Martin,
These changes have caused a number of tests to break and wreaked havoc
in our CI system (as those tests get executed a lot in different
configs). The problem seems to be changes to stack use and contents:
-
Looks good.
Thanks for updating.
David
On 13/09/2019 9:02 am, Brent Christian wrote:
Hi,
From the bug report:
"The ProblemList indicates that
vmTestbase/nsk/jdb/eval/eval001/eval001.java was added due to
JDK-8212117. That bug has been fixed, but this test still fails. That
line in the
Hi TK,
Try -J-Xmx4g
David
On 8/09/2019 7:58 am, Tomisław Kityński wrote:
Hello,
I've been trying to run jpackage with different heap sizes, as I get
exception as in the subject from jlink:
java.io.IOException: jlink failed with: Error: Java heap space
java.lang.OutOfMemoryError: Java heap
Hi Brent,
Good to see this all come together :)
A couple of comments below.
On 5/09/2019 7:12 am, Brent Christian wrote:
Hi,
Please review my fix for JDK-8212117[1]. The webrev is here:
http://cr.openjdk.java.net/~bchristi/8212117/webrev09/
So to clarify for others any current caller to
vid
[1] https://wiki.openjdk.java.net/display/csr/CSR+FAQs
-- 原始邮件 --
*发件人:* "David Holmes";
*发送时间:* 2019年9月5日(星期四) 下午2:00
*收件人:* "未来阳光"<2217232...@qq.com>;"core-libs-dev"d...@openjdk.java.net>;
*主题:* Re: 回复： what to do nex
-- 原始邮件 --
*发件人:* "David Holmes";
*发送时间:* 2019年9月5日(星期四) 中午1:44
*收件人:* "未来阳光"<2217232...@qq.com>;"core-libs-dev"d...@openjdk.java.net>;
*主题:* Re: what to do next to fix JDK-8230557. thanks
On 5/09/2019 3:35 pm, 未来阳光 wrote:
>
Hi,
I responded to your other email.
David
On 5/09/2019 3:31 pm, wrote:
Hi, leaders.
A few days ago, I report a bug in core lib[1]. According to the contribute document[2],
I had send oca to oracle andmy name has been listed onoca[3].
But I still can't push my changes to jdk, can
On 5/09/2019 3:35 pm, 未来阳光 wrote:
Hi, leaders.
Hi,
No "leaders" here only developers :)
A few days ago, I report a bug in core lib[1]. According to the contribute document[2],
I had send oca to oracle andmy name has been listed onoca[3].
Welcome aboard!
But I still can't push my
Hi Dan,
With my CSR Group member hat on
On 5/09/2019 8:06 am, Daniel D. Daugherty wrote:
Brent,
You currently have '-XX:+ClassForNameDeferLinking' as a 'product'
option, but
product options are harder to remove down the road. Would it be better as a
diagnostic option? A diagnostic
Hi Claes,
This cleanup all appears fine to me.
The unused Mutex declarations might be better handled in a separate RFE
but I don't insist. You could file the RFE and still fix together in
this one changeset.
Testing: tier1-4
Do you know which tests actually test the older verifier? Just
Re-directing to core-libs-dev
David
On 15/08/2019 7:48 pm, Stephen Buergler wrote:
Not really sure where to send this.
flatMap was fixed so that it doesn't prevent short circuiting.
https://bugs.openjdk.java.net/browse/JDK-8075939
If you replace the test cases in the ticket with versions that
On 13/08/2019 8:55 am, Mandy Chung wrote:
On 8/12/19 3:28 PM, David Holmes wrote:
Hi Mandy,
On 13/08/2019 6:24 am, Mandy Chung wrote:
Having a second thought, I'm keeping @Stable bci field while zero
indicates an invalid BCI that makes it obvious that this field will
be updated. VM will set
Hi Mandy,
On 13/08/2019 6:24 am, Mandy Chung wrote:
Having a second thought, I'm keeping @Stable bci field while zero
indicates an invalid BCI that makes it obvious that this field will be
updated. VM will set StackFrameInfo::bci to value+1.
I don't know this code but why have the VM set
On 11/08/2019 2:50 pm, Mandy Chung wrote:
On 8/10/19 12:30 AM, Aleksey Shipilev wrote:
On 8/9/19 10:19 PM, Mandy Chung wrote:
An earlier version of this patch was reviewed [1] but I
didn't get back to explore the other approach. I rebase
the patch and take out the hotspot change which will be
Hi Prakhar,
The bar for getting new language features added is extremely high - new
operators even higher I think. New operators for parallelism ... well I
don't see that ever happening.
I'm not a fan of implicit parallelism like you propose, it simply raises
too many issues for the system
FYI open again
--- Begin Message ---
Hi.
hg:jdk/jdk is now open and verifies. Even if your local repository is
corrupt, you may continue using it. The corruption does not propagate
via pushes, since changeset IDs are unchanged.
I strongly advise everybody to at least understand whether their
FYI in case this was not seen on jdk-dev list.
David
--- Begin Message ---
Hi.
I've made the hg:jdk/jdk repository READ-ONLY.
A verify error which was discovered in the repository and we'd like to ensure
that no further changesets are pushed as a solution is investigated.
Thanks,
values, nor order
-0.0 and +0.0
** It's been 7 years since I helped Doug Lea put the parallelising code
into the JDK so I'm a bit rusty on the details :) and I'm surprised such
a bug has not been detected before now.
Cheers,
David
Thank you,
Vladimir
Среда, 24 июля 2019, 15:39 +03:00 от
Hi Vladimir,
On 24/07/2019 8:53 pm, Vladimir Yaroslavskiy wrote:
Hi all,
I've found bug in parallel sorting of float / double arrays in the latest JDK.
When float / double values are sorted, additional actions are
required: NaNs must be moved to the end and negative zeros
must be placed
method that declares it throws IOException (and can actually throw it?).
I don't see why that method couldn't still honour the checkError
protocol as well though.
David
On 24/07/2019 11:31 am, David Holmes wrote:
Jumping in here as this change is starting to really confuse me ...
On 24/07/2019 2
Jumping in here as this change is starting to really confuse me ...
On 24/07/2019 2:41 am, Brian Burkhalter wrote:
On Jul 23, 2019, at 8:27 AM, Brian Burkhalter
wrote:
On Jul 23, 2019, at 8:20 AM, Alan Bateman mailto:alan.bate...@oracle.com>> wrote:
On 23/07/2019 16:08, Brian Burkhalter
.
Thanks for the pointers!
Best regards, Rafael
David Holmes mailto:david.hol...@oracle.com>>
schrieb am Di., 23. Juli 2019, 06:10:
Hi Rafael,
A couple of comments on process here ...
On 23/07/2019 6:48 am, Rafael Winterhalter wrote:
> Hello,
>
> I have
Hi Rafael,
A couple of comments on process here ...
On 23/07/2019 6:48 am, Rafael Winterhalter wrote:
Hello,
I have created a patch such that getReceiverType() returns a parameterized
type if the receiver type declaration is itself generic. Currently, the
receiver type is always a type
On 22/07/2019 5:14 pm, Jie Fu wrote:
Hi David,
On 2019/7/22 下午2:55, David Holmes wrote:
Did you use -N when generating the webrev? You shouldn't in this case.
Yes, I had used `ksh webrev.ksh -u jiefu -N -r 55752` to generate
webrev.02.
Updated: http://cr.openjdk.java.net/~jiefu/8225648
,
David
Thanks a lot.
Best regards,
Jie
On 2019/7/22 下午2:22, David Holmes wrote:
Hi Jie,
On 22/07/2019 4:18 pm, Jie Fu wrote:
Hi all,
Could someone help to push this:
http://cr.openjdk.java.net/~jiefu/8225648/webrev.01/ ?
I need a sponsor.
To prepare your patch for your sponsor you should
Hi Jie,
On 22/07/2019 4:18 pm, Jie Fu wrote:
Hi all,
Could someone help to push this:
http://cr.openjdk.java.net/~jiefu/8225648/webrev.01/ ?
I need a sponsor.
To prepare your patch for your sponsor you should commit it with the
correct format commit message, including reviewers, so that
Hi Mandy,
This approach looks much cleaner and safer to me, and the slight
shuffling in the init order should not cause any startup issues.
Thanks,
David
-
On 20/07/2019 2:20 am, Mandy Chung wrote:
This was a follow up to the observation during the code review
of JDK-82193798.
Webrev:
Hi Claes,
On 18/07/2019 1:04 am, Claes Redestad wrote:
Hi,
removing volatile aligns LangReflectAccess initialization with the
pattern used for other access objects: it's only initialized in the
static initializer of some class which we ensure is initialized, which
means any initialization race
, I wasn't aware of it. Would be
nice to expand it to give more guidelines on handling deprecation etc.
Cheers,
David
-
On 4/07/2019 3:36 am, Mandy Chung wrote:
On 7/2/19 11:10 PM, David Holmes wrote:
Hi Mandy,
Thanks for taking a look.
On 3/07/2019 8:57 am, Mandy Chung wrote:
On 7/2
Hi Mandy,
Thanks for taking a look.
On 3/07/2019 8:57 am, Mandy Chung wrote:
On 7/2/19 3:44 PM, David Holmes wrote:
webrev: http://cr.openjdk.java.net/~dholmes/8227055/webrev/
bug: https://bugs.openjdk.java.net/browse/JDK-8227055
The launcher help text needs some minor updates/corrections
webrev: http://cr.openjdk.java.net/~dholmes/8227055/webrev/
bug: https://bugs.openjdk.java.net/browse/JDK-8227055
The launcher help text needs some minor updates/corrections
- -verbose needs more info
- -Xdebug needs to say it does nothing
- -Xloggc is deprecated and replaced by
Hi Prakhar,
On 22/06/2019 1:28 am, Prakhar Makhija wrote:
Topic: OR operator represented by ||
That should be the subject of your email - not a reply to a digest.
Query: The expression evaluation of the operands, of OR operator, does it
happen in parallel, when Java code runs, in the
Hi Roger,
On 18/06/2019 6:00 am, Roger Riggs wrote:
Hi,
Updated:
http://cr.openjdk.java.net/~rriggs/webrev-spawn-diag-8225192-3/
+ if (WIFEXITED(status)) {
+ snprintf(ebuf, sizeof ebuf,
+ "Failed to exec spawn helper: pid: %d, exit value: %d",
+ pid,
Hi Mandy,
Functional fix looks good, but layout and indentation appears off in the
diff.
Thanks to Alan for the time spent investigating this!
Thanks,
David
On 4/06/2019 1:02 pm, Mandy Chung wrote:
test/jdk/java/lang/reflect/PublicMethods/PublicMethodsTest.java time out
in certain
David Holmes wrote:
Hi Florian,
On 25/05/2019 6:50 am, Florian Weimer wrote:
* Jiangli Zhou:
Hi Florian,
On Fri, May 24, 2019 at 2:46 AM Florian Weimer wrote:
* Jiangli Zhou:
[3] change: http://cr.openjdk.java.net/~jiangli/tls_size/webrev/
(contributed by Jeremy Manson
Hi Kim,
This seems reasonable to me.
Thanks,
David
On 31/05/2019 7:04 am, Kim Barrett wrote:
On May 30, 2019, at 3:58 PM, Roger Riggs wrote:
Hi Kim,
To ensure you see some messages in the case of timeouts, it would be
useful to call System.out.flush() after printing the message in
Hi Florian,
On 25/05/2019 6:50 am, Florian Weimer wrote:
* Jiangli Zhou:
Hi Florian,
On Fri, May 24, 2019 at 2:46 AM Florian Weimer wrote:
* Jiangli Zhou:
[3] change: http://cr.openjdk.java.net/~jiangli/tls_size/webrev/
(contributed by Jeremy Manson)
_dl_get_tls_static_info is an
Hi Florian,
On 24/05/2019 8:13 pm, Florian Weimer wrote:
* David Holmes:
My thoughts haven't really changed since 2015 - and sadly neither has
there been any change in glibc in that time. Nor, to my recollection,
have there been any other reported issues with this.
The issue gets
Adding back hotspot-dev. I don't think Kim saw this.
David
On 30/05/2019 4:04 am, Roger Riggs wrote:
Hi Kim,
In the normal output less output is cleaner.
It would be more useful to have the Duration of the wait and end time of
the wait.
(It saves the reader doing subtraction of times).
+
Hi Roger,
I think it is important that the "best effort" be kept as per this
version. It may not be a directly testable property but it does capture
intent regarding quality-of-implementation IMO.
Thanks,
David
On 30/05/2019 5:25 am, Roger Riggs wrote:
Hi,
ok, thanks for the comments.
Hi Jiangli,
On 24/05/2019 9:21 am, Jiangli Zhou wrote:
Hi David (and others),
There was a discussion [1] (between you, Jeremy, Martin and others)
back in 2015 regarding a stack size issue caused by a glibc bug
related to TLS (Thread local storage) [2]. The issue was manifested as
a
Looks good! Thanks Daniel.
David
On 23/05/2019 7:32 pm, Daniel Fuchs wrote:
Hi,
Please find a patch below that temporarily problem lists
java/security/SecureClassLoader/DefineClass.java
on linux and windows until JDK-8224635 [1] is fixed:
8224656: Problem list
Looks good.
Thanks,
David
On 23/05/2019 12:44 pm, Henry Jen wrote:
On May 22, 2019, at 7:04 PM, David Holmes wrote:
On 23/05/2019 11:56 am, Henry Jen wrote:
Thanks for the quick review,
On May 22, 2019, at 6:34 PM, David Holmes wrote:
Hi Henry,
On 23/05/2019 11:07 am, Henry Jen wrote
On 23/05/2019 11:56 am, Henry Jen wrote:
Thanks for the quick review,
On May 22, 2019, at 6:34 PM, David Holmes wrote:
Hi Henry,
On 23/05/2019 11:07 am, Henry Jen wrote:
Hi,
Please review a webrev[1] to deprecate the -Xfuture option per CSR-8224524[2].
src/hotspot/share/Xusage.txt
Hi Henry,
On 23/05/2019 11:07 am, Henry Jen wrote:
Hi,
Please review a webrev[1] to deprecate the -Xfuture option per CSR-8224524[2].
src/hotspot/share/Xusage.txt
Ignoring the usefulness, or otherwise of this file, the entry for
Xfuture should not be deleted (that happens when an option is
Hi Alan,
This javac change should be reviewed on compiler-dev not core-libs-dev.
Thanks,
David
On 23/05/2019 10:42 am, Alan Malloy wrote:
Hello. Please review this patch to eliminate an unnecessary upcast and
method call in LambdaToMethod.
bug:
+.PP
\-Xloggc:\fIfilename\fR
.RS 4
Sets the file to which verbose GC events information should be redirected for
logging\&. The information written to this file is similar to the output of
Cheers,
Henry
On May 21, 2019, at 4:11 PM, David Holmes wrote:
Hi Henry,
On 22/05/2019 8:41 am, H
Hi Henry,
On 22/05/2019 8:41 am, Henry Jen wrote:
Hi,
Please review a trivial patch that add some hints about how to use -Xlog in
java help and man page.
diff -r cd3c74c0
src/java.base/share/classes/sun/launcher/resources/launcher.properties
---
Hi Roger,
On 16/05/2019 6:32 am, Roger Riggs wrote:
Please review a change in the synchronization during the creation of an
ObjectInputStream.
Currently, a synchronized block is used to initialize the streams filter
is read the global serial filter
which becomes a bottleneck under high
Hi Christoph,
I'm very reluctant to see changes like this that the compiler folk have
not determined are actually incorrect. That said ...
On 15/05/2019 7:03 am, Langer, Christoph wrote:
Thanks Daniel.
Can anybody help reviewing the changes to:
Hi Bob,
This fix seems quite reasonable.
Thanks,
David
On 8/05/2019 6:25 am, Bob Vandette wrote:
Please review this simple fix for a TestCgroupMetrics.java test failure.
--- a/src/java.base/linux/classes/jdk/internal/platform/cgroupv1/SubSystem.java
+++
Hi Martin,
On 30/04/2019 4:00 am, Martin Buchholz wrote:
https://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/overview.html
8222930: ConcurrentSkipListMap.clone() shares size variable between
original and clone
On 26/04/2019 7:25 pm, Alan Bateman wrote:
On 26/04/2019 06:32, David Holmes wrote:
I pushed this today based on Dan and Robbin's reviews, but realized
just after the act that I should have waited for any feedback from
core-libs - apologies about that. If there are concerns I will roll
I pushed this today based on Dan and Robbin's reviews, but realized just
after the act that I should have waited for any feedback from core-libs
- apologies about that. If there are concerns I will roll it back.
Thanks,
David
-
On 26/04/2019 2:57 pm, David Holmes wrote:
Thanks Dan
ker);
_parker = NULL;
to do "delete _parker" instead.
I'll file a RFE for that.
Thanks,
David
Thanks, Robbin
On 4/24/19 9:12 AM, David Holmes wrote:
Bug: https://bugs.openjdk.java.net/browse/JDK-8222518
webrev: http://cr.openjdk.java.net/~dholmes/8222518/webrev/
The original i
Thanks Dan! Extraneous ; culled.
David
On 25/04/2019 1:16 am, Daniel D. Daugherty wrote:
On 4/24/19 3:12 AM, David Holmes wrote:
Bug: https://bugs.openjdk.java.net/browse/JDK-8222518
webrev: http://cr.openjdk.java.net/~dholmes/8222518/webrev/
src/hotspot/share/classfile/javaClasses.cpp
Bug: https://bugs.openjdk.java.net/browse/JDK-8222518
webrev: http://cr.openjdk.java.net/~dholmes/8222518/webrev/
The original implementation of Unsafe.unpark simply extracted the
JavaThread reference from the java.lang.Thread oop and if non-null
extracted the Parker instance from it and
the class got loaded "for free". The reproducer
test certainly applies to 13 (it's a valid check) but you can also eyeball the classes
loaded and see the effect.
On 4/22/19, 11:42 PM, "Alan Bateman" wrote:
On 22/04/2019 23:11, David Holmes wrote:
> Hi Ryan,
&g
PS. Given you have implemented this in the VM you're asking for a review
on the wrong mailing list.
David
On 23/04/2019 7:04 am, Sciampacone, Ryan wrote:
Bug: https://bugs.openjdk.java.net/browse/JDK-8194653
Webrev: http://cr.openjdk.java.net/~phh/8194653/webrev.00/
Eliminates a race
Hi Ryan,
On 23/04/2019 7:04 am, Sciampacone, Ryan wrote:
Bug: https://bugs.openjdk.java.net/browse/JDK-8194653
Webrev: http://cr.openjdk.java.net/~phh/8194653/webrev.00/
Why does this need to be pushed to the VM? Why not do the
pre-loading/initializing at the Java level?
Cheers,
David
Hi Severin,
I took a look at this (again**) and although I'm not at all familiar
with the actual cgroup facilities the changes seem reasonable in that
they only look for a hierarchical memory limit if the initial limit is
"unlimited".
So you can add me as a reviewer.
Thanks,
David
** I
Thanks Patrick! Changes pushed.
David
On 16/04/2019 8:44 pm, Patrick Zhang OS wrote:
Done. http://cr.openjdk.java.net/~qpzhang/8222334/webrev.05
Regards
Patrick
-Original Message-
From: David Holmes
Sent: Tuesday, April 16, 2019 6:34 PM
To: Patrick Zhang OS
Cc: core-libs-dev
copyright years. Also instead of this comment:
It can verify the issue fixed in 8222334.
Just add 8222334 to the @bug line.
Thanks,
David
Regards
Patrick
-Original Message-
From: core-libs-dev On Behalf Of
Patrick Zhang OS
Sent: Tuesday, April 16, 2019 4:23 PM
To: David Holmes
Cc: core
Patrick,
Sorry should have picked up on this earlier. Can you please update the
following two tests to add a test for '0' as appropriate:
./jdk/tools/launcher/TooSmallStackSize.java
./hotspot/jtreg/runtime/Thread/TooSmallStackSize.java
Thanks,
David
On 16/04/2019 5:47 pm, David Holmes wrote
On 16/04/2019 5:40 pm, Alan Bateman wrote:
On 15/04/2019 08:48, David Holmes wrote:
On 15/04/2019 5:34 pm, Patrick Zhang OS wrote:
Removed it.
http://cr.openjdk.java.net/~qpzhang/8222334/webrev.03/jdk.changeset
By the way, could you please sponsor to push it once approved? thanks
in advance
Hi Michael,
Re-directing to core-libs-dev and hotspot-gc-dev.
Thanks,
David
On 16/04/2019 12:14 pm, Michael Pollmeier wrote:
Quoting
https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/lang/ref/SoftReference.html
All soft references to softly-reachable objects are guaranteed
;-) )
Cheers,
David
Regards
Patrick
-Original Message-
From: David Holmes
Sent: Monday, April 15, 2019 2:33 PM
To: Patrick Zhang OS ; core-libs-dev
Subject: Re: RFR: 8222334: java -Xss0 triggers StackOverflowError
Hi Patrick,
On 15/04/2019 3:42 pm, Patrick Zhang OS wrote:
Hi David
indows" might ambiguously mean "GetDefaultJavaVMInitArgs returns 0 for windows
only" or "only windows supports 0". I updated it as "for example, Windows"
http://cr.openjdk.java.net/~qpzhang/8222334/webrev.02/
Regards
Patrick
-Original Message-
From: Da
t affected by -XX:ThreadStackSize=n as that only gets processed when
the JVM is actually loaded.
Thanks,
David
On 12/04/2019 6:11 pm, David Holmes wrote:
Hi Patrick,
First apologies that it took me so long to get my head around this. :)
Let me summarise the problem as I see it.
The launcher
opped and bcc'ed jdk-dev and jdk-updates-dev.
Regards
Patrick
-Original Message-
From: David Holmes
Sent: Friday, April 12, 2019 3:43 PM
To: Patrick Zhang OS ; jdk-...@openjdk.java.net
Cc: jdk-updates-...@openjdk.java.net
Subject: Re: RFR: 8222334: java -Xss0 triggers StackOverflowError
+1
Strange that an old gcc complains but the newer ones that add more and
more warnings each time, let this slip through :(
Arguably all the exit(-1) in the main method should just be return -1
instead - but that's a different matter.
Thanks,
David
On 8/04/2019 10:08 pm, Alan Bateman
\
Mandy
On 4/7/19 10:47 AM, David Holmes wrote:
Looks good.
Thanks,
David
On 7/04/2019 9:37 am, Mandy Chung wrote:
A simple test fix. The test causes the build failure.
Thanks
Mandy
diff --git
a/test/jdk/java/lang/reflect/exeCallerAccessTest/exeCallerAccessTest.c b/test/jdk/java/lang/reflect
Looks good.
Thanks,
David
On 7/04/2019 9:37 am, Mandy Chung wrote:
A simple test fix. The test causes the build failure.
Thanks
Mandy
diff --git
a/test/jdk/java/lang/reflect/exeCallerAccessTest/exeCallerAccessTest.c
b/test/jdk/java/lang/reflect/exeCallerAccessTest/exeCallerAccessTest.c
Hi Andrew,
This all looks good to me - thanks for making the changes.
Two nits:
- BE was barely acceptable when used like a local variable, but now I
think BIG_ENDIAN would be better.
- If you don't use static import you can name the UnsafeConstants fields
the obvious way without clashing
Hi Kusti,
The folks on swing-dev or awt-dev are probably the ones most likely to
be able to assist.
Cheers,
David
On 4/04/2019 3:51 pm, Kustaa Nyholm wrote:
Hi,
I've got an application where zooming with the scroll wheel on the mouse will
also center the mouse on the screen (well window
Follow up ...
On 1/04/2019 2:27 pm, David Holmes wrote:
Hi Andrew,
On 29/03/2019 8:40 pm, Andrew Dinn wrote:
Hi David,
Thanks very much for reviewing this patch.
On 29/03/2019 01:25, David Holmes wrote:
This seems fine in general but I have a few queries on some details:
src/hotspot/share
Hi Andrew,
On 29/03/2019 8:40 pm, Andrew Dinn wrote:
Hi David,
Thanks very much for reviewing this patch.
On 29/03/2019 01:25, David Holmes wrote:
This seems fine in general but I have a few queries on some details:
src/hotspot/share/classfile/javaClasses.hpp
f(java_lang_Thread
Hi Andrew,
This seems fine in general but I have a few queries on some details:
src/hotspot/share/classfile/javaClasses.hpp
f(java_lang_Thread) \
+ f(jdk_internal_misc_UnsafeConstants) \
f(java_lang_ThreadGroup) \
Is there a reason this needs to be shoved in there? Similarly with
need
to set a reasonable initial locale as part of the test setup. Many of
the hotspot tests check actual and expected output and we, in general,
have no idea what kinds of output may be subject to locale specific changes.
Cheers,
David
Naoto
On 3/27/19 10:47 PM, David Holmes wrote:
Hi Jing
Hi Jing,
On 28/03/2019 3:22 pm, Jing Tian wrote:
Hi,
When I am doing the 'make test'.If the local LANG is set as
'zh_CN.UTF-8', Test cases will have a lot of error messages.
==
Test summary
==
TEST
Hi Mandy,
This sounds quite reasonable to me. If there is no calling context then
only public entities of publicly accessible packages should be
accessible. JNI itself does not apply access checks so JNI code should
be using direct field access, and not core reflection, if it needs to
bypass
On 26/03/2019 11:56 pm, Aleksey Shipilev wrote:
On 3/26/19 2:28 PM, Alan Bateman wrote:
Also, are we not doing "[TESTBUG]" prefixes in
synopsis anymore? I see you changed it in JIRA.
The "testbug" label is used to tag test only issues, encoding in the bug
description/commit message
isn't
://bugs.openjdk.java.net/browse/JDK-8154236
https://bugs.openjdk.java.net/browse/JDK-8174865
https://bugs.openjdk.java.net/browse/JDK-8174864
though I'm not clear if your testcase falls under the same
categorization as above.
David
-
On 26/03/2019 2:08 pm, David Holmes wrote:
On 26/03/2019 2:03 pm, seth
is test loads a nested type into a different classloader to its
enclosing type
and:
> it is a requirement that all nest members be defined in the same
> package - which implies the same classloader
On Mon, Mar 25, 2019 at 11:40 PM David Holmes <mailto:david.hol...@oracle.com>> wrote:
myCodeClass = Class.forName(
"test.SerializedLambdaTest",
true,
myCl
);
Runnable myCode = (Runnable) myCodeClass.newInstance();
myCode.run();
}
}
On Mon, Mar 25, 2019 at 10:34 PM David Holmes <mailto:david.h
ned in the same
package - which implies the same classloader.
David
On Mon, Mar 25, 2019 at 9:34 PM David Holmes <mailto:david.hol...@oracle.com>> wrote:
Hi Seth,
On 26/03/2019 11:22 am, seth lytle wrote:
> if a lambda is a field and captures `this`, and it's deseri
Hi Seth,
On 26/03/2019 11:22 am, seth lytle wrote:
if a lambda is a field and captures `this`, and it's deserialized into a
new class loader, it throws a ClassCastException.
Not sure I follow. If you load a class into a different classloader then
you get a different type. It might appear
Hi Thomas,
A few queries, comments and concerns ...
On 25/03/2019 6:58 am, Thomas Stüfe wrote:
Hi all,
After a long time I tried to build a Windows 32bit VM (VS2017) and failed;
I'm somewhat surprised as I thought someone was actively doing Windows
32-bit builds out there, plus there are
On 15/03/2019 5:03 pm, Ivan Gerasimov wrote:
Thank you David!
On 3/14/19 11:01 PM, David Holmes wrote:
Hi Ivan,
On 15/03/2019 12:02 pm, Ivan Gerasimov wrote:
Hi David!
On 3/14/19 5:28 PM, David Holmes wrote:
Hi Ivan,
On 15/03/2019 5:49 am, Ivan Gerasimov wrote:
Hello!
The default
Hi Ivan,
On 15/03/2019 11:42 am, Ivan Gerasimov wrote:
Thank you David!
On 3/14/19 4:48 PM, David Holmes wrote:
Hi Ivan,
This is an "ancient" bug that you are fixing. I don't think it is valid.
On 15/03/2019 3:29 am, Ivan Gerasimov wrote:
Hello!
Not all the man pages agree
Hi Ivan,
On 15/03/2019 12:02 pm, Ivan Gerasimov wrote:
Hi David!
On 3/14/19 5:28 PM, David Holmes wrote:
Hi Ivan,
On 15/03/2019 5:49 am, Ivan Gerasimov wrote:
Hello!
The default implementation of Process.waitFor(long, TimeUnit) does
not check if the process has exited after the last
On 2/21/19 11:53 AM, Igor Ignatyev wrote:
On Feb 21, 2019, at 12:11 AM, David Holmes <mailto:david.hol...@oracle.com>> wrote:
Hi Igor,
On 21/02/2019 3:19 pm, Igor Ignatyev wrote:
http://cr.openjdk.java.net/~iignatyev//8219139/webrev.00/index.html
40 lines changed: 17 ins; 2 del; 2
601 - 700 of 2723 matches
Mail list logo
