On Thu, 18 Nov 2021 20:05:15 GMT, Stuart Marks wrote:
>> Pretty much what it says. The new option controls a static member in
>> InstanceKlass that's consulted to determine whether the finalization
>> machinery is activated for instances when a class is loaded. A new native
>> method is added
On Thu, 18 Nov 2021 20:13:23 GMT, Mandy Chung wrote:
>> I think this could just be `return InstanceKlass::finalization_enabled();`.
>> There is lots of code in this file and elsewhere that assumes C++ `bool`
>> converts to `jboolean` appropriately.
>
> One typical way for VM to pass the
On Thu, 18 Nov 2021 06:47:05 GMT, Aleksey Shipilev wrote:
>> Stuart Marks has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Rename InstanceKlass::finalization_enabled to is_finalization_enabled.
>> Minor cleanups.
>
>
On Sun, 17 Oct 2021 21:06:44 GMT, Andrey Turbanov wrote:
> Non-static classes hold a link to their parent classes, which can be avoided.
Marked as reviewed by rriggs (Reviewer).
-
PR: https://git.openjdk.java.net/jdk/pull/5983
On Sun, 26 Sep 2021 15:10:52 GMT, Andrey Turbanov wrote:
> In couple of classes, result part of arrays of Pattern.split is compared with
> `null`. Pattern.split (and hence String.split) never returns `null` in array
> elements. Such comparisons are redundant.
Marked as reviewed by rriggs
On Sun, 26 Sep 2021 15:10:52 GMT, Andrey Turbanov wrote:
> In couple of classes, result part of arrays of Pattern.split is compared with
> `null`. Pattern.split (and hence String.split) never returns `null` in array
> elements. Such comparisons are redundant.
Marked as reviewed by iris
On Sun, 17 Oct 2021 21:06:44 GMT, Andrey Turbanov wrote:
> Non-static classes hold a link to their parent classes, which can be avoided.
Marked as reviewed by iris (Reviewer).
-
PR: https://git.openjdk.java.net/jdk/pull/5983
> Hi all,
>
> Please review this fix for Infinite loop in ZipOutputStream.close().
> The main issue here is when ever there is an exception during close
> operations on GZip we are not setting the deflator to a finished state which
> is leading to an infinite loop when we try writing on the
case of ZipException in
ZipOutputStream.closeEntry().
Now close the deflater in ZipOutputStream.closeEntry() only in case of an
IOException and not with ZipException.
Mach5 is green :
https://mach5.us.oracle.com/mdash/jobs?search=id:rreddy-jdk-2028-1708-26358737
Thanks,
Ravi
-
PR: https://git.openjdk.java.net/jdk/pull/5522
On Thu, 18 Nov 2021 07:52:18 GMT, David Holmes wrote:
>> Yeah, "flag" is `Holder.ENABLED` here. I mean, are Java methods
>> `registerFinalizer` and `runFinalization` called only by VM? If so, can VM
>> check the whole thing on VM side, without going to Java and asking back from
>> there?
>
>
On Thu, 18 Nov 2021 06:49:03 GMT, Kim Barrett wrote:
>> src/hotspot/share/prims/jvm.cpp line 694:
>>
>>> 692:
>>> 693: JVM_ENTRY(jboolean, JVM_IsFinalizationEnabled(JNIEnv * env))
>>> 694: return InstanceKlass::finalization_enabled() ? JNI_TRUE : JNI_FALSE;
>>
>> missing indentation
>
> I
On Thu, 18 Nov 2021 12:33:06 GMT, Alan Bateman wrote:
>> The wording is adjusted accordingly. Thanks.
>
>> The wording is adjusted accordingly. Thanks.
>
> Thanks for the update. The API additions (and clarification) look good to me.
> Do you have other reviewers for the impl change and tests?
On Thu, 7 Oct 2021 18:00:33 GMT, Andrey Turbanov wrote:
> Pass cause exception as constructor parameter is shorter and easier to read.
Marked as reviewed by rriggs (Reviewer).
-
PR: https://git.openjdk.java.net/jdk/pull/5854
On Thu, 18 Nov 2021 15:05:49 GMT, Peter Levart wrote:
>> Or, you could move the static initialization block that statrts the
>> finalizer thread into the Finalizer.FinalizerThread class itself and then
>> arrange for that class to be initialized explicitly immediately after the
>> Finalizer
> Pretty much what it says. The new option controls a static member in
> InstanceKlass that's consulted to determine whether the finalization
> machinery is activated for instances when a class is loaded. A new native
> method is added so that this state can be queried from Java. This is used
On Thu, 18 Nov 2021 15:33:26 GMT, Roger Riggs wrote:
>> The ObjectInputStream.GetField.get(String name, Object val) method is
>> returning null instead of throwing an exception when the class of the object
>> is not found. The caller is not able to correctly handle the case where the
>> class
Hi Mandy,
On 19/11/2021 6:16 am, Mandy Chung wrote:
On Thu, 18 Nov 2021 06:49:03 GMT, Kim Barrett wrote:
src/hotspot/share/prims/jvm.cpp line 694:
692:
693: JVM_ENTRY(jboolean, JVM_IsFinalizationEnabled(JNIEnv * env))
694: return InstanceKlass::finalization_enabled() ? JNI_TRUE :
On Wed, 17 Nov 2021 19:48:25 GMT, kabutz wrote:
>> BigInteger currently uses three different algorithms for multiply. The
>> simple quadratic algorithm, then the slightly better Karatsuba if we exceed
>> a bit count and then Toom Cook 3 once we go into the several thousands of
>> bits. Since
On Wed, 17 Nov 2021 19:11:35 GMT, Paul Sandoz wrote:
>
>
> > I also do not like potentially non-obvious default behavior, nor a command
> > line flag, nor a (static) setting on `BigInteger`. Thus I think the
> > original `parallelMultiply()` (or perhaps `multiplyParallel()`) would be
> >
On Fri, 19 Nov 2021 00:14:18 GMT, Stuart Marks wrote:
>> Pretty much what it says. The new option controls a static member in
>> InstanceKlass that's consulted to determine whether the finalization
>> machinery is activated for instances when a class is loaded. A new native
>> method is added
On Fri, 19 Nov 2021 05:07:23 GMT, Vicente Romero wrote:
>> Please review this PR which aims to optimize the implementation of the
>> `toString` method we provide for records. A benchmark comparing the
>> implementation we are providing for records with lombok found out that
>> lombok is much
On Wed, 10 Nov 2021 17:28:05 GMT, Joe Wang wrote:
>> Add setProperty/getProperty methods to the XPath API so that properties can
>> be supported in the future.
>
> Joe Wang has updated the pull request incrementally with one additional
> commit since the last revision:
>
> adjust wording
On Thu, 18 Nov 2021 15:33:26 GMT, Roger Riggs wrote:
>> The ObjectInputStream.GetField.get(String name, Object val) method is
>> returning null instead of throwing an exception when the class of the object
>> is not found. The caller is not able to correctly handle the case where the
>> class
On Fri, 19 Nov 2021 01:03:22 GMT, David Holmes wrote:
> > When the finalization is disabled, perhaps jcmd GC.finalizer_info should
> > just be made as a nop in the VM.
>
> Yes that is a trivial change to add. @stuart-marks I can provide the code.
> You can choose whether to include in this PR
On Thu, 18 Nov 2021 20:05:15 GMT, Stuart Marks wrote:
>> Pretty much what it says. The new option controls a static member in
>> InstanceKlass that's consulted to determine whether the finalization
>> machinery is activated for instances when a class is loaded. A new native
>> method is added
On Thu, 18 Nov 2021 21:15:11 GMT, Mandy Chung wrote:
> When the finalization is disabled, perhaps jcmd GC.finalizer_info should just
> be made as a nop in the VM.
Would it be interesting (perhaps in a follow-up) for GC.finalizer_info to
report that the given VM had finalization disabled?
On Nov 18, 2021, at 2:41 AM, kabutz
mailto:d...@openjdk.java.net>> wrote:
Yes, it **must** be opt-in. However I'm not sure that a tuning knob will be
necessary. BigInteger has thresholds for using different multiply algorithms
and these are also not configurable.
Those thresholds are the
> Pretty much what it says. The new option controls a static member in
> InstanceKlass that's consulted to determine whether the finalization
> machinery is activated for instances when a class is loaded. A new native
> method is added so that this state can be queried from Java. This is used
On Fri, 19 Nov 2021 00:59:10 GMT, David Holmes wrote:
>> Stuart Marks has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Remove Finalizer.Holder class.
>
> src/java.base/share/classes/java/lang/ref/Finalizer.java line 64:
>
>> 62: }
On Fri, 19 Nov 2021 00:14:34 GMT, Stuart Marks wrote:
>> src/java.base/share/classes/java/lang/ref/Finalizer.java line 195:
>>
>>> 193:
>>> 194: static {
>>> 195: if (Holder.ENABLED) {
>>
>> Hello Stuart,
>> My understanding of the the lazy `Holder` is that it's there to delay the
On Fri, 19 Nov 2021 05:28:10 GMT, Guoxiong Li wrote:
> FYI: this patch also seems to solve
> [JDK-8265747](https://bugs.openjdk.java.net/browse/JDK-8265747).
yep, although I prefer to keep
[JDK-8265747](https://bugs.openjdk.java.net/browse/JDK-8265747) because it is
also referring to the
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 spec for JEP
421. It also updates the relevant @SuppressWarning
On Fri, 19 Nov 2021 05:07:23 GMT, Vicente Romero wrote:
>> Please review this PR which aims to optimize the implementation of the
>> `toString` method we provide for records. A benchmark comparing the
>> implementation we are providing for records with lombok found out that
>> lombok is much
On Thu, 18 Nov 2021 21:19:44 GMT, Stuart Marks wrote:
>> One typical way for VM to pass the arguments to the library is via private
>> system properties. System::initPhase1 will save the VM properties in
>> `jdk.internal.misc.VM` and filters out the private properties from the
>> system
> Add setProperty/getProperty methods to the XPath API so that properties can
> be supported in the future.
Joe Wang has updated the pull request incrementally with one additional commit
since the last revision:
update as commented
-
Changes:
- all:
On Wed, 10 Nov 2021 17:28:05 GMT, Joe Wang wrote:
>> Add setProperty/getProperty methods to the XPath API so that properties can
>> be supported in the future.
>
> Joe Wang has updated the pull request incrementally with one additional
> commit since the last revision:
>
> adjust wording
On Thu, 18 Nov 2021 04:13:21 GMT, Jaikiran Pai wrote:
>> Stuart Marks has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Remove Finalizer.Holder class.
>
> src/java.base/share/classes/java/lang/ref/Finalizer.java line 195:
>
>> 193:
>>
On Fri, 19 Nov 2021 00:14:18 GMT, Stuart Marks wrote:
>> Pretty much what it says. The new option controls a static member in
>> InstanceKlass that's consulted to determine whether the finalization
>> machinery is activated for instances when a class is loaded. A new native
>> method is added
On Fri, 19 Nov 2021 02:29:33 GMT, Stuart Marks wrote:
>>> When the finalization is disabled, perhaps jcmd GC.finalizer_info should
>>> just be made as a nop in the VM.
>>
>> Yes that is a trivial change to add. @stuart-marks I can provide the code.
>> You can choose whether to include in this
On Thu, 18 Nov 2021 22:04:52 GMT, Stuart Marks wrote:
>> I renamed the function to `is_finalization_enabled` per previous comment,
>> and I also made these cleanups.
>
> Regarding using system properties, my initial prototype did this in the
> launcher, and it did run into the problem that the
On Mon, 15 Nov 2021 18:47:34 GMT, Andrew Leonard wrote:
> Both jar and jmod utilise java.io file operations whose methods define no
> ordering of the return file lists, and in fact rely on OS query file
> ordering, which can differ by underlying OS architecture.
> This PR adds sort processing
On Thu, 18 Nov 2021 11:40:24 GMT, Magnus Ihse Bursie wrote:
>> @magicus
>> ah right, got you. So the order of each version's String[] is as ordered on
>> the jar cmd line args:
>>
On Thu, 18 Nov 2021 23:36:23 GMT, Brent Christian wrote:
> When the finalization is disabled, perhaps jcmd GC.finalizer_info should just
> be made as a nop in the VM.
Yes that is a trivial change to add. @stuart-marks I can provide the code. You
can choose whether to include in this PR or
> Please review this PR which aims to optimize the implementation of the
> `toString` method we provide for records. A benchmark comparing the
> implementation we are providing for records with lombok found out that lombok
> is much faster mainly because our implementation uses
On Wed, 10 Nov 2021 17:28:05 GMT, Joe Wang wrote:
>> Add setProperty/getProperty methods to the XPath API so that properties can
>> be supported in the future.
>
> Joe Wang has updated the pull request incrementally with one additional
> commit since the last revision:
>
> adjust wording
On Fri, 19 Nov 2021 00:14:18 GMT, Stuart Marks wrote:
>> Pretty much what it says. The new option controls a static member in
>> InstanceKlass that's consulted to determine whether the finalization
>> machinery is activated for instances when a class is loaded. A new native
>> method is added
`AbstractLdapNamingEnumeration` `next` throws `NullPointerException` instead of
`NoSuchElementException`, however the javadoc for `NamingEnumeration` says that
next should throw `NoSuchElementException` when no elements are available
On Mon, 15 Nov 2021 17:28:30 GMT, Roger Riggs wrote:
> The ObjectInputStream.GetField.get(String name, Object val) method is
> returning null instead of throwing an exception when the class of the object
> is not found. The caller is not able to correctly handle the case where the
> class is
> The ObjectInputStream.GetField.get(String name, Object val) method is
> returning null instead of throwing an exception when the class of the object
> is not found. The caller is not able to correctly handle the case where the
> class is not found. The signature of GetField.get(name, val)
On Wed, 17 Nov 2021 22:00:30 GMT, Vicente Romero wrote:
>> Please review this PR which aims to optimize the implementation of the
>> `toString` method we provide for records. A benchmark comparing the
>> implementation we are providing for records with lombok found out that
>> lombok is much
Hi Alan,
> We could start out by adding GB18030-2005, as you suggest.
Sure.
> A potential next step would be to rename GB13080 to GB13080-2000, with
> "GB13080" as an alias. As it stands, the charset name is "GB13080" with
> "GB13080-2000" as an alias so it should be compatible
On Thu, 18 Nov 2021 07:44:05 GMT, Aleksey Shipilev wrote:
>> @shipilev not sure what you mean by "a flag on the Java side". The Java
>> code just queries the VM for the finalization enabled/disabled state and
>> uses that to control things.
>
> Yeah, "flag" is `Holder.ENABLED` here. I mean,
On Wed, 17 Nov 2021 21:44:29 GMT, Mandy Chung wrote:
>> Both jar and jmod utilise java.io file operations whose methods define no
>> ordering of the return file lists, and in fact rely on OS query file
>> ordering, which can differ by underlying OS architecture.
>> This PR adds sort processing
> Pretty much what it says. The new option controls a static member in
> InstanceKlass that's consulted to determine whether the finalization
> machinery is activated for instances when a class is loaded. A new native
> method is added so that this state can be queried from Java. This is used
On Thu, 18 Nov 2021 07:26:45 GMT, David Holmes wrote:
> To add my 2c IMO a parallel version of this type absolutely **must** be
> opt-in. There are simply far too many side-effects of using the FJP and
> multiple threads to perform the calculation in parallel as if it is just a
> minor
What about a new API multiply method which takes an forkjoinpool, and only if
that is used/specified it will use the parallel mode (and only if Notsitzes
threshold applies?). Most of the pool tuning can then done with this argument.
It also avoids surprise threads.
Gruss
Bernd
--
- Original Message -
> From: "Bernd Eckenfels"
> To: "core-libs-dev"
> Sent: Jeudi 18 Novembre 2021 12:07:19
> Subject: Re: RFR: JDK-8277175 : Add a parallel multiply method to BigInteger
> [v3]
> What about a new API multiply method which takes an forkjoinpool, and only if
> that is
On Wed, 17 Nov 2021 21:45:45 GMT, Mandy Chung wrote:
>> Both jar and jmod utilise java.io file operations whose methods define no
>> ordering of the return file lists, and in fact rely on OS query file
>> ordering, which can differ by underlying OS architecture.
>> This PR adds sort processing
On Thu, 18 Nov 2021 09:10:16 GMT, Andrew Leonard wrote:
>> src/jdk.jartool/share/classes/sun/tools/jar/Main.java line 131:
>>
>>> 129: // There's also a files array per version
>>> 130: // Use a LinkedHashMap to keep original insertion ordering
>>> 131: Map filesMap = new
On Thu, 18 Nov 2021 10:02:45 GMT, Magnus Ihse Bursie wrote:
>> @mlchung the way I looked at this was the filesMap is a HashMap, so the
>> filesMap.keySet() iteration order is not defined (or necessarily
>> deterministic), the expanded order of the file sets for each version could
>> be ver1,
On Wed, 17 Nov 2021 20:21:09 GMT, Lance Andersen wrote:
> It would be good to consider adding a benchmark as part of this PR. I realize
> you did your own testing.
@LanceAndersen i'll add a simple benchmark test, eg.a 10,000 file jar x50
benchmark
-
PR:
On Wed, 10 Nov 2021 17:24:25 GMT, Joe Wang wrote:
> The wording is adjusted accordingly. Thanks.
Thanks for the update. The API additions (and clarification) look good to me.
Do you have other reviewers for the impl change and tests?
-
PR:
Yes but that does not help with the decision if parallel should be used or not.
But yes, if it is generally not wanted to make the pool explicite a simple
parallel signature without argument would also work to make the decision
explicite (I.e. new api). That won’t automatically tune the
On Wed, 17 Nov 2021 19:16:28 GMT, Magnus Ihse Bursie wrote:
> Just to verify, this test jar had 16000 files in a single directory? Since
> having 100 files in 160 directories would not have the same impact, right?
@magicus so the first test I did was 16,000 files in multiple directories, as I
On Thu, 18 Nov 2021 11:05:54 GMT, Andrew Leonard wrote:
>> I'm guessing Mandy asks not if the keys are sorted -- this is changed by
>> your patch, but if the value retrieved -- the String[], is sorted. It's a
>> valid question, I think. It's not apparent to me at least that this is the
>>
On Thu, 18 Nov 2021 11:38:08 GMT, Andrew Leonard wrote:
>> Just to verify, this test jar had 16000 files in a single directory? Since
>> having 100 files in 160 directories would not have the same impact, right?
>
>> Just to verify, this test jar had 16000 files in a single directory? Since
>>
On Wed, 17 Nov 2021 21:25:16 GMT, Lance Andersen wrote:
> Hi Ravi,
>
> The current revision looks good to me.
>
> Best Lance
I agree, commit d9112977 looks much better. There will be follow-up
clarification needed to javadoc but they can be down with another JBS issue/PR.
-
PR:
On Mon, 15 Nov 2021 16:20:07 GMT, iaroslavski wrote:
>> Sorting:
>>
>> - adopt radix sort for sequential and parallel sorts on
>> int/long/float/double arrays (almost random and length > 6K)
>> - fix tryMergeRuns() to better handle case when the last run is a single
>> element
>> - minor
On Thu, 18 Nov 2021 08:39:52 GMT, Alan Bateman wrote:
>> Yeah, "flag" is `Holder.ENABLED` here. I mean, are Java methods
>> `registerFinalizer` and `runFinalization` called only by VM? If so, can VM
>> check the whole thing on VM side, without going to Java and asking back from
>> there?
>
>
On Thu, 18 Nov 2021 14:53:38 GMT, Peter Levart wrote:
>> I think @shipilev asks a good question. This could be done completely in the
>> VM without the changes to j.l.ref.Finalizer. The CLI option is for
>> experimenting, at least in the short term, and should be benign to have the
>>
70 matches
Mail list logo
