On 30/10/2019 2:26 am, Alan Bateman wrote:
On 23/10/2019 08:25, Alan Bateman wrote:
Thread::countStackFrames has been deprecated for 20+ years and has
been marked for-removal since Java SE 9. I'd like to remove it for
Java SE 14. It's was never a well-defined method and I've been unable
to
LGTM.
Thanks,
David
On 30/10/2019 1:04 am, Alexey Ivanov wrote:
Hi David, Christoph,
Thank you for your reviews.
On 29/10/2019 07:49, David Holmes wrote:
Shall I remove one of them? The one in jvm.h because it's unused?
Yes please remove the unused one in jvm.h.
The updated webrev:
Hi Doug,
Your proposed patch wasn't quite right. I made some adjustments but I'm
still having issues with the test,
HotSpotMethodSubstitutionTest.testThreadSubstitutions, as I don't see
how to make the test execution conditional on the VM config.
Updated webrev:
Hi Remi,
On 30/10/2019 7:38 am, Remi Forax wrote:
Hi David,
in java.lang.Thread interrupt0 should be renamed to setInterruptEvent, because
what it does now
There is only an "interrupt event" on Windows. What interrupt0 does is
issue all the necessary unparks so that blocked threads will
Thanks for the review Dan!
Fixed the nit in thread.c
Thanks,
David
On 30/10/2019 6:51 am, Daniel D. Daugherty wrote:
On 10/29/19 3:42 AM, David Holmes wrote:
Bug: https://bugs.openjdk.java.net/browse/JDK-8229516
CSR: https://bugs.openjdk.java.net/browse/JDK-8232676 (already approved)
webrev:
On 30/10/2019 4:05 am, serguei.spit...@oracle.com wrote:
Hi David,
The fix looks good to me.
Thanks Serguei!
David
I did not pay much attention to the Graal related changes though.
The test coverage for Serviceability is complete.
Running java/lang/instrument tests is not necessary.
Nice catch!
Thank you so much, Mandy.
On 2019/10/30 上午1:19, Mandy Chung wrote:
Hi Jie,
This looks good but I ran into test/jdk/tools/jlink/BasicTest failure
with OOME in some system configuration. I made a minor fix to the
cleanup of the configuration collections after the plugin
There are still ongoing discussions (as comments on
https://bugs.openjdk.java.net/browse/JDK-8232806) as to whether the performance
implications and loss of reference equality caused by this change are
acceptable for the GraalVM Native Image.
I would suggest to hold off merging this change
Hi David,
in java.lang.Thread interrupt0 should be renamed to setInterruptEvent, because
what it does now
and I don't really understand the comment in interrupted(), if a thread is
interrupted by two other threads calling interrupt(), you will loose an
interrupt anyway.
Rémi
- Mail
On 10/29/19 12:26 PM, Alan Bateman wrote:
On 23/10/2019 08:25, Alan Bateman wrote:
Thread::countStackFrames has been deprecated for 20+ years and has
been marked for-removal since Java SE 9. I'd like to remove it for
Java SE 14. It's was never a well-defined method and I've been unable
to
On 10/29/19 3:42 AM, David Holmes wrote:
Bug: https://bugs.openjdk.java.net/browse/JDK-8229516
CSR: https://bugs.openjdk.java.net/browse/JDK-8232676 (already approved)
webrev: http://cr.openjdk.java.net/~dholmes/8229516/webrev/
make/hotspot/symbols/symbols-unix
No comments.
For tracing classes that fail to load:
Currently, if a delegated class loader can't find a class, if will throw
ClassNotFoundException in its loadClass() method. So if we run with
-Xlog:exceptions, we may get lots of CNFEs for classes that are
eventually found. This doesn't happen with the
On Tue, Oct 29, 2019 at 1:12 PM Rob Spoor wrote:
>
> I agree. There is no reason to use == instead of equals. Not for
> readability, because it will most likely confuse people who will come
> asking why you're not using equals. Not for performance, because since
> at least Java 7 String.equals
On 28/10/2019 21:34, Florian Weimer wrote:
* Сергей Цыпанов:
Hello,
current implementation of e.g. String.toUpperCase() returns the object
it was called on in case all code points are in upper case.
E.g. this test
@Test
public void upperCase() {
String str = "AZ";//
On 10/29/19 9:26 AM, Alan Bateman wrote:
On 23/10/2019 08:25, Alan Bateman wrote:
Thread::countStackFrames has been deprecated for 20+ years and has
been marked for-removal since Java SE 9. I'd like to remove it for
Java SE 14. It's was never a well-defined method and I've been unable
to
Since nothing seems to have moved, here's the familiar monthly reminder ;-)
Greetings
Raffaello
On 2019-08-30 10:47, Raffaello Giulietti wrote:
Hi,
just a gentle reminder for a RFR of [1] (see [5] for the original request).
An efficient implementation can be found on [2] and in Brian
Hi Adam,
It'd be useful to provide a few typical scenarios that customers run into.
That would give better understanding on the problem "hard to diagnose
why a given class was not loaded" and help the consideration on
alternatives. The debug output could produce lots of trace output but
Thanks, Sato-san.
There is no special meaning to the word "until now".
I rewrote charset related testcases, then I found this issue.
I read "Frequently Asked Questions about the CSR" [1],
I tried "Create CSR" operation, but I could not determine it worked or
not...
(Select "Create CSR" from
On 25/10/2019 19:42, Lance Andersen wrote:
I have updated the patch per your suggestion.
The updated webrev can be found at:
http://cr.openjdk.java.net/~lancea/8231451/webrev.02/index.html
This version looks good.
-Alan
Hi Serban,
Looks like a regression from the fix for
https://bugs.openjdk.java.net/browse/JDK-8223325.
I'v created https://bugs.openjdk.java.net/browse/JDK-8233138 to track this.
- Alexey
On 10/29/2019 12:50 PM, Serban Iordache wrote:
Issue on Windows 10, with jpackage build 14-jpackage+1-64
Hi David,
The fix looks good to me.
I did not pay much attention to the Graal related changes though.
The test coverage for Serviceability is complete.
Running java/lang/instrument tests is not necessary.
Thanks,
Serguei
On 10/29/19 00:42, David Holmes wrote:
Bug:
http://cr.openjdk.java.net/~almatvee/8232186/webrev.03/test/jdk/tools/jpackage/share/AdditionalLaunchersTest.java.sdiff.html:
To disable running the test for dmg packaging, just call
packageTest.excludeTypes(PackageType.MAC_DMG) like this is done in
FileAssociationsTest test.
The way
On 10/15/19 2:26 AM, Alan Bateman wrote:
On 14/10/2019 23:34, Mandy Chung wrote:
MethodHandles::lookup produces a Lookup object on the caller class.
The original intention for a Lookup object whose lookup class is
always a non-array and non-primitive class.
MethodHandles::privateLookupIn
Hi Jie,
This looks good but I ran into test/jdk/tools/jlink/BasicTest failure
with OOME in some system configuration. I made a minor fix to the
cleanup of the configuration collections after the plugin executes.
// Let it go
- speciesTypes = null;
- invokerTypes =
Issue on Windows 10, with jpackage build 14-jpackage+1-64 (2019/10/28):
When using the --win-dir-chooser option, the generated MSI package is not
valid.
The error message issued by Windows Installer is:
"The installer has encountered an unexpected error installing this package.
This may indicate
Hi Vojin,
I think it would be useful to include such a test (for capturing and
non-capturing) to protect against a regression.
Thanks,
Paul.
> On Oct 29, 2019, at 3:57 AM, Vojin Jovanovic
> wrote:
>
> The only way I see to test this (without calling LMF directly) is to inspect
> the stack
Alan,
Was there a technical reason that the method was specified to fail
when called from within the same thread ? Ie, is there a race
condition or something similar that can happen, perhaps because the
JVM relocates the stack ?
On Tue, Oct 29, 2019 at 12:26 PM Alan Bateman wrote:
>
> On
Hi Richard,
Seems like `rpmbuild, --eval=%{_target_cpu}` command did two unexpected
things in addition to printing out arch value:
1. printed out `rpmbuild: no spec files given for build`
2. exited with code `1`.
What version of rpmbuild are you using?
- Alexey
On 10/29/2019 12:21 PM,
On 23/10/2019 08:25, Alan Bateman wrote:
Thread::countStackFrames has been deprecated for 20+ years and has
been marked for-removal since Java SE 9. I'd like to remove it for
Java SE 14. It's was never a well-defined method and I've been unable
to find anything that uses it. The StackWalker
Just upgraded to the latest 14-jpackage+1-64 and my rpm building script
is failing, here's the end of the --verbose output:
Running [rpmbuild, --eval=%{_target_cpu}]
rpmbuild: no spec files given for build
x86_64
java.io.IOException: Command [rpmbuild, --eval=%{_target_cpu}] exited
with 1 code
Looks good to me.
Remi
On October 28, 2019 10:29:58 PM UTC, mark.reinh...@oracle.com wrote:
>2019/10/28 11:10:25 -0700, vojin.jovano...@oracle.com:
>> This email proposes a change to the LambdaMetaFactory that allows to
>> disable eager initialization (with Unsafe) of generated lambdas. ...
>>
Thanks Alan,
I'll push this after running through jdk-submit. I'm preparing another patch
for some further cleanup regarding canonicalize. But it won't get rid of the
call from JPLIS.
Best regards
Christoph
> -Original Message-
> From: Alan Bateman
> Sent: Dienstag, 29. Oktober 2019
Hi David, Christoph,
Thank you for your reviews.
On 29/10/2019 07:49, David Holmes wrote:
Shall I remove one of them? The one in jvm.h because it's unused?
Yes please remove the unused one in jvm.h.
The updated webrev:
http://cr.openjdk.java.net/~aivanov/8232724/webrev.01/
--
Regards,
On 23/10/2019 14:26, Langer, Christoph wrote:
Hi Alan,
I have this on my list to look at. I think we'll need to figure out a
path to separate the usages (the JPLIS agent usage is technical debt, we
should have addressed that issue a long time ago).
I agree that it's a good thing to explore
Hey All,
To restart (and re-centre) the chat on this:
The issue I'm trying to solve is that it's hard to determine why a given
class was not loaded by OpenJDK.
The solution I proposed was additional (optional) debug output from the
different classloaders.
This way we can find out:
- Whether
The next EA build of JPackage is available at https://jdk.java.net/jpackage/
Build 14-jpackage+1-64 (2019/10/28) contains the following changes
(since Build Build 14-jpackage+1-49 on 2019/10/02)
JDK-8231910 Expose the APPDIR variable to applications that use jpackage
JDK-8232646
The only way I see to test this (without calling LMF directly) is to inspect
the stack trace created in a static initialiser of a lambda super-type. The
stack trace should not contain LMF when
-Djdk.internal.lambda.disableEagerInitialization=true. Let me know if this kind
of a test reasonable;
> On 29 Oct 2019, at 10:12, David Holmes wrote:
>
> Hi Doug,
>
> Thanks for taking a look so quickly! :)
>
> On 29/10/2019 6:55 pm, Doug Simon wrote:
>> Hi David,
>> Since Graal needs to work against multiple JVMCI versions (and VM
>> versions!), the Graal changes should only disable the
Hi Doug,
Thanks for taking a look so quickly! :)
On 29/10/2019 6:55 pm, Doug Simon wrote:
Hi David,
Since Graal needs to work against multiple JVMCI versions (and VM versions!),
the Graal changes should only disable the intrinsic when the relevant VM config
is missing:
So to be clear I
Hi David,
Since Graal needs to work against multiple JVMCI versions (and VM versions!),
the Graal changes should only disable the intrinsic when the relevant VM config
is missing:
diff --git
a/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java
Hi Alexey,
On 29/10/2019 4:46 am, Alexey Ivanov wrote:
Hello,
Please review the following fix which removes indirection in calling
JNU_NewStringPlatform via NewStringPlatform.
bug: https://bugs.openjdk.java.net/browse/JDK-8232724
webrev:
Bug: https://bugs.openjdk.java.net/browse/JDK-8229516
CSR: https://bugs.openjdk.java.net/browse/JDK-8232676 (already approved)
webrev: http://cr.openjdk.java.net/~dholmes/8229516/webrev/
This cross-cuts core-libs, hotspot-runtime and the JIT compilers, but
only in small pieces each. There is
42 matches
Mail list logo
