On 1/2/07, Robin Garner <[EMAIL PROTECTED]> wrote:
- Finalizers should be run with high priority because memory (possibly
large structures) can't be freed until they have completed.
I agree, In described case it should work with high priority.
In current finalization scheme if garbage col
On 1/2/07, Weldon Washburn <[EMAIL PROTECTED]> wrote:
Yes with one reservation. I'd like to see the existing DRLVM
mechanisms hard coded for just one finalizer thread for now. And that no
finalizer code be committed that suspends/resumes java app threads. The
intention is to reduce debug con
On 12/27/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
On Dec 27, 2006, at 9:34 PM, Weldon Washburn wrote:
> On 12/27/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote
>
>
>
>> [snip]
>
>> Why can't we simply mimic the rational behavior of the RI and other
>> production VMs and leave it at
On Jan 1, 2007, at 11:05 PM, Robin Garner wrote:
From what I've seen to date, all the available DRLVM mechanisms are
perfectly adequate, and we should all get back to doing something
productive.
That's a bit harsh. Clearly someone has an interest in this. :)
I think that Weldon, Pav
and we should all get back to doing something
productive.
Good point. As painful as it is, hammering out a workable design is
actually productive. Robin, thanks for bearing with us through this
process. As usual, your input is valuable.
Sorry didn't mean to sound so negative. I've foll
On 1/1/07, Robin Garner <[EMAIL PROTECTED]> wrote:
Pavel Afremov wrote:
> On 12/31/06, Weldon Washburn <[EMAIL PROTECTED]> wrote:
>>
>> This looks good to me. Its close enough for the current state of
>> drlvm. In
>> other words, don't try to precisely replicate the performance numbers I
>> co
Pavel Afremov wrote:
On 12/31/06, Weldon Washburn <[EMAIL PROTECTED]> wrote:
This looks good to me. Its close enough for the current state of
drlvm. In
other words, don't try to precisely replicate the performance numbers I
collected from Sun 1.5.0.
1/50 ratio with usual work load for fin
On 12/31/06, Weldon Washburn <[EMAIL PROTECTED]> wrote:
This looks good to me. Its close enough for the current state of
drlvm. In
other words, don't try to precisely replicate the performance numbers I
collected from Sun 1.5.0.
1/50 ratio with usual work load for finalization system is no
If we'd like to copy the commercial VM behavior we can write several
synthetic tests, and try to reach the same behavior. And if any test works
on RI it should works on DRLVM.
Or we can optimize DRLVM for defined set of applications. Let's choose one
of the way here, at first.
Happy New Year
On Dec 31, 2006, at 10:18 AM, Weldon Washburn wrote:
On 12/29/06, Pavel Afremov <[EMAIL PROTECTED]> wrote:
I've checked Weldon's finalization scheme and two existing schemes on
Weldon's test in mode 1 and 2.
On my Machine WinXP HT Pentium 4 I've got following results.
Weldon's design (on my
On 12/29/06, Pavel Afremov <[EMAIL PROTECTED]> wrote:
I've checked Weldon's finalization scheme and two existing schemes on
Weldon's test in mode 1 and 2.
On my Machine WinXP HT Pentium 4 I've got following results.
Weldon's design (on my machine 2 threads with highest priority).
Mod
Also this test shows that during printing many objects are created, maybe
include finalizable objects.
Could anybody run Weldon's test on current DRLVM implementation on the other
machine? The result ratio should be ready after 10 min of the run. It will
be very useful in the future.
Thanks
P
I've checked Weldon's finalization scheme and two existing schemes on
Weldon's test in mode 1 and 2.
On my Machine WinXP HT Pentium 4 I've got following results.
Weldon's design (on my machine 2 threads with highest priority).
Mode 1: 1/50 (main loop/finalizer call)
Mode 2:
JFYI
The current GC-finalization Subsystem interface and intercommoning
communication described in DevGuide. And now there are two finalization
implementation: multithreading one based on java thread and the other new
(created for GC5), based on 1 native thread.
On usual, multithreading imple
On Dec 28, 2006, at 1:54 PM, Rana Dasgupta wrote:
GCV5 does not need a custom finalizer. That is what would impact
modularity.
In fact, even that would not, if the interface were standardised.
However, one would prefer GC's not to provide their own
implementations for
the interface since th
GCV5 does not need a custom finalizer. That is what would impact modularity.
In fact, even that would not, if the interface were standardised.
However, one would prefer GC's not to provide their own implementations for
the interface since they are not fully aware of system load, and the GC dll
can
On Dec 28, 2006, at 11:33 AM, Rana Dasgupta wrote:
On 12/28/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
>Well, we need a finalizer. I agree that we're overthinking this a
>bit, but I'd like to understand why anyone thinks this belongs in
the
>GC - we keep claiming to do a modular
On 12/28/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
>Well, we need a finalizer. I agree that we're overthinking this a
>bit, but I'd like to understand why anyone thinks this belongs in the
>GC - we keep claiming to do a modular VM, yet then do things like
>this... :)
We can keep th
On Dec 28, 2006, at 11:01 AM, Rana Dasgupta wrote:
On 12/28/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
>Question - why would this be part of the GC system, rather than a VM
>facility that the GC uses?
It is a VM faciity, but the only consumer is the GC. So it doesn't
matter
whe
On 12/28/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
>Question - why would this be part of the GC system, rather than a VM
>facility that the GC uses?
It is a VM faciity, but the only consumer is the GC. So it doesn't matter
where the code lives.
Finalization is hardly ever used inte
Did you check it on current implementation of DRLVM Finalization System?
BR
Pavel Afremov.
On 12/28/06, Weldon Washburn <[EMAIL PROTECTED]> wrote:
On 12/27/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote
> [snip]
> Why can't we simply mimic the rational behavior of the RI and other
>
+1 Why?
It should be VM subsystem or independent component, I believe.
BR
Pavel Afremov.
On 12/28/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
On Dec 28, 2006, at 9:33 AM, Xiao-Feng Li wrote:
> On 12/28/06, Weldon Washburn <[EMAIL PROTECTED]> wrote:
>> On 12/27/06, Geir Magnusson Jr
On Dec 28, 2006, at 9:33 AM, Xiao-Feng Li wrote:
On 12/28/06, Weldon Washburn <[EMAIL PROTECTED]> wrote:
On 12/27/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote
[SNIP]
Mode 2
Again the JVM is running exactly 7 threads. Only the one object's
finalize() method is ever called. Process
On 12/28/06, Weldon Washburn <[EMAIL PROTECTED]> wrote:
On 12/27/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote
> [snip]
> Why can't we simply mimic the rational behavior of the RI and other
> production VMs and leave it at that?
>
> geir
I agree. To discover what other JVMs do, I cr
Wow - same number of threads? I'd have never guessed that.
geir
On Dec 28, 2006, at 6:26 AM, Tim Ellison wrote:
I ran your test on IBM Java 5.0, and saw similar results. I was using
the SysInternals processViewer so the details may not quite match up,
but in each case there were seven thread
I ran your test on IBM Java 5.0, and saw similar results. I was using
the SysInternals processViewer so the details may not quite match up,
but in each case there were seven threads created, and the scenario you
described below of threads making progress appear to jive with my
observations. Let m
On Dec 27, 2006, at 9:34 PM, Weldon Washburn wrote:
On 12/27/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote
[snip]
Why can't we simply mimic the rational behavior of the RI and other
production VMs and leave it at that?
geir
I agree. To discover what other JVMs do, I created a
On 12/27/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote
[snip]
Why can't we simply mimic the rational behavior of the RI and other
production VMs and leave it at that?
geir
I agree. To discover what other JVMs do, I created a very simple finalizer
probe then put it in JIRA HARMON
On 12/27/06, Pavel Afremov <[EMAIL PROTECTED]> wrote:
Oh. I see. In your proposal threads quantity isn't changed. It's a
difference. I see.
So on Intel Core 2 Quad, for example, VM will have 4 permanent high
priority finalaser threads. Is it correct?
Yes. That is the proposal for this sta
Oh. I see. In your proposal threads quantity isn't changed. It's a
difference. I see.
So on Intel Core 2 Quad, for example, VM will have 4 permanent high
priority finalaser threads. Is it correct?
BR
On 12/27/06, Weldon Washburn <[EMAIL PROTECTED]> wrote:
On 12/26/06, Pavel Afremov <[EMAIL
On Dec 26, 2006, at 8:30 PM, Xiao-Feng Li wrote:
On 12/27/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
On Dec 26, 2006, at 10:53 AM, Weldon Washburn wrote:
>
> 5)
> How are real java apps designed? What do they really use finalizer
> for?
I don't believe that people use them anymore.
On 12/26/06, Weldon Washburn <[EMAIL PROTECTED]> wrote:
On 12/25/06, Gregory Shimansky <[EMAIL PROTECTED]> wrote:
>
> Weldon Washburn wrote:
> > On 12/24/06, Gregory Shimansky <[EMAIL PROTECTED]> wrote:
> >>
> >> On Sunday 24 December 2006 16:23 Weldon Washburn wrote:
> [snip]
This is a very
On 12/27/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
On Dec 26, 2006, at 10:53 AM, Weldon Washburn wrote:
> On 12/26/06, Gregory Shimansky <[EMAIL PROTECTED]> wrote:
>>
>> 2006/12/26, Weldon Washburn <[EMAIL PROTECTED]>:
>> >
>> > On 12/25/06, Gregory Shimansky <[EMAIL PROTECTED]> wrote:
On Dec 26, 2006, at 10:53 AM, Weldon Washburn wrote:
On 12/26/06, Gregory Shimansky <[EMAIL PROTECTED]> wrote:
2006/12/26, Weldon Washburn <[EMAIL PROTECTED]>:
>
> On 12/25/06, Gregory Shimansky <[EMAIL PROTECTED]> wrote:
> >
> > Weldon Washburn wrote:
> > > On 12/24/06, Gregory Shimansky <[E
On Dec 25, 2006, at 5:45 PM, Weldon Washburn wrote:
On 12/24/06, Gregory Shimansky <[EMAIL PROTECTED]> wrote:
On Sunday 24 December 2006 16:23 Weldon Washburn wrote:
> Very interesting. Please tell me if the following is correct.
Without
> WBS, finalizing objects falls further and furthe
On 12/26/06, Pavel Afremov <[EMAIL PROTECTED]> wrote:
Hi.
On 12/19/06, in "[drlvm][gcv5] finalizer design" thread I wrote,
that "WBS
should increase relative finalization performance by following steps:
- Increase number of finalizer threads while them quantity is less
then processors num
Hi.
On 12/19/06, in "[drlvm][gcv5] finalizer design" thread I wrote, that "WBS
should increase relative finalization performance by following steps:
- Increase number of finalizer threads while them quantity is less
then processors number.
- Using locks for stopping user threads. I have s
On 12/26/06, Gregory Shimansky <[EMAIL PROTECTED]> wrote:
2006/12/26, Weldon Washburn <[EMAIL PROTECTED]>:
>
> On 12/25/06, Gregory Shimansky <[EMAIL PROTECTED]> wrote:
> >
> > Weldon Washburn wrote:
> > > On 12/24/06, Gregory Shimansky <[EMAIL PROTECTED]> wrote:
> > >>
> > >> On Sunday 24 Decem
2006/12/26, Weldon Washburn <[EMAIL PROTECTED]>:
On 12/25/06, Gregory Shimansky <[EMAIL PROTECTED]> wrote:
>
> Weldon Washburn wrote:
> > On 12/24/06, Gregory Shimansky <[EMAIL PROTECTED]> wrote:
> >>
> >> On Sunday 24 December 2006 16:23 Weldon Washburn wrote:
> [snip]
This is a very good i
On 12/25/06, Gregory Shimansky <[EMAIL PROTECTED]> wrote:
Weldon Washburn wrote:
> On 12/24/06, Gregory Shimansky <[EMAIL PROTECTED]> wrote:
>>
>> On Sunday 24 December 2006 16:23 Weldon Washburn wrote:
[snip]
This is a very good investigation, looks like this is exactly the way
that produ
Weldon Washburn wrote:
On 12/24/06, Gregory Shimansky <[EMAIL PROTECTED]> wrote:
On Sunday 24 December 2006 16:23 Weldon Washburn wrote:
> Very interesting. Please tell me if the following is correct. Without
> WBS, finalizing objects falls further and further behind because
> finalization th
On 12/24/06, Gregory Shimansky <[EMAIL PROTECTED]> wrote:
On Sunday 24 December 2006 16:23 Weldon Washburn wrote:
> Very interesting. Please tell me if the following is correct. Without
> WBS, finalizing objects falls further and further behind because
> finalization thread(s) are unable to gr
On Sunday 24 December 2006 16:23 Weldon Washburn wrote:
> Very interesting. Please tell me if the following is correct. Without
> WBS, finalizing objects falls further and further behind because
> finalization thread(s) are unable to grab enough of the CPU(s) to keep up.
> Instead of increasing
On 12/23/06, Ivan Volosyuk <[EMAIL PROTECTED]> wrote:
On 12/22/06, Weldon Washburn <[EMAIL PROTECTED]> wrote:
> On 12/22/06, Mikhail Fursov <[EMAIL PROTECTED]> wrote:
> >
> > Weldon,
> > AFAIR without WBS it's an easy to write a test(we had such tests) that
> > will
> > work smoothly on SUN or B
On 12/22/06, Weldon Washburn <[EMAIL PROTECTED]> wrote:
On 12/22/06, Mikhail Fursov <[EMAIL PROTECTED]> wrote:
>
> Weldon,
> AFAIR without WBS it's an easy to write a test(we had such tests) that
> will
> work smoothly on SUN or BEA but fails on Harmony.
> Is "run any app RI is able to run" reaso
On 12/22/06, Mikhail Fursov <[EMAIL PROTECTED]> wrote:
Weldon,
AFAIR without WBS it's an easy to write a test(we had such tests) that
will
work smoothly on SUN or BEA but fails on Harmony.
Is "run any app RI is able to run" reason enough?
Yes indeed this is reason enough for this stage of Har
Weldon,
AFAIR without WBS it's an easy to write a test(we had such tests) that will
work smoothly on SUN or BEA but fails on Harmony.
Is "run any app RI is able to run" reason enough?
On 12/22/06, Weldon Washburn <[EMAIL PROTECTED]> wrote:
The existing VM finalizer system has something called a
The existing VM finalizer system has something called a Work Balancing
System. It would be good to know the motivation for this feature. If this
feature was built for specific workloads, please tell us which ones.
Thanks
--
Weldon Washburn
Intel Enterprise Solutions Software Division
48 matches
Mail list logo
