 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
http://www.infoq.com/news/2012/08/azul-zing-free
I am pretty sure this means it's real-time GC.
--
Darren New, San Diego CA, USA (PST)
"Oh no! We're out of code juice!"
"Don't panic. There's beans and filters
in the cabinet."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 12/08/2012 02:40, Darren New nous fit lire :
> http://www.infoq.com/news/2012/08/azul-zing-free
>
> I am pretty sure this means it's real-time GC.
>
there was already the trick of serial GC vs parallel GC (or how to get a
java application out of trouble when GC kick in, since JVM 5.0)
(GC: garbage collector)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 12/08/2012 01:40 AM, Darren New wrote:
> http://www.infoq.com/news/2012/08/azul-zing-free
>
> I am pretty sure this means it's real-time GC.
Oh thank God. They've had this magical silver bullet all along, and now
they've /finally/ released it to the rest of the world. How did we ever
manage without it? :-P
I like how the algorithm description is sufficiently vague that you
can't tell how it actually works. It claims to be able to mark
concurrently "without live objects escaping the collector's reach", but
doesn't explain how. It says it can delete a page after all objects have
been relocated, and it "detects" any attempt to access a moved object,
but again doesn't say how. (It sure /sounds/ like they're saying they do
some O(n) operation on every single pointer read, which is of course
absurd.) Come to think of it, they say they use page features to
implement some of this stuff - which is interesting, since only the OS
can do that...
Also,
"Initial in-memory tests on the full Wikipedia English-language site
index show Zing is truly pauseless while managing a heap in excess of
140 GB."
Since it's impossible to have a machine with 140GB of RAM, what's the
point of having a heap that large? It'll just spend forever swapping.
Surely you'd get far better performance by implementing some explicit
file handling yourself?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 8/12/2012 2:23, Orchid Win7 v1 wrote:
> I like how the algorithm description is sufficiently vague that you can't
> tell how it actually works.
It was four clicks away, with the previous three clicks giving successively
more detailed descriptions.
http://labs.oracle.com/jtech/pubs/04-g1-paper-ismm.pdf
You're welcome.
> it "detects" any attempt to access a moved object, but again doesn't say
> how.
Memory mapping. It traps on reading the memory that hasn't been fixed yet,
then fixed up the entire page worth of references, then marks the memory as
readable.
> Since it's impossible to have a machine with 140GB of RAM,
Since when is it impossible? We had 128G of RAM on the Sparcstation we used
back in 1995 or so. And that wasn't even a mainframe.
--
Darren New, San Diego CA, USA (PST)
"Oh no! We're out of code juice!"
"Don't panic. There's beans and filters
in the cabinet."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid Win7 v1 wrote:
> Since it's impossible to have a machine with 140GB of RAM, what's the
> point of having a heap that large? It'll just spend forever swapping.
> Surely you'd get far better performance by implementing some explicit
> file handling yourself?
I'm don't know why you might think that.
http://www.tacc.utexas.edu/user-services/user-guides/lonestar-user-guide#overview:upgrade:largemem
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 12/08/2012 05:27 PM, Darren New wrote:
> On 8/12/2012 2:23, Orchid Win7 v1 wrote:
>> I like how the algorithm description is sufficiently vague that you can't
>> tell how it actually works.
>
> It was four clicks away, with the previous three clicks giving
> successively more detailed descriptions.
>
> http://labs.oracle.com/jtech/pubs/04-g1-paper-ismm.pdf
>
> You're welcome.
No.
This is the GC from Sun, the GC that the Azul one is supposed to be
superior to.
>> it "detects" any attempt to access a moved object, but again doesn't say
>> how.
>
> Memory mapping. It traps on reading the memory that hasn't been fixed
> yet, then fixed up the entire page worth of references, then marks the
> memory as readable.
So you mean it relocates an entire page of live objects, and then uses
page faults to detect access to the non-existent page and lookup where
the data has gone?
The only problem with that, of course, is that paging is controlled by
the operating system, not by a user-level application program.
>> Since it's impossible to have a machine with 140GB of RAM,
>
> Since when is it impossible? We had 128G of RAM on the Sparcstation we
> used back in 1995 or so. And that wasn't even a mainframe.
That's interesting. Because in 1998, I did some work experience with BT.
One day I was showed into their main datacenter, and their most powerful
server was running off a RAID-5 array containing not one, not two, not
three, but SEVEN 4.2 GB drives. I remember feeling slightly giddy trying
to work out how many multiple gigabytes of data that thing must be able
to hold in total.
And you're claiming you had 100x more than that IN RAM? Somehow, I doubt it.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 12.08.2012 11:23, schrieb Orchid Win7 v1:
> Come to think of it, they say they use page features to
> implement some of this stuff - which is interesting, since only the OS
> can do that...
"Three successive generations of Azul's Vega series systems relied on
custom multi-core processors and a custom OS kernel to deliver both the
scale and features needed to support Pauseless GC. In 2010, Azul
released its first software-only commercial implementation of C4 for
modern commodity X86 hardware, using Linux kernel enhancements to
support the required feature set."
Virtualization features maybe, dunno.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 13/08/2012 10:47 AM, clipka wrote:
> Am 12.08.2012 11:23, schrieb Orchid Win7 v1:
>
>> Come to think of it, they say they use page features to
>> implement some of this stuff - which is interesting, since only the OS
>> can do that...
>
> "Three successive generations of Azul's Vega series systems relied on
> custom multi-core processors and a custom OS kernel to deliver both the
> scale and features needed to support Pauseless GC. In 2010, Azul
> released its first software-only commercial implementation of C4 for
> modern commodity X86 hardware, using Linux kernel enhancements to
> support the required feature set."
Oh, wait - you have to run a customised OS kernel for it to work? Yeah,
OK, that explains it then...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 12.08.2012 22:35, schrieb Orchid Win7 v1:
> So you mean it relocates an entire page of live objects, and then uses
> page faults to detect access to the non-existent page and lookup where
> the data has gone?
>
> The only problem with that, of course, is that paging is controlled by
> the operating system, not by a user-level application program.
Yes, of course. That's also why virtual machines are mind-bogglingly
slow and/or rely on specially patched OSes. Rrrright.
Andy, wake up.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 13.08.2012 11:48, schrieb Invisible:
> On 13/08/2012 10:47 AM, clipka wrote:
>> Am 12.08.2012 11:23, schrieb Orchid Win7 v1:
>>
>>> Come to think of it, they say they use page features to
>>> implement some of this stuff - which is interesting, since only the OS
>>> can do that...
>>
>> "Three successive generations of Azul's Vega series systems relied on
>> custom multi-core processors and a custom OS kernel to deliver both the
>> scale and features needed to support Pauseless GC. In 2010, Azul
>> released its first software-only commercial implementation of C4 for
>> modern commodity X86 hardware, using Linux kernel enhancements to
>> support the required feature set."
>
> Oh, wait - you have to run a customised OS kernel for it to work? Yeah,
> OK, that explains it then...
You HAD to run a customised OS kernel for it to work.
If I understand it correctly, modern CPUs and modern Linux kernels
already include all the necessary "customizations".
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> The only problem with that, of course, is that paging is controlled by
>> the operating system, not by a user-level application program.
>
> Yes, of course. That's also why virtual machines are mind-bogglingly
> slow and/or rely on specially patched OSes. Rrrright.
>
> Andy, wake up.
You say that, but last time I tried to do virtualisation on Linux, it
/did/ actually require loading a special kernel module. (Which is
presumably why it didn't work when I tried it...)
No idea how it works in Windows.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 8/12/2012 13:35, Orchid Win7 v1 wrote:
> The only problem with that, of course, is that paging is controlled by the
> operating system, not by a user-level application program.
Not in this system. I believe Linux now has a hack in it that lets you get
first dibs on page faults.
> And you're claiming you had 100x more than that IN RAM? Somehow, I doubt it.
Yep. And the room the box was in was full of mainframes, including three
tape carousels that held 2.5TB each. You've just never worked for a company
with enough money to buy stuff.
--
Darren New, San Diego CA, USA (PST)
"Oh no! We're out of code juice!"
"Don't panic. There's beans and filters
in the cabinet."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 13/08/2012 03:54 PM, Darren New wrote:
> On 8/12/2012 13:35, Orchid Win7 v1 wrote:
>> The only problem with that, of course, is that paging is controlled by
>> the
>> operating system, not by a user-level application program.
>
> Not in this system. I believe Linux now has a hack in it that lets you
> get first dibs on page faults.
Hmm, OK.
>> And you're claiming you had 100x more than that IN RAM? Somehow, I
>> doubt it.
>
> Yep. And the room the box was in was full of mainframes, including three
> tape carousels that held 2.5TB each. You've just never worked for a
> company with enough money to buy stuff.
So you're saying that the fact that British Telecom plc could only
afford 25.2GB of spinning disk for a mission-critical system means that
they're "not big enough" to play with the Big Boys? :-P
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 13.08.2012 18:09, schrieb Orchid Win7 v1:
> So you're saying that the fact that British Telecom plc could only
> afford 25.2GB of spinning disk for a mission-critical system means that
> they're "not big enough" to play with the Big Boys? :-P
Heck, maybe they didn't need more.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 8/13/2012 9:09, Orchid Win7 v1 wrote:
> So you're saying that the fact that British Telecom plc could only afford
> 25.2GB of spinning disk for a mission-critical system means that they're
> "not big enough" to play with the Big Boys? :-P
I don't know. AT&T had five major databases (and bunches of minor ones) the
smallest of which was 300TB.
EDS (the mainframe room I'm talking about) processes pretty much every
credit card in the USA and many internationally. So, yes.
How many power companies did BT get their power from? Was it
mission-critical enough that if one of the power plants exploded, they'd
still be online?
--
Darren New, San Diego CA, USA (PST)
"Oh no! We're out of code juice!"
"Don't panic. There's beans and filters
in the cabinet."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> So you're saying that the fact that British Telecom plc could only afford
>> 25.2GB of spinning disk for a mission-critical system means that they're
>> "not big enough" to play with the Big Boys? :-P
> How many power companies did BT get their power from? Was it
> mission-critical enough that if one of the power plants exploded, they'd
> still be online?
It wasn't /that/ mission-critical. It was only their fault-reporting
database, not one of the actual call routine systems or anything like that.
Still, if it's as trivial as you claim to have multiple TB of RAM back
in 1995, why didn't they do that?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 14.08.2012 10:35, schrieb Invisible:
>>> So you're saying that the fact that British Telecom plc could only
>>> afford
>>> 25.2GB of spinning disk for a mission-critical system means that they're
>>> "not big enough" to play with the Big Boys? :-P
>
>> How many power companies did BT get their power from? Was it
>> mission-critical enough that if one of the power plants exploded, they'd
>> still be online?
>
> It wasn't /that/ mission-critical. It was only their fault-reporting
> database, not one of the actual call routine systems or anything like that.
>
> Still, if it's as trivial as you claim to have multiple TB of RAM back
> in 1995, why didn't they do that?
The claim was about hundreds of GB, not TB. It sure as hell wasn't
available for a dollar and a dime. But it was /possible/ and could be
obtained... for money.
Why on earth would a company (or government-funded institution for that
matter) spend even a single /penny/ to pimp their equipment beyond what
they actually /need/?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 2012-08-14 04:35, Invisible a écrit :
>>> So you're saying that the fact that British Telecom plc could only
>>> afford
>>> 25.2GB of spinning disk for a mission-critical system means that they're
>>> "not big enough" to play with the Big Boys? :-P
>
>> How many power companies did BT get their power from? Was it
>> mission-critical enough that if one of the power plants exploded, they'd
>> still be online?
>
> It wasn't /that/ mission-critical. It was only their fault-reporting
> database, not one of the actual call routine systems or anything like that.
>
> Still, if it's as trivial as you claim to have multiple TB of RAM back
> in 1995, why didn't they do that?
Because they didn't need to.
If their fault reporting system was able to run just fine on a system
using 1 raid array of 4GB disks, there was no need to have it run on a
more powerful system. (Side note: the PC I bought in 99 had a 20GB HD,
so those 4.2GB disks were probably already a few years old.)
Also, 128GB is not multiple TB.
--
/*Francois Labreque*/#local a=x+y;#local b=x+a;#local c=a+b;#macro P(F//
/* flabreque */L)polygon{5,F,F+z,L+z,L,F pigment{rgb 9}}#end union
/* @ */{P(0,a)P(a,b)P(b,c)P(2*a,2*b)P(2*b,b+c)P(b+c,<2,3>)
/* gmail.com */}camera{orthographic location<6,1.25,-6>look_at a }
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Tue, 14 Aug 2012 09:35:48 +0100, Invisible wrote:
> Still, if it's as trivial as you claim to have multiple TB of RAM back
> in 1995, why didn't they do that?
I don't think anyone said it was "trivial" - just "possible".
Neither of those implies "cheap" or "desirable in all circumstances"
either.
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> Still, if it's as trivial as you claim to have multiple TB of RAM back
>> in 1995, why didn't they do that?
>
> I don't think anyone said it was "trivial" - just "possible".
>
> Neither of those implies "cheap" or "desirable in all circumstances"
> either.
I said "why would you want a 140GB heap when it's impossible to have
that much RAM?"
And everyone was like "OMG, are you kidding? Of COURSE you can have
hundreds of GB of RAM. EVERYBODY does this ALL THE TIME for EVERYTHING!
If your company doesn't do this then they're just being cheap."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 14.08.2012 23:03, schrieb Orchid Win7 v1:
> I said "why would you want a 140GB heap when it's impossible to have
> that much RAM?"
>
> And everyone was like "OMG, are you kidding? Of COURSE you can have
> hundreds of GB of RAM.
Yes, everyone was like that indeed.
> EVERYBODY does this ALL THE TIME for EVERYTHING!
No, nobody was like that.
Your question was based on the presumption that "it's impossible to have
that much RAM"; everyone disagreed with that presumption and told you
so, and examples were given that proved it wrong.
> If your company doesn't do this then they're just being cheap."
Well, actually everyone was like "If your company doesn't do this it
doesn't mean a thing; there may be other reasons than outright
impossibility."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Tue, 14 Aug 2012 22:03:49 +0100, Orchid Win7 v1 wrote:
>>> Still, if it's as trivial as you claim to have multiple TB of RAM back
>>> in 1995, why didn't they do that?
>>
>> I don't think anyone said it was "trivial" - just "possible".
>>
>> Neither of those implies "cheap" or "desirable in all circumstances"
>> either.
>
> I said "why would you want a 140GB heap when it's impossible to have
> that much RAM?"
>
> And everyone was like "OMG, are you kidding? Of COURSE you can have
> hundreds of GB of RAM. EVERYBODY does this ALL THE TIME for EVERYTHING!
> If your company doesn't do this then they're just being cheap."
No, I don't think anyone responded that way.
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 2012-08-14 17:03, Orchid Win7 v1 a écrit :
>>> Still, if it's as trivial as you claim to have multiple TB of RAM back
>>> in 1995, why didn't they do that?
>>
>> I don't think anyone said it was "trivial" - just "possible".
>>
>> Neither of those implies "cheap" or "desirable in all circumstances"
>> either.
>
> I said "why would you want a 140GB heap when it's impossible to have
> that much RAM?"
>
> And everyone was like "OMG, are you kidding? Of COURSE you can have
> hundreds of GB of RAM. EVERYBODY does this ALL THE TIME for EVERYTHING!
> If your company doesn't do this then they're just being cheap."
[Citation required]
--
/*Francois Labreque*/#local a=x+y;#local b=x+a;#local c=a+b;#macro P(F//
/* flabreque */L)polygon{5,F,F+z,L+z,L,F pigment{rgb 9}}#end union
/* @ */{P(0,a)P(a,b)P(b,c)P(2*a,2*b)P(2*b,b+c)P(b+c,<2,3>)
/* gmail.com */}camera{orthographic location<6,1.25,-6>look_at a }
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
