On Thu, 21 Jul 2022 22:33:36 GMT, Leonid Mesnik wrote:
> Propagate test.vm.opts/test.java.opts to tested process. Also, accept the
> output of non-generation (ZGC) GC as valid.
This pull request has now been integrated.
Changeset: 348a0521
Author:Leonid Mesnik
URL:
https://git.open
On Thu, 21 Jul 2022 22:33:36 GMT, Leonid Mesnik wrote:
> Propagate test.vm.opts/test.java.opts to tested process. Also, accept the
> output of non-generation (ZGC) GC as valid.
Looks good to me.
Thanks,
Serguei
-
Marked as reviewed by sspitsyn (Reviewer).
PR: https://git.openjdk.
On Thu, 21 Jul 2022 22:33:36 GMT, Leonid Mesnik wrote:
> Propagate test.vm.opts/test.java.opts to tested process. Also, accept the
> output of non-generation (ZGC) GC as valid.
Marked as reviewed by cjplummer (Reviewer).
-
PR: https://git.openjdk.org/jdk/pull/9604
On Wed, 27 Jul 2022 21:39:47 GMT, Leonid Mesnik wrote:
>> I meant shouldn't we see ZGC failures before your changes. Otherwise I don't
>> understand why this change is needed.
>
> Before my changes test just silently ignored any GC setting and always use G1.
Ah, ok. That makes sense now.
-
On Fri, 22 Jul 2022 19:27:29 GMT, Chris Plummer wrote:
>> No, test passes with ZGC.
>
> I meant shouldn't we see ZGC failures before your changes. Otherwise I don't
> understand why this change is needed.
Before my changes test just silently ignored any GC setting and always use G1.
--
On Fri, 22 Jul 2022 03:10:11 GMT, Leonid Mesnik wrote:
>> So shouldn't we have ZGC test failures then?
>
> No, test passes with ZGC.
I meant shouldn't we see ZGC failures before your changes. Otherwise I don't
understand why this change is needed.
-
PR: https://git.openjdk.org/jdk
The proposal is to encapsulate the nmethod mark for deoptimization logic in one
place and only allow access to the `mark_for_deoptimization` from a closure
object:
```C++
class DeoptimizationMarkerClosure : StackObj {
public:
virtual void marker_do(Deoptimization::MarkFn mark_fn) = 0;
};
This
On Mon, 11 Jul 2022 14:58:07 GMT, Axel Boldt-Christmas wrote:
> Currently the `RegisterMap` constructor uses implicit boolean arguments to
> configure its function. Implicit boolean arguments makes code harder to
> understand and reason about at the call site. Using explicit scoped enums
> ins
On Wed, 27 Jul 2022 09:45:25 GMT, Axel Boldt-Christmas wrote:
>> Currently the `RegisterMap` constructor uses implicit boolean arguments to
>> configure its function. Implicit boolean arguments makes code harder to
>> understand and reason about at the call site. Using explicit scoped enums
>>
> Currently the `RegisterMap` constructor uses implicit boolean arguments to
> configure its function. Implicit boolean arguments makes code harder to
> understand and reason about at the call site. Using explicit scoped enums
> instead makes it both clear what is being configured and the type s
On Tue, 26 Jul 2022 16:25:04 GMT, Thomas Schatzl wrote:
>> Currently the `RegisterMap` constructor uses implicit boolean arguments to
>> configure its function. Implicit boolean arguments makes code harder to
>> understand and reason about at the call site. Using explicit scoped enums
>> inste
11 matches
Mail list logo
