On Mon, Jul 14, 2025 at 10:14 AM fabioromano1 wrote:
>
> On Sat, 12 Jul 2025 09:18:27 GMT, fabioromano1 wrote:
>
> >> This PR implements nth root computation for BigIntegers using Newton
method.
> >
> > fabioromano1 has updated the pull request incrementally with one
additional commit since the l
On Fri, Jul 11, 2025 at 11:44 AM fabioromano1 wrote:
>
> On Fri, 11 Jul 2025 18:07:31 GMT, fabioromano1 wrote:
>
> >> This PR implements nth root computation for BigIntegers using Newton
method.
> >
> > fabioromano1 has updated the pull request incrementally with one
additional commit since the l
Apologies if this has been discussed before.
The explanation for the exception for negative n ("This would cause
the operation to yield a non-integer value.") feels wrong to me. I think
the definition of the result as: x.signum() * floor(abs(nthRoot(x, n)))
works fine for that case, if nthRoot(x,-
On Fri, Apr 11, 2025 at 2:39 PM Roger Riggs wrote:
> On Fri, 11 Apr 2025 20:09:10 GMT, Brent Christian
> wrote:
>
> test/lib/jdk/test/whitebox/WhiteBox.java line 568:
>
> > 566: private Method getWaitForReferenceProcessingMethod() {
> > 567: Method wfrp = waitForReferenceProcessingMethod;
On Mon, May 13, 2024 at 12:16 PM Brent Christian
wrote:
> On 5/10/24 10:54 AM, Hans Boehm wrote:
> > I'm not convinced this helps.
> >
> > The isAlive() spec says:
> >
> > "A thread is alive if it has been started and has not yet terminated."
>
I'm not convinced this helps.
The isAlive() spec says:
"A thread is alive if it has been started and has not yet terminated."
Clearly an object is reachable if it can be accessed by a thread that will
be started in the future. Is that part of a "potential continuing
computation from any live thr
Is it worth keeping the discussion starting with "It is sometimes possible
to better encapsulate ..." and the associated example code? I find this
example extremely unconvincing. It's very hard to construct a case in which
you can safely use the result of getExternalResource(). And I don't want to
On Thu, 25 Jan 2024 23:09:51 GMT, Brent Christian wrote:
>> Classes in the `java.lang.ref` package would benefit from an update to bring
>> the spec in line with how the VM already behaves. The changes would focus on
>> _happens-before_ edges at some key points during reference processing.
>>
On Mon, 13 Nov 2023 22:31:16 GMT, Brent Christian wrote:
> Classes in the `java.lang.ref` package would benefit from an update to bring
> the spec in line with how the VM already behaves. The changes would focus on
> _happens-before_ edges at some key points during reference processing.
>
> A
On Tue, 21 Nov 2023 22:58:09 GMT, Roger Riggs wrote:
>> Classes in the `java.lang.ref` package would benefit from an update to bring
>> the spec in line with how the VM already behaves. The changes would focus on
>> _happens-before_ edges at some key points during reference processing.
>>
>> A
On Mon, 13 Nov 2023 22:31:16 GMT, Brent Christian wrote:
> Classes in the `java.lang.ref` package would benefit from an update to bring
> the spec in line with how the VM already behaves. The changes would focus on
> _happens-before_ edges at some key points during reference processing.
>
> A
Since I think this is about asymptotic complexity, which is determined by
behavior on large inputs, is there a reason to talk about switching to
other algorithms on smaller inputs? We certainly don't want to get into the
habit of listing "easy case" optimizations everywhere.
I'm unclear about the
On Tue, Aug 2, 2022 at 7:43 PM Stuart Marks wrote:
> ...
> Setting this aside, it does seem like all uses of a cleanable object need
> to have a try/finally statement, with at least an RF in the finally clause.
> Is there any evidence that shows that this construct isn't needed?
>
I think the rea
On Mon, Jul 25, 2022 at 10:30 PM Stuart Marks wrote:
...
>
> Hans Boehm wrote:
>
> > I also have concerns about the use of fullFence here. I believe it
should be the case that reachabilityFence guarantees visibility
> > of memory operations program-ordered before the reacha
I also have concerns about the use of fullFence here. I believe it should
be the case that reachabilityFence guarantees visibility of memory
operations program-ordered before the reachabilityFence(p) to the Cleaner
associated with p. Mutator-collector synchronization should normally ensure
that. On
15 matches
Mail list logo
