On Wed, 11 Nov 2020 23:02:49 GMT, Mandy Chung wrote:
> If `Module::getPackages` is invoked on the unnamed module of a class loader
> then the set of packages returned will include the packages of any named
> modules
> that are defined to that class loader. This is a spec and implementation
On Wed, 11 Nov 2020 19:12:08 GMT, Alan Bateman wrote:
>> Hui Shi has refreshed the contents of this pull request, and previous
>> commits have been removed. The incremental views will show differences
>> compared to the previous content of the PR.
>
>
If `Module::getPackages` is invoked on the unnamed module of a class loader
then the set of packages returned will include the packages of any named modules
that are defined to that class loader. This is a spec and implementation bug.
`Module::getPackages` is changed to return the packages that
On Tue, 22 Sep 2020 02:45:36 GMT, Corey Ashford
wrote:
> This patch set encompasses the following commits:
>
> - Adds a new HotSpot intrinsic candidate to the java.lang.Base64 class -
> decodeBlock(), and provides a flexible API for the intrinsic. The API is
> similar to the existing
On Wed, 11 Nov 2020 18:52:10 GMT, Mandy Chung wrote:
> Provide the `Lookup::defineHiddenClassWithClassData` API that allows live
> objects
> be shared between a hidden class and other classes. A hidden class can load
> these live objects as dynamically-computed constants via this API.
>
>
On Wed, 11 Nov 2020 05:38:08 GMT, Hui Shi wrote:
>> …AccessorImpl object
>>
>> We met real problem when using protobuf with option optimized for code size,
>> detail in JBS https://bugs.openjdk.java.net/browse/JDK-8255883
>>
>> Optimize solution is adding a new boolean field to detect
Hi Mandy,
maybe a stupid question but why this mechanism is limited to hidden classes ?
regards,
Rémi
- Mail original -
> De: "Mandy Chung"
> À: "core-libs-dev" , "hotspot compiler"
>
> Envoyé: Mercredi 11 Novembre 2020 19:57:04
> Objet: RFR: 8230501: Class data support for hidden
Provide the `Lookup::defineHiddenClassWithClassData` API that allows live
objects
be shared between a hidden class and other classes. A hidden class can load
these live objects as dynamically-computed constants via this API.
Specdiff
On Wed, 11 Nov 2020 18:13:30 GMT, Albert Mingkun Yang wrote:
> With `getInactive`, is the null check, `if (finalizee != null` still needed?
Good point! I don't think it is. The GC should not clean the referent before we
finalized it (or not at all), and no other code is clearing it either.
On Wed, 11 Nov 2020 18:19:01 GMT, Mandy Chung wrote:
>> Roman Kennke has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Rename inactive-getter and improve javadocs
>
> src/java.base/share/classes/java/lang/ref/Reference.java line 356:
>
On Wed, 11 Nov 2020 17:48:12 GMT, Roman Kennke wrote:
>> Finalizer calls Reference.get() from the Finalizer to acquire the finalizee.
>> Concurrent reference processing GCs like Shenandoah and ZGC would return
>> NULL for unreachable referents, and thus would not call finalize() on them.
>>
On Wed, 11 Nov 2020 18:04:12 GMT, Erik Österlund wrote:
>> Roman Kennke has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Rename inactive-getter and improve javadocs
>
> Looks good.
With `getInactive`, is the null check, `if (finalizee
On Tue, 10 Nov 2020 09:37:29 GMT, Roman Kennke wrote:
> Finalizer calls Reference.get() from the Finalizer to acquire the finalizee.
> Concurrent reference processing GCs like Shenandoah and ZGC would return NULL
> for unreachable referents, and thus would not call finalize() on them.
>
> ZGC
On Wed, 11 Nov 2020 17:48:12 GMT, Roman Kennke wrote:
>> Finalizer calls Reference.get() from the Finalizer to acquire the finalizee.
>> Concurrent reference processing GCs like Shenandoah and ZGC would return
>> NULL for unreachable referents, and thus would not call finalize() on them.
>>
> Finalizer calls Reference.get() from the Finalizer to acquire the finalizee.
> Concurrent reference processing GCs like Shenandoah and ZGC would return NULL
> for unreachable referents, and thus would not call finalize() on them.
>
> ZGC works around this by fixing the referent before
Hello all,
Were those downsides seriously considered and strongly argued against? :
(1) Iterable belongs to java.lang so, at least from how it is usually
approached, it's a feature at the very level of the language, not a
util feature like Collection. Adding a find on it, is it really
relevant,
On Wed, 11 Nov 2020 15:23:12 GMT, Roman Kennke wrote:
>> Finalizer calls Reference.get() from the Finalizer to acquire the finalizee.
>> Concurrent reference processing GCs like Shenandoah and ZGC would return
>> NULL for unreachable referents, and thus would not call finalize() on them.
>>
On Tue, 10 Nov 2020 21:26:59 GMT, Lance Andersen wrote:
> Hi,
>
> Please review the fix for JDK-8256018 which addresses the issue that the
> update(ByteBuffer) methods of Adler32, CRC32, and CRC32C should use
> Reference.reachabilityFence to ensure that direct byte buffer are kept kept
>
On Wed, 11 Nov 2020 11:05:47 GMT, Vladimir Ivanov wrote:
>> Maurizio Cimadamore has updated the pull request incrementally with 10
>> additional commits since the last revision:
>>
>> - Merge pull request #7 from JornVernee/Additional_Review_Comments
>>
>>Additional review comments
>>
On Wed, 11 Nov 2020 11:58:08 GMT, Lance Andersen wrote:
>> Hi,
>>
>> Please review the fix for JDK-8256018 which addresses the issue that the
>> update(ByteBuffer) methods of Adler32, CRC32, and CRC32C should use
>> Reference.reachabilityFence to ensure that direct byte buffer are kept
> Finalizer calls Reference.get() from the Finalizer to acquire the finalizee.
> Concurrent reference processing GCs like Shenandoah and ZGC would return NULL
> for unreachable referents, and thus would not call finalize() on them.
>
> ZGC works around this by fixing the referent before
On Wed, 11 Nov 2020 14:17:20 GMT, Vladimir Ivanov wrote:
>> Maurizio Cimadamore has updated the pull request incrementally with 10
>> additional commits since the last revision:
>>
>> - Merge pull request #7 from JornVernee/Additional_Review_Comments
>>
>>Additional review comments
>>
On Wed, 11 Nov 2020 12:44:56 GMT, Vladimir Ivanov wrote:
>> Maurizio Cimadamore has updated the pull request incrementally with 10
>> additional commits since the last revision:
>>
>> - Merge pull request #7 from JornVernee/Additional_Review_Comments
>>
>>Additional review comments
>>
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
On Wed, 11 Nov 2020 13:31:11 GMT, Jorn Vernee wrote:
>> Where's the logic for the native thread to detach? We have a similar problem
>> in libgraal. We have a [utility
>>
On Wed, 11 Nov 2020 13:25:32 GMT, Doug Simon wrote:
>> The context is a thread that is spawned by native code doing an upcall. We
>> need to attach the thread to the VM first in that case. Normally this would
>> be handled by the calling code, but in our case the calling code doesn't
>> know
On Mon, 9 Nov 2020 11:50:54 GMT, Jorn Vernee wrote:
>> src/hotspot/cpu/aarch64/universalUpcallHandler_aarch64.cpp line 99:
>>
>>> 97: if (thread == NULL) {
>>> 98: JavaVM_ *vm = (JavaVM *)(_vm);
>>> 99: vm -> functions -> AttachCurrentThreadAsDaemon(vm, _env, NULL);
>>
>> Style nit:
> Hi,
>
> Please review the fix for JDK-8256018 which addresses the issue that the
> update(ByteBuffer) methods of Adler32, CRC32, and CRC32C should use
> Reference.reachabilityFence to ensure that direct byte buffer are kept kept
> alive when they are accessed directly.
>
> The Mach5
> This patch contains the changes associated with the third incubation round of
> the foreign memory access API incubation (see JEP 393 [1]). This iteration
> focus on improving the usability of the API in 3 main ways:
>
> * first, by providing a way to obtain truly *shared* segments, which
> This patch contains the changes associated with the third incubation round of
> the foreign memory access API incubation (see JEP 393 [1]). This iteration
> focus on improving the usability of the API in 3 main ways:
>
> * first, by providing a way to obtain truly *shared* segments, which
On 11/11/2020 9:19 pm, Jorn Vernee wrote:
On Wed, 11 Nov 2020 07:18:33 GMT, David Holmes wrote:
Maurizio Cimadamore has updated the pull request incrementally with 10
additional commits since the last revision:
- Merge pull request #7 from JornVernee/Additional_Review_Comments
On Wed, 11 Nov 2020 07:18:33 GMT, David Holmes wrote:
>> Maurizio Cimadamore has updated the pull request incrementally with 10
>> additional commits since the last revision:
>>
>> - Merge pull request #7 from JornVernee/Additional_Review_Comments
>>
>>Additional review comments
>> -
On Wed, 11 Nov 2020 05:38:08 GMT, Hui Shi wrote:
>> …AccessorImpl object
>>
>> We met real problem when using protobuf with option optimized for code size,
>> detail in JBS https://bugs.openjdk.java.net/browse/JDK-8255883
>>
>> Optimize solution is adding a new boolean field to detect
On Mon, 9 Nov 2020 09:19:44 GMT, Jie Fu wrote:
> Hi all,
>
> May I get reviews for this change?
>
> com/sun/jndi/dns/ConfigTests/PortUnreachable.java fails occasionally on some
> of our testing platforms.
> The reason is that the hard coded Threshold (1000 ms) [1] is a little smaller
> than
34 matches
Mail list logo
