Re: RFR: 8212879: Make JVMTI TagMap table concurrent [v11]
On Wed, 18 Nov 2020 19:31:44 GMT, Serguei Spitsyn wrote:
> test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach021/attach021Agent00.cpp:
>
> The change below is not needed as the call to
> nsk_jvmti_aod_disableEventAndFinish() does exactly the same:
>
> ```
> -nsk_jvmti_aod_disableEventAndFinish(agentName, JVMTI_EVENT_OBJECT_FREE,
> success, jvmti, jni);
> +
> +/* Flush any pending ObjectFree events, which may set success to 1 */
> +if (jvmti->SetEventNotificationMode(JVMTI_DISABLE,
> +JVMTI_EVENT_OBJECT_FREE,
> +NULL) != JVMTI_ERROR_NONE) {
> +success = 0;
> +}
> +
> +nsk_aod_agentFinished(jni, agentName, success);
> }
> ```
This change really is needed.
The success variable in the test is a global, initially 0, set to 1 by the
ObjectFree handler.
In the old code, if the ObjectFree event hasn't been posted yet, we pass the
initial 0 value of success to nsk_jvmti_aod_disabledEventAndFinish, where
it's a local variable (so unaffected by any changes to the variable in the
test), so stays 0 through to the call to nsk_aod_agentFinished. So the test
fails.
The split in the change causes the updated post-ObjectFree event success
value of 1 to be passed to agentFinished. So the test passes.
That required some head scratching to find at the time. That's the point of
the comment about flushing pending events. Maybe the comment should be
improved.
-
PR: https://git.openjdk.java.net/jdk/pull/967
Re: RFR: 8212879: Make JVMTI TagMap table concurrent [v12]
> This change turns the HashTable that JVMTI uses for object tagging into a > regular Hotspot hashtable - the one in hashtable.hpp with resizing and > rehashing. Instead of pointing directly to oops so that GC has to walk the > table to follow oops and then to rehash the table, this table points to > WeakHandle. GC walks the backing OopStorages concurrently. > > The hash function for the table is a hash of the lower 32 bits of the > address. A flag is set during GC (gc_notification if in a safepoint, and > through a call to JvmtiTagMap::needs_processing()) so that the table is > rehashed at the next use. > > The gc_notification mechanism of weak oop processing is used to notify Jvmti > to post ObjectFree events. In concurrent GCs there can be a window of time > between weak oop marking where the oop is unmarked, so dead (the phantom load > in peek returns NULL) but the gc_notification hasn't been done yet. In this > window, a heap walk or GetObjectsWithTags call would not find an object > before the ObjectFree event is posted. This is dealt with in two ways: > > 1. In the Heap walk, there's an unconditional table walk to post events if > events are needed to post. > 2. For GetObjectWithTags, if a dead oop is found in the table and posting is > required, we use the VM thread to post the event. > > Event posting cannot be done in a JavaThread because the posting needs to be > done while holding the table lock, so that the JvmtiEnv state doesn't change > before posting is done. ObjectFree callbacks are limited in what they can do > as per the JVMTI Specification. The allowed callbacks to the VM already have > code to allow NonJava threads. > > To avoid rehashing, I also tried to use object->identity_hash() but this > breaks because entries can be added to the table during heapwalk, where the > objects use marking. The starting markWord is saved and restored. Adding a > hashcode during this operation makes restoring the former markWord (locked, > inflated, etc) too complicated. Plus we don't want all these objects to have > hashcodes because locking operations after tagging would have to always use > inflated locks. > > Much of this change is to remove serial weak oop processing for the > weakProcessor, ZGC and Shenandoah. The GCs have been stress tested with > jvmti code. > > It has also been tested with tier1-6. > > Thank you to Stefan, Erik and Kim for their help with this change. Coleen Phillimore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits: - Merge branch 'master' into jvmti-table - Fix minimal build. - Reverse remove_dead_entries_locked function names. - Merge branch 'master' into jvmti-table - Add shenandoah set_needs_cleaning but this doesn't work. - fix vmTestbase/nsk/jvmti tests - improve tagmap cleanup and objectfree event posting - Add logging to event posting in case of pauses. - Merge branch 'master' into jvmti-table - Add back WeakProcessorPhases::Phase enum. - ... and 7 more: https://git.openjdk.java.net/jdk/compare/2b155713...9ef44f28 - Changes: https://git.openjdk.java.net/jdk/pull/967/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=967=11 Stats: 1884 lines in 49 files changed: 768 ins; 992 del; 124 mod Patch: https://git.openjdk.java.net/jdk/pull/967.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/967/head:pull/967 PR: https://git.openjdk.java.net/jdk/pull/967
Re: RFR: 8212879: Make JVMTI TagMap table concurrent [v11]
On Wed, 18 Nov 2020 19:31:44 GMT, Serguei Spitsyn wrote: > There is a double-check for _needs_cleaning, so the one at line 136 can be > removed: I want to leave _needs_cleaning at 136 because even though the boolean is checked twice, it doesn't hurt performance and it has a nice symmetry in that function. I asked Kim about the other change. Thank you for reviewing, Serguei! - PR: https://git.openjdk.java.net/jdk/pull/967
Re: RFR: 8212879: Make JVMTI TagMap table concurrent [v10]
On Mon, 16 Nov 2020 23:10:21 GMT, Coleen Phillimore wrote:
>> This change turns the HashTable that JVMTI uses for object tagging into a
>> regular Hotspot hashtable - the one in hashtable.hpp with resizing and
>> rehashing. Instead of pointing directly to oops so that GC has to walk the
>> table to follow oops and then to rehash the table, this table points to
>> WeakHandle. GC walks the backing OopStorages concurrently.
>>
>> The hash function for the table is a hash of the lower 32 bits of the
>> address. A flag is set during GC (gc_notification if in a safepoint, and
>> through a call to JvmtiTagMap::needs_processing()) so that the table is
>> rehashed at the next use.
>>
>> The gc_notification mechanism of weak oop processing is used to notify Jvmti
>> to post ObjectFree events. In concurrent GCs there can be a window of time
>> between weak oop marking where the oop is unmarked, so dead (the phantom
>> load in peek returns NULL) but the gc_notification hasn't been done yet. In
>> this window, a heap walk or GetObjectsWithTags call would not find an object
>> before the ObjectFree event is posted. This is dealt with in two ways:
>>
>> 1. In the Heap walk, there's an unconditional table walk to post events if
>> events are needed to post.
>> 2. For GetObjectWithTags, if a dead oop is found in the table and posting is
>> required, we use the VM thread to post the event.
>>
>> Event posting cannot be done in a JavaThread because the posting needs to be
>> done while holding the table lock, so that the JvmtiEnv state doesn't change
>> before posting is done. ObjectFree callbacks are limited in what they can
>> do as per the JVMTI Specification. The allowed callbacks to the VM already
>> have code to allow NonJava threads.
>>
>> To avoid rehashing, I also tried to use object->identity_hash() but this
>> breaks because entries can be added to the table during heapwalk, where the
>> objects use marking. The starting markWord is saved and restored. Adding a
>> hashcode during this operation makes restoring the former markWord (locked,
>> inflated, etc) too complicated. Plus we don't want all these objects to
>> have hashcodes because locking operations after tagging would have to always
>> use inflated locks.
>>
>> Much of this change is to remove serial weak oop processing for the
>> weakProcessor, ZGC and Shenandoah. The GCs have been stress tested with
>> jvmti code.
>>
>> It has also been tested with tier1-6.
>>
>> Thank you to Stefan, Erik and Kim for their help with this change.
>
> Coleen Phillimore has updated the pull request with a new target base due to
> a merge or a rebase. The pull request now contains 15 commits:
>
> - Reverse remove_dead_entries_locked function names.
> - Merge branch 'master' into jvmti-table
> - Add shenandoah set_needs_cleaning but this doesn't work.
> - fix vmTestbase/nsk/jvmti tests
> - improve tagmap cleanup and objectfree event posting
> - Add logging to event posting in case of pauses.
> - Merge branch 'master' into jvmti-table
> - Add back WeakProcessorPhases::Phase enum.
> - Serguei 1.
> - Code review comments from Kim and Albert.
> - ... and 5 more:
> https://git.openjdk.java.net/jdk/compare/0357db35...daaa13fe
test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach021/attach021Agent00.cpp
line 72:
> 70:
> Java_nsk_jvmti_AttachOnDemand_attach021_attach021Target_shutdownAgent(JNIEnv
> * jni,
> 71: jclass klass) {
> 72:
@kimbarrett ? I'm not sure why you made this change. See Serguei's comment.
-
PR: https://git.openjdk.java.net/jdk/pull/967
Re: RFR: 8256497: Zero: enable G1 and Shenandoah GCs
On Tue, 17 Nov 2020 19:02:03 GMT, Aleksey Shipilev wrote: > Following the [JDK-8255796](https://bugs.openjdk.java.net/browse/JDK-8255796) > improvement that ditched the inline contiguous alloc use from Zero, we can > now rely on GC interface to hook the GCs properly. G1 and Shenandoah are a > bit special here, because they require special `Reference.get` handling. > > Note that it does not change the default GC for Zero, because Zero is > implicitly `NeverActAsServerMachine`, which still selects Serial GC by > default. After this change, Zero users can opt-in to G1 or Shenandoah. > > Additional testing: > - [x] Linux x86_64 Zero fastdebug `hotspot_gc_shenandoah` (some lingering > failures about non-enabled compressed oops) > - [ ] Linux x86_64 Zero fastdebug `tier1` with `-XX:+UseG1GC` Build change looks ok. - Marked as reviewed by erikj (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1268
Re: RFR: 8256538: Fix annoying awk warning in configure for java versions [v2]
> The change from grep to awk in JDK-8244248 and further bug fixed in > JDK-8244756 still has invalid syntax. This causes some awk (most notably > gawk, the most commonly used) to complain: > > gawk: cmd. line:1: warning: regexp escape sequence `"' is not a known regexp > operator > > This is annoying and should be fixed. Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: Also fix bad code as copied in BOOTJDK_CHECK_BUILD_JDK - Changes: - all: https://git.openjdk.java.net/jdk/pull/1285/files - new: https://git.openjdk.java.net/jdk/pull/1285/files/9d5fd4fc..842287e0 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=1285=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk=1285=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1285.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1285/head:pull/1285 PR: https://git.openjdk.java.net/jdk/pull/1285
Integrated: 8256538: Fix annoying awk warning in configure for java versions
On Wed, 18 Nov 2020 09:47:58 GMT, Magnus Ihse Bursie wrote: > The change from grep to awk in JDK-8244248 and further bug fixed in > JDK-8244756 still has invalid syntax. This causes some awk (most notably > gawk, the most commonly used) to complain: > > gawk: cmd. line:1: warning: regexp escape sequence `"' is not a known regexp > operator > > This is annoying and should be fixed. This pull request has now been integrated. Changeset: 3110d589 Author:Magnus Ihse Bursie URL: https://git.openjdk.java.net/jdk/commit/3110d589 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8256538: Fix annoying awk warning in configure for java versions Reviewed-by: erikj - PR: https://git.openjdk.java.net/jdk/pull/1285
Re: RFR: 8256538: Fix annoying awk warning in configure for java versions [v2]
On Wed, 18 Nov 2020 14:13:03 GMT, Bernhard Urban-Forster wrote: >> Marked as reviewed by erikj (Reviewer). > > Thank you Magnus, this is something that has bugged me as well. > > FWIW the same problem exists here with the build JDK detection: > https://github.com/openjdk/jdk/blob/9d5fd4fcabf7bdf580e2fff8e12c2cf130ef44c9/make/autoconf/boot-jdk.m4#L519 > > Would you mind fixing it as part of this PR too? @lewurm Thanks! I had not noticed that one. (In fact, I'm unsure when we got such a huge chunk of duplicated code... *sigh* Should look into it some day, I think.) - PR: https://git.openjdk.java.net/jdk/pull/1285
Re: RFR: JDK-6251738: Want a top-level summary page that itemizes all spec documents referenced from javadocs (OEM spec) [v3]
> This introduces support for a new `@spec` tag that can be used as either an
> inline tag or as a block tag. It is used to identify references to external
> specifications, in such a way that the references can be collected together
> on a new summary page, called "Other Specifications", available from either
> the static INDEX page or the interactive search box.
>
> As an inline tag, the format is `{@spec url label}`, which is roughly
> translated to `label` in the generated docs.
>
> As a block tag, the format is simply
>
> @spec url label
>
> which is handled in a manner analogous to
>
> @see label
>
> The tag is notable for being the first standard/supported tag that can be
> used as either an inline or block tag. (We have had support for bimodal
> non-standard/custom tags for a while, such as `{@jls}` and `{@jvms}`.) To
> support bimodal standard tags, some changes to `DocCommentParser` are
> incorporated here.
>
> This change is only the _support_ for the new tag; it does _not_ include any
> changes to API docs to _use_ the new tag.
Jonathan Gibbons has updated the pull request with a new target base due to a
merge or a rebase. The pull request now contains 12 commits:
- Merge master
- Fix merge issues; review feedback
- Merge with master
- allow rich content in createAnchorAndSearchIndex
- update Docs.gmk to stop disabling spec tag
- fix TestSpecTag.testEncodedURI
- fix tests
- remove support to workaround legacy @spec tag
- Merge remote-tracking branch 'upstream/master' into new-spec-tag
- fix trailing whitespace in test
- ... and 2 more: https://git.openjdk.java.net/jdk/compare/300cbaa6...69595e04
-
Changes: https://git.openjdk.java.net/jdk/pull/790/files
Webrev: https://webrevs.openjdk.java.net/?repo=jdk=790=02
Stats: 1374 lines in 42 files changed: 1337 ins; 14 del; 23 mod
Patch: https://git.openjdk.java.net/jdk/pull/790.diff
Fetch: git fetch https://git.openjdk.java.net/jdk pull/790/head:pull/790
PR: https://git.openjdk.java.net/jdk/pull/790
Re: RFR: 8212879: Make JVMTI TagMap table concurrent [v11]
On Mon, 16 Nov 2020 23:30:25 GMT, Coleen Phillimore wrote:
>> This change turns the HashTable that JVMTI uses for object tagging into a
>> regular Hotspot hashtable - the one in hashtable.hpp with resizing and
>> rehashing. Instead of pointing directly to oops so that GC has to walk the
>> table to follow oops and then to rehash the table, this table points to
>> WeakHandle. GC walks the backing OopStorages concurrently.
>>
>> The hash function for the table is a hash of the lower 32 bits of the
>> address. A flag is set during GC (gc_notification if in a safepoint, and
>> through a call to JvmtiTagMap::needs_processing()) so that the table is
>> rehashed at the next use.
>>
>> The gc_notification mechanism of weak oop processing is used to notify Jvmti
>> to post ObjectFree events. In concurrent GCs there can be a window of time
>> between weak oop marking where the oop is unmarked, so dead (the phantom
>> load in peek returns NULL) but the gc_notification hasn't been done yet. In
>> this window, a heap walk or GetObjectsWithTags call would not find an object
>> before the ObjectFree event is posted. This is dealt with in two ways:
>>
>> 1. In the Heap walk, there's an unconditional table walk to post events if
>> events are needed to post.
>> 2. For GetObjectWithTags, if a dead oop is found in the table and posting is
>> required, we use the VM thread to post the event.
>>
>> Event posting cannot be done in a JavaThread because the posting needs to be
>> done while holding the table lock, so that the JvmtiEnv state doesn't change
>> before posting is done. ObjectFree callbacks are limited in what they can
>> do as per the JVMTI Specification. The allowed callbacks to the VM already
>> have code to allow NonJava threads.
>>
>> To avoid rehashing, I also tried to use object->identity_hash() but this
>> breaks because entries can be added to the table during heapwalk, where the
>> objects use marking. The starting markWord is saved and restored. Adding a
>> hashcode during this operation makes restoring the former markWord (locked,
>> inflated, etc) too complicated. Plus we don't want all these objects to
>> have hashcodes because locking operations after tagging would have to always
>> use inflated locks.
>>
>> Much of this change is to remove serial weak oop processing for the
>> weakProcessor, ZGC and Shenandoah. The GCs have been stress tested with
>> jvmti code.
>>
>> It has also been tested with tier1-6.
>>
>> Thank you to Stefan, Erik and Kim for their help with this change.
>
> Coleen Phillimore has updated the pull request incrementally with one
> additional commit since the last revision:
>
> Fix minimal build.
Hi Coleen,
It looks good to me.
Just a couple of nits below.
src/hotspot/share/prims/jvmtiTagMap.cpp:
There is a double-check for _needs_cleaning, so the one at line 136 can be
removed:
136 if (_needs_cleaning &&
137 post_events &&
138 env()->is_enabled(JVMTI_EVENT_OBJECT_FREE)) {
139 remove_dead_entries(true /* post_object_free */);
1158 void JvmtiTagMap::remove_dead_entries(bool post_object_free) {
1159 assert(is_locked(), "precondition");
1160 if (_needs_cleaning) {
1161 log_info(jvmti, table)("TagMap table needs cleaning%s",
1162(post_object_free ? " and posting" : ""));
1163 hashmap()->remove_dead_entries(env(), post_object_free);
1164 _needs_cleaning = false;
1165 }
1166 }
test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach021/attach021Agent00.cpp:
The change below is not needed as the call to
nsk_jvmti_aod_disableEventAndFinish() does exactly the same:
-nsk_jvmti_aod_disableEventAndFinish(agentName, JVMTI_EVENT_OBJECT_FREE,
success, jvmti, jni);
+
+/* Flush any pending ObjectFree events, which may set success to 1 */
+if (jvmti->SetEventNotificationMode(JVMTI_DISABLE,
+JVMTI_EVENT_OBJECT_FREE,
+NULL) != JVMTI_ERROR_NONE) {
+success = 0;
+}
+
+nsk_aod_agentFinished(jni, agentName, success);
}
-
Marked as reviewed by sspitsyn (Reviewer).
PR: https://git.openjdk.java.net/jdk/pull/967
Integrated: JDK-8256501: libTestMainKeyWindow fails to build with Xcode 12.2
On Tue, 17 Nov 2020 21:04:08 GMT, Erik Joelsson wrote: > In Xcode 12.2, the framework JavaVM was removed in the sysroot and all > (relevant) frameworks inside were just moved one step up so we still find > things like JavaNativeFoundation and JavaRuntimeSupport. There is however one > test that currently links explicitly to JavaVM, which fails the build. The > fix seems to be to simply remove this from the linker flags. This pull request has now been integrated. Changeset: 4e5116c4 Author:Erik Joelsson URL: https://git.openjdk.java.net/jdk/commit/4e5116c4 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8256501: libTestMainKeyWindow fails to build with Xcode 12.2 Reviewed-by: ihse, serb - PR: https://git.openjdk.java.net/jdk/pull/1275
Re: RFR: 8256538: Fix annoying awk warning in configure for java versions
On Wed, 18 Nov 2020 13:35:14 GMT, Erik Joelsson wrote: >> The change from grep to awk in JDK-8244248 and further bug fixed in >> JDK-8244756 still has invalid syntax. This causes some awk (most notably >> gawk, the most commonly used) to complain: >> >> gawk: cmd. line:1: warning: regexp escape sequence `"' is not a known regexp >> operator >> >> This is annoying and should be fixed. > > Marked as reviewed by erikj (Reviewer). Thank you Magnus, this is something that has bugged me as well. FWIW the same problem exists here with the build JDK detection: https://github.com/openjdk/jdk/blob/9d5fd4fcabf7bdf580e2fff8e12c2cf130ef44c9/make/autoconf/boot-jdk.m4#L519 Would you mind fixing it as part of this PR too? - PR: https://git.openjdk.java.net/jdk/pull/1285
Re: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators [v3]
On Wed, 18 Nov 2020 13:18:30 GMT, Jim Laskey wrote: >> I am unsure if the intent is also to support external libraries providing >> `RandomGenerator` implementations. Currently there is an implicit contract >> for properties (reflectively invoking a method returning a map with a set of >> entries with known keys). Since the service provider implementation is the >> `RandomGenerator` itself, rather than `RandomGeneratorFactory` it is harder >> expose the meta-data with a clearer contract. > > Need rebase Created new PR because of forced push: https://github.com/openjdk/jdk/pull/1292 - PR: https://git.openjdk.java.net/jdk/pull/1273
Re: RFR: 8256497: Zero: enable G1 and Shenandoah GCs
On Tue, 17 Nov 2020 19:02:03 GMT, Aleksey Shipilev wrote: > Following the [JDK-8255796](https://bugs.openjdk.java.net/browse/JDK-8255796) > improvement that ditched the inline contiguous alloc use from Zero, we can > now rely on GC interface to hook the GCs properly. G1 and Shenandoah are a > bit special here, because they require special `Reference.get` handling. > > Note that it does not change the default GC for Zero, because Zero is > implicitly `NeverActAsServerMachine`, which still selects Serial GC by > default. After this change, Zero users can opt-in to G1 or Shenandoah. > > Additional testing: > - [x] Linux x86_64 Zero fastdebug `hotspot_gc_shenandoah` (some lingering > failures about non-enabled compressed oops) > - [ ] Linux x86_64 Zero fastdebug `tier1` with `-XX:+UseG1GC` Looks good to me! Thanks! - Marked as reviewed by rkennke (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1268
RFR: 8256497: Zero: enable G1 and Shenandoah GCs
Following the [JDK-8255796](https://bugs.openjdk.java.net/browse/JDK-8255796) improvement that ditched the inline contiguous alloc use from Zero, we can now rely on GC interface to hook the GCs properly. G1 and Shenandoah are a bit special here, because they require special `Reference.get` handling. Note that it does not change the default GC for Zero, because Zero is implicitly `NeverActAsServerMachine`, which still selects Serial GC by default. After this change, Zero users can opt-in to G1 or Shenandoah. Additional testing: - [x] Linux x86_64 Zero fastdebug `hotspot_gc_shenandoah` (some lingering failures about non-enabled compressed oops) - [ ] Linux x86_64 Zero fastdebug `tier1` with `-XX:+UseG1GC` - Commit messages: - Remove TODO - 8256497: Zero: enable G1 and Shenandoah GCs Changes: https://git.openjdk.java.net/jdk/pull/1268/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=1268=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8256497 Stats: 72 lines in 5 files changed: 54 ins; 16 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/1268.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1268/head:pull/1268 PR: https://git.openjdk.java.net/jdk/pull/1268
Re: RFR: 8256538: Fix annoying awk warning in configure for java versions
On Wed, 18 Nov 2020 09:47:58 GMT, Magnus Ihse Bursie wrote: > The change from grep to awk in JDK-8244248 and further bug fixed in > JDK-8244756 still has invalid syntax. This causes some awk (most notably > gawk, the most commonly used) to complain: > > gawk: cmd. line:1: warning: regexp escape sequence `"' is not a known regexp > operator > > This is annoying and should be fixed. Marked as reviewed by erikj (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/1285
Re: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators [v3]
On Wed, 18 Nov 2020 00:51:43 GMT, Paul Sandoz wrote: >> Jim Laskey has updated the pull request with a new target base due to a >> merge or a rebase. The pull request now contains 40 commits: >> >> - Merge branch 'master' into 8248862 >> - 8248862: Implement Enhanced Pseudo-Random Number Generators >> >>Update package-info.java >> - 8248862: Implement Enhanced Pseudo-Random Number Generators >> >>Updated RandomGeneratorFactory javadoc. >> - 8248862: Implement Enhanced Pseudo-Random Number Generators >> >>Updated documentation for RandomGeneratorFactory. >> - Merge branch 'master' into 8248862 >> - Merge branch 'master' into 8248862 >> - 8248862: Implement Enhanced Pseudo-Random Number Generators >> >>Move RandomGeneratorProperty >> - Merge branch 'master' into 8248862 >> - 8248862: Implement Enhanced Pseudo-Random Number Generators >> >>Clear up javadoc >> - 8248862; Implement Enhanced Pseudo-Random Number Generators >> >>remove RandomGeneratorProperty from API >> - ... and 30 more: >> https://git.openjdk.java.net/jdk/compare/f7517386...6fe94c68 > > I am unsure if the intent is also to support external libraries providing > `RandomGenerator` implementations. Currently there is an implicit contract > for properties (reflectively invoking a method returning a map with a set of > entries with known keys). Since the service provider implementation is the > `RandomGenerator` itself, rather than `RandomGeneratorFactory` it is harder > expose the meta-data with a clearer contract. Need rebase - PR: https://git.openjdk.java.net/jdk/pull/1273
Withdrawn: 8248862: Implement Enhanced Pseudo-Random Number Generators
On Tue, 17 Nov 2020 19:58:47 GMT, Jim Laskey wrote: > This PR is to introduce a new random number API for the JDK. The primary API > is found in RandomGenerator and RandomGeneratorFactory. Further description > can be found in the JEP https://openjdk.java.net/jeps/356 . This pull request has been closed without being integrated. - PR: https://git.openjdk.java.net/jdk/pull/1273
Re: RFR: 8256538: Fix annoying awk warning in configure for java versions
On Wed, 18 Nov 2020 09:47:58 GMT, Magnus Ihse Bursie wrote: > The change from grep to awk in JDK-8244248 and further bug fixed in > JDK-8244756 still has invalid syntax. This causes some awk (most notably > gawk, the most commonly used) to complain: > > gawk: cmd. line:1: warning: regexp escape sequence `"' is not a known regexp > operator > > This is annoying and should be fixed. I have gotten confirmation from Martin Doerr that this also works on AIX, which has an awk that previously complained about this pattern. And I've tested it on all platforms used in the Oracle CI system. - PR: https://git.openjdk.java.net/jdk/pull/1285
RFR: 8256240: Reproducible builds should turn on the "deterministic" flag for Visual Studio
The microsoft toolchain now supports a new "deterministic" build mode. This goes a long way towards building properly deterministic. Another important feature is that with the deterministic build mode enabled, the -pathmap flag, similar to gcc's -fmacro-prefix-map, is enabled. - Commit messages: - 8256240: Reproducible builds should turn on the "deterministic" flag for Visual Studio Changes: https://git.openjdk.java.net/jdk/pull/1287/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=1287=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8256240 Stats: 68 lines in 4 files changed: 48 ins; 14 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/1287.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1287/head:pull/1287 PR: https://git.openjdk.java.net/jdk/pull/1287
Re: RFR: 8256499: Zero: enable Epsilon GC
On Tue, 17 Nov 2020 19:11:45 GMT, Aleksey Shipilev wrote:
> Following the [JDK-8255796](https://bugs.openjdk.java.net/browse/JDK-8255796)
> improvement that ditched the inline contiguous alloc use from Zero, we can
> now rely on GC interface to hook the GCs properly. Epsilon GC does not
> require anything else. Other GCs require a bit of fiddling and more testing
> (see e.g. [JDK-8256497](https://bugs.openjdk.java.net/browse/JDK-8256497)).
>
> Additional testing:
> - [x] Linux x86_64 Zero {fastdebug,release}, `gc/epsilon` tests
Marked as reviewed by ihse (Reviewer).
-
PR: https://git.openjdk.java.net/jdk/pull/1269
RFR: 8256538: Fix annoying awk warning in configure for java versions
The change from grep to awk in JDK-8244248 and further bug fixed in JDK-8244756 still has invalid syntax. This causes some awk (most notably gawk, the most commonly used) to complain: gawk: cmd. line:1: warning: regexp escape sequence `"' is not a known regexp operator This is annoying and should be fixed. - Commit messages: - 8256538: Fix annoying awk warning in configure for java versions Changes: https://git.openjdk.java.net/jdk/pull/1285/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=1285=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8256538 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1285.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1285/head:pull/1285 PR: https://git.openjdk.java.net/jdk/pull/1285
Re: RFR: 8256499: Zero: enable Epsilon GC
On Tue, 17 Nov 2020 19:11:45 GMT, Aleksey Shipilev wrote:
> Following the [JDK-8255796](https://bugs.openjdk.java.net/browse/JDK-8255796)
> improvement that ditched the inline contiguous alloc use from Zero, we can
> now rely on GC interface to hook the GCs properly. Epsilon GC does not
> require anything else. Other GCs require a bit of fiddling and more testing
> (see e.g. [JDK-8256497](https://bugs.openjdk.java.net/browse/JDK-8256497)).
>
> Additional testing:
> - [x] Linux x86_64 Zero {fastdebug,release}, `gc/epsilon` tests
Great! Looks good!
-
Marked as reviewed by rkennke (Reviewer).
PR: https://git.openjdk.java.net/jdk/pull/1269
RFR: 8256499: Zero: enable Epsilon GC
Following the [JDK-8255796](https://bugs.openjdk.java.net/browse/JDK-8255796)
improvement that ditched the inline contiguous alloc use from Zero, we can now
rely on GC interface to hook the GCs properly. Epsilon GC does not require
anything else. Other GCs require a bit of fiddling and more testing (see e.g.
[JDK-8256497](https://bugs.openjdk.java.net/browse/JDK-8256497)).
Additional testing:
- [x] Linux x86_64 Zero {fastdebug,release}, `gc/epsilon` tests
-
Commit messages:
- 8256499: Zero: enable Epsilon GC
Changes: https://git.openjdk.java.net/jdk/pull/1269/files
Webrev: https://webrevs.openjdk.java.net/?repo=jdk=1269=00
Issue: https://bugs.openjdk.java.net/browse/JDK-8256499
Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
Patch: https://git.openjdk.java.net/jdk/pull/1269.diff
Fetch: git fetch https://git.openjdk.java.net/jdk pull/1269/head:pull/1269
PR: https://git.openjdk.java.net/jdk/pull/1269
