Re: RFR: 8284161: Implementation of Virtual Threads (Preview) [v8]

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

Re: RFR: 8177107: Reduce memory footprint of java.lang.reflect.Constructor/Method

On Mon, 4 Apr 2022 09:58:35 GMT, Claes Redestad wrote: > As an alternative to #7667 I took a look at injecting an empty class array > from the VM. Turns out we already do this for exception types - see > https://github.com/openjdk/jdk/blob/master/src/hotspot/share/oops/method.cpp#L918 > - and

Re: RFR: 8275731: CDS archived enums objects are recreated at runtime [v3]

On Wed, 19 Jan 2022 05:44:10 GMT, Ioi Lam wrote: >> src/hotspot/share/cds/heapShared.cpp line 433: >> >>> 431: oop mirror = k->java_mirror(); >>> 432: int i = 0; >>> 433: for (JavaFieldStream fs(k); !fs.done(); fs.next()) { >> >> This seems like it should also use

Re: RFR: 8275731: CDS archived enums objects are recreated at runtime [v6]

On Wed, 23 Feb 2022 04:15:28 GMT, Ioi Lam wrote: >> **Background:** >> >> In the Java Language, Enums can be tested for equality, so the constants in >> an Enum type must be unique. Javac compiles an enum declaration like this: >> >> >> public enum Day { SUNDAY, MONDAY ... } >> >> >> to

Re: RFR: 8275731: CDS archived enums objects are recreated at runtime [v3]

On Sat, 11 Dec 2021 01:55:50 GMT, Ioi Lam wrote: >> **Background:** >> >> In the Java Language, Enums can be tested for equality, so the constants in >> an Enum type must be unique. Javac compiles an enum declaration like this: >> >> >> public enum Day { SUNDAY, MONDAY ... } >> >> >> to

Re: RFR: 8266936: Add a finalization JFR event [v17]

On Fri, 15 Oct 2021 09:27:54 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

Re: RFR: 8266936: Add a finalization JFR event [v16]

On Wed, 13 Oct 2021 18:03:25 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

Re: RFR: 8266936: Add a finalization JFR event [v10]

On Thu, 14 Oct 2021 21:58:42 GMT, Coleen Phillimore wrote: >> "Since you remove entries on unloading, I don't see any reason to have any >> concurrent cleanup." >> Thank you, that is true. The only concurrent work required will be to grow >> the table. >>

Re: RFR: 8266936: Add a finalization JFR event [v10]

On Mon, 13 Sep 2021 10:54:18 GMT, Markus Grönlund wrote: >> src/hotspot/share/services/finalizerService.cpp line 44: >> >>> 42: _ik(ik), >>> 43: _objects_on_heap(0), >>> 44: _total_finalizers_run(0) {} >> >> Is this hashtable for every InstanceKlass that defines a finalizer? How

Re: RFR: 8266936: Add a finalization JFR event [v11]

On Mon, 13 Sep 2021 17:12:49 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

Re: RFR: 8266936: Add a finalization JFR event [v11]

On Mon, 13 Sep 2021 17:12:49 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

Re: RFR: 8266936: Add a finalization JFR event [v10]

On Fri, 27 Aug 2021 15:23:35 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

Re: RFR: JDK-8256844: Make NMT late-initializable [v2]

On Sun, 1 Aug 2021 08:17:08 GMT, Thomas Stuefe wrote: >> Short: this patch makes NMT available in custom-launcher scenarios and >> during gtests. It simplifies NMT initialization. It adds a lot of >> NMT-specific testing, cleans them up and makes them sideeffect-free. >> >> - >> >>

Re: RFR: JDK-8256844: Make NMT late-initializable [v2]

On Fri, 30 Jul 2021 09:32:22 GMT, Thomas Stuefe wrote: >> [Not a review, just a drive-by comment.] This is a normal and idiomatic >> overload on the const-ness of `this`. > > To expand on Kim's answer. This is a way to solve const/nonconst problems > like

Re: RFR: JDK-8256844: Make NMT late-initializable [v2]

On Fri, 30 Jul 2021 09:44:57 GMT, Thomas Stuefe wrote: > Is that a real-life problem? Are there cases where the launcher would want to > live on if the JVM failed to load? There are a lot of other reasons why the launcher couldn't live on if the JVM fails to load. This was only one of them.

Re: RFR: JDK-8256844: Make NMT late-initializable

On Thu, 22 Jul 2021 14:58:47 GMT, Thomas Stuefe wrote: > Short: this patch makes NMT available in custom-launcher scenarios and during > gtests. It simplifies NMT initialization. It adds a lot of NMT-specific > testing, cleans them up and makes them sideeffect-free. > > - > > NMT

Re: RFR: 8254598: StringDedupTable should use OopStorage

On Fri, 23 Apr 2021 19:48:47 GMT, Kim Barrett wrote: > Please review this change to the String Deduplication facility. It is being > changed to use OopStorage to hold weak references to relevant objects, > rather than bespoke data structures requiring dedicated processing phases by > supporting

Re: RFR: 8264805: Remove the experimental Ahead-of-Time Compiler [v4]

On Thu, 8 Apr 2021 20:28:27 GMT, Igor Ignatyev wrote: >> Vladimir Kozlov has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Remove exports from Graal module to jdk.aot > > Test changes look good to me. There's a comment above void

Re: RFR: 8264805: Remove the experimental Ahead-of-Time Compiler [v4]

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

Re: RFR: 8264805: Remove the experimental Ahead-of-Time Compiler

On Thu, 8 Apr 2021 15:23:52 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 execution >

Re: RFR: 8263412: ClassFileInstaller can't be used by classes outside of default package

On Thu, 11 Mar 2021 05:47:00 GMT, Igor Ignatyev wrote: > Hi all, > > could you please review the patch which moves `ClassFileInstaller` class to > `jdk.test.lib.helpers` package? > to reduce changes in the tests, `ClassFileInstaller` in the default package > is kept w/ just `main` method

Re: RFR: 8261031: Move some ClassLoader name checking to native/VM [v3]

On Thu, 11 Feb 2021 12:44:54 GMT, Claes Redestad wrote: >> This patch moves some sanity checking done in ClassLoader.java to the >> corresponding endpoints in native or VM code. > > Claes Redestad has updated the pull request incrementally with one additional > commit since the last revision:

Re: RFR: 8195744: Avoid calling ClassLoader.checkPackageAccess if security manager is not installed [v3]

On Fri, 5 Feb 2021 03:00:05 GMT, David Holmes wrote: >> Coleen Phillimore has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Fix comments and copyright. > > src/hotspot/share/classfile/javaClasses.cpp l

Re: RFR: 8195744: Avoid calling ClassLoader.checkPackageAccess if security manager is not installed [v3]

s > option. > > Tested with tier1 hotspot, jdk and langtools. > and tier2-6. Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: Fix comments and copyright. - Changes: - all: https://git.openjdk.java.ne

Re: RFR: 8195744: Avoid calling ClassLoader.checkPackageAccess if security manager is not installed [v2]

On Fri, 5 Feb 2021 01:45:58 GMT, David Holmes wrote: >> Coleen Phillimore has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Add comment and read NEVER field from System > > src/hotspot/share/classfile/dict

Re: RFR: 8195744: Avoid calling ClassLoader.checkPackageAccess if security manager is not installed [v2]

s > option. > > Tested with tier1 hotspot, jdk and langtools. > and tier2-6. Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: Add comment and read NEVER field from System - Changes: - all: https://git.

Re: RFR: 8261031: Move some ClassLoader name checking to native/VM

On Wed, 3 Feb 2021 19:49:30 GMT, Mandy Chung wrote: >> This patch moves some sanity checking done in ClassLoader.java to the >> corresponding endpoints in native or VM code. > > src/java.base/share/native/libjava/ClassLoader.c line 291: > >> 289: } >> 290: // disallow slashes in input,

Re: RFR: 8261031: Move some ClassLoader name checking to native/VM

On Thu, 4 Feb 2021 13:11:47 GMT, Coleen Phillimore wrote: >> src/java.base/share/native/libjava/ClassLoader.c line 291: >> >>> 289: } >>> 290: // disallow slashes in input, change '.' to '/' >>> 291: if (verifyFixClassname(clname)) { &

Re: RFR: 8261031: Move some ClassLoader name checking to native/VM

On Wed, 3 Feb 2021 12:21:30 GMT, Claes Redestad wrote: > This patch moves some sanity checking done in ClassLoader.java to the > corresponding endpoints in native or VM code. Changes requested by coleenp (Reviewer). src/java.base/share/classes/java/lang/ClassLoader.java line 1259: > 1257:

Re: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v2]

On Tue, 26 Jan 2021 11:31:18 GMT, Anton Kozlov wrote: >> This could be a follow-up RFE. > > I assume a WXVerifier class that tracks W^X mode in debug mode and does > nothing in release mode. I've considered to do this, it's relates to small > inefficiencies, while this patch brings zero

Re: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v2]

On Mon, 25 Jan 2021 15:01:25 GMT, Anton Kozlov wrote: >> src/hotspot/share/jfr/instrumentation/jfrJvmtiAgent.cpp line 87: >> >>> 85: JavaThread* jt = JavaThread::thread_from_jni_environment(jni_env); >>> 86: DEBUG_ONLY(JfrJavaSupport::check_java_thread_in_native(jt));; >>> 87:

Re: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v2]

On Mon, 25 Jan 2021 14:40:09 GMT, Coleen Phillimore wrote: >> Anton Kozlov has updated the pull request incrementally with two additional >> commits since the last revision: >> >> - Address feedback for signature generators >> - Enable -Wformat-nonliteral back

Re: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v2]

On Sun, 24 Jan 2021 15:32:59 GMT, Anton Kozlov wrote: >> Please review the implementation of JEP 391: macOS/AArch64 Port. >> >> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and >> windows/aarch64. >> >> Major changes are in: >> * src/hotspot/cpu/aarch64: support of

Re: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v2]

On Sun, 24 Jan 2021 15:32:59 GMT, Anton Kozlov wrote: >> Please review the implementation of JEP 391: macOS/AArch64 Port. >> >> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and >> windows/aarch64. >> >> Major changes are in: >> * src/hotspot/cpu/aarch64: support of

RFR: 8257726: Make -XX:+StressLdcRewrite option a diagnostic option

See bug for details. Tested: $ java -XX:+StressLdcRewrite -version Error: VM option 'StressLdcRewrite' is diagnostic and must be enabled via -XX:+UnlockDiagnosticVMOptions. Error: The unlock option must precede 'StressLdcRewrite'. Error: Could not create the Java Virtual Machine. Error: A fatal

Re: RFR: 8254231: Implementation of Foreign Linker API (Incubator) [v18]

On Tue, 10 Nov 2020 14:16:22 GMT, Maurizio Cimadamore wrote: >> This patch contains the changes associated with the first incubation round >> of the foreign linker access API incubation >> (see JEP 389 [1]). This work is meant to sit on top of the foreign memory >> access support (see JEP 393

Re: RFR: 8254231: Implementation of Foreign Linker API (Incubator) [v15]

On Mon, 9 Nov 2020 16:31:23 GMT, Jorn Vernee wrote: >> src/hotspot/cpu/aarch64/universalUpcallHandler_aarch64.cpp line 121: >> >>> 119: upcall_info.upcall_method.name, >>> upcall_info.upcall_method.sig, >>> 120: , thread); >>> 121: } >> >>

Re: RFR: 8254231: Implementation of Foreign Linker API (Incubator) [v15]

On Thu, 5 Nov 2020 21:26:16 GMT, Maurizio Cimadamore wrote: >> This patch contains the changes associated with the first incubation round >> of the foreign linker access API incubation >> (see JEP 389 [1]). This work is meant to sit on top of the foreign memory >> access support (see JEP 393

Re: RFR: 8254231: Implementation of Foreign Linker API (Incubator) [v15]

On Fri, 6 Nov 2020 21:47:42 GMT, Coleen Phillimore wrote: >> Maurizio Cimadamore has updated the pull request with a new target base due >> to a merge or a rebase. The pull request now contains 64 commits: >> >> - Merge branch '8254162' into 8254231_linker >>

Re: RFR: 8254231: Implementation of Foreign Linker API (Incubator) [v4]

On Thu, 15 Oct 2020 17:08:28 GMT, Maurizio Cimadamore wrote: >> This patch contains the changes associated with the first incubation round >> of the foreign linker access API incubation >> (see JEP 389 [1]). This work is meant to sit on top of the foreign memory >> access support (see JEP 393

Re: RFR: 8246774: Record Classes (final) implementation [v3]

On Wed, 23 Sep 2020 03:34:29 GMT, Vicente Romero wrote: >> Co-authored-by: Vicente Romero >> Co-authored-by: Harold Seigel >> Co-authored-by: Jonathan Gibbons >> Co-authored-by: Brian Goetz >> Co-authored-by: Maurizio Cimadamore >> Co-authored-by: Joe Darcy >> Co-authored-by: Chris Hegarty

Re: RFR: 8241390: 'Deadlock' with VM_RedefineClasses::lock_classes()

On Tue, 15 Sep 2020 16:43:01 GMT, Daniil Titov wrote: > The change fixes a 'deadlock' situation in VM_RedefineClasses::lock_classes() > when the current thread is in the middle > of redefining the same class. The change is based on the fix [1] suggested in > the Jira issue [2] comment. > [1]

Re: RFR: 8244778: Archive full module graph in CDS [v3]

On Wed, 9 Sep 2020 18:46:33 GMT, Lois Foltan wrote: >> Ioi Lam has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Feedback from Coleen > > Thanks Ioi for addressing my review comments. Overall, looks great! Ok thanks! So many emails

Re: RFR: 8244778: Archive full module graph in CDS

On Tue, 8 Sep 2020 15:59:33 GMT, Ioi Lam wrote: > This is the same patch as > [8244778-archive-full-module-graph.v03](http://cr.openjdk.java.net/~iklam/jdk16/8244778-archive-full-module-graph.v03/) > published in >

Re: Review Request: 8238358: Implementation of JEP 371: Hidden Classes

On 3/30/20 5:54 AM, David Holmes wrote: Sorry to jump in on this but it caught my eye though I may be missing a larger context ... On 30/03/2020 7:30 pm, serguei.spit...@oracle.com wrote: Hi Mandy, I have just one comment so far.

Re: RFR: JEP 359: Records (Preview) (full code)

(resending to all the lists) Hi, I've looked at the hotspot code again, and it looks good.  Nice work, Harold and Vincente! Coleen On 11/27/19 11:37 PM, Vicente Romero wrote: Hi, Please review the code for the records feature at [1]. This webrev includes all: APIs, runtime, compiler,

Re: RFR JDK-8193325: StackFrameInfo::getByteCodeIndex returns wrong value if bci > 32767

On 8/14/19 3:42 PM, Mandy Chung wrote: I have further discussion with Coleen and walkthrough the vframe implementation.  Here is what we confirm and agree. vframeStream::bci might return an invalid bci whereas javaVFrame::bci returns a valid bci (compiledVFrame::bci adjusts invalid bci to

Re: RFR JDK-8193325: StackFrameInfo::getByteCodeIndex returns wrong value if bci > 32767

Hi, I saw my name in this thread and had a discussion with Mandy. I don't like that the VM and JDK having this special coordinated dance of +1/-1, and the reason for this is to differentiate the value of 0 in StackFrame meaning either uninitialized or invalid.  If through some race, an

Re: RFR(L): 8218628: Add detailed message to NullPointerException describing what is null.

a Core Libs ; hotspot-runtime-...@openjdk.java.net; Coleen Phillimore (coleen.phillim...@oracle.com) Subject: RE: RFR(L): 8218628: Add detailed message to NullPointerException describing what is null. Hi Goetz, I've played with the messages a little bit and they generally look good. But I've

Re: JEP 306

This seems like better mailing list for this inquiry. Coleen On 5/9/18 6:43 AM, A Z wrote: Does anyone know what is going to be decided around full target status of JEP 306? I have been recommended to this list for the sake of this question. ? http://openjdk.java.net/jeps/306

Re: RFR 8184289: Obsolete -XX:+UnsyncloadClass and -XX:+MustCallLoadClassInternal options

On 2/12/18 1:54 AM, David Holmes wrote: Hi Harold, Adding core-libs-dev so they are aware of the ClassLoader change. On 10/02/2018 5:44 AM, harold seigel wrote: Hi David, Thanks for reviewing this. Please see updated webrev:

Re: RFR (S) 8173715: Remove FlatProfiler

Besides the launcher.properties files of other languages, there was a bsd file in the jdk that had -Xprof: bsd/doc/man/java.1:\-Xprof Does that have to be updated.  Otherwise I think it looks good. thanks, Coleen On 8/16/17 1:48 PM, Gerard Ziemski wrote: hi all, (this is jdk part of the

Re: RFR 8156073 : 2-slot LiveStackFrame locals (long and double) are incorrect (updated)

Thanks Brent, looks good! Coleen On 1/31/17 1:19 PM, Brent Christian wrote: On 1/30/17 5:52 PM, Coleen Phillimore wrote: in http://cr.openjdk.java.net/~bchristi/8156073/webrev.03/hotspot/src/share/vm/prims/stackwalk.cpp.html 287 int mode = 0; 288 if (_jvf->is_interpreted_fr

Re: RFR 8156073 : 2-slot LiveStackFrame locals (long and double) are incorrect (updated)

Added core-libs-dev. Coleen On 1/30/17 5:52 PM, Coleen Phillimore wrote: Hi Brent, I think this looks more conservative and better. in http://cr.openjdk.java.net/~bchristi/8156073/webrev.03/hotspot/src/share/vm/prims/stackwalk.cpp.html 287 int mode = 0; 288 if (_jvf

Re: RFR: 8163014: Mysterious/wrong value for "long" frame local variable on 64-bit

On 9/7/16 9:09 AM, Max Ockner wrote: Does the stackwalk API have access to the type of variable at each slot? Where is this information stored? My operating assumption was that it did not have this information, and therefore needed to read the garbage slot. This is true. The StackWalk API

Re: JDK 9 RFR of JDK-8162539: Test fails because it expects a blank between method signature and throws exception

are weighted toward toGenericString since the tests were added for that functionality. HTH, Yes, thanks. Glad there's a test now. Coleen -Joe On 7/26/2016 12:23 PM, Coleen Phillimore wrote: Thank you for fixing this so quickly. This looks good but I have a question about: http

Re: JDK 9 RFR of JDK-8162539: Test fails because it expects a blank between method signature and throws exception

Thank you for fixing this so quickly. This looks good but I have a question about: http://cr.openjdk.java.net/~darcy/8162539.0/test/java/lang/reflect/Constructor/GenericStringTest.java.udiff.html @ExpectedGenericString( "protected TestClass1(S,T) throws java.lang.Exception") +

Re: Advice on cross-repo change: JDK-8160997

Hi, You can send this to core-libs-dev@openjdk.java.net and hotspot-...@openjdk.java.net The sponsor should be from the runtime group. I don't know this well enough, so I'm going to point you to Dan (and Jerry, except Jerry's not a committer). To run JPRT don't forget to use -testset

Re: RFR 8153123 : Streamline StackWalker code

ml Thank you for making this change. It looks good! I've reviewed this. Coleen -Brent On 04/05/2016 11:25 AM, Coleen Phillimore wrote: A correction below. On 4/5/16 1:29 PM, Coleen Phillimore wrote: Also meant to include core-libs-dev in the email. Thanks, Coleen On 4/5/16 1:27

Re: RFR 8153123 : Streamline StackWalker code

A correction below. On 4/5/16 1:29 PM, Coleen Phillimore wrote: Also meant to include core-libs-dev in the email. Thanks, Coleen On 4/5/16 1:27 PM, Coleen Phillimore wrote: Hi, I've reviewed the hotspot changes and some of the jdk changes. This looks really good. One comment about

Re: RFR 8153123 : Streamline StackWalker code

Also meant to include core-libs-dev in the email. Thanks, Coleen On 4/5/16 1:27 PM, Coleen Phillimore wrote: Hi, I've reviewed the hotspot changes and some of the jdk changes. This looks really good. One comment about the jvm function names: I think FillInStackTraceElement is too close

Re: RFR 8150778: Reduce Throwable.getStackTrace() calls to the JVM

On 3/11/16 6:36 PM, Aleksey Shipilev wrote: On 03/08/2016 01:55 AM, Coleen Phillimore wrote: Aside: see the last experiment, avoiding StringTable::intern (shows in profiles a lot!) trims down construction costs down even further. I'd think that is a worthwhile improvement to consider. Hm

Re: RFR 8150778: Reduce Throwable.getStackTrace() calls to the JVM

Hi Aleksey, This is an interesting experiment. On 3/4/16 8:28 AM, Aleksey Shipilev wrote: On 03/02/2016 11:21 PM, Aleksey Shipilev wrote: On 03/02/2016 10:57 PM, Coleen Phillimore wrote: On 3/2/16 1:58 PM, Aleksey Shipilev wrote: Is there an underlying reason why we can't return the pre

Re: RFR 8150778: Reduce Throwable.getStackTrace() calls to the JVM

Mandy, thank you for reviewing this. On 3/2/16 9:18 PM, Mandy Chung wrote: On Mar 2, 2016, at 4:03 PM, Coleen Phillimore <coleen.phillim...@oracle.com> wrote: Freshly tested changes with jck tests, with missing checks and other changes to use the depth field, as pointed out by A

Re: RFR 8150778: Reduce Throwable.getStackTrace() calls to the JVM

On 3/2/16 3:21 PM, Aleksey Shipilev wrote: On 03/02/2016 10:57 PM, Coleen Phillimore wrote: On 3/2/16 1:58 PM, Aleksey Shipilev wrote: Is there an underlying reason why we can't return the pre-filled StackTraceElements[] array from the JVM_GetStackTraceElements to begin with? This will avoid

Re: RFR 8150778: Reduce Throwable.getStackTrace() calls to the JVM

On 3/2/16 1:58 PM, Aleksey Shipilev wrote: Hi Coleen, On 03/02/2016 09:44 PM, Coleen Phillimore wrote: Summary: replace JVM_GetStackTraceDepth and JVM_GetStackTraceElement, with JVM_GetStackTraceElements that gets all the elements in the StackTraceElement[] These improvements were found

Re: ClassFileTransformer does not apply to anonymous classes

On 1/22/16 4:11 AM, Andrew Dinn wrote: On 21/01/16 22:14, Rafael Winterhalter wrote: Hi Andrew, if there is any update on the matter, I would of course love to hear about it. Unfortunately, I never received an answer to my question, but maybe I picked the wrong list. Thank you for your

Re: RFR [9] 8141615: Add new public methods to sun.reflect.ConstantPool

/jvms-4.html#jvms-4.4-140). Thanks -Konstantin On 11/27/2015 07:48 PM, Konstantin Shefov wrote: Coleen, Thanks for review On 11/24/2015 07:33 PM, Coleen Phillimore wrote: I have a couple preliminary comments. First, there are no tests added with all this new functionality. Tests should be adde

Re: RFR JDK-8141491: Unaligned memory access in Bits.c

Sending to core-libs mailing list. On 11/25/15 2:19 PM, Alexander Smundak wrote: Please take a look at http://cr.openjdk.java.net/~asmundak/8141491/jdk/webrev.00 that fixes the problem. It utilizes the ability of some (GCC and Clang) to declare data alignment explicitly. I have verified it

Re: Code Review for JEP 259: Stack-Walking API

On 11/18/15 5:06 PM, Mandy Chung wrote: On Nov 18, 2015, at 1:01 PM, Coleen Phillimore <coleen.phillim...@oracle.com> wrote: One of the things that I'm struggling with is that StackFrameInfo contains both the collected information from walking the stack frames, method id, bci,

Re: Code Review for JEP 259: Stack-Walking API

One of the things that I'm struggling with is that StackFrameInfo contains both the collected information from walking the stack frames, method id, bci, mirror, version and cpref, and the digested information: interned string for class name, method name, line number and source file name.

Re: RFR (M) 8140802 - Clean up and refactor of class loading code for CDS

On 11/2/15 1:57 PM, Ioi Lam wrote: On 10/30/15 1:31 PM, Coleen Phillimore wrote: On 10/30/15 4:18 PM, Karen Kinnear wrote: Coleen, Question for you below please ... On Oct 30, 2015, at 3:44 PM, Coleen Phillimore <coleen.phillim...@oracle.com> wrote: Hi Ioi, This is a manageabl

Re: RFR (M) 8140802 - Clean up and refactor of class loading code for CDS

On 10/30/15 4:18 PM, Karen Kinnear wrote: Coleen, Question for you below please ... On Oct 30, 2015, at 3:44 PM, Coleen Phillimore <coleen.phillim...@oracle.com> wrote: Hi Ioi, This is a manageable code change. http://cr.openjdk.java.net/~iklam/8140802-cds-refactoring.v01/hotsp

Re: RFR (M) 8140802 - Clean up and refactor of class loading code for CDS

Hi Ioi, This is a manageable code change. http://cr.openjdk.java.net/~iklam/8140802-cds-refactoring.v01/hotspot/src/share/vm/classfile/classListParser.hpp.html You forward declare Klass* but don't use it in this header file. Also can you add a comment to #endif to say what it's endifing. ie.

Re: Please review: 8066185: VM crashed with SIGSEGV VirtualMemoryTracker::add_reserved_region

Kumar, This looks good to me. I didn't review all the changes in the test very carefully, so someone else should vouch for that. Thank you for fixing this! Coleen On 2/23/15, 9:09 PM, David Holmes wrote: Hi Kumar, On 24/02/2015 8:14 AM, Kumar Srinivasan wrote: Hello, Please review the

Re: RFR: 8042418: Remove JVM_FindClassFromClassLoader

Thanks, David. Coleen On 12/13/14, 5:47 PM, David Holmes wrote: Looks okay to me Coleen. Thanks, David On 13/12/2014 6:59 AM, Coleen Phillimore wrote: Summary: The function has been replaced so is no longer used. This function was replaced with a better FindClassFromCaller function

RFR: 8042418: Remove JVM_FindClassFromClassLoader

Summary: The function has been replaced so is no longer used. This function was replaced with a better FindClassFromCaller function. The compatibility request (CCC) was approved. open webrev at http://cr.openjdk.java.net/~coleenp/8042418_jdk/ open webrev at

Re: [8u40] RFR 6642881: Improve performance of Class.getClassLoader()

Thanks David! Coleen On 9/7/14, 9:38 PM, David Holmes wrote: Looks okay to me. David On 6/09/2014 5:55 AM, Coleen Phillimore wrote: Summary: Add classLoader to java/lang/Class instance for fast access This is a backport request for 8u40. This change has been in the jdk9 code for 3 months

Re: [8u40] RFR 6642881: Improve performance of Class.getClassLoader()

Thanks, Mandy! Coleen On 9/8/14, 6:59 PM, Mandy Chung wrote: Thumbs up. Mandy On 9/5/2014 12:55 PM, Coleen Phillimore wrote: Summary: Add classLoader to java/lang/Class instance for fast access This is a backport request for 8u40. This change has been in the jdk9 code for 3 months

[8u40] RFR 6642881: Improve performance of Class.getClassLoader()

Summary: Add classLoader to java/lang/Class instance for fast access This is a backport request for 8u40. This change has been in the jdk9 code for 3 months without any problems. The JDK changes hg imported cleanly. The Hotspot change needed a hand merge for create_mirror call in

Re: RFR 8047737 Move array component mirror to instance of java/lang/Class

On 7/2/14, 8:41 AM, Peter Levart wrote: On 07/02/2014 02:38 PM, Peter Levart wrote: On 07/02/2014 02:22 PM, Peter Levart wrote: On 07/02/2014 08:26 AM, Mandy Chung wrote: On 6/30/2014 9:51 PM, Christian Thalinger wrote: On Jun 30, 2014, at 5:50 PM, Coleen Phillimore coleen.phillim

Re: RFR 8047737 Move array component mirror to instance of java/lang/Class

this in the JVM to disable these optimizations if they are ever implemented. Thank you for reviewing the code. Coleen On 7/2/14, 2:26 AM, Mandy Chung wrote: On 6/30/2014 9:51 PM, Christian Thalinger wrote: On Jun 30, 2014, at 5:50 PM, Coleen Phillimore coleen.phillim...@oracle.com wrote: On 6/30/14

Re: RFR 8047737 Move array component mirror to instance of java/lang/Class

Thank you! Coleen On 7/1/14, 12:51 AM, Christian Thalinger wrote: On Jun 30, 2014, at 5:50 PM, Coleen Phillimore coleen.phillim...@oracle.com wrote: On 6/30/14, 3:50 PM, Christian Thalinger wrote: private Class(ClassLoader loader) { // Initialize final field for classLoader

Re: RFR 6642881: Improve performance of Class.getClassLoader()

Hi Peter, On 6/24/14, 4:23 AM, Peter Levart wrote: On 06/24/2014 01:45 AM, Coleen Phillimore wrote: Please review a change to the JDK code for adding classLoader field to the instances of java/lang/Class. This change restricts reflection from changing access to the classLoader field

Re: RFR 6642881: Improve performance of Class.getClassLoader()

Coleen, It seems that there's still a reference to JVM_GetClassLoader in file jdk/src/share/native/common/check_code.c. The code looks like dead code, but it would be nice to clean it up. Thanks, Fred On 06/24/2014 01:45 AM, Coleen Phillimore wrote: Please review a change to the JDK code

Re: RFR 6642881: Improve performance of Class.getClassLoader()

of the macro BROKEN_JAVAC. I update the copyrights when I commit the changeset. http://cr.openjdk.java.net/~coleenp/6642881_jdk_5/ Thanks! Coleen Thanks, Fred On 06/24/2014 01:45 AM, Coleen Phillimore wrote: Please review a change to the JDK code for adding classLoader field to the instances

Re: RFR 6642881: Improve performance of Class.getClassLoader()

, at 20:46, Coleen Phillimore coleen.phillim...@oracle.com wrote: On 6/17/14, 12:38 AM, Joel Borggrén-Franck wrote: Have you considered hiding the Class.classLoader field from reflection? I’m not sure it is necessary but I’m not to keen on the idea of people poking at this field with Unsafe

Re: RFR 6642881: Improve performance of Class.getClassLoader()

On 6/23/14, 9:36 PM, Mandy Chung wrote: Coleen, On 6/23/2014 4:45 PM, Coleen Phillimore wrote: Please review a change to the JDK code for adding classLoader field to the instances of java/lang/Class. This change restricts reflection from changing access to the classLoader field

Re: RFR (S) 8025238: nsk/jvmti/scenarios/bcinstr/BI04/bi04t002 crashed with SIGSEGV

to figure out why that is, does someone else know why? Thanks! Jeremy On Thu, Oct 3, 2013 at 11:02 AM, Coleen Phillimore coleen.phillim...@oracle.com mailto:coleen.phillim...@oracle.com wrote: Summary: Redefined class in stack trace may not be found by method_idnum so handle null

Re: RFR (M) 8023041: The CDS classlist needs to be updated for JDK 8

Thanks, Alan. I've looked at this and reviewed it too, so I'll push it. Thanks Harold for sending it out. Coleen On 11/14/2013 10:03 AM, harold seigel wrote: Hi Alan, Thank you for the review. Harold On 11/13/2013 10:04 AM, Alan Bateman wrote: On 13/11/2013 14:55, harold seigel wrote:

hg: jdk8/tl/jdk: 2 new changesets

Changeset: 59f46f135584 Author:hseigel Date: 2013-11-14 10:44 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/59f46f135584 8023041: The CDS classlist needs to be updated for JDK 8 Summary: Generate new classlists from JDK 8 classes Reviewed-by: alanb, coleenp, hseigel

hg: jdk8/tl/jdk: 8025238: nsk/jvmti/scenarios/bcinstr/BI04/bi04t002 crashed with SIGSEGV

Changeset: f581b72e3715 Author:sla Date: 2013-10-21 23:32 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f581b72e3715 8025238: nsk/jvmti/scenarios/bcinstr/BI04/bi04t002 crashed with SIGSEGV Summary: Redefined class in stack trace may not be found by method_idnum so handle

RFR (S) 8025238: nsk/jvmti/scenarios/bcinstr/BI04/bi04t002 crashed with SIGSEGV

Summary: Redefined class in stack trace may not be found by method_idnum so handle null. This is a simple change. I had another change to save the method name (as u2) in the backtrace, but it's not worth the extra footprint in backtraces for this rare case. The root problem was that we

hg: jdk8/tl/jdk: 2 new changesets

Changeset: cb74d71fd02f Author:hseigel Date: 2013-08-13 10:56 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cb74d71fd02f 8022259: MakeClasslist is buggy and its README is out of date. Summary: Fixed bug in FOR loop and updated comments and README Reviewed-by: dholmes, alanb

hg: jdk8/tl/jdk: 7124706: enable RetransformBigClass.sh test when fix for 8013063 is promoted

Changeset: f18337edd201 Author:coleenp Date: 2013-06-07 22:15 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f18337edd201 7124706: enable RetransformBigClass.sh test when fix for 8013063 is promoted Summary: The code for this test is fixed now and integrated to TL repo and

RFR: 7124706: enable RetransformBigClass.sh test when fix for 8013063 is promoted

Summary: The code for this test is fixed now and integrated to TL repo and it passes now. open webrev at http://cr.openjdk.java.net/~coleenp/7124706_jdk/ bug link at http://bugs.sun.com/view_bug.do?bug_id=7124706_jdk Thanks, Coleen

hg: jdk8/tl/jdk: 2 new changesets

Changeset: 7f9f69729934 Author:coleenp Date: 2013-04-17 12:50 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7f9f69729934 8009531: Crash when redefining class with annotated method Summary: Add code to annotated methods and command line flags to the tests to verify bug

Re: RFR (S) 8009531: Crash when redefining class with annotated method

On 04/14/2013 11:29 PM, David Holmes wrote: On 15/04/2013 1:08 PM, David Holmes wrote: Hi Coleen, On 13/04/2013 3:45 AM, Coleen Phillimore wrote: Summary: Add annotations to the tests to verify bug above open webrev at http://cr.openjdk.java.net/~coleenp/8009531_jdk/ bug link at http

RFR (S) 8009531: Crash when redefining class with annotated method

Summary: Add annotations to the tests to verify bug above open webrev at http://cr.openjdk.java.net/~coleenp/8009531_jdk/ bug link at http://bugs.sun.com/view_bug.do?bug_id=8009531_jdk The Hotspot change is in tl repository now. Also, this has been reviewed by the hotspot group. Thanks,

Re: RFR (S) 8009531: Crash when redefining class with annotated method

Can you reply to me as well as the mailing list since I'm not on this mailing list? thanks, Coleen Original Message Subject: RFR (S) 8009531: Crash when redefining class with annotated method Date: Fri, 12 Apr 2013 13:45:30 -0400 From: Coleen Phillimore

  1   2   >