On Fri, 8 Apr 2022 08:13:33 GMT, Thomas Schatzl wrote:
> Hi all,
>
> can I have reviews for this change that adds dedicated filler objects to
> the VM?
>
> Currently, when formatting areas of dead objects all gcs use instances of
> j.l.Object and int-arrays.
>
&g
On Mon, 11 Apr 2022 14:55:32 GMT, Thomas Schatzl wrote:
>> Hi all,
>>
>> can I have reviews for this change that adds dedicated filler objects to
>> the VM?
>>
>> Currently, when formatting areas of dead objects all gcs use instances of
>> j.l.
On Fri, 29 Apr 2022 16:45:01 GMT, Ioi Lam wrote:
>> Thomas Schatzl has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Fix test
>
> The latest version looks good to me.
Thanks @iklam @walulyai for your rev
On Tue, 26 Apr 2022 17:27:35 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 the
On Mon, 11 Apr 2022 21:51:32 GMT, David Holmes wrote:
> Do you really need to define a real `FillerObject.java` class? Can't you use
> an internal-only variant of a hidden class to represent this?
I am not sure I understand this request, but of course I am open to try
different approaches. An
nal/vm/FillerArray;` for that, looking at other internal
> symbols/klasses, but I'm not sure this adheres to naming guidelines.
>
> Thanks go to @iklam for helping out with the change.
>
> Thanks,
> Thomas
Thomas Schatzl has updated the pull request incrementally
On Fri, 8 Apr 2022 16:45:54 GMT, Ioi Lam wrote:
>> Thomas Schatzl has updated the pull request incrementally with two
>> additional commits since the last revision:
>>
>> - iklam review
>> - Test case
>
> src/hotspot/share/classfile/systemDictio
nal/vm/FillerArray;` for that, looking at other internal
> symbols/klasses, but I'm not sure this adheres to naming guidelines.
>
> Thanks go to @iklam for helping out with the change.
>
> Thanks,
> Thomas
Thomas Schatzl has updated the pull request incrementally
Hi all,
can I have reviews for this change that adds dedicated filler objects to the
VM?
Currently, when formatting areas of dead objects all gcs use instances of
j.l.Object and int-arrays.
This has the drawback of not being easily able to discern whether a given
object is actually dead (an
On Fri, 19 Nov 2021 20:57:46 GMT, Daniel D. Daugherty
wrote:
> This reverts commit 936f7ff49ed86adb74bb1ff10d93cb3d7f7d70a0.
>
> So far we've had 3 failed Tier2 job sets in a row. My Mach5 Tier2 of this
> [BACKOUT] has
> passed the macosx-aarch64 test task that was failing before.
Marked as
On Thu, 14 Oct 2021 06:37:19 GMT, Nick Gasson wrote:
> This reverts "8269559: AArch64: Implement string_compare intrinsic in SVE"
> which caused some unknown failures in Oracle's CI.
Lgtm.
-
Marked as reviewed by tschatzl (Reviewer).
PR: https://git.openjdk.java.net/jdk/pull/5941
On Tue, 31 Aug 2021 20:04:23 GMT, Сергей Цыпанов
wrote:
>> Just a very tiny clean-up.
>>
>> There are some places in JDK code base where we call
>> `Enum.class.getEnumConstants()` to get all the values of the referenced
>> `enum`. This is excessive, less-readable and slower than just calling
On Wed, 3 Feb 2021 19:12:25 GMT, Emmanuel Bourg
wrote:
> This PR fixes the following spelling errors:
>
> choosen -> chosen
> commad -> command
> hiearchy -> hierarchy
> leagacy -> legacy
> minium -> minimum
> subsytem -> subsystem
> unamed -> unnamed
Lgtm.
-
Marke
On Wed, 30 Jun 2021 22:52:36 GMT, Mandy Chung wrote:
>> This spec clarification is a follow-up to
>> [JDK-8224760](https://bugs.openjdk.java.net/browse/JDK-8224760?focusedCommentId=14268320&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14268320)
>> w.r.t. refer
On Mon, 28 Jun 2021 17:05:49 GMT, Daniel D. Daugherty
wrote:
> A trivial fix to remove java/util/concurrent/locks/Lock/TimedAcquireLeak.java
> from ProblemList.txt
Lgtm and trivial.
-
Marked as reviewed by tschatzl (Reviewer).
PR: https://git.openjdk.java.net/jdk17/pull/164
On Fri, 7 May 2021 08:28:43 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
>> supporti
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
On Thu, 10 Dec 2020 08:56:25 GMT, Kim Barrett wrote:
>> I understand that the test code previously just forwarded the
>> `InterruptedException` if it happened in the `Thread.sleep()` call too. So
>> this may only be an exiting issue and please ignore this comment.
>> Not catching `InterruptedEx
On Thu, 10 Dec 2020 09:01:54 GMT, Kim Barrett wrote:
>> Please review this change that eliminates the use of Reference.isEnqueued by
>> tests. There were three tests using it:
>>
>> vmTestbase/gc/gctests/ReferencesGC/ReferencesGC.java
>> vmTestbase/gc/gctests/WeakReferenceGC/WeakReferenceGC.jav
On Wed, 9 Dec 2020 13:23:47 GMT, Thomas Schatzl wrote:
>> Please review this change that eliminates the use of Reference.isEnqueued by
>> tests. There were three tests using it:
>>
>> vmTestbase/gc/gctests/ReferencesGC/ReferencesGC.java
>> vmTestb
On Tue, 8 Dec 2020 09:52:51 GMT, Kim Barrett wrote:
> Please review this change that eliminates the use of Reference.isEnqueued by
> tests. There were three tests using it:
>
> vmTestbase/gc/gctests/ReferencesGC/ReferencesGC.java
> vmTestbase/gc/gctests/WeakReferenceGC/WeakReferenceGC.java
> jd
On Tue, 8 Dec 2020 17:30:11 GMT, Mandy Chung wrote:
>> Please review this change that eliminates the use of Reference.isEnqueued by
>> tests. There were three tests using it:
>>
>> vmTestbase/gc/gctests/ReferencesGC/ReferencesGC.java
>> vmTestbase/gc/gctests/WeakReferenceGC/WeakReferenceGC.java
On Thu, 24 Sep 2020 10:02:13 GMT, Aleksey Shipilev wrote:
>> Lgtm.
>
> Trivial, right?
Trivial.
-
PR: https://git.openjdk.java.net/jdk/pull/331
On Thu, 24 Sep 2020 08:35:24 GMT, Aleksey Shipilev wrote:
> JDK-8246697 added -Xmx4g to test configurations. 32-bit VMs cannot do it.
> @requires tests the OS RAM size, but you can
> easily have the x86_32 host with more than 4G ram, yet JVM would fail to
> acquire that heap size. Need to check
Hi,
I looked a bit at the allocations themselves, but first answering
questions.
On 15.07.20 15:25, David Holmes wrote:
> On 15/07/2020 10:18 pm, Jim Laskey wrote:
>> Thomas explained: That large objects are never moved (outstanding
>> issue) So, it's possible to fragment the -Xmx4g such tha
Hi,
On 15.07.20 15:35, Jim Laskey wrote:
Try this:
- You have a 4G heap.
- You allocate some stuff, say 1 byte.
- You allocate a 2G object - so there is only 2G - 1, left. Not enough space
for another 2G object.
- But you do allocate 1 byte.
- You have 1 byte, 2G and 1 byte.
- You free the ori
Hi,
On 08.04.20 02:25, Kim Barrett wrote:
[Note review on both core-libs and hotspot-gc-dev lists; try not to lose
either when replying.]
Please review a new function: java.lang.ref.Reference.refersTo.
[...]
CR:
https://bugs.openjdk.java.net/browse/JDK-8188055
https://bugs.openjdk.java.net/
Hi Martin,
On Fri, 2018-05-18 at 07:47 -0700, Martin Buchholz wrote:
>
>
> On Fri, May 18, 2018 at 3:26 AM, Thomas Schatzl e.com> wrote:
> > Hi,
> >
> > On Wed, 2018-05-16 at 18:31 -0700, Martin Buchholz wrote:
> > > I've been confused by NULL vs
Hi,
On Wed, 2018-05-16 at 18:31 -0700, Martin Buchholz wrote:
> I've been confused by NULL vs null for years.
>
> 8203327: Small cleanups in java.lang.ref
> http://cr.openjdk.java.net/~martin/webrevs/jdk/Reference-cleanup/
> https://bugs.openjdk.java.net/browse/JDK-8203327
JDK-8203028 which is
Hi,
On Fri, 2018-03-16 at 17:19 +, Ian Rogers wrote:
> Thanks Paul, very interesting.
>
> On Fri, Mar 16, 2018 at 9:21 AM Paul Sandoz
> wrote:
> > Hi Ian, Thomas,
> >
> > [...]
> > (This is also something we need to consider if we modify buffers to
> > support capacities larger than Integer
Hi,
On Thu, 2018-03-15 at 01:00 +, Ian Rogers wrote:
> An old data point on how large a critical region should be comes from
> java.nio.Bits. In JDK 9 the code migrated into unsafe, but in JDK 8
> the copies within a critical region were bound at most copying 1MB:
> http://hg.openjdk.java.net/
Hi,
On Wed, 2018-02-14 at 13:45 -0800, sangheon.kim wrote:
> Hi all,
>
> Could I have some reviews for CMM removal?
> This is closed CR but some public codes also need small
> modifications.
> This CR is for removing stuff related to an Oracle JDK
> module/package.
> Changes are just removing CM
Hi,
On Fri, 2017-11-24 at 14:13 +0100, Per Liden wrote:
> The clock and timestamp fields in SoftReference should be declared
> volatile. These fields are read or updated by the VM, (possibly)
> concurrently with the execution of Java threads.
>
> To be more specific, the timestamp field is read
Hi Kim,
On Wed, 2015-07-29 at 03:57 -0400, Kim Barrett wrote:
> Please review this fix of a race condition in
> j.l.r.Reference/ReferenceQueue. See comments in the bug report for a
> description of the race. The race is being fixed by reordering a pair
> of volatile assignments.
>
> CR:
> https
Hi,
On Sun, 2015-06-07 at 10:46 +0200, Peter Levart wrote:
> Hi,
>
> On 06/05/2015 11:11 PM, Jonathan Payne wrote:
> > My problem was that finalization was not being run at all with the G1
>>collector. Not at all. That would have been fine with me because none
>>of the existing objects in the Fin
Hi,
On Wed, 2013-08-14 at 10:43 +0100, Alan Bateman wrote:
> Mandy is just back from vacation and might not have got to your mail
> yet. However it's not clear to me that there is an actual problem as it
> looks like you've just ended up with two heads, maybe a hg fetch when
> you had changes w
Hi all,
could somebody take care of the missing merge for the fix below?
Thanks,
Thomas
Forwarded Message
> From: Thomas Schatzl
> To: mandy.ch...@oracle.com
> Subject: Missing merge for 8014890: Reference queues may return more
> entries than expected
> Da
Hi,
On Fri, 2013-07-12 at 19:22 +0800, Mandy Chung wrote:
> Hi Thomas,
>
> On 7/1/2013 7:51 PM, Thomas Schatzl wrote:
> > I changed this in
> > http://cr.openjdk.java.net/~tschatzl/8014890/webrev.refactor to that
> > version now, using a temporary variable tha
Hi all,
On Mon, 2013-07-01 at 15:44 +0400, Aleksey Shipilev wrote:
> On 07/01/2013 03:37 PM, David Holmes wrote:
> > On 1/07/2013 8:14 PM, Aleksey Shipilev wrote:
> >> The same "thou shalt not do multiple volatile reads" applies to
> >> "(r.queue == NULL) || (r.queue == ENQUEUED)" now.
> >
> > D
Hi David,
On Mon, 2013-07-01 at 17:51 +1000, David Holmes wrote:
> Well you can ignore what I wrote below - sorry. Somehow I got it in my
> head that multiple enqueue's were intended/supported when of course they
> are not. :(
>
> So the proposed fix is okay - though I'd simplify the comment to
Hi,
On Wed, 2013-06-19 at 17:56 +0400, Aleksey Shipilev wrote:
> On 06/19/2013 04:05 PM, David Holmes wrote:
> > I think I'm going to need a lot more time to understand this issue
> > completely. The synchronization being used seems complex and
> > somewhat ill-defined, and also inadequate. I'm n
Hi,
On Wed, 2013-06-19 at 09:25 +0200, Thomas Schatzl wrote:
> Hi,
>
> On Tue, 2013-06-18 at 15:53 -0700, Mandy Chung wrote:
> > Hi Thomas,
> >
> > Thanks for the detailed analysis.
> > > http://cr.openjdk.java.net/~tschatzl/8014890/webrev/
> >
> &
Hi Peter,
On Wed, 2013-06-19 at 11:05 +0200, Peter Levart wrote:
> On 06/19/2013 09:17 AM, Thomas Schatzl wrote:
> > Hi,
> >
> > On Wed, 2013-06-19 at 12:47 +1000, David Holmes wrote:
> >> Hi Thomas,
> >>
> >> On 19/06/2013 7:08 AM, Thomas Schatzl
Hi,
one more note :)
On Wed, 2013-06-19 at 09:28 +0200, Thomas Schatzl wrote:
> Hi again,
>
> some correction...
>
> On Wed, 2013-06-19 at 09:17 +0200, Thomas Schatzl wrote:
> > Hi,
> >
> > On Wed, 2013-06-19 at 12:47 +1000, David Holmes wrote:
> > &g
Hi again,
some correction...
On Wed, 2013-06-19 at 09:17 +0200, Thomas Schatzl wrote:
> Hi,
>
> On Wed, 2013-06-19 at 12:47 +1000, David Holmes wrote:
> > Hi Thomas,
> >
> > On 19/06/2013 7:08 AM, Thomas Schatzl wrote:
> > > Hi all,
> > >
> &g
Hi,
On Tue, 2013-06-18 at 15:53 -0700, Mandy Chung wrote:
> Hi Thomas,
>
> Thanks for the detailed analysis.
> > http://cr.openjdk.java.net/~tschatzl/8014890/webrev/
>
> The fix looks good. I was able to reproduce the failure with the
> test case in the bug report running with jdk8 b94 fastdebu
Hi,
On Wed, 2013-06-19 at 12:47 +1000, David Holmes wrote:
> Hi Thomas,
>
> On 19/06/2013 7:08 AM, Thomas Schatzl wrote:
> > Hi all,
> >
> >can I have reviews for the following change?
> >
> > It happens if multiple threads are enqueuing and dequeuing
Hi all,
can I have reviews for the following change?
It happens if multiple threads are enqueuing and dequeuing reference
objects into a reference queue, that Reference objects may be enqueued
at multiple times.
This is because when java.lang.ref.ReferenceQueue.poll() returns and
inactivates a
Hi,
On Fri, 2013-05-24 at 09:09 +0100, Alan Bateman wrote:
> On 24/05/2013 08:20, Thomas Schatzl wrote:
> > Hi all,
> >
> > On Fri, 2013-05-24 at 14:30 +1000, David Holmes wrote:
> >> Thomas,
> >>
> >> Are we still waiting for a second core-libs
/
Thomas
>
> David
>
> On 17/05/2013 5:56 PM, Thomas Schatzl wrote:
> > On Fri, 2013-05-17 at 10:47 +1000, David Holmes wrote:
> >> On 16/05/2013 8:44 PM, Thomas Schatzl wrote:
> >>> On Mon, 2013-05-13 at 13:55 +0200, Thomas Schatzl wrote:
> &
On Fri, 2013-05-17 at 10:47 +1000, David Holmes wrote:
> On 16/05/2013 8:44 PM, Thomas Schatzl wrote:
> > On Mon, 2013-05-13 at 13:55 +0200, Thomas Schatzl wrote:
> >>I updated the test program and the patch in java.lang.ref.Reference
> >> accordingly.
>
Hi,
On Sat, 2013-05-11 at 09:45 +1000, David Holmes wrote:
> On 11/05/2013 6:53 AM, Dean Long wrote:
> > On 5/10/2013 1:22 PM, Peter Levart wrote:
> >>
> >> On 05/10/2013 10:08 PM, Peter Levart wrote:
> >>>
> >>> On 05/10/2013 08:10 PM, Dean Long wrote:
> If you really want to bullet-proof Re
Hi all,
On Mon, 2013-05-13 at 13:55 +0200, Thomas Schatzl wrote:
> Hi all,
>
> I updated the test program and the patch in java.lang.ref.Reference
> accordingly.
>
> As for the problem of reproducibility, in my tests I had a 100%
> reproduction rate with the previou
Hi all,
On Fri, 2013-05-10 at 12:52 +0200, Peter Levart wrote:
> Hi David, Thomas,
>
> I think I understand you now, David. You want to minimize the
> possibility of vacuously passing the test. So here's my attempt at that:
>
>
> public class OOMEInReferenceHandler {
> static Object[] fil
Hi,
please review the latest webrev for this patch that is available at
http://cr.openjdk.java.net/~tschatzl/7038914/webrev.2/
As mentioned, it incorporates the fix and reproducer from Peter Levart.
Bugs.sun.com:
http://bugs.sun.com/view_bug.do?bug_id=7038914
JIRA:
https://jbs.oracle.com/bug
Hi,
On Tue, 2013-05-07 at 16:10 +0200, Peter Levart wrote:
> On 05/07/2013 03:26 PM, Thomas Schatzl wrote:
> > Hi,
>
> > There is a message emitted by the VM reading "java.lang.OutOfMemoryError
> > thrown from the UncaughtExceptionHandler in thread "Reference H
Hi,
On Tue, 2013-05-07 at 15:12 +0200, Peter Levart wrote:
> On 05/07/2013 09:51 AM, Thomas Schatzl wrote:
> > Hi all,
> >
> > On Tue, 2013-05-07 at 12:31 +1000, David Holmes wrote:
> >> Catching ThreadDeath is futile. If someone is invoking stop() then you
>
Hi all,
On Tue, 2013-05-07 at 12:31 +1000, David Holmes wrote:
> Catching ThreadDeath is futile. If someone is invoking stop() then you
> can encounter the ThreadDeath anywhere and it is impossible to write
> completely robust code in the face of such an async exception. So please
> let's not e
Hi,
On Sat, 2013-05-04 at 21:23 +0200, Peter Levart wrote:
>
> On 05/04/2013 07:38 PM, Vitaly Davidovich wrote:
>
> > Oops, that was my mistake - I thought the lock here was a j.u.c.Lock
> > which of course doesn't even make sense given we're talking about
> > ObjectMonitor. So disregard that b
Hi,
>
> Hi Tomas,
>
> I don't know if this is the case here, but what if the
> ReferenceHandler thread is interrupted while wait()-ing and the
> construction of InterruptedException triggers OOME?
I am sure this is the case - previously I thought InterruptedException
is a preallocated exception
Hi,
On Tue, 2013-04-30 at 16:44 +0100, Alan Bateman wrote:
> On 30/04/2013 15:57, Thomas Schatzl wrote:
> > Hi all,
> >
> >the webrev at http://cr.openjdk.java.net/~tschatzl/7038914/webrev/
> > presents a first stab at the CR "7038914: VM could throw uncau
Hi all,
the webrev at http://cr.openjdk.java.net/~tschatzl/7038914/webrev/
presents a first stab at the CR "7038914: VM could throw uncaught OOME
in ReferenceHandler thread".
The problem is that under very heavy memory pressure, there is the
reference handler throws an exception with the messag
62 matches
Mail list logo
