On Tue, 31 May 2022 15:39:39 GMT, Alan Bateman wrote:
>> This patch adds an alternative virtual thread implementation where each
>> virtual thread is backed by an OS thread. It doesn't scale but it can be
>> used by ports that don't have continuations support in the VM. Aside from
>>
On Mon, 23 May 2022 07:28:41 GMT, Yi Yang wrote:
> It seems that calculation of
> MemoryMXBean.getNonHeapMemoryUsage(jmm_GetMemoryUsage) is wrong.
>
> Currently,
> `NonHeapUsage=CodeCache+Metaspace(ClassTypeSpace+NonClassTypeSpace)+CompressedClassSpace(ClassTypeSpace)`
>
> ==> CodeHeap
On Thu, 28 Apr 2022 18:24:33 GMT, Andrey Turbanov wrote:
>> Joe Darcy has updated the pull request with a new target base due to a merge
>> or a rebase. The incremental webrev excludes the unrelated changes brought
>> in by the merge/rebase. The pull request contains seven additional commits
On Thu, 28 Apr 2022 16:58:40 GMT, Joe Darcy wrote:
>> To enable more complete doclint checking (courtesy @jonathan-gibbons),
>> please review this PR to add type-level @param tags where they are missing.
>>
>> To the maintainers of java.util.concurrent, those changes could be separated
>> out
On Wed, 27 Apr 2022 14:24:20 GMT, Alan Bateman wrote:
>> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which
>> JDK version to target.
>>
>> We will refresh this PR periodically to pick up changes and fixes from the
>> loom repo.
>>
>> Most of the new mechanisms in
On Wed, 27 Apr 2022 18:13:15 GMT, Paul Sandoz wrote:
>> src/java.base/share/classes/java/lang/PinnedThreadPrinter.java line 58:
>>
>>> 56:
>>> 57: // maps a class to the hashes of stack traces pinned by that code
>>> in that class
>>> 58: private static final Map, Hashes>
On Wed, 27 Apr 2022 14:24:20 GMT, Alan Bateman wrote:
>> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which
>> JDK version to target.
>>
>> We will refresh this PR periodically to pick up changes and fixes from the
>> loom repo.
>>
>> Most of the new mechanisms in
On Wed, 27 Apr 2022 14:24:20 GMT, Alan Bateman wrote:
>> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which
>> JDK version to target.
>>
>> We will refresh this PR periodically to pick up changes and fixes from the
>> loom repo.
>>
>> Most of the new mechanisms in
On Wed, 27 Apr 2022 14:24:20 GMT, Alan Bateman wrote:
>> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which
>> JDK version to target.
>>
>> We will refresh this PR periodically to pick up changes and fixes from the
>> loom repo.
>>
>> Most of the new mechanisms in
On Tue, 19 Apr 2022 10:49:14 GMT, Alan Bateman wrote:
>> src/java.base/share/classes/java/lang/ref/ReferenceQueue.java line 61:
>>
>>> 59: private final Condition notEmpty;
>>> 60:
>>> 61: void signal() { notEmpty.signalAll(); }
>>
>> `signal()`, `await()` and `await(long)` methods
On Sun, 17 Apr 2022 16:03:30 GMT, Alan Bateman wrote:
>> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which
>> JDK version to target.
>>
>> We will refresh this PR periodically to pick up changes and fixes from the
>> loom repo.
>>
>> Most of the new mechanisms in
On Sun, 17 Apr 2022 16:03:30 GMT, Alan Bateman wrote:
>> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which
>> JDK version to target.
>>
>> We will refresh this PR periodically to pick up changes and fixes from the
>> loom repo.
>>
>> Most of the new mechanisms in
On Sun, 17 Apr 2022 16:03:30 GMT, Alan Bateman wrote:
>> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which
>> JDK version to target.
>>
>> We will refresh this PR periodically to pick up changes and fixes from the
>> loom repo.
>>
>> Most of the new mechanisms in
On Tue, 22 Mar 2022 21:19:20 GMT, Kevin Walls wrote:
> There are no uses of jdk/internal/agent/spi/AgentProvider, since the SNMP
> agent was removed ( 8071367 ): this class should be removed. It is not a
> public interface.
>
> Remove
>
On Mon, 21 Mar 2022 20:19:03 GMT, Kevin Walls wrote:
>> Removing permission checks which, in the presence of a Security Manager,
>> would check for a RuntimePermission "className.subclass". This was to
>> prevent subclassing these classes, but is no longer necessary with strong
>>
On Fri, 18 Mar 2022 17:49:05 GMT, Kevin Walls wrote:
>> Removing permission checks which, in the presence of a Security Manager,
>> would check for a RuntimePermission "className.subclass". This was to
>> prevent subclassing these classes, but is no longer necessary with strong
>>
On Mon, 10 Jan 2022 11:17:12 GMT, Kevin Walls wrote:
>> Remove the use of Security Manager from jstatd.
>> Add use of an ObjectInputFilter to restrict RMI.
>>
>> Also we can undo the property-setting Launcher.gmk change from: 8279007:
>> jstatd fails to start because SecurityManager is
On Mon, 10 Jan 2022 11:17:12 GMT, Kevin Walls wrote:
>> Remove the use of Security Manager from jstatd.
>> Add use of an ObjectInputFilter to restrict RMI.
>>
>> Also we can undo the property-setting Launcher.gmk change from: 8279007:
>> jstatd fails to start because SecurityManager is
On Wed, 22 Dec 2021 18:14:43 GMT, Kevin Walls wrote:
> Remove the use of Security Manager from jstatd.
> Add use of an ObjectInputFilter to restrict RMI.
>
> Also we can undo the property-setting Launcher.gmk change from: 8279007:
> jstatd fails to start because SecurityManager is disabled
>
On Fri, 19 Nov 2021 18:15:46 GMT, Brent Christian wrote:
>> src/java.base/share/classes/java/lang/Object.java line 481:
>>
>>> 479: * system resources or to perform other cleanup.
>>> 480: *
>>> 481: * When running in a Java virtual machine in which finalization
>>> has been
>>
On Thu, 18 Nov 2021 21:51:30 GMT, Brent Christian wrote:
> Here are the code changes for the "Deprecate finalizers in the standard Java
> API" portion of JEP 421 ("Deprecate Finalization for Removal") for code
> review.
>
> This change makes the indicated deprecations, and updates the API
On Thu, 18 Nov 2021 21:51:30 GMT, Brent Christian wrote:
> Here are the code changes for the "Deprecate finalizers in the standard Java
> API" portion of JEP 421 ("Deprecate Finalization for Removal") for code
> review.
>
> This change makes the indicated deprecations, and updates the API
On Thu, 18 Nov 2021 04:03:06 GMT, Leonid Mesnik wrote:
>> The nsk.share.jdi.TestClass1 is used via reflection. The reflective call
>> creates MethodHandle and one more reference to TestClass1. So the number of
>> expected references should be incremented. Thanks to @plummercj and
>>
On Tue, 16 Nov 2021 02:45:13 GMT, Leonid Mesnik wrote:
>> The nsk.share.jdi.TestClass1 is used via reflection. The reflective call
>> creates MethodHandle and one more reference to TestClass1. So the number of
>> expected references should be incremented. Thanks to @plummercj and
>>
On Tue, 16 Nov 2021 02:45:13 GMT, Leonid Mesnik wrote:
>> The nsk.share.jdi.TestClass1 is used via reflection. The reflective call
>> creates MethodHandle and one more reference to TestClass1. So the number of
>> expected references should be incremented. Thanks to @plummercj and
>>
On Tue, 16 Nov 2021 02:45:13 GMT, Leonid Mesnik wrote:
>> The nsk.share.jdi.TestClass1 is used via reflection. The reflective call
>> creates MethodHandle and one more reference to TestClass1. So the number of
>> expected references should be incremented. Thanks to @plummercj and
>>
On Thu, 4 Nov 2021 13:25:14 GMT, Thomas Stuefe wrote:
> `VM.metaspace`, `VM.classloaders` and `VM.class_hierarchy` all print out
> reflection invocation targets for delegating reflection class loaders. Post
> JEP 416 we don't use DelegatingClassLoaders anymore.
>
> This patch removes the
On Thu, 28 Oct 2021 13:03:56 GMT, Severin Gehwolf wrote:
> Please review this change to remove some API which no longer works as
> expected as recent OCI runtimes start to drop support for `--kernel-memory`
> switch. See the bug for references. This part of the API is not present in
> hotspot
On Sat, 16 Oct 2021 20:32:43 GMT, Andrey Turbanov wrote:
> Non-static classes hold a link to their parent classes, which can be avoided.
Marked as reviewed by mchung (Reviewer).
-
PR: https://git.openjdk.java.net/jdk/pull/5974
On Fri, 15 Oct 2021 06:43:13 GMT, Andrey Turbanov wrote:
> Non-static classes hold a link to their parent classes, which can be avoided.
Marked as reviewed by mchung (Reviewer).
-
PR: https://git.openjdk.java.net/jdk/pull/5962
java.lang.management, com.sun.management API and JVM TI only report Java
threads. The internal GC threads are not Java threads and are
filtered. There is no supported API to get the safepoint time and
GC/compiler thread CPU time.
I also think that the internal thread CPU time/usage are
On Wed, 29 Sep 2021 17:46:46 GMT, Aleksey Shipilev wrote:
> Fails like this:
>
>
> $ CONF=linux-x86_64-server-fastdebug make run-test
> TEST=java/lang/management/ManagementFactory/MXBeanException.java
> TEST_VM_OPTS="-XX:+UseShenandoahGC"
>
> ...
>
> java.lang.NullPointerException: Cannot
On Wed, 29 Sep 2021 17:56:00 GMT, Aleksey Shipilev wrote:
> Currently it fails with:
>
>
> $ CONF=linux-x86_64-server-fastdebug make run-test
> TEST=java/lang/management/MemoryMXBean/MemoryTest.java
>
> STDERR:
> java.lang.RuntimeException: TEST FAILED: Number of heap pools = 1 but
>
On Sat, 25 Sep 2021 14:22:28 GMT, Markus Grönlund wrote:
>> Greetings,
>>
>> Object.finalize() was deprecated in JDK9. There is an ongoing effort to
>> replace and mitigate Object.finalize() uses in the JDK libraries; please see
>> https://bugs.openjdk.java.net/browse/JDK-8253568 for more
On Fri, 24 Sep 2021 09:27:02 GMT, Markus Grönlund wrote:
>> Greetings,
>>
>> Object.finalize() was deprecated in JDK9. There is an ongoing effort to
>> replace and mitigate Object.finalize() uses in the JDK libraries; please see
>> https://bugs.openjdk.java.net/browse/JDK-8253568 for more
On Mon, 12 Jul 2021 05:21:34 GMT, Yi Yang wrote:
> I'm not familiar with the review process of core-lib group. Is it sufficient
> for merging with one approval? Should I have more reviews for this? 樂
It depends on the change.
For this patch, it's good to get another reviewer to look through
On Thu, 8 Jul 2021 03:12:24 GMT, Yi Yang wrote:
>> After JDK-8265518(#3615), it's possible to replace all variants of
>> checkIndex by
>> Objects.checkIndex/Objects.checkFromToIndex/Objects.checkFromIndexSize in
>> the whole JDK codebase.
>
> Yi Yang has refreshed the contents of this pull
On Wed, 7 Jul 2021 16:22:25 GMT, Mandy Chung wrote:
>> Hi Mandy, thanks for reviewing this.
>>
>>> I suggest to separate the client changes (both src and test) in a separate
>>> PR for the client review.
>>
>> Does "client changes" means
On Wed, 7 Jul 2021 02:10:10 GMT, Yi Yang wrote:
> Does "client changes" means changes involving src/java.desktop and
> test/java/awt?
src/java.desktop, test/java/awt, and test/javax/imageio
-
PR: https://git.openjdk.java.net/jdk/pull/4507
On Wed, 23 Jun 2021 03:54:55 GMT, Yi Yang wrote:
>> After JDK-8265518(#3615), it's possible to replace all variants of
>> checkIndex by
>> Objects.checkIndex/Objects.checkFromToIndex/Objects.checkFromIndexSize in
>> the whole JDK codebase.
>
> Yi Yang has updated the pull request
On Mon, 5 Jul 2021 06:29:58 GMT, David Holmes wrote:
>> @dholmes-ora @AlanBateman @PaulSandoz do you have any comments on the latest
>> version? Thanks.
>
> @kelthuzadx I did not see any response to my query about the change in
> initialization (not load) order. I also remain concerned about
On Mon, 7 Jun 2021 21:46:52 GMT, Chris Plummer wrote:
>> The URL for the users guide, referenced from both the About dialog and from
>> the "Help -> Online Users Guide" menu item, has not functioned for a few
>> releases due the restructuring of the JDK online docs. This PR fixes the
>> URL.
Try "using_jconsole"
Mandy
On 6/7/21 2:09 PM, Chris Plummer wrote:
On Mon, 7 Jun 2021 19:36:23 GMT, Chris Plummer wrote:
The URL for the users guide, referenced from both the About dialog and from the "Help
-> Online Users Guide" menu item, has not functioned for a few releases due the
On Mon, 7 Jun 2021 19:36:23 GMT, Chris Plummer wrote:
> The URL for the users guide, referenced from both the About dialog and from
> the "Help -> Online Users Guide" menu item, has not functioned for a few
> releases due the restructuring of the JDK online docs. This PR fixes the URL.
> Note
On Mon, 17 May 2021 18:23:41 GMT, Weijun Wang wrote:
> Please review this implementation of [JEP
> 411](https://openjdk.java.net/jeps/411).
>
> The code change is divided into 3 commits. Please review them one by one.
>
> 1.
>
On Mon, 17 May 2021 17:51:36 GMT, Weijun Wang wrote:
> Please review the test changes for [JEP
> 411](https://openjdk.java.net/jeps/411).
>
> With JEP 411 and the default value of `-Djava.security.manager` becoming
> `disallow`, tests calling `System.setSecurityManager()` need
>
for checking. I thought I remembered something like this
somewhere, but it may be that you already fixed such tests when you
did hidden classes? In any case, seems like we're all good now.
Cheers,
-Brian
On 5/13/2021 2:50 PM, Mandy Chung wrote:
I did a search on java.base and the tests on `String
I did a search on java.base and the tests on `String::indexOf` and
`String::contains` of a slash and don't spot any such test. The JDK has
no use of VM anonymous class. If the test is trying to determine if
it's lambda proxy class, it should be converted to call
`Class::isHidden` but
On Wed, 12 May 2021 16:10:24 GMT, Harold Seigel wrote:
>> Please review this large change to remove Unsafe::defineAnonymousClass().
>> The change removes dAC relevant code and changes a lot of tests. Many of
>> the changed tests need renaming. I hope to do this in a follow up RFE.
>> Some
On Tue, 11 May 2021 14:13:49 GMT, Harold Seigel wrote:
>> Please review this large change to remove Unsafe::defineAnonymousClass().
>> The change removes dAC relevant code and changes a lot of tests. Many of
>> the changed tests need renaming. I hope to do this in a follow up RFE.
>> Some
On Thu, 8 Apr 2021 17:24:38 GMT, Vladimir Kozlov wrote:
>> As part of [JEP 410](http://openjdk.java.net/jeps/410) remove code related
>> to Ahead-of-Time Compiler from JDK:
>>
>> - `jdk.aot` module — the `jaotc` tool
>> - `src/hotspot/share/aot` — loads AoT compiled code into VM for
On Fri, 2 Apr 2021 18:00:57 GMT, Daniel Fuchs wrote:
>> This RFE proposes to extend the MXBean framework to define a mapping to
>> records.
>>
>> The MXBean framework already defines a mapping of `CompositeType` to plain
>> java objects. Records are a natural representation of CompositeTypes.
On Wed, 31 Mar 2021 21:02:51 GMT, Daniel Fuchs wrote:
>> This RFE proposes to extend the MXBean framework to define a mapping to
>> records.
>>
>> The MXBean framework already defines a mapping of `CompositeType` to plain
>> java objects. Records are a natural representation of
On Wed, 31 Mar 2021 15:38:22 GMT, Daniel Fuchs wrote:
>> Link added. With respect to adding a section for records, it's a bit
>> difficult to separate that from the "Mapping for other types" without a lot
>> of duplication. I can add a row in the summary table, and then add a new
>> section
On Fri, 26 Mar 2021 15:15:48 GMT, Daniel Fuchs wrote:
>> This RFE proposes to extend the MXBean framework to define a mapping to
>> records.
>>
>> The MXBean framework already defines a mapping of `CompositeType` to plain
>> java objects. Records are a natural representation of
On Sat, 27 Mar 2021 01:40:17 GMT, Mandy Chung wrote:
>> Daniel Fuchs has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Fixed typo. Moved example with record after example with from method to
>> respect t
On Tue, 26 Jan 2021 19:34:35 GMT, Claes Redestad wrote:
> Simplify and desugar the static initialization of PlatformMBeanFinder.
>
> While arguably making the code easier to comprehend, this saves 5-6ms on
> startup in various applications such as the spring-petclinic.
Looks fine.
On Tue, 22 Dec 2020 22:11:19 GMT, Serguei Spitsyn wrote:
>> This change have been already reviewed by Mandy, Sundar, Alan and David.
>> Please, see the jdk 15 review thread:
>>
>> http://mail.openjdk.java.net/pipermail/serviceability-dev/2020-June/031998.html
>>
>> Now, the PR approval is
On Tue, 22 Dec 2020 05:47:19 GMT, Serguei Spitsyn wrote:
>> This change have been already reviewed by Mandy, Sundar, Alan and David.
>> Please, see the jdk 15 review thread:
>>
>> http://mail.openjdk.java.net/pipermail/serviceability-dev/2020-June/031998.html
>>
>> Now, the PR approval is
On Fri, 18 Dec 2020 12:00:48 GMT, Serguei Spitsyn wrote:
>> This change have been already reviewed by Mandy, Sundar, Alan and David.
>> Please, see the jdk 15 review thread:
>>
>> http://mail.openjdk.java.net/pipermail/serviceability-dev/2020-June/031998.html
>>
>> Now, the PR approval is
On Thu, 17 Dec 2020 04:59:17 GMT, Serguei Spitsyn wrote:
>> This change have been already reviewed by Mandy, Sundar, Alan and David.
>> Please, see the jdk 15 review thread:
>>
>> http://mail.openjdk.java.net/pipermail/serviceability-dev/2020-June/031998.html
>>
>> Now, the PR approval is
On Wed, 16 Dec 2020 08:18:49 GMT, Alan Bateman wrote:
> So PR1694 is really just about aligning the spec so that the premain method
> is public. However, it does not fix the overall accessibility issue.
OK I see that JDK-5070281 changes to allow the agent class to be non-public as
the main
On Wed, 16 Dec 2020 07:40:18 GMT, Serguei Spitsyn wrote:
>> This change have been already reviewed by Mandy, Sundar, Alan and David.
>> Please, see the jdk 15 review thread:
>>
>> http://mail.openjdk.java.net/pipermail/serviceability-dev/2020-June/031998.html
>>
>> Now, the PR approval is
On Wed, 16 Dec 2020 07:40:18 GMT, Serguei Spitsyn wrote:
>> This change have been already reviewed by Mandy, Sundar, Alan and David.
>> Please, see the jdk 15 review thread:
>>
>> http://mail.openjdk.java.net/pipermail/serviceability-dev/2020-June/031998.html
>>
>> Now, the PR approval is
On 12/15/20 5:50 PM, David Holmes wrote:
On 16/12/2020 11:35 am, Serguei Spitsyn wrote:
On Wed, 16 Dec 2020 00:50:04 GMT, David Holmes
wrote:
The agent class doesn't have to be public it just has to be accessible.
The premain method should be queried for public modifier rather than
just
On 12/14/20 2:47 PM, Serguei Spitsyn wrote:
On Mon, 14 Dec 2020 02:39:30 GMT, David Holmes wrote:
Serguei Spitsyn has updated the pull request incrementally with one additional
commit since the last revision:
added 8165276 to @bug list of impacted tests
Changes requested by dholmes
On Thu, 10 Dec 2020 00:37:14 GMT, Serguei Spitsyn wrote:
>> This change have been already reviewed by Mandy, Sundar, Alan and David.
>> Please, see the jdk 15 review thread:
>>
>> http://mail.openjdk.java.net/pipermail/serviceability-dev/2020-June/031998.html
>>
>> Now, the PR approval is
On Wed, 9 Dec 2020 06:40:25 GMT, Serguei Spitsyn wrote:
>> src/java.instrument/share/classes/sun/instrument/InstrumentationImpl.java
>> line 501:
>>
>>> 499: String msg = "method " + classname + "." + methodname + "
>>> must be declared public";
>>> 500: throw new
On Thu, 3 Dec 2020 22:54:54 GMT, Mandy Chung wrote:
> This patch replaces some uses of `Reference::get` to `Reference::refersTo` to
> avoid keeping a referent strongly reachable that could cause unnecessary
> delay in collecting such object. I only made change in some but not all
n `Reference::refersTo`.
> The remaining uses are left for the component owners to convert at
> appropriate time.
Mandy Chung has updated the pull request with a new target base due to a merge
or a rebase. The pull request now contains 15 commits:
- revise matchsKey to check equalit
On Fri, 4 Dec 2020 20:14:13 GMT, Peter Levart wrote:
>> Good point on checking k != null. A cleaner check:
>>
>> // then check for equality if the referent is not cleared
>> Object k = e.get();
>> return k != null || key.equals(k);
>
> You meant: `return k != null &&
On Fri, 4 Dec 2020 20:05:23 GMT, Kevin Rushforth wrote:
>> This patch replaces some uses of `Reference::get` to `Reference::refersTo`
>> to avoid keeping a referent strongly reachable that could cause unnecessary
>> delay in collecting such object. I only made change in some but not all
>>
On Fri, 4 Dec 2020 19:47:17 GMT, Peter Levart wrote:
>> This patch replaces some uses of `Reference::get` to `Reference::refersTo`
>> to avoid keeping a referent strongly reachable that could cause unnecessary
>> delay in collecting such object. I only made change in some but not all
>>
On Fri, 4 Dec 2020 18:12:36 GMT, Kim Barrett wrote:
>> This patch replaces some uses of `Reference::get` to `Reference::refersTo`
>> to avoid keeping a referent strongly reachable that could cause unnecessary
>> delay in collecting such object. I only made change in some but not all
>>
On Fri, 4 Dec 2020 09:19:23 GMT, Aleksey Shipilev wrote:
>> This patch replaces some uses of `Reference::get` to `Reference::refersTo`
>> to avoid keeping a referent strongly reachable that could cause unnecessary
>> delay in collecting such object. I only made change in some but not all
>>
This patch replaces some uses of `Reference::get` to `Reference::refersTo` to
avoid keeping a referent strongly reachable that could cause unnecessary delay
in collecting such object. I only made change in some but not all classes in
core libraries when working with Kim on
On Thu, 10 Sep 2020 05:25:43 GMT, Robert LU
wrote:
> When many thread try to load same class, the thread will stuck on
> `ClassLoader.loadClass`.
> At current jdk, the stacktrace by example program is:
> "Thread-1" prio=5 Id=13 BLOCKED on java.lang.String@724af044 owned by
> "Thread-0" Id=12
On Thu, 22 Oct 2020 17:16:23 GMT, Jonathan Gibbons wrote:
> The change is (just) to remove legacy usages of a JDK-private custom tag.
Marked as reviewed by mchung (Reviewer).
-
PR: https://git.openjdk.java.net/jdk/pull/814
On Thu, 24 Sep 2020 00:23:13 GMT, Mandy Chung wrote:
>> @vicente-romero-oracle I noticed that we can also remove the preview args
>> from the record serialization tests and
>> ObjectMethodsTest. I opened a PR against the branch in your fork. You should
>> be able to j
On Tue, 22 Sep 2020 09:49:12 GMT, Chris Hegarty wrote:
>> note: I have removed from the original patch the code related to
>> javax.lang.model, I will publish them in a separate PR
>
> @vicente-romero-oracle I noticed that we can also remove the preview args
> from the record serialization
On 6/27/20 12:23 AM, Alan Bateman wrote:
On 27/06/2020 01:40, serguei.spit...@oracle.com wrote:
The implementation has this order of lookup:
// The agent class must have a premain or agentmain method that
// has 1 or 2 arguments. We check in the following order:
//
On 6/24/20 12:26 PM, serguei.spit...@oracle.com wrote:
On 6/24/20 05:25, David Holmes wrote:
Ah! The test class SimpleAgent is what is not public. That seems a
bug in the test.
There are many such tests.
We can break some of the existing agents by rejecting non-public agent
classes.
I'm
Hi Serguei,
I'm glad that you have a patch for this.
On 6/23/20 7:05 PM, serguei.spit...@oracle.com wrote:
Please, review a fix for:
https://bugs.openjdk.java.net/browse/JDK-8165276
CSR draft (one CSR reviewer is needed before finalizing it):
+1
Mandy
On 6/22/20 4:55 PM, Jonathan Gibbons wrote:
Please review a small change to fix an unresolved reference in
`@throws IOException`.
The problem is that the method signature uses a fully-qualified name
for `java.io.IOException` instead of importing it. meaning that the
`@throws`
+1. Thanks for fixing this.
Mandy
On 6/18/20 8:16 PM, Jonathan Gibbons wrote:
resend, with correct subject line
On 6/18/20 8:12 PM, Jonathan Gibbons wrote:
Please review some changes to fix typos in some recent doc updates.
In two places, ${docRoot} is used instead of {@docRoot}
-- Jon
/management/package.html
Thu Jun 18 15:51:09 2020 -0700
@@ -234,7 +234,7 @@
The java.lang.management API is thread-safe.
-@see <mailto:-@see>{@linkplain javax.management JMX Specification}
+@see javax.management JMX Specification
@author Mandy Chung
@since 1.5
On 6/12/20 12:27 AM, David Holmes wrote:
No. There is no MXBeanServer.
This attempts to shed some light on everything:
https://docs.oracle.com/en/java/javase/14/docs/api/java.management/javax/management/MXBean.html
"An MXBean is a kind of MBean. An MXBean object can be registered
overwrite it
*verify_legal_class_name(class_name, CHECK);*
break;
}
Thanks, Harold
On 5/28/2020 5:12 PM, Mandy Chung wrote:
I read the JVMS but it isn't clear to me that the VM will validate
the names in `PermittedSubclasses`attribute are valid class
descriptors. I see Con
Hi Harold,
On 5/27/20 1:35 PM, Harold Seigel wrote:
Incremental webrev:
http://cr.openjdk.java.net/~hseigel/sealedClasses.8225056.incr.2/
full webrev:
http://cr.openjdk.java.net/~hseigel/sealedClasses.8225056.2/webrev/
Class.java
4406 ReflectionData rd = reflectionData();
4407
Hi Vicente,
On 5/20/20 8:40 AM, Vicente Romero wrote:
Hi David,
src/java.base/share/classes/java/lang/Class.java
There needs to be a CSR request for these changes.
yes there is one already:
https://bugs.openjdk.java.net/browse/JDK-8244556
Adding to David's comment w.r.t. @throws IAE:
On 4/20/20 1:06 PM, Chris Plummer wrote:
On 4/18/20 3:28 PM, Mandy Chung wrote:
Hi Chris, Serguei,
On 4/18/20 12:18 AM, Chris Plummer wrote:
Yes. I'd like to see all this as part of the Class/Classloading spec
in some sort of section that gives an overview of all these topics,
but mostly
Hi Chris, Serguei,
On 4/18/20 12:18 AM, Chris Plummer wrote:
Yes. I'd like to see all this as part of the Class/Classloading spec
in some sort of section that gives an overview of all these topics,
but mostly clarifies what an initiating loader is, and the (non)
relationship to hidden
On 4/18/20 12:47 AM, Chris Plummer wrote:
It's a link to
https://download.java.net/java/early_access/jdk15/docs/specs/jni/types.html#type-signatures.
This is how the current JVM TI spec defines.
Since it looks like this reference was present before your changes, I
guess it's ok to leave
On 4/17/20 3:51 PM, Chris Plummer wrote:
Hi Mandy,
Thanks for updating the svc specs. Some comments below:
In the JDWP spec update, you changed "JNI signature" to "type
signature" in one place, but left it as "JNI signature" everywhere
else. Should they all be changed?
JDWP signature
On 4/16/20 11:42 AM, serguei.spit...@oracle.com wrote:
Hi Mandy,
I have a couple of minor comments on the Serviceability spec update.
Svc spec change webrev:
http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.06-svc-spec-changes/
thanks
Mandy
[1]
https://mail.openjdk.java.net/pipermail/valhalla-dev/2020-April/007155.html
Paul.
On Apr 11, 2020, at 8:13 PM, Mandy Chung wrote:
Please review the delta
a proxy class
3. include Serguei's patch to fix JDK-8242166: regression in JDI
ClassUnload events
4. drop the uniqueness guarantee of the suffix of the hidden class's name
On 3/31/20 8:01 PM, Mandy Chung wrote:
Thanks to the review feedbacks.
Updated webrev:
http://cr.openjdk.java.net/~mchung/v
On 4/6/20 9:56 AM, serguei.spit...@oracle.com wrote:
The suggested fix is:
http://cr.openjdk.java.net/~sspitsyn/webrevs/2020/valhalla-jdi-regression-8242166.1/
This patch looks okay. I'll include in my local patch.
On 4/6/20 11:00 AM, Chris Plummer wrote:
I think that's fine but I don't
Hi Peter,
On 4/4/20 3:58 AM, Peter Levart wrote:
Here I think, you are not quite right. First I need to clarify that we
are talking about the case where the method reference in above example
is not converted to lambda by javac, so the proxy class needs to
invoke the superclass method
On 4/4/20 9:16 AM, Peter Levart wrote:
Hi Mandy,
Just another observation of the code in InnerClassLambdaMetafactory...
For the useImplMethodHandle case you generate the protectedImplMethod
static field to hold the MH and a static setter method:
mv = cw.visitMethod(ACC_PRIVATE
1 - 100 of 703 matches
Mail list logo
