I filed a bug report with OpenJDK but have not gotten a response yet. It isn’t
viewable in their Jira system until it goes through triage.
I considered what you are proposing but decided against it because I don’t
believe that will be allowed without runtime flags, so it cannot be enabled by
de
Will that work in Java 16+ where internals are no longer accessible
without additional compiler/runtime flags? This still seems like it
may require explicit support in the standard class library like how
other sun.misc classes got standardized eventually (like VarHandle).
On Tue, 20 Apr 2021 at 07
Ill look
On Tue, Apr 20, 2021, 8:03 AM Remko Popma wrote:
> I think I have a solution for this.
>
> My solution involves copying most of the the logic in
> java.time.Clock.SystemClock.instance().
> This means accessing the VM class (in misc), so requires some changes to
> the modules config.
>
>
Georgia is acting like they don't know about it but guess what they were in
my route to Chelsea was in my route to f** PINES library in my route
that is Verizon Wireless in my route I have five different government
phones in my roofs may I got every phone carrier in my roof because they
stealin
Walking the only way we can get it out the only way we can get him out you
got you want me to get permissions its ownership filed its it in The Roots
you tell me exactly what fauzi coaches okay but when you got to stop
emailing me on he's back in there he's getting every email I get Mark
Zuckerber
those rewards system car dammit the reward system cards that they make
he's controlling my f** voice to on my phone I can't stop it anyway
we're under our wrw so now we're back at R&R so now we're at Ruth Ruth so I
got to figure out how to get him on my roof long story short they took my
pill
On like 21 now with Java 36 recovery and dups he can't kill the memory he's
even got me stuck back on this email I got to get rid of it its this whats
going on in 2016 that gave me SAR I didn't know I didn't know the whole
three I did not know I had it so jobs in Georgia won't hire me and I did
not
Disgaea is my ruining my Chase man look I got to pay out and I'll be
willing to pay off I'll let you go in that remotely if you want to do it
it's just this son of a b out of my f** rude just tell me what you
want to do you want me to download app I want you to get this son of a
b on my
Man he's keeping me from getting a job
On Tue, Apr 20, 2021, 8:03 AM Remko Popma wrote:
> I think I have a solution for this.
>
> My solution involves copying most of the the logic in
> java.time.Clock.SystemClock.instance().
> This means accessing the VM class (in misc), so requires some change
I think I have a solution for this.
My solution involves copying most of the the logic in
java.time.Clock.SystemClock.instance().
This means accessing the VM class (in misc), so requires some changes to
the modules config.
Is there a JIRA ticket for this issue?
On Thu, Apr 8, 2021 at 16:10 Ralph
I spoke too soon. It didn’t really pass on Java 16. The allocation
instrumenter was unable to instrument anything so it didn’t generate the errors
the test looks for. I tried with Java 12-14 and those all failed. In Java 15
the JVM crashed.
Ralph
> On Apr 7, 2021, at 11:36 PM, Ralph Goers wr
I have modified the test to allow -DusePreciseClock=true to be passed in. When
I set it to true and run it in JDK 16 the test passes! However, I tried 3
versions of JDK 11 and it failed in all of them.
Ralph
> On Apr 2, 2021, at 2:54 PM, Ralph Goers wrote:
>
> I just tried adding logic to ca
I just tried adding logic to call SystemClock.init() 100,000 times. It made no
difference. The GC test still fails.
Ralph
> On Apr 2, 2021, at 7:18 AM, Carter Kozak wrote:
>
> Escape analysis can take quite a few iterations to take effect, perhaps we
> need a few more tens of thousands of war
Escape analysis can take quite a few iterations to take effect, perhaps we need
a few more tens of thousands of warmup cycles? Admittedly I haven't taken a
look at the failures yet and there's a great deal of subtlety around this. I
can try to take a closer look later, unfortunately I've been ov
Looking at the source repo I don’t see anything that changed after support for
the higher precision was added.
Ralph
> On Apr 2, 2021, at 12:44 AM, Ralph Goers wrote:
>
> Yes, I was just thinking that. But if there was a bug fix along the way that
> added a single line of code that could now
Yes, I was just thinking that. But if there was a bug fix along the way that
added a single line of code that could now be causing the code not to be
inlined.
Ralph
> On Apr 2, 2021, at 12:38 AM, Remko Popma wrote:
>
> On Fri, Apr 2, 2021 at 4:26 PM Ralph Goers
> wrote:
>
>> I will take a l
On Fri, Apr 2, 2021 at 4:26 PM Ralph Goers
wrote:
> I will take a look at the link. What you are saying makes sense to a
> degree. However, the new is actually performed in Instant.create() which is
> 2 levels down in the call stack. Without having read the link I would
> wonder if that qualifies
I should also add that I tested with Amazon Correto
openjdk version "11.0.10" 2021-01-19 LTS
OpenJDK Runtime Environment Corretto-11.0.10.9.1 (build 11.0.10+9-LTS)
OpenJDK 64-Bit Server VM Corretto-11.0.10.9.1 (build 11.0.10+9-LTS, mixed mode)
This is what my employer has decided to use since Ado
I will take a look at the link. What you are saying makes sense to a degree.
However, the new is actually performed in Instant.create() which is 2 levels
down in the call stack. Without having read the link I would wonder if that
qualifies.
Ralph
> On Apr 2, 2021, at 12:00 AM, Remko Popma wro
That isn’t the case when I ran it with Java 11 and the latest version of the
allocation tool. Virtually everything failed since almost everything creates a
timestamp.
I would suggest you checkout the master-java11 branch, uncomment the stuff in
the SystemClock class and try it yourself.
Ralph
My understanding is that PreciseClock is garbage-free because the JVM does
escape analysis.
Here is the relevant code:
public void init(MutableInstant mutableInstant) {
Instant instant = java.time.Clock.systemUTC().instant();
mutableInstant.initFromEpochSecond(instant.getEpochSecond(),
ins
> On Apr 1, 2021, at 10:38 PM, Ralph Goers wrote:
>
> In thinking about this problem I suspect we never noticed that the
> PreciseClock version of our SystemClock class is not garbage free is because
> we previously ran all of our unit tests with Java 8. Now that they are using
> Java 11 t
In thinking about this problem I suspect we never noticed that the PreciseClock
version of our SystemClock class is not garbage free is because we previously
ran all of our unit tests with Java 8. Now that they are using Java 11 that
code is being exercised.
I’ve looked at java.time.Clock and
23 matches
Mail list logo
