Аминь!
On Fri, Feb 15, 2008 at 4:11 PM, Alexey Varlamov
<[EMAIL PROTECTED]> wrote:
> Done: old verifier and gc_cc are moved out of trunk, gc_cc mode
> support is dropped (bti, drlvm build).
>
> --
> Alexey
>
> 2008/2/15, Gregory Shimansky <[EMAIL PROTECTED]>:
>
>
> > Tim Ellison said the follo
The article is available for everyone now:
http://lwn.net/Articles/250967/
--
Regards,
Ivan
On 9/26/07, Yuri Dolgov <[EMAIL PROTECTED]> wrote:
>
> Hello Mark,
>
> Thanks for detailed explanation. That's my mistake, I've missed that
> subscription is not free, and just used an easiest way to read
Hi guys,
I have found exceptionally interesting article about present day memory
technology.
It may be of interest for those who want to implement efficient memory
management subsystem (read GC) or thinks about efficient implementation of
various data containers or even system as whole.
This is t
On 2/16/07, Xiao-Feng Li <[EMAIL PROTECTED]> wrote:
On 2/15/07, Ivan Volosyuk <[EMAIL PROTECTED]> wrote:
> On 2/14/07, Xiao-Feng Li <[EMAIL PROTECTED]> wrote:
> > Some researchers seperate "on-the-fly" GC from concurrent GC as a
> > special case [3].
On 2/14/07, Xiao-Feng Li <[EMAIL PROTECTED]> wrote:
Some researchers seperate "on-the-fly" GC from concurrent GC as a
special case [3]. The difference as stated is "on-the-fly" GC doesn't
require any synchronization point where all mutators are suspended,
i.e., it suspends and resumes mutators on
t is not as good
> > > as using full fledged debugger to analyze the problem.
> > >
> > > > On 10 January 2007 at 21:07, Gregory Shimansky <[EMAIL PROTECTED]
> >
> > > wrote:
> > > >> Tim Ellison wrote:
> > > >>> I&
On 2/5/07, Rana Dasgupta <[EMAIL PROTECTED]> wrote:
On 2/5/07, Tim Ellison <[EMAIL PROTECTED]> wrote:
>
> Rana Dasgupta wrote:
> >> On 2/3/07, Xiao-Feng Li <[EMAIL PROTECTED]> wrote:
> >>>
> >>
> >>> >Tim, the pinned memory is required by the API spec. We have to
> support
> >>> >it either in VM
On 2/5/07, Tim Ellison <[EMAIL PROTECTED]> wrote:
Xiao-Feng Li wrote:
> On 2/5/07, Tim Ellison <[EMAIL PROTECTED]> wrote:
>> Xiao-Feng Li wrote:
>> > It's a little big strange to me if API encourages this kind of
>> > behavior that programmer grabs resources freely while relying on
>> > certain u
On 2/5/07, Tim Ellison <[EMAIL PROTECTED]> wrote:
Geir Magnusson Jr. wrote:
> On Feb 4, 2007, at 8:13 PM, Ivan Volosyuk wrote:
>> On 2/4/07, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
>>> I'm getting confused on where people think that this pro
On 2/5/07, Xiao-Feng Li <[EMAIL PROTECTED]> wrote:
On 2/5/07, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
>
> On Feb 4, 2007, at 8:24 PM, Ivan Volosyuk wrote:
>
> > On 2/5/07, Ivan Volosyuk <[EMAIL PROTECTED]> wrote:
> >> On 2/4/07, Ge
On 2/5/07, Ivan Volosyuk <[EMAIL PROTECTED]> wrote:
On 2/5/07, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
>
> On Feb 4, 2007, at 8:24 PM, Ivan Volosyuk wrote:
>
> > On 2/5/07, Ivan Volosyuk <[EMAIL PROTECTED]> wrote:
> >> On 2/4/07, Ge
On 2/5/07, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
On Feb 4, 2007, at 8:24 PM, Ivan Volosyuk wrote:
> On 2/5/07, Ivan Volosyuk <[EMAIL PROTECTED]> wrote:
>> On 2/4/07, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
>> >
>> > On Feb
On 2/5/07, Ivan Volosyuk <[EMAIL PROTECTED]> wrote:
On 2/4/07, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
>
> On Feb 4, 2007, at 8:41 AM, Gregory Shimansky wrote:
>
> > Leo Li wrote:
> >> On 2/4/07, Gregory Shimansky <[EMAIL PROTECTED]> wrote:
>
On 2/4/07, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
On Feb 4, 2007, at 8:41 AM, Gregory Shimansky wrote:
> Leo Li wrote:
>> On 2/4/07, Gregory Shimansky <[EMAIL PROTECTED]> wrote:
>>>
>>> I see no difference in the approach I've suggested already. If we
>>> have
>>> to take care about all
On 2/4/07, Gregory Shimansky <[EMAIL PROTECTED]> wrote:
Leo Li wrote:
> On 2/4/07, Gregory Shimansky <[EMAIL PROTECTED]> wrote:
>>
>> Ivan Volosyuk wrote:
>> > On 2/3/07, LvJimmy，Jing <[EMAIL PROTECTED]> wrote:
>> >> 2007/2/2, Xiao-Feng Li
thers like thread objects, zlib functionality and so
on, should also be addressed. Not all of this entities can be
converted to java objects.
On 2/3/07, Xiao-Feng Li <[EMAIL PROTECTED]> wrote:
On 2/3/07, Ivan Volosyuk <[EMAIL PROTECTED]> wrote:
> On 2/3/07, LvJimmy，Jing <[
On 2/3/07, Leo Li <[EMAIL PROTECTED]> wrote:
Thanks for all the advices.
Can we conclude that:
1. The problem is related to a series of problems, as Ivan summarized. It is
about the pattern to release native resources in java.
2. It is related to gc, if we do not intend to design another mechani
On 2/3/07, LvJimmy，Jing <[EMAIL PROTECTED]> wrote:
2007/2/2, Xiao-Feng Li <[EMAIL PROTECTED]>:
> Thank you, Jimmy and Leo, for the clear explanations.
>
> I think temporarily you can put the System.gc() there to workaround
> this issue. Yes, this is only a workaround since we cannot rely on it
>
Proactive freeing such native resources may lead to instability. We
don't have enough control of all references to that native resources.
On 2/3/07, Rana Dasgupta <[EMAIL PROTECTED]> wrote:
I don't know much about DirectByteBuffer implementation, but it would be
nice to keep the memory managemen
Yes, gc_cc has a hardcoded compressed pointers support. Adding dynamic
switching between compressed and uncompressed pointers is somewhere in
my todo list. I can make the changes if we going to go this way.
There is also some code in interpreter which compresses references in
interpreter stack. I
Let me summarize:
Sometimes we have small java heap objects which relates to much bigger
native memory chunks. In some cases this memory may exceed limits and
VM will crash. Calling GC from the other side will make this memory
free. There are quite a few place in VM and classlib which uses such
d
Hi All,
There is such problem for quite a while:
http://issues.apache.org/jira/browse/HARMONY-2881
Running VM with heap size 2.5Gb works fine on EM64T using interpreter
but it crashes if using jitrino. It seems that somewhere signed values
are used instead of unsigned ones or vice versa. Here is
Is the VM arguments for large TLB pages support are compatible with
the same of GCv4.1 or different? Just interesting. One more
observation, it makes sense to use large TLB pages for all VM
including classloader pools and other code not just for GC.
--
Ivan
On 1/24/07, Xiao-Feng Li <[EMAIL PROTEC
nd
disable it by default, and have an option to enable it for those that want.
Regards,
Tim
Ivan Volosyuk wrote:
> It seems that in cmain.c in function genericSignalHandler() just
> removing abort() statement will cause default system handler to
> execute pointing the exact place of fault right
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/16/06, Xiao-Feng Li <[EMAIL PROTECTED]> wrote:
All. It's good to see this discussion initiated. That's exactly what
we want. It would be a little frustrating to see our solution
committed without any response from the community. :-) Anyway, we
submitted GCv5 finalizer solution for three re
e:
Did You mean high priority forever? Or tuned priority of finalizer thread?
You wrote threads. How many threads You'd like to have?
Pavel.
On 12/11/06, Ivan Volosyuk <[EMAIL PROTECTED]> wrote:
>
> On 12/11/06, Pavel Afremov <[EMAIL PROTECTED]> wrote:
> > 3.
On 12/11/06, Pavel Afremov <[EMAIL PROTECTED]> wrote:
3. In Finalization system now there is Work Balance Mechanism which
tunes performance of finalization. When many finalizable object are
allocated and queue for finalization isn't empty this mechanism increase
performance of finalization
Helper code is equal. GC code is not. Lets compare apples with oranges.
--
Ivan
On 12/5/06, Mikhail Fursov <[EMAIL PROTECTED]> wrote:
The helpers code is equal, except this load. So if we have different
performance -> this extra memory access is the cause.
On 12/5/06, Ivan Volosyu
On 12/5/06, Xiao-Feng Li <[EMAIL PROTECTED]> wrote:
On 12/4/06, Robin Garner <[EMAIL PROTECTED]> wrote:
> > On 11/30/06, Robin Garner <[EMAIL PROTECTED]> wrote:
> >> Xiao-Feng Li wrote:
> >> >
> >> >/* If the slot is in NOS or the target is not in NOS, we simply
> >> > return*/
> >> >
I think in order to do this comparison, other conditions should be
equal. Comparing helper with 1 dependent load in gc_cc and helper with
2 dependent loads in gc_v5 makes no sense to me.
--
Ivan
On 12/5/06, Xiao-Feng Li <[EMAIL PROTECTED]> wrote:
On 12/5/06, Mikhail Fursov <[EMAIL PROTECTED]> wr
They need to benchmark computational part. Benchmarking with IO are
much more complex and not obvious to interpret.
BTW, IO implementation in classlib is highly inefficient, see HARMONY-2288.
--
Ivan
On 11/29/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
Sergey Kuksenko wrote:
> On 11/28/0
I will call it a bug in source base, because if we define inline
function in cpp file it should only be used inside it. Any public
inline functions should be defined in header files.
Intel compiler is much more aggressive for optimizations, this require
a cleaner code to be written in order to us
Most probably it should be an object with finalize() method. This was
done to prevent fast path allocation for such objects. This is a very
old code.
--
Ivan
On 11/30/06, Weldon Washburn <[EMAIL PROTECTED]> wrote:
Xiao Feng,
It would be great if you could publish something like a list of what t
Adding a write barrier fast path in current development stage is IMHO
a good idea.
+1
--
Ivan
On 11/29/06, Xiao-Feng Li <[EMAIL PROTECTED]> wrote:
Mikhail Fursov has finished the GC alloc helper inlining, it's
probably time to discuss the inlining for write barrier. Write barrier
is one of the t
Missing IPF version of exclude file. HARMONY-2266.
--
Ivan
On 11/21/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
As an interim step to track where we are as the build-test and
harmonytest.org keep evolving, I've created a wiki page :
http://wiki.apache.org/harmony/DRLVMTestTracking
tha
but removes a pain with freeing memory.
Ivan, Sergey, Oleg, what do you think?
On 11/17/06, Ivan Volosyuk <[EMAIL PROTECTED]> wrote:
> Sergey,
>
> It is ok to have not thread safe code in AWT implementation which can
> work incorrectly in some cases. It is not ok (IMHO) if the inco
37 matches
Mail list logo
